Classes are just functions for constructing certain kinds of objects using open recursion. There's nothing wrong with them per se, but their elevated status is confusing. It also might lead to trying to solve all complexity concerns using open recursion. I'm interested in clear analysis about how good or bad that idea is honestly. At this point I just find it (a) not personally necessary and (b) interesting.
As to the author's problem? I imagine it might have some deep seated cause related to the above, but that keeps getting translated to abstract disdain for the concept. Which is tragic.
Classes adds complexity and reduces composability. With OO you end up with a soup of inheritence and patterns. Functions are way easier to compose and reason about.
>Classes adds complexity and reduces composability.
I could easily argue the opposite. Classes reduce complexity, and increase composability. Classes allow you to group methods in a cohesive manner into a single entity. For example, a class named Queue, List, or Vector would imply to the programmer what it does without them reading any code at all.
>With OO you end up with a soup of inheritence and patterns.
Just because programmers don't make clean code, doesn't mean the whole idea is somehow lesser then just using functions. Having a hodge-podge of 2000 line functions in one massive file is just as evil as "dirty" OOP code. At least classes encourage you to group your functions in some hopefully sane manner.
>Functions are way easier to compose and reason about.
Functions are easy to compose and reason about, however, that does not mean that classes and OOP are not as easy. Each have their own clear costs/benefits. OOP, and procedural programming, should both be in a programmers toolbox.f
(article author here) I very much agree with this point of view. The most important concern is a developer who thinks and writes clearly, irrespective of style or programming paradigm.
That said, I find FP easier to reason about and comprehend, but that is just one man's opinion. I also find it more fun.
The "bad bet" I was referring to was that you can make JS impersonate Java. That strikes me as a losing proposition. Sugaring up prototype inheritance to look like class-based inheritance just muddies the water.
They don't necessarily introduce complexity. Its a case of using thing s in the appropriate place. I use Python Django. Class based inheritance is useful, though it probably not overdone like it is in the Java world. I also use functions - I find these tend to be better for smaller units of computation and classes for overall organization.
You might be interested in trying Go's OO out, which privileges composition above inheritance. It's not often talked about on HN under the low-signal furor about generics, but it is a case of a small change that has a surprisingly profound effect on the language. I am becoming convinced that the current backlash against OO should really be against inheritance, not OO. Inheritance is a thing that is occasionally useful and often painful; composition is occasionally painful and often useful. The latter should be the syntactically-privileged default.
No, the composition aspects. Go privileges composition over inheritance syntactically, which has a surprisingly large affect on the whole. Interfaces end up extending it in other interesting ways, but that's a different aspect.
The whole is still an imperative language in the end, but I've found that while it may not encourage composition and separation of concerns as much as I'd like, it fights me less than some other imperative languages.
As to the author's problem? I imagine it might have some deep seated cause related to the above, but that keeps getting translated to abstract disdain for the concept. Which is tragic.