|
Why it’s time to move on from OOP "OOPs!...I did it again"
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
Had the author met Booch, Rumbaugh and Jacobson twenty five years ago, she would have had a different opinion.
|
|
|
|
|
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
|
|
|
|
|
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
modified 26-Jul-19 4:48am.
|
|
|
|
|
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
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!
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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
«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 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.
|
|
|
|