Charles Scalfani

Joe Armstrong said that in the context of code re-usability in OOP. At first it took me a while to understand what he actually meant with that, because OOP is about making code re-usable, after all. But then I read an article that explained this quote in great length and other potential pitfalls of OOP, and then it all started to make sense. I would write all of this in my own words, but it would become really long and I don't have the time at the moment. I tried to find the original article I read, but I'm unable to, but here is a similar article I just found: https://medium.com/@cscalfani/goodbye-object-oriented-programming-a59c… I'd understand if the inflammatory writing style and the memes are not yours, but I skimmed through it and I think it does explain some of the problems well. I'm sure there are better written articles on this subject, but I have to leave now unfortunately.

This link (to devgenius.io) is to a plagiarized copy of the original, which is here: https://medium.com/@cscalfani/goodbye-object-oriented-programming-a59c… . Update: The way I figured this out is that I mod a subreddit called OOP Is Bad. I usually jump the gun on new articles, and then I have to roll back my posts when I realize they're duplicates. Anyway if you want to read up on the subject, you could do worse. http://reddit.com/r/oopisbad

It's not just luke, here's a couple more, two of these I remember in particular the others are just from a google search https://reasonablypolymorphic.com/blog/elm-is-wrong/ https://dev.to/kspeakman/elm-019-broke-us--khn https://blog.bitsrc.io/elm-and-why-its-not-quite-ready-yet-2c516a81e25… https://medium.com/@cscalfani/the-biggest-problem-with-elm-4faecaa58b7… I've come to view Elm as someones personal compiler project. If you are good with the decisions made then you're going to have a fine time, otherwise you probably won't

I suggest searching google for "problems with object oriented programming". There have been countless discussions, articles and videos. Examples: https://www.youtube.com/watch?v=QM1iUe6IofM https://medium.com/machine-words/the-rise-and-fall-of-object-oriented-… https://medium.com/@cscalfani/goodbye-object-oriented-programming-a59c…

After many years of a lot of OOP, many people have realized, that putting behavior and state together into one entity might not be a good idea. We can see modern languages moving away from such practices. For example in Clojure one has defmethod, which defined a method separately. In Rust one has structs and implements traits for them separately. In some languages OO systems are libraries, which are optional, opt-in, not part of the core language. Think GOOPS and CLOS. Usually those languages define functions for data structures separately and you will have something like vector-length. So it seems wisdom is slowly sinking in and we are progressing away from bundling state and behavior together. Why is this done? For example to avoid having to subclass loads of stuff. For example in Rust one uses composition over inheritance and one can add behavior later by implementing traits, that make use of the parts of the structs. This way one does not need to subclass everything to add a new behavior. Similar for defmethod in Clojure. With Erlang this is raised to a whole new level, by defining the behavior in separate actors, which process messages, which are the data, which travel around without the behavior part. Overall it makes it possible to actually have encapsulation. A similar thing happens when we leave the boundaries of one machine and look at the web and REST, where we basically pass messages, conceptually similar to what happens between actors. For details about how…