The author puts out four reasons for OOP:
Reason 1 - It was thought to be easy to learn.
Reason 2 - It was thought to make code reuse easier.
Reason 3 - It was hyped.
Reason 4 - It created a new software industry.
I feel the author is stuck too much on thinking #3 and 4 are the reason for OOPs. “Hype” is a mix of word-of-mouth advertising and “official” advertising and is often the case for people trying out new languages. I know that’s how I learned Ruby and, incidentally how I started on Haskell. There is a lot of hype round functional programming languages - quite suddenly, it seems to me. FP is now being put forth as the cure to all the evils that OOP brings with it.
I recall as a young man being quite taken with C++. The whole concept of inheritance and polymorphism was AMAZING. It was quite a treat to write classes, debug them and then extend them in a block-by-block fashion. It allowed me to do things like particle simulations in a very neat and logical way. There are many, many problems that lend themselves naturally to an object-based abstraction.
When i started doing data analysis, rather than simulation, I reverted to a functional programming style. At first because MATLAB (The language I used) was unwieldy in terms of OOP structure, but also because data processing lends itself naturally to the FP style of chaining functions that perform transformations on the data. I migrated to Python and used it - without any conscious effort - in a “functional” way, which means the function itself has no state - though state could be part of the data.
In summary, both OOP and FP have domains of use and can be used effectively with discipline.
I’m having a lot of difficulty understanding why there even needs to be a post about OOP ‘sucking’. In my opinion it is evident that a lot of the world is running on systems & applications written with OOP. It’s also my opinion that a lot of those systems & applications run proficiently or else a lot of businesses and infrastructure would be in a hot mess.
Programmers, for any given problem, should just use the tools that are best suited for that given problem. FP and OOP all have their place, no need for mud slinging.
It’s also my opinion that a lot of those systems & applications run proficiently or else a lot of businesses and infrastructure would be in a hot mess.
Is it also your opinion that a lot of business code and infrastructure is not a hot mess? Because I will contend very strongly that in fact it is. (I’ve never worked anywhere it was not.)
It is my opinion that a lot of business code and infrastructure is not a hot mess, and a lot of it is a hot mess. I’m not trying to be facetious, we might end up just agreeing that there is a lot of code out there.
But I don’t have any data to validate that claim besides Github and private repos. When it comes to this ‘OOP sucks’ post, I don’t like trying to tie the hot mess some people are in with OOP for all projects ever.
Objection 4 - Objects have private state
Non-const objects have private state. So prefer const objects, and you’re back in the happy erlangy FP'ish immutable world again.
Furthermore, there are two things much much worse than something with private state….
Something with public state that any random client can slap into a state inconsistent with the invariant for the related items of state.
Arcane kludges to dance around modelling something that is intrinsically mutable in a language that only permits immutable objects.
I do everything immutable where appropriate… and mutable where appropriate.
Not really, no. It’s a good first step, but a very small one.
It’s worth considering why Haskellers are able to leverage mutability on a case by case basis to make certain algorithms faster without it wrecking the ability to reason about their code.
There are higher leverage ways to fix your stuff than const-correctness.
Depends somewhat on the OO language concerned, some sabotage you at the primitive level.
In Ruby I’m in the habit of “freeze"ing everything after construction until my unit tests tell me I can’t.
And then I often refactor so I can. (Or “metamorphize” a larval object into an immutable adult phase. It’s a nice pattern that…. Have a larval stage to an object with only mutators, and when it is built and read to use, pupated it into a frozen immutable adult phase with no mutators, only “use” methods.
The D language provides a richer vocabulary for “Doing The Right Thing”, and then checking at compile time that you have.
Let me introduce you to Haskell then. More expressive than Ruby, verify more at compile-time than D, still get a REPL like Lisp, pretty damn fast to boot. The linked paper shows pure Haskell code beating Nginx in routing and serving web pages, C++ and Java in SDNs.
My guide to learn Haskell is here.
I would not have changed to Haskell from Clojure if it wasn’t more expressive, with better concurrency options, and a type-system that makes you love types.
The #haskell channel on Freenode is one of the largest programming language channels on Freenode, within 300 users of #ubuntu (1400 vs. 1700) these days.
Here’s a silly little URL shortener in Haskell.
In my opinion, the essential tension or difference between FP & OO is initial and final encodings respectively. Haskell has, in my opinion, unified these approaches to programming better than any others - including those with ML modules.
See here for an example of how Haskell uses types to lock up and isolate useful applications of mutability using a pretty simple type-system feature.
How well does it do in the Resource Constrained, Real Time Critical, Controlling Arcane hardware, Deeply Embedded System use case?
Because that’s my day job…
And I’d deeply love to dump C/C++ and D seems to be by far the most promising candidate on the horizon.
Haskell happens to be an exceptional language for creating DSLs that enforce invariants statically. A lot of what Galois does is related to security or embedded work that has to work. That’s why they use Haskell.
I just realized that OO breaks the protocol abstraction, by separating data layout from the algorithm it allows different pieces of code to communicate in an n:m vs n2 architecture. Libraries like flatbuffers and capnproto will further ‘protocolize’ the heap. I’d write more on the subject but I am Blaisé on it.