Evidence points to OOP being bullshit (2013)
content.pivotal.io
content.pivotal.io
Object Oriented Programming got to the level of "McDojo" martial arts practice. A minority of people learned the essence. The majority got to hang out with people spouting the same ideology, went through the same motions, and felt good about socializing while circle jerking together. So on the whole, it's accurate to say that OOP was oversold, in much the same way that martial arts was oversold. There was some calisthenic benefit, but not much more than that.
So what makes Functional Programming any different? I'm not so sure if anything can't turn out to be just a structured way of writing spaghetti code. Most writing is meh, and deserves to be eventually forgotten. Most music is meh, and deserves to be eventually forgotten.
Sturgeon's Law: 90% of everything is shite.
It prevents bad programmers to fall into messy OOP.
Languages are less about readability and features, but always about what it allows the programmer to do, so that it prevents him for writing bad code.
I came with the idea that a programming language is a frame that surrounds the programmer, and only allows him to do things in a certain way that is tolerable and not abusive in term of design.
I'm not a fan of rust, but all the ckecks rust is doing, are very rigid, yet it is exactly what I am talking about: you help the programmer to avoid doing things he might regret and not know about.
You can write bad engineering student FORTRAN code in any language. I've seen it done in Smalltalk. In all fairness, most functional languages make this painful enough, that all but the dimmest don't bother.
I came with the idea that a programming language is a frame that surrounds the programmer, and only allows him to do things in a certain way that is tolerable and not abusive in term of design.
That's bankrupt. The best you can really do is to encourage and reward the programmer for doing it the right way. If you earnestly try to block every way of doing something bad, you just wind up with a system that's unusable.
Aka "the Wirth school of non-programming".
There's an easier way to do that: just don't program.
FP encourages taking immutability to the extreme which makes your project a comedy if finished.
Break apart an FP program and you have great general purpose libraries.
Break apart an OOP project and you have a splitting headache.
(Now that JS has classes and frameworks like angular are adopting them I think it is dangerous to flag this article and the related opinions like mine as things people shouldn't hear because they are negative.. A lot of self trained programmers are about to think they are bad programmers because there is a bad feature being adopted.)
Taking one of the most absurd features (COME FROM [1][2]) from a programming language satire (Intercal [3]) and making that your composition mechanism is...special. And then complaining about Java OOP while quoting Alan Kay, as other posters mentioned.
[1] https://en.wikipedia.org/wiki/Aspect-oriented_programming#Cr...
[2] https://en.wikipedia.org/wiki/COMEFROM
[3] https://en.wikipedia.org/wiki/Esoteric_programming_language
http://www.cs.ubc.ca/~gregor/papers/kiczales-ECOOP1997-AOP.p...
Many programmers moved from imperative programming to structured programming to object oriented programming (a form of structured programming), and some of them perceived benefits while others didn't. This is some paradigms work better with different requirements.
Any paradigm can be used to implement unmaintainable spaghetti. Don't blame the paradigm.
I'd like to see someone try to make a decent game (including frontend) with Erlang, Haskell or Scala.
Sometimes you need to separate state into different objects and let those objects manage their own internal state otherwise the code becomes overly complex. OOP was invented specifically to support this kind of isolation. Yes, sometimes OOP makes it more difficult to follow the flow of logic but once you understand the structure and core components of the system, it's much easier to make non-breaking changes and additions to the code.
This article is just regurgitating FP rhetoric and preaching FP as a silver bullet.
Where it has not worked so well: Web-backend programming. To me OOP has always felt out of place there.
I don't really understand why functional programmers bash on OOP so much. If you code up a bunch of immutable objects with methods that return changed versions, you're now a functional object-oriented programmer. It's a pretty nice paradigm! It beats the hell out of "everything is a list" and car/cdr is your hammer.
Yeah, a lot of Java programmers fail to grok immutability and irritate us with wordy half-measures like builder patterns. On the other hand, the stream api allows you to write code that looks reasonably close to the clojure-equivalent -- perhaps a bit more verbose, but at least it's typesafe. If you want more concise there's Varvr. This is more of a culture problem than a language problem.
Essentially they have invested in huge blocks of take it or leave it nonsense similar to the banana quote in the article.
I get the same general feeling from FP OO as normal classical OO. There seems to be a need for a hierarchy in parts of base type systems and other standard library pieces, but once some framework layer declares a class to be extended you just have bug after bug that all relate to an imaginary hierarchies invented because everyone needed to provide a nail for the OO hammer.
Personally, I'm much happier with interfaces that rely on a duck style to implicitly define types with implementors. I find it sad that some older languages are reimplementing classes when it seems like newer ones have correctly moved on to no unique relationship hierarchies in general code.
I just wish it was just faster to compile sigh.
Reprimand me for doing the thing I am doing without providing tools or guidance on how to change, you have a new enemy.
they tend to follow whatever is bright and shiny without truly understanding why they even need it.