Object-Oriented Programming — The trillion dollar disaster
-
A bunch of opinions but nothing to back it up. Hilarious. I get this a lot from people who don't really get OOP.
#SupportHeForShe Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
-
Functional programming: 1. Is older than object-oriented programming 2. Is well-known and well-practiced in academic settings, where people first learn programming 3. Has been constantly pushed for the past four decades to become mainstream for enterprise development 4. Has official support in both the Java and .NET ecosystems 5. Still only manages to be used as a side technology for special cases Horse-and-car = Wrong analogy.
-
Tl;dr I don't understand OOP and am paid by the word to whine about something, so the OOP windmill it is.
-
Quote:
There’s no objective and open evidence that OOP is better than plain procedural programming.
Ha ha ha! Ha ha ha ha! Ha ha! Ha ha ha ha! Ha! Ha ha! Ha ha! Ha ha ha! Ha ha ha ha ha ha ha ha ha! Ha ha! Ha ha ha ha. Ha! Sorry, this guy's an idiot. I've seen C code. I've seen C++ code. C++ took what was going to be a thousand-plus-line C function and made it into two-hundred, through the magic of virtual functions. It was so much easier to understand the logic it wasn't even funny. tldr - wouldn't hire Ilya Suzdalnitski for any coding needs.
-
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