Object-Oriented Programming — The trillion dollar disaster
-
The bad thing with Functional Programming is: it is harder to grasp than Object-Oriented Programming. And most people actually fail with the basic ideas of OOP (e.g. SOLID)... Writing "
class" on top of a bunch of lines of code is NOT OOP, but many people think so.Oh sanctissimi Wilhelmus, Theodorus, et Fredericus!
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.
-
BillWoodruff wrote:
the article has reinforced my preexisting curiosity about what's so cool about FP
Recently I read Manning | Functional Programming in C#[^] which I found a great introduction. Not theory driven like Seemann's blog From design patterns to category theory[^] but more oriented to normal programming tasks. Still I have to get some more understanding of the Functional Paradigma, but that was a good start.
Oh sanctissimi Wilhelmus, Theodorus, et Fredericus!
Thanks, Bernhard; if you recommend it, I will read it :) I have "Real World Functional Programming: With Examples in F# and C#" by Tomas Petricek, Jon Skeet [^] waiting for my one-good-eyeball-to-screen ration :omg: Manning's site touts the book with this quote:
Quote:
From the Foreword: You will never look at your code in the same way again. Mads Torgersen, C# PM, Microsoft
cheers, Bill
«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 bad thing with Functional Programming is: it is harder to grasp than Object-Oriented Programming. And most people actually fail with the basic ideas of OOP (e.g. SOLID)... Writing "
class" on top of a bunch of lines of code is NOT OOP, but many people think so.Oh sanctissimi Wilhelmus, Theodorus, et Fredericus!
I tend to think of OOP as a Platonic philosophy, a way to express "ideal/pure Forms" and their inclusive/exclusive/hierarchical relations. I really like SOLID as an Aristotelian "techne," a set of principles for how to structure the creation, use, interaction, of the (necessarily imperfect !) instances of those "Forms." While I see OOP as the best way to model hierarchies, I (currently) wonder how suited it is to typical modern multi-threaded apps driven by asynchronous events ... where any damn thing can happen any damn time :omg: Is it "right" to indict OOP with the charge of criminal mutability of state ... rather than indict the programmer who does not control access/mutability using the provided tools, such as ... in C# ... Linq, System.Collections.Immutable, and such pedestrian access modifiers as 'readonly ?
«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:
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!