Object-Oriented Programming — The trillion dollar disaster
-
The worst thing about functional programming is its poor resilience to non-ideal development situations. When large organizations maintain code over long periods of time, non-ideal practices constantly leak in. Hurried developers updating confusing code may be bad for object-oriented code bases but is horrible-to-fatal for functional-style code.
jesarg wrote:
non-ideal development situations
I've never known any other type.
«Where is the Life we have lost in living? Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information?» T. S. Elliot
-
The worst thing about functional programming is its poor resilience to non-ideal development situations. When large organizations maintain code over long periods of time, non-ideal practices constantly leak in. Hurried developers updating confusing code may be bad for object-oriented code bases but is horrible-to-fatal for functional-style code.
jesarg wrote:
When large organizations maintain code over long periods of time, non-ideal practices constantly leak in. Hurried developers updating confusing code may be bad for object-oriented code bases but is horrible-to-fatal for functional-style code.
I would appreciate hearing about a specific case of this you have seen. What type of change to code unique to FP would cause problems that would not be flagged at compile time ?
«Where is the Life we have lost in living? Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information?» T. S. Elliot
-
jesarg wrote:
When large organizations maintain code over long periods of time, non-ideal practices constantly leak in. Hurried developers updating confusing code may be bad for object-oriented code bases but is horrible-to-fatal for functional-style code.
I would appreciate hearing about a specific case of this you have seen. What type of change to code unique to FP would cause problems that would not be flagged at compile time ?
«Where is the Life we have lost in living? Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information?» T. S. Elliot
The first developer writes code. The second developer updates the code, despite slightly misunderstanding the first developer's code, making the resulting code confusing and prone to bugs. The third developer updates the code, while slightly misunderstanding the first developer's code, the second developer's code, and the second developer's misunderstanding of the first developer's code, making the resulting code more confusing and bug-prone. The fourth developer updates the code, seriously misunderstanding the first developer's code, the second developer's code, the third developer's code, the second developer's misunderstanding of the first developer's code, the third developer's misunderstanding of the first developer's code, the third developer's misunderstanding of the second developer's code, and the third developer's misunderstanding of the second developer's misunderstanding of the first developer's code. Etc. until maintenance is impossible, bugs never get fixed, and rewrites are demanded. This problem isn't unique to functional programming, but using a functional style amplifies the compounding negative effects (which is why start-ups have success stories of using functional languages and large organizations don't). When using more procedural styles, the negative side effects of not fully understanding the code being updated are lower. You can read about project successes and failures with LISP; they don't specifically mention the effect I described, but they seem to have experienced it nonetheless. http://www.paulgraham.com/avg.html https://www.quora.com/Does-Yahoo-Stores-previously-Viaweb-still-use-Lisp https://discuss.fogcreek.com/joelonsoftware/default.asp?cmd=show&ixPost=31402
-
The first developer writes code. The second developer updates the code, despite slightly misunderstanding the first developer's code, making the resulting code confusing and prone to bugs. The third developer updates the code, while slightly misunderstanding the first developer's code, the second developer's code, and the second developer's misunderstanding of the first developer's code, making the resulting code more confusing and bug-prone. The fourth developer updates the code, seriously misunderstanding the first developer's code, the second developer's code, the third developer's code, the second developer's misunderstanding of the first developer's code, the third developer's misunderstanding of the first developer's code, the third developer's misunderstanding of the second developer's code, and the third developer's misunderstanding of the second developer's misunderstanding of the first developer's code. Etc. until maintenance is impossible, bugs never get fixed, and rewrites are demanded. This problem isn't unique to functional programming, but using a functional style amplifies the compounding negative effects (which is why start-ups have success stories of using functional languages and large organizations don't). When using more procedural styles, the negative side effects of not fully understanding the code being updated are lower. You can read about project successes and failures with LISP; they don't specifically mention the effect I described, but they seem to have experienced it nonetheless. http://www.paulgraham.com/avg.html https://www.quora.com/Does-Yahoo-Stores-previously-Viaweb-still-use-Lisp https://discuss.fogcreek.com/joelonsoftware/default.asp?cmd=show&ixPost=31402
So in the end it boils down to a simple point: most programmers are not capable of grasping concepts which go beyond simple procedural statements (like if or switch or assignments).
Oh sanctissimi Wilhelmus, Theodorus, et Fredericus!
-
The first developer writes code. The second developer updates the code, despite slightly misunderstanding the first developer's code, making the resulting code confusing and prone to bugs. The third developer updates the code, while slightly misunderstanding the first developer's code, the second developer's code, and the second developer's misunderstanding of the first developer's code, making the resulting code more confusing and bug-prone. The fourth developer updates the code, seriously misunderstanding the first developer's code, the second developer's code, the third developer's code, the second developer's misunderstanding of the first developer's code, the third developer's misunderstanding of the first developer's code, the third developer's misunderstanding of the second developer's code, and the third developer's misunderstanding of the second developer's misunderstanding of the first developer's code. Etc. until maintenance is impossible, bugs never get fixed, and rewrites are demanded. This problem isn't unique to functional programming, but using a functional style amplifies the compounding negative effects (which is why start-ups have success stories of using functional languages and large organizations don't). When using more procedural styles, the negative side effects of not fully understanding the code being updated are lower. You can read about project successes and failures with LISP; they don't specifically mention the effect I described, but they seem to have experienced it nonetheless. http://www.paulgraham.com/avg.html https://www.quora.com/Does-Yahoo-Stores-previously-Viaweb-still-use-Lisp https://discuss.fogcreek.com/joelonsoftware/default.asp?cmd=show&ixPost=31402
I asked you for specifics, and you come up with this ? What you describe has nothing specific to do with either OOP or FP.
«Where is the Life we have lost in living? Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information?» T. S. Elliot
-
So in the end it boils down to a simple point: most programmers are not capable of grasping concepts which go beyond simple procedural statements (like if or switch or assignments).
Oh sanctissimi Wilhelmus, Theodorus, et Fredericus!
@BHiller Or, it boils down to some programmers have a bias, a prejudice, for, or against, FP or OOP ... that they cannot articulate, or cannot describe any specific example they have actually encountered ? It is inevitable we have biases, and, it is a fact that many programmers tend to "fall in love" with their languages/tools to a certain degree, sometimes comically extreme ... I think of a hilarious encounter I had with a FORTH "messiah" in the 1970's. I like Gandhi's statement: "I want the winds of all the cultures to blow around my house, but I don't want to be knocked over by any of them." By the way, I hate VB :wtf:
«Where is the Life we have lost in living? Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information?» T. S. Elliot
-
So in the end it boils down to a simple point: most programmers are not capable of grasping concepts which go beyond simple procedural statements (like if or switch or assignments).
Oh sanctissimi Wilhelmus, Theodorus, et Fredericus!
-
The experts in functional programming run each over with messes just like the novices do. It boils down to functional programming giving people more power than they are likely to handle well.
That's true for quite any programming language/paradigm, even FORTRAN.
Oh sanctissimi Wilhelmus, Theodorus, et Fredericus!