Hacker News Reader

Comment by TT-392 | Hacker News Reader

Object-Oriented Programming: "Luckily the industry doesn’t really use this term any more"

Wait really? What world are they living in? Am I just out of touch or something?

Bubbles. Software isn't just whatever the author's particular bubble happens to be.

OOP is still very alive and well, mainly because an aweful lot of the most widespread languages are OOP, how can you talk about java and python without using OOP ?

OOP became a marketing term, but no longer sells designs, languages, etc. OOP alone used to be hot. Now it is either just assumed, or eschewed, or considered ambiguous.

We’re getting there with FP, too. OOP…which kind? FP…which kind?

Just because it is not a selling point, doesn't mean people don't still use the term a lot. I used to only know C, OOP is still a relatively new thing for me.

Please note that the author never specifies that their context is marketing or management. They instead use a far broader term, “computing”. It would be very difficult for huge swaths of developers to do their job without using OOP and other attendant terms.

OOP is pretty well defined.

99% of the time it means type dependent namespaces.

Class A.foo and Class B.foo both represent separate namespaces in which a field or method foo can be defined, the name space is directly tied to a type. In Haskell every function is defined in what amounts to be a global namespace. This is particularly annoying when you have records that share the same attribute names.

You might argue that structs fit this definition but they are missing type dependent namespaces for functions/methods and the fact that you can define fields and methods to only be accessible within their type dependent namespace, not outside of them.

Is using structs in C OOP by that definition?

Would be, but isn't.

By that, then, you mean undefined.

It once meant that three features appeared: encapsulation, inheritance, and constrained runtime binding.

Any time it is used without implying those, it is just more or less noise.

That said, OO has become a niche technique: it fits certain problem spaces well, others very badly. Any big enough system will have some parts that could meaningfully be described as mostly OO. But there is no value in purity, so none in distinguishing those bits, particularly, or excluding non-OO notions there.

Trying to cram all solutions into the OO shoe by providing no support for any other organization (cough Java) damaged the brand, probably irreparably. It still makes sense to say part of a system has an OO flavor, for exposition, but there is little value, otherwise.

I think we have to look to Alan Kay for an original definition, since he invented the term, and according to him, inheritance is not a necessary part of object orientation. In Smalltalk (and various Lisps), inheritance is something that is created from objects and messages, not a fundamental feature of the language. In [one place](http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay...) he defines it as "OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things."

This is the fruitful definition of OOP to me. None of that Java Corporate insanity

Alan Kay's definition of OO has drifted over the years as he tries to exclude any language that is not Smalltalk.

He is free to do that, but we have no need to play along.

I love how the well-defined starts with a definition I've never heard for OOP.

I've observed the same for at least the past 20 years: most people who are working as programmers can't or won't write object-oriented code, nor will they write functional code. For whatever reason, even if they're working in a language like Java that's fundamentally object oriented, they'll write primarily procedural code (mostly static functions accessing datatypes with no functionality besides getters and setters): either they don't understand that there's an alternative, or they see some benefit in it.

I'm a functional guy myself, so I think OO is a downgrade from plain ol' procedural code. Regardless, the procedural soup model gets applied because it's the end result of too many hands touching any given codebase. Elegant abstractions take time to grok, and are opinionated. If you start a project with a UML diagram, I'm going to be disgusted. If I start a project by defining the whole thing as a left fold over an infinite stream, someone else is going to be appalled. Abstractions have a target audience, and that rarely aligns with corporate hiring practices.

If you're working on a given project for a long time, you'll appreciate the abstractions. If you just want to monkeypatch in a quick fix/feature because your boss told you to, you find where it fits, you hammer it into place, and call it a day.

Rinse repeat for a few years, and all corporate code becomes procedural.

You aren't out of touch. Some people are just living in bubbles. There's still a massive amount of Java, C# and other OOP work going on out there.

Just because it is in Java (equivalently, C#) does not mean it is OO. Java just makes coding the non-OO parts of a system awkward and unnatural.

Of course most parts of most systems are non-OO.

Reply on news.ycombinator.com