from Hacker News

How Class-based Programming Sucks (2011)

by vimes656 on 12/13/13, 11:17 AM with 139 comments

• by barrkel on 12/13/13, 1:13 PM

  Class-based programming works great for GUI toolkits. In most other contexts, the suitability is variable. OO is a horrible match for compilers, for example.

  The article is chasing down the wrong tree when he tries to build an Option type in C++, though. The normal OO way to handle the same class of functionality as ADT sum types is to use separate subclasses. What he's not acknowledging is that OO and functional+ADTs both only handle half the expression problem[1], in different ways. There's no absolute superiority for either model. It depends on the domain.

  Less mutability is good almost everywhere though. The lack of persistent data types is a blight on almost all non-functional container libraries.

  http://en.wikipedia.org/wiki/Expression_problem

• by choult on 12/13/13, 12:04 PM

  The thing about "Class based Programming" - or Object Orientated Programming - is that it allows you to model a problem domain in real-world terms. No one approach is ever going to be perfect; OO being mutable makes it perhaps less founded (on the face of things) on formal principles, but for a lot of large codebases it can have a great beneficial effect on readability and maintainability - cognitive overhead is, perhaps, reduced when you can "ground" your understanding in real-life terms.

  At the end of the day, pick what language and coding paradigms best suit your problem domain and you as a coder. Pick right, and there's no mistake there.

• by xcthulhu on 12/13/13, 2:14 PM

  Okay, for one:

  1. Dynamically Typed Languages (LISP, Erlang, Smalltalk, Python, Ruby, and Javascript) are all easier than Haskell, JAVA, C++ or any other typed language for working with ADTs. Whether the language is OO or not isn't really relevant. On the other hand, you loose type-safety/efficient representations. But life is filled with choices, different tools are good for different things at different times.

  2. You can have closures in a class based language. Here's some rather exotic Python code that uses both for measuring the performance of iterators: https://github.com/wearpants/measure_it/blob/master/measure_...

  Smalltalk and Scala also have closures. It's not an either/or for classes vs. closures in programming language land.

  3. There's more to concurrency than shared memory, so immutability is again a weapon that is good for some battles. If you have an app which you've factored into workers, unless they are on the same machine they'll need to communicate. Having your data be serializable is more important than having things be immutable in this context. What a worker does with data while it is handling it can involve lots of mutation.

  So everyone should take a big breath, and remember that there's no one way to think about software and there's no universal rules, other than probably P != NP and stuff like that.

• by rowanseymour on 12/13/13, 12:13 PM

  Best (and most humorous) argument against Java's object oriented obession that I've ever read is: http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom...

• by arithma on 12/13/13, 12:37 PM

  I find a mix between Object-Orientation to model the problem, and a lot of functional thinking in the 'solving' department to be the most comfortable. The modernisation (as in taking features from the old languages into the newer ones) of C++, C#, Java, Obj-C etc. are all liberal with this direction.

• by rayiner on 12/13/13, 12:16 PM

  This is a very good article. The point about mutable state is key. Class based programming encourages you to treat objects as little bags of mutable state, instead of as values, and everything goes downhill from there. Its one thing to not go all the way to disallowing mutation. Its another to encourage it to be used pervasively.

• by pbsd on 12/13/13, 1:36 PM

  > You may even have to inherit a base class or implement an interface. Subtype polymorphism is a very poor substitute for closures. This is why C++ algorithm library is unusable.

  Does anybody understand what the author means by this? STL's algorithm library does not use class hierarchies for anything. And they often take functions (be they free functions, lambdas, or functors) as arguments.

• by auggierose on 12/13/13, 12:05 PM

  In case you don't know ML, you should. Also note that though OCaml is the most popular ML dialect right now, Standard ML is where it all started (PolyML is a good Standard ML implementation: http://www.polyml.org/)

• by draegtun on 12/13/13, 1:52 PM

  Also see: The problem with OOL is not the OO by Carl Sassenrath (from 2009) - http://www.rebol.com/article/0425.html

  PS. Just submitted to HN - https://news.ycombinator.com/item?id=6900426

• by swah on 12/13/13, 1:27 PM

  Relevant recent tweet by the creator of the Io Language, Steve Dekorte: https://twitter.com/stevedekorte/status/411045428361056256

  I suppose most folks here disagree?

• by alkonaut on 12/13/13, 2:18 PM

  I agree, mostly, with the conclusions. "Classes" as a method of code re-use is dead. However, his conclusion that ML would dominate C# and Java as a language, I highly contest.

  The most important thing in my opinion is tools and platform support. Show me a fast, good looking IDE with good autocomplete/intellisense/integrated debugger and UI tools for ML. See?

  Is there an abundance of libraries and api wrappers available (that doesn't require you to do straight C-interop)? See?

  Also: the design of a language should be done with the tools in mind. While there is not much difference between norm(vec) and vec.norm() the latter is the form that supports autocomplete. So even for functional languages, being able to use member properties and member functions is an absolute reqirement to support the tooling that we expect.

  You could say that F# dominates C#. It has almost the same tool and library support, while having the features you expect from an ML type language.

• by al2o3cr on 12/13/13, 3:22 PM

  "The obvious conclusion is that ML simply dominates Java (and C#) as a language. Time to switch."

  The obvious conclusion is that any statement that contains the phrase "the obvious conclusion is" is 100% BS, including this one.

• by toolslive on 12/13/13, 12:32 PM

  mutable state is not a problem per se. _Shared_ mutable state however, is a recipe for disaster.

  There are other problems with Object-Orientation. For example, it tends to scatter allocation which has performance impact. ( see this nice presentation: http://harmful.cat-v.org/software/OO_programming/_pdf/Pitfal... )

  If performance is not an issue, I'd guess the price you pay for OO is that you eschew parallelism and concurrency.

• by mtdewcmu on 12/13/13, 8:52 PM

  A language can't suck just because it isn't Haskell or ML.