SERVING THE QUANTITATIVE FINANCE COMMUNITY

  • 1
  • 2
  • 3
  • 4
  • 5
  • 12
 
User avatar
Cuchulainn
Posts: 59702
Joined: July 16th, 2004, 7:38 am
Location: Amsterdam
Contact:

Grammar-Pattern Programmers: Is Over-Abstraction Delivering Projects Faster Or Slower?

April 10th, 2016, 3:32 pm

What about egoless programming?
 
User avatar
Cuchulainn
Posts: 59702
Joined: July 16th, 2004, 7:38 am
Location: Amsterdam
Contact:

Grammar-Pattern Programmers: Is Over-Abstraction Delivering Projects Faster Or Slower?

April 10th, 2016, 4:02 pm

Another issue IMO is much programming work is programming in the smallWe miss the forest for the trees?The classic problem is 'inheriting' an undocumented C++ class library, 6 deep with multiple inheritance.
Last edited by Cuchulainn on April 9th, 2016, 10:00 pm, edited 1 time in total.
 
User avatar
Traden4Alpha
Posts: 23951
Joined: September 20th, 2002, 8:30 pm

Grammar-Pattern Programmers: Is Over-Abstraction Delivering Projects Faster Or Slower?

April 11th, 2016, 1:59 pm

QuoteOriginally posted by: CuchulainnWhat about egoless programming?Looks like psychobabble to me. Moreover I doubt it works on heterogeneous problems or in heterogeneous groups in which most people's ideas about most things are crap but each person's ideas about some things are correct.
 
User avatar
Cuchulainn
Posts: 59702
Joined: July 16th, 2004, 7:38 am
Location: Amsterdam
Contact:

Grammar-Pattern Programmers: Is Over-Abstraction Delivering Projects Faster Or Slower?

April 11th, 2016, 2:04 pm

QuoteOriginally posted by: Traden4AlphaQuoteOriginally posted by: CuchulainnWhat about egoless programming?Looks like psychobabble to me. Moreover I doubt it works on heterogeneous problems or in heterogeneous groups in which most people's ideas about most things are crap but each person's ideas about some things are correct.But you know how developers ... charmed by their own inventions. You see it when you let one talk in front of an audience. Nowadays we has Scrum and Agile, yes?
Last edited by Cuchulainn on April 10th, 2016, 10:00 pm, edited 1 time in total.
 
User avatar
Traden4Alpha
Posts: 23951
Joined: September 20th, 2002, 8:30 pm

Grammar-Pattern Programmers: Is Over-Abstraction Delivering Projects Faster Or Slower?

April 11th, 2016, 2:13 pm

QuoteOriginally posted by: CuchulainnAnother issue IMO is much programming work is programming in the smallWe miss the forest for the trees?The classic problem is 'inheriting' an undocumented C++ class library, 6 deep with multiple inheritance.Indeed! Over-encapsulation and over-layering create rat-holes filled with bugs and unexpected behavior. The challenge is in balancing the KISS principle at the level of lines of code per module versus numbers of modules in the total system. Sometimes the solution really does require some complexity -- the devil in the details may require some fiendish code.
 
User avatar
Cuchulainn
Posts: 59702
Joined: July 16th, 2004, 7:38 am
Location: Amsterdam
Contact:

Grammar-Pattern Programmers: Is Over-Abstraction Delivering Projects Faster Or Slower?

April 11th, 2016, 2:24 pm

QuoteOriginally posted by: Traden4AlphaQuoteOriginally posted by: CuchulainnAnother issue IMO is much programming work is programming in the smallWe miss the forest for the trees?The classic problem is 'inheriting' an undocumented C++ class library, 6 deep with multiple inheritance.Indeed! Over-encapsulation and over-layering create rat-holes filled with bugs and unexpected behavior. The challenge is in balancing the KISS principle at the level of lines of code per module versus numbers of modules in the total system. Sometimes the solution really does require some complexity -- the devil in the details may require some fiendish code.But how to KISS? Really, really, really?
 
User avatar
Traden4Alpha
Posts: 23951
Joined: September 20th, 2002, 8:30 pm

Grammar-Pattern Programmers: Is Over-Abstraction Delivering Projects Faster Or Slower?

April 11th, 2016, 2:40 pm

QuoteOriginally posted by: CuchulainnQuoteOriginally posted by: Traden4AlphaQuoteOriginally posted by: CuchulainnWhat about egoless programming?Looks like psychobabble to me. Moreover I doubt it works on heterogeneous problems or in heterogeneous groups in which most people's ideas about most things are crap but each person's ideas about some things are correct.But you know how developers ... charmed by their own inventions. You see it when you let one talk in front of an audience. Nowadays we has Scrum and Agile, yes?So true!Part of the rationale for Scrum & Agile is for systems where the requirements are uncertain or fluid. I've seen a lot of Scrum/Agile being used in startups where no one really knows exactly what the system must do so they try to create some kind of demo and iterate. It's 100% trial-and-error rather than top-down rational design from a set of well-formed requirements.I'd also think that some of these social/group approaches to programming work well with teams of mediocre programmers. It's like the human brain -- each neuron is pretty stupid and incapable of solving anything, but if one networks them together then things get done.But all of this it orthogonal to the grammar-pattern or loopers vs. algies issue which seems to correlation to intrinsic styles of thinking.
 
User avatar
Traden4Alpha
Posts: 23951
Joined: September 20th, 2002, 8:30 pm

Grammar-Pattern Programmers: Is Over-Abstraction Delivering Projects Faster Or Slower?

April 11th, 2016, 3:01 pm

QuoteOriginally posted by: CuchulainnQuotehttps://atilanevesoncode.wordpress.com/2015/06/08/the-loopers-and-the-algies/I'm speechless.This is exactly what I am talking about.If you have N programmers each write some "good" code and then show each programmer's output to the other programmers, then some of the other programmers will agree the code is "good" and some of the programmers will disagree. The loopers don't like the algies' code and the algies don't like the loopers' code.It's like Sapir-Worf except that everyone is using the same language but using it is such different ways that it is as if they were using two different languages.
 
User avatar
Traden4Alpha
Posts: 23951
Joined: September 20th, 2002, 8:30 pm

Grammar-Pattern Programmers: Is Over-Abstraction Delivering Projects Faster Or Slower?

April 11th, 2016, 3:06 pm

QuoteOriginally posted by: CuchulainnQuoteOriginally posted by: Traden4AlphaQuoteOriginally posted by: CuchulainnAnother issue IMO is much programming work is programming in the smallWe miss the forest for the trees?The classic problem is 'inheriting' an undocumented C++ class library, 6 deep with multiple inheritance.Indeed! Over-encapsulation and over-layering create rat-holes filled with bugs and unexpected behavior. The challenge is in balancing the KISS principle at the level of lines of code per module versus numbers of modules in the total system. Sometimes the solution really does require some complexity -- the devil in the details may require some fiendish code.But how to KISS? Really, really, really?Really.It's KISS in the sense of: does one minimize the number of lines of code per module (the "simple modules" strategy) or does one minimize the total number of modules (the "simple architecture" strategy).
 
User avatar
Cuchulainn
Posts: 59702
Joined: July 16th, 2004, 7:38 am
Location: Amsterdam
Contact:

Grammar-Pattern Programmers: Is Over-Abstraction Delivering Projects Faster Or Slower?

April 11th, 2016, 3:10 pm

QuoteOriginally posted by: Traden4AlphaQuoteOriginally posted by: CuchulainnQuoteOriginally posted by: Traden4AlphaQuoteOriginally posted by: CuchulainnAnother issue IMO is much programming work is programming in the smallWe miss the forest for the trees?The classic problem is 'inheriting' an undocumented C++ class library, 6 deep with multiple inheritance.Indeed! Over-encapsulation and over-layering create rat-holes filled with bugs and unexpected behavior. The challenge is in balancing the KISS principle at the level of lines of code per module versus numbers of modules in the total system. Sometimes the solution really does require some complexity -- the devil in the details may require some fiendish code.But how to KISS? Really, really, really?Really.It's KISS in the sense of: does one minimize the number of lines of code per module (the "simple modules" strategy) or does one minimize the total number of modules (the "simple architecture" strategy).How? I mean the criteria.
 
User avatar
Traden4Alpha
Posts: 23951
Joined: September 20th, 2002, 8:30 pm

Grammar-Pattern Programmers: Is Over-Abstraction Delivering Projects Faster Or Slower?

April 11th, 2016, 3:43 pm

QuoteOriginally posted by: CuchulainnQuoteOriginally posted by: Traden4AlphaQuoteOriginally posted by: CuchulainnQuoteOriginally posted by: Traden4AlphaQuoteOriginally posted by: CuchulainnAnother issue IMO is much programming work is programming in the smallWe miss the forest for the trees?The classic problem is 'inheriting' an undocumented C++ class library, 6 deep with multiple inheritance.Indeed! Over-encapsulation and over-layering create rat-holes filled with bugs and unexpected behavior. The challenge is in balancing the KISS principle at the level of lines of code per module versus numbers of modules in the total system. Sometimes the solution really does require some complexity -- the devil in the details may require some fiendish code.But how to KISS? Really, really, really?Really.It's KISS in the sense of: does one minimize the number of lines of code per module (the "simple modules" strategy) or does one minimize the total number of modules (the "simple architecture" strategy).How? I mean the criteria.Are you asking about the criteria for simplicity?If so, there's always the old favorites of lines of code (which has many flaws) or function points. Of course, the algies and the loopers disagree on what is simple.KISS may be like beauty, art, or porn - you know it when you see it.
 
User avatar
Cuchulainn
Posts: 59702
Joined: July 16th, 2004, 7:38 am
Location: Amsterdam
Contact:

Grammar-Pattern Programmers: Is Over-Abstraction Delivering Projects Faster Or Slower?

April 11th, 2016, 3:48 pm

QuoteOriginally posted by: Traden4AlphaQuoteOriginally posted by: CuchulainnQuoteOriginally posted by: Traden4AlphaQuoteOriginally posted by: CuchulainnQuoteOriginally posted by: Traden4AlphaQuoteOriginally posted by: CuchulainnAnother issue IMO is much programming work is programming in the smallWe miss the forest for the trees?The classic problem is 'inheriting' an undocumented C++ class library, 6 deep with multiple inheritance.Indeed! Over-encapsulation and over-layering create rat-holes filled with bugs and unexpected behavior. The challenge is in balancing the KISS principle at the level of lines of code per module versus numbers of modules in the total system. Sometimes the solution really does require some complexity -- the devil in the details may require some fiendish code.But how to KISS? Really, really, really?Really.It's KISS in the sense of: does one minimize the number of lines of code per module (the "simple modules" strategy) or does one minimize the total number of modules (the "simple architecture" strategy).How? I mean the criteria.Are you asking about the criteria for simplicity?If so, there's always the old favorites of lines of code (which has many flaws) or function points. Of course, the algies and the loopers disagree on what is simple.KISS may be like beauty, art, or porn - you know it when you see it.No, I mean criteria for decomposing a system into subsystems. Simplicity is a by-product, nice to have of course.
Last edited by Cuchulainn on April 10th, 2016, 10:00 pm, edited 1 time in total.
 
User avatar
Traden4Alpha
Posts: 23951
Joined: September 20th, 2002, 8:30 pm

Grammar-Pattern Programmers: Is Over-Abstraction Delivering Projects Faster Or Slower?

April 11th, 2016, 6:23 pm

QuoteOriginally posted by: CuchulainnQuoteOriginally posted by: Traden4AlphaQuoteOriginally posted by: CuchulainnQuoteOriginally posted by: Traden4AlphaQuoteOriginally posted by: CuchulainnQuoteOriginally posted by: Traden4AlphaQuoteOriginally posted by: CuchulainnAnother issue IMO is much programming work is programming in the smallWe miss the forest for the trees?The classic problem is 'inheriting' an undocumented C++ class library, 6 deep with multiple inheritance.Indeed! Over-encapsulation and over-layering create rat-holes filled with bugs and unexpected behavior. The challenge is in balancing the KISS principle at the level of lines of code per module versus numbers of modules in the total system. Sometimes the solution really does require some complexity -- the devil in the details may require some fiendish code.But how to KISS? Really, really, really?Really.It's KISS in the sense of: does one minimize the number of lines of code per module (the "simple modules" strategy) or does one minimize the total number of modules (the "simple architecture" strategy).How? I mean the criteria.Are you asking about the criteria for simplicity?If so, there's always the old favorites of lines of code (which has many flaws) or function points. Of course, the algies and the loopers disagree on what is simple.KISS may be like beauty, art, or porn - you know it when you see it.No, I mean criteria for decomposing a system into subsystems. Simplicity is a by-product, nice to have of course.Tricky!It depends on:1. Language: decomposition is different for OOP vs. non-OOP languages (or functional vs. procedural ones).2. The OS and off-the-shelf libraries: Mandatory or convenient voluntary APIs will surely affect the atoms of the system.3. Programmer (or team) experience: As with item #2, certain structures might be easier to adopt because they already exist and are well understood.4. System covariations: One could imagine doing some kind of notional PCA on the cross-correlation matrix between all possible inputs and the set of corresponding required outputs. Highly covariant things belong together and non-covariant things may be separated.
 
User avatar
Cuchulainn
Posts: 59702
Joined: July 16th, 2004, 7:38 am
Location: Amsterdam
Contact:

Grammar-Pattern Programmers: Is Over-Abstraction Delivering Projects Faster Or Slower?

April 11th, 2016, 6:53 pm

QuoteOriginally posted by: Traden4AlphaQuoteOriginally posted by: CuchulainnQuoteOriginally posted by: Traden4AlphaQuoteOriginally posted by: CuchulainnQuoteOriginally posted by: Traden4AlphaQuoteOriginally posted by: CuchulainnQuoteOriginally posted by: Traden4AlphaQuoteOriginally posted by: CuchulainnAnother issue IMO is much programming work is programming in the smallWe miss the forest for the trees?The classic problem is 'inheriting' an undocumented C++ class library, 6 deep with multiple inheritance.Indeed! Over-encapsulation and over-layering create rat-holes filled with bugs and unexpected behavior. The challenge is in balancing the KISS principle at the level of lines of code per module versus numbers of modules in the total system. Sometimes the solution really does require some complexity -- the devil in the details may require some fiendish code.But how to KISS? Really, really, really?Really.It's KISS in the sense of: does one minimize the number of lines of code per module (the "simple modules" strategy) or does one minimize the total number of modules (the "simple architecture" strategy).How? I mean the criteria.Are you asking about the criteria for simplicity?If so, there's always the old favorites of lines of code (which has many flaws) or function points. Of course, the algies and the loopers disagree on what is simple.KISS may be like beauty, art, or porn - you know it when you see it.No, I mean criteria for decomposing a system into subsystems. Simplicity is a by-product, nice to have of course.Tricky!It depends on:1. Language: decomposition is different for OOP vs. non-OOP languages (or functional vs. procedural ones).2. The OS and off-the-shelf libraries: Mandatory or convenient voluntary APIs will surely affect the atoms of the system.3. Programmer (or team) experience: As with item #2, certain structures might be easier to adopt because they already exist and are well understood.4. System covariations: One could imagine doing some kind of notional PCA on the cross-correlation matrix between all possible inputs and the set of corresponding required outputs. Highly covariant things belong together and non-covariant things may be separated.David Parnas ..QuoteWe have tried to demonstrate by these examples thatit is almost always incorrect to begin the decompositionof a system into modules on the basis of a flowchart.We propose instead that one begins with a list ofdifficult design decisions or design decisions which arelikely to change. Each module is then designed to hidesuch a decision from the others. Since, in most cases,design decisions transcend time of execution, moduleswill not correspond to steps in the processing. Toachieve an efficient implementation we must abandonthe assumption that a module is one or more subroutines,and instead allow subroutines and programsto be assembled collections of code from variousmodules.Received August 1971; revisedInformation Hiding, really.Another criterion is potential concurrency (just think of a graphics hidden surface removal/renderer pipeline).
Last edited by Cuchulainn on April 10th, 2016, 10:00 pm, edited 1 time in total.
 
User avatar
Polter
Posts: 2526
Joined: April 29th, 2008, 4:55 pm

Grammar-Pattern Programmers: Is Over-Abstraction Delivering Projects Faster Or Slower?

April 12th, 2016, 5:00 pm

An interesting talk in this context (Lie #2: Code designed around model of the world):Three Big Lies: Typical Design Failures in Game Programming: http://www.gdcvault.com/play/1012200/Th ... es2010.pdf
ABOUT WILMOTT

PW by JB

Wilmott.com has been "Serving the Quantitative Finance Community" since 2001. Continued...


Twitter LinkedIn Instagram

JOBS BOARD

JOBS BOARD

Looking for a quant job, risk, algo trading,...? Browse jobs here...


GZIP: On