Comment by joe_the_user | Hacker News Reader

Comment by joe_the_user | Hacker News Reader

Parent Full thread

This is brilliant.

While there has unquestionably been some hype about objects over the years, I have too much respect for the many brilliant developers I have met in industry to believe they have been hoodwinked, for decades now, by a fad. The question therefore arises: might there be genuine advantages of object-oriented programming that could explain its success?

A big factor is that programmers tend to be idealists. They want code that's the absolute best. {code: goodness(code)=max}. OO is a way to take pretty terrible code and go from goodness(code)=X to X+1. But it doesn't guarantee getting further. It might even make harder to go to the next iteration. That's a terrible thing for any idealist but absolutely crucial in practice. Most code is "terrible" and most code embeds a lot of institutional knowledge that prevents it from being tossed away (see the tendency for disaster from "the big rewrite").

I would contrast this with the paradigm that's been "up and coming" for decades now - functional programming. FP aims to "start at the best and stay there". The problem is that even if we assume FP can do that, it's not aiming to solve the "increment the goodness" problem, which is what a lot of ordinary programming at ordinary companies has to involve.

I'm an obsessive idealist and I blame OO programming for my unfathomable (to most people) lack of productivity. With OO I always see, for instance, that code organization B is better than code organization A for very good reason. And C is better than B. But then A is better than C, also for good reason. After that nothing gets done.

I feel like I got more done writing assembly when I was 13 than I do today.

Every time you switch, remember what that implies about your weighting of what's important. If you force yourself to develop a consistent weighting of criteria- or even just to let your weighting of criteria change in a consistent direction- then you won't cycle back to previously-discarded solutions.

So when you say that B is better than A, get specific. "If I choose B over A, I'm saying that testability and straightforward implementation are more important in the context of this project than concision. Is that true?" If it's not, keep A. If it is, remember your choice! Then when C tempts you, you can ask yourself- is switching to C consistent with the weighting of criteria that caused you to switch from A to B?

Perfect software doesn't exist. But you can try to best match your implementation to the particular concerns of the context it's written in.

objective points i hated about OOP ala Java:

- mutability is always there, you're never sure something in the object graph will bite you back

- no clear initialization, object can be "constructed" but you never know what state you get in the end, you need to read every class implicit protocol to be sure you called the right methods after `new` (FP asks for near in-order static trees.. less cute but quite obvious about dependencies). that is unless people played fully with generics and classes (phantom types to express what step you're in the object state graph)

- too much bike shedding about private / public fields

- single dispatch forcing someone to own some logic when there's zero logical reason to do so

> FP aims to "start at the best and stay there"

I'd say there's a difference between purely functional languages and functional concepts in general. Purely functional languages have indeed remained relatively unpopular (I'm not really sure why, but I'd guess it's a convex combination of "it's not how the machine works", "it's relatively esoteric unless you have studied math or cs" and "not very much backing/support"), but we've also seen functional concepts "contaminate" traditional OO languages.

Yes, I know, it's not really "functional" and diehard FP programmers will hate me, but I'd still say it's evidence that the functional paradigm can be (and in fact has been) used to "increment the goodness".

> Purely functional languages have indeed remained relatively unpopular (I'm not really sure why, but I'd guess it's a convex combination of "it's not how the machine works", "it's relatively esoteric unless you have studied math or cs" and "not very much backing/support")

My intuition on this:

Procedural/imperative thinking is more "natural" for most people. Asking someone to explain a process without any formal training in any formal language/modeling process on this (ie, a non-programmer) they'll give you a procedural/imperative description of what to do.

OOP languages are, mostly, procedural/imperative languages with extra constructs. To varying degrees these constructs are organizational as much as actually substantive additions to the execution model. For instance, classes in Java are modules for collecting related behavior and controlling access to (usually) private data fields. They can be seen as "rich" structs: data objects + procedures for altering the data.

Now, polymorphism actually adds a lot more and can be used to subsume other control flow mechanisms, I'm not saying that OOP is just procedural + organizational elements. But as a first pass, people can step into OOP by treating it as such and learn the rest as they continue.

FP languages, by contrast, do not start off as procedural + first class functions or expressive type systems. In particular, the pure FP languages drop the imperative notions (or obscure them). This creates a major hurdle for many would-be learners. Their intuition doesn't apply to these languages.

See also Prolog and relational programming for another area where people's natural tendency towards imperative thinking creates a major block on learning (or on using it to its potential).

Yep. This is also why people suck at OOP, because most "good" OOP isn't a series of instructions - it's an abstraction layer - e.g. "ask, don't tell". Lots and lots of "OOP" ends up bad and telling and digging into internals with train.wrecks.like.this.

Really, most people would probably be more at home coding in something like a safer version of C.

The other thing about functional programming is it involves a sort of tradeoff that's very different from object orientation. It makes functions into "first class (language) objects". Manipulating functions directly is a very power ability. As tradeoff, making functions pure and making variable immutable limits that power and makes your operations on functions understandable as well as powerful. Because if you take functions with side effects and manipulate these in various ways, you can quickly wind-up with a powerful but incomprehensible system.

This means that "functional effects" do sometimes do best as something like subsystems called by the main system.

Reply on news.ycombinator.com