Hacker News Reader

Comment by munificent | Hacker News Reader

I'm sure this will ruffle some feathres, but the technical skill that has been the most persistently valuable across the past 25 years of my career is object-oriented programming and design. It's not the only paradigm I use, but being able to organize large programs in terms of OOP has been incredibly valuable and hugely productive for me across several languages and domains.

View on HN

On the contrary, I think that's a self-fulfilling perception. If assets are already organized as objects, then it'll continue to work well with oop. But if you take the approach from the get-go to use data and FP approaches, things can be quite nice. Examples:

- interface/trait based programming / structural subtyping (widely used in go/rust, increasingly in TS and python)

- terraform

- react

- aws lambda / cloud functions

- flow-based data processing (the whole of deep learning, spark/hadoop)

- and of course, anything declarative DSL based (SQL, jq and friends)

So I would counter that the more valuable skill is "how do I solve problems in terms of applying and composing transforms to data"

To clarify, since everyone has their own definition of OOP, and of the four pillars, Abstraction, Polymorphism, aren't at all unique to OOP, and Encapsulation is just Abstraction: the defining features of OOP are inheritance and poking-and-prodding-state into opaque objects. Inheritance is subsumed by interfaces / structural subtyping, and poking at state is contrasted with reactor patterns, event sourcing, persistent data structures, etc.

Oop really shines at the middlin-low level, in languages without a lifetime (state for things like IO resourcese, at the GUI widget level, and the (micro)service level, which is more like the original smalltalk sort of objects, in which case inheritance isn't a think.

React is implemented using OOP, which I think is great for libraries that are defining and defending boundaries.

Hooks is not really OOP. The original OOP interface was abandoned because it lead to a very complicated lifecycle that was hard to reason about.

Except the little detail that JavaScript is an OOP language in the linage of SELF, where even basic types have methods.

I'm referring to the implementation of React, not its API.

Can confirm, unless it's changed radically since I last looked at it, yes, everydamnthing in React ends up as an object representing a component, and I don't just mean in the way that JS functions are technically also objects.

No, it's not.

It is, in large part, right down at what you might call the heart of the whole thing. Though I haven't read the React source code since a bit after Hooks were added so I guess maybe that's changed—though I doubt it.

That's like saying the Glasgow Haskell Compiler is implemented in part with C, therefore Haskell is imperative.

The React "way" is very much leaning into pure immutable data that flows through components which react to changes. Components aren't objects in the OOP sense. You don't call methods on them to update their internal state.

Never said React was imperative.

> On the contrary, I think that's a self-fulfilling perception.

So is using SQL. My point, as well as the parent author's point, is that I've found a technology that has been a useful source of value for my entire career. I make no claims that there aren't other useful sources of value, but I've never for a second regretted the time I've spent getting better at writing object-oriented code.

I'm also quite comfortable writing functional and dataflow-oriented code, but I've never found those to be as exciting as some people seem to.

Fair enough!

And yeah, since OOP is everywhere, there's zero downside to getting better at it.

> I've never found those to be as exciting as some people seem to.

It's less about excitement (for me at least) and less about the hair pulling associated with reasoning about complex state. I find the more independent attributes an object has, the harder it gets to reason about, unless I can serialize the whole thing (which usually goes against encapsulation).

I'd say that's the number 1 thing I do to get "better at OOP": have a healthy suspicion towards any long-lived object I can't serialize/deserialize using primitive types.

Everyone has a different experience! Object oriented programming and design have had approximately no impact on my own career, while SQL knowledge has been indispensable. I don't think they're really in competition.

Tell me you've never worked on large FP codebases (as a point of comparison) without telling me you've never worked on large FP codebases ;)

That's true, I haven't.

Weird how many large OOP codebases there are to find oneself working on and how few large FP ones. :) Maybe that's just coincidental, or maybe not.

Should the inference be:

FP doesn't scale?

- or -

FP inherently creates small code bases?

Well, having worked on both, I was able to tell that you only worked on one since your stated opinion would likely be very different had you worked with both, so take from that what you may

> Weird how many large OOP codebases there are to find oneself working on and how few large FP ones.

How on earth is that weird when OOP is a hundred times more popular than FP?

The point is to ask why OOP is a hundred times more popular if, according to FP advocates, it's so much worse as a paradigm.

Inertia is a powerful thing. Look at how many people still use C and C++ (and Java!) despite there being arguably better alternatives.

I can see how can that be the case if one never works with products that rely heavily on having a database.

Yes, my career is possibly a bit unusual in that I've mostly not worked on heavily database-driven stuff. Mostly client applications, games, tools, and programming languages.

Just a slow-to-die 90’s fad in the end.

OOP is considerably older than '90s. Turbo Pascal 5.5 had objects in 1989 and was far from the first.

Anyway structs plus FP is no less object oriented. You just don't have to write the methods in the same code module. See NIM Method Call Syntax for example: https://nim-lang.org/docs/tut2.html#object-oriented-programm...

Yes, I know NIM is not purely functional. Use F# instead to get a bit closer to purity, it also does OOP quite nicely as does pretty much any functional language that has closures.

OOP is a tool just as Git is a tool.

> OOP is considerably older than '90s.

Fad means popular (in a deragetory way). 90’s was its popularity heyday.

> See NIM Method Call Syntax for example: https://nim-lang.org/docs/tut2.html#object-oriented-programm...

So oop is when you `obj.methodName(args)` instead of `methodName(obj, args)`? Well if that’s all it is about then I can get behind it...

> OOP is a tool just as Git is a tool.

An iron maiden is just a tool. Don’t be hatin’ it’s just a tool what has it done to you?

> FP is no less object oriented.

In fact, Erlang (and Elixir, I suppose) may be the only object-oriented programming language[1].

[1] https://www.infoq.com/interviews/johnson-armstrong-oop/

Reply on news.ycombinator.com