Object-Oriented Programming — The trillion dollar disaster
-
And for a real question, after my initial laugh. I've read several intros to functional programming. Nothing I've read answers the question, "How do real-world functional programs handle changes to huge-size data-blocks without clobbering memory?" In other words, say you create a word processor. The functional programming explanations I've seen indicate you have a 'document' in memory that might be 2 MB. If you add a letter to the document via a keystroke, in order to keep it immutable, you need to generate an entirely new 2 MB block with the added character, which becomes the 'new' document. The program always updates to that 'new' document, in order to eliminate mutability. Something has to be wrong with my understanding, because if that is the case functional programming cannot handle real-world word processors and other editing chores because it will just start shuffling around huge blocks of memory, trashing the cache and becoming slow as dog poo in snow.
-
Had the author met Booch, Rumbaugh and Jacobson twenty five years ago, she would have had a different opinion.
-
And for a real question, after my initial laugh. I've read several intros to functional programming. Nothing I've read answers the question, "How do real-world functional programs handle changes to huge-size data-blocks without clobbering memory?" In other words, say you create a word processor. The functional programming explanations I've seen indicate you have a 'document' in memory that might be 2 MB. If you add a letter to the document via a keystroke, in order to keep it immutable, you need to generate an entirely new 2 MB block with the added character, which becomes the 'new' document. The program always updates to that 'new' document, in order to eliminate mutability. Something has to be wrong with my understanding, because if that is the case functional programming cannot handle real-world word processors and other editing chores because it will just start shuffling around huge blocks of memory, trashing the cache and becoming slow as dog poo in snow.
David O'Neil wrote:
In other words, say you create a word processor. The functional programming explanations I've seen indicate you have a 'document' in memory that might be 2 MB. If you add a letter to the document via a keystroke, in order to keep it immutable, you need to generate an entirely new 2 MB block with the added character, which becomes the 'new' document. The program always updates to that 'new' document, in order to eliminate mutability.
One way might be to divide the document into smaller portions (e.g. paragraphs), each immutable, and a list of paragraphs. Updating a keystroke would then consist of (a) making a new copy of the paragraph, and (b) making a new copy of the list, which points to the new paragraph. Nowhere does it say that all the data in a functional program must consist of a single block.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
-
And for a real question, after my initial laugh. I've read several intros to functional programming. Nothing I've read answers the question, "How do real-world functional programs handle changes to huge-size data-blocks without clobbering memory?" In other words, say you create a word processor. The functional programming explanations I've seen indicate you have a 'document' in memory that might be 2 MB. If you add a letter to the document via a keystroke, in order to keep it immutable, you need to generate an entirely new 2 MB block with the added character, which becomes the 'new' document. The program always updates to that 'new' document, in order to eliminate mutability. Something has to be wrong with my understanding, because if that is the case functional programming cannot handle real-world word processors and other editing chores because it will just start shuffling around huge blocks of memory, trashing the cache and becoming slow as dog poo in snow.
The following is from the Roslyn code base, but does illustrate the kind of data structures involved... [Roslyn and my favorite persistent data structure – Alex Polozov](https://alexpolozov.com/blog/roslyn-and-my-favorite-persistent-data-structure/)
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
-
The following is from the Roslyn code base, but does illustrate the kind of data structures involved... [Roslyn and my favorite persistent data structure – Alex Polozov](https://alexpolozov.com/blog/roslyn-and-my-favorite-persistent-data-structure/)
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
interesting link. Thanks
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
-
I agree with him on many of his OOP criticisms. Truth to tell, with the benefit of hindsight, every OS, every framework, every language would be different to the ones we use. The sad reality, though, is that we now live in a world of (often huge and clunky) objects and that's the world that we have to interact with; so even if we write our bits in an object-free way, there's still going to be a whole ton of boxing and unboxing to be done in the middleware whenever we need to talk to something else. We simply can't be entirely object free in an object-obsessed world. Coders, in retrospect, probably did embrace OO with too much enthusiasm and we're quite possibly about to see a generation dive done the FP rabbit-hole with the same blind devotion and similarly mixed results.
Whenever you find yourself on the side of the majority, it is time to pause and reflect. - Mark Twain
-
David O'Neil wrote:
In other words, say you create a word processor. The functional programming explanations I've seen indicate you have a 'document' in memory that might be 2 MB. If you add a letter to the document via a keystroke, in order to keep it immutable, you need to generate an entirely new 2 MB block with the added character, which becomes the 'new' document. The program always updates to that 'new' document, in order to eliminate mutability.
One way might be to divide the document into smaller portions (e.g. paragraphs), each immutable, and a list of paragraphs. Updating a keystroke would then consist of (a) making a new copy of the paragraph, and (b) making a new copy of the list, which points to the new paragraph. Nowhere does it say that all the data in a functional program must consist of a single block.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
Thank you.
-
The following is from the Roslyn code base, but does illustrate the kind of data structures involved... [Roslyn and my favorite persistent data structure – Alex Polozov](https://alexpolozov.com/blog/roslyn-and-my-favorite-persistent-data-structure/)
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
Thank you.
-
That's a lot of words and claims but I'm still trying to find actual examples, especially in the "Real world examples, please!" sections. In any case Beta was better than VHS and JavaScript will end up ruling the world.
cheers Chris Maunder
-
My comment on the article posted to the site:
Quote:
A gigantic cauldron of boiling spew delivered with the fervent self-righteousness of the true believer who has seen the Light (Erlang). A symphony of anger with hyperbole at top volume in crescendo after crescendo. yawn …
I wonder if they will delete it ? I will admit that the article has reinforced my preexisting curiosity about what's so cool about FP. I already write code in C# that generates functions based on generic templates (not using reflection, or building Expressions), code that allows chaining of generic functions, merging, etc. Hopefully, I will locate some sober authors.
«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
-
My comment on the article posted to the site:
Quote:
A gigantic cauldron of boiling spew delivered with the fervent self-righteousness of the true believer who has seen the Light (Erlang). A symphony of anger with hyperbole at top volume in crescendo after crescendo. yawn …
I wonder if they will delete it ? I will admit that the article has reinforced my preexisting curiosity about what's so cool about FP. I already write code in C# that generates functions based on generic templates (not using reflection, or building Expressions), code that allows chaining of generic functions, merging, etc. Hopefully, I will locate some sober authors.
«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
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!
-
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 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