If you're only being buzzword compliant with Object Oriented Programming, yes, you're going to have a meh experience. If you're only going so far as to be buzzword compliant with, say, buying a guitar, it's much the same. On the other hand, if you also spend some time with diligent practice and study, which the purchase of the guitar would have enabled, you may well have an extraordinary experience.
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.
> So what makes Functional Programming any different?
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.
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.
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.
OOP encourages ruining code in the small which means a theologically correct project is either good for a small class of programs that would answer a sequence of diamond problems the same or completely useless.
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.)
Isn't Pivotal responsible for the Spring (Java) framework? In that case it would make sense to trash-talk OOP for them, since Spring is widely known to take magic Java annotations to an absurd level. While OOP for things such as oauth and data binding etc. would result in slightly more verbose upfront code using just libs and light annotations, the majority of time spent in Spring/Spring Boot apps is trying to understand Spring's opinionated framework and boilerplate on Java newbie boards. Sadly, Spring has overtaken alternatives for Java developers who know what they're doing and generally exercise more mental discipline in their work.
That would be funny. If you think OOP is "bad" (I don't think it is..), let me introduce you to my friend AOP.
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.
This is old (2013). However, i think it's really ironic to talk trash about OOP while thinking in Java and pointing Alan Kay in the same post. Alan Kay being the father of OOP always made clear Java wasn't the OOPL he had in mind.
It's a bit confused alright. His first two quotes are from people who designed OO languages. (Joe Armstrong later realised that Erlang may be the only fully object oriented language, one he learned that java is not oop https://news.ycombinator.com/item?id=5205976 )
Nice link!. I should add that exist a correlation between objects and lambda calculus for functional programming. So, they are different perspectives of the same idea. And you have to take care of both perspectives.
Presenting opinions as facts is dogmatism and that is exactly what this article is.
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.
All evidence points to this article being bullshit.
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.
Pretty low-quality article, mostly just a bunch of links to other opinions. I'm used to better commentary from pivotal.
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.
My avoidance of OOP predates my use of FP like most people I know.. As imperative C programmers of old, we often had to deal with people trying to add C++ on top and then needing help.. Their projects were often months of work and a total failure because they had fractally encoded their model into how their code, data and model operate. Inevitably a few of their ideas of that model were wrong or needed to change for unexpected reasons and are encoded across all sorts of things via inheritance and method parameters.
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.
Backtracks on the title's claim in the opening sentence. Then states some basic well-known points that even advocates of OOP would agree with, even in 2013. Then neglects to suggest solutions except alluding to functional programming a couple times.
For any given paradigm, has useful software been written using that paradigm? If so, it is not "bullshit". And it's not exactly surprising that well-known academics and theoretical computer scientists smack talk Java - it's not appropriate for most number-heavy problems. For the other 99% of programmers, it does CRUD pretty well.
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.