Live data from Hacker News

Ask HN: Why do new(ish) programming languages eschew OOP features?

news.ycombinator.com

111–120 of 234 posts

Re: Ask HN: Why do new(ish) programming languages eschew OOP features?

#112
post #56
post #55

Earlier quoted context omitted.

Unpopular answer to the unpopular answer: OOP was pure fashion .. “Our customers wanted OO prolog so we made OO prolog” .. http://harmful.cat-v.org/software/OO_programming/why_oo_suck... .. screw things up with any idiotic "object model" crap. .. http://harmful.cat-v.org/software/c++/linus

I don't see that follows. The flood of OO languages in the early 90's went hand in hand with a very broad reorientation of the way design was done. That that had bad side effects isn't really a rejection of the fact that OO design really was a fundamentally different way of thinking about problems, and languages that supported it syntactically were doing so to enable this paradigm shift. That's not really "fashion" i…

Fashion is surely a part of it.

But to me the rise of OOP in the 90es where driven by the need of programming user interfaces and the rise of Windows and similar. A graphical user interface is naturally represented as a hierarchy of objects each with their own internal state. Often the language was designed to work in an integrated development environment with a user interface builder (with language features such as object serialization and reflection).

This is very obvious in Borland Delphi (OO Pascal), Objective-C, VB, Smalltalk, C#.

Then things shifted and people started doing web development where all of sudden you had hundreds of concurrent users on a single server; and then people began (re)inventing languages that handled concurrency well.

Having said that. I don't think the dominating trend today is functional programming but rather "multiparadigm" (as it should be).

Re: Ask HN: Why do new(ish) programming languages eschew OOP features?

#113
post #96

OOP was a huge trend in the 90s and I think a lot of devs have learned from experience the ways in which it kinda sucks.. - It doesn’t do great as the code gets older or more complex. Google “fragile base class problem”. - Inheritance doesn’t do a good job of modeling most real-world problems. Most situations don’t map into a simple “class Dog extends Animal” kind of hierarchy. Steve Yegge’s “the kingdom of nouns” is…

OOP is great as long as your inheritance stack is at most 2 classes deep: abstract base classes for different backend implementations, or for holding heterogeneous objects like a syntax tree or, idk, inodes in the kernel, or even just one actual implementation and additional implementations for tests. At which point you may as well call the base class an interface. Can't think of any sensible 3+ classes deep hierarch…

Most modern code bases I've seen only use interfaces now. Only in the odd exception do they use inheritance.

Re: Ask HN: Why do new(ish) programming languages eschew OOP features?

#114
post #55
post #5

Unpopular answer: pure fashion. There's nothing wrong with object methods (that's 100% pure syntax vs. a function call) and an implicit "this" scope for symbols (which is just a limited form of dynamic scope[1]). They don't make code hard to understand. OO can be abused to produce bad designs, of course, but that's not an indictment of its syntax. Non-syntactic aspects are maybe a more involved discussion. For an exa…

Unpopular answer to the unpopular answer: OOP was pure fashion .. “Our customers wanted OO prolog so we made OO prolog” .. http://harmful.cat-v.org/software/OO_programming/why_oo_suck... .. screw things up with any idiotic "object model" crap. .. http://harmful.cat-v.org/software/c++/linus

Isn't that obvious? If fashion is a reason for something to come into existence then fashion can also be a reason for it to fade away.

Re: Ask HN: Why do new(ish) programming languages eschew OOP features?

#115
IMHO and very TL;DR: same reason why Agile failed. Just like Agile, OOP has some good ideas at the core, but "Big Enterprise" ruined it by starting the (from todays point-of-view, unbelievable) big OOP-hype in the 90s (OOP was basically the Machine Learning / Blockchain of the late 90's, just worse because it infected absolutely every last corner of software development, everything had to be OOP, from programming languages, to application architecture, to operating systems, to CPUs...)

Thankfully people started to look behind the curtain and noticed that the whole "industrial-scale ceremony" that was built around the few good OOP ideas actually hinders software development, so they took the few good pieces and integrated them into the new languages we're starting to see now.

20 years late, but better late than never :)

(PS: watch the same cycle unfold around functional languages in the next 20 years)

Re: Ask HN: Why do new(ish) programming languages eschew OOP features?

#116
post #5

Unpopular answer: pure fashion. There's nothing wrong with object methods (that's 100% pure syntax vs. a function call) and an implicit "this" scope for symbols (which is just a limited form of dynamic scope[1]). They don't make code hard to understand. OO can be abused to produce bad designs, of course, but that's not an indictment of its syntax. Non-syntactic aspects are maybe a more involved discussion. For an exa…

It's "pure fashion" until you try to massage your new subclass into behaving slightly differently when you're living with class hierarchies that are N levels deep. Clean compositions, ala Scala traits, can be done with OO. It's just not something I've seen in the wild, or something actively encouraged by any OO teachings I've witnessed. At the same time, composition is pretty much the only way FP is taught (at least…

Exactly this. I think this is the issue with OO that developers have come to realise, and which more functional languages get around. It's the "banana, gorilla, forest" problem that Joe Armstrong of Erlang once mentioned in a book I think, and it boils down to the lack of care when considering separation of concerns.

Of course you can separate concerns properly in an OO context, but most developers don't. It's much easier to consider properly when the entire language is structured around it.

Re: Ask HN: Why do new(ish) programming languages eschew OOP features?

#117
post #97

Earlier quoted context omitted.

And yet most of software for quite some time was/is written in OOP languages.

A real tragedy of our time.

In what way? What do you believe would change if all that software was written in a perfect language of you choice?

Re: Ask HN: Why do new(ish) programming languages eschew OOP features?

#118
post #5

Unpopular answer: pure fashion. There's nothing wrong with object methods (that's 100% pure syntax vs. a function call) and an implicit "this" scope for symbols (which is just a limited form of dynamic scope[1]). They don't make code hard to understand. OO can be abused to produce bad designs, of course, but that's not an indictment of its syntax. Non-syntactic aspects are maybe a more involved discussion. For an exa…

I'll disagree with your popular answer (it's the most upvoted right now). There is a certain degree of fashion, however pure functions and immutable values make data parallelism extremely easy, almost trivial. Our hardware has almost hit the ceiling on single core performance, so easy parallelism is the way to make use of this.

I do believe that object orientation as a concept has value. A lot of concepts map easily to objects by nature. However the 90s OOP fashion, exemplified by Java, lead to horrible lasagna code. Especially if the underlying space didn't map straightforwardly to the concept of an object, then you're adding a layer of abstraction that can lead to misunderstandings.

Re: Ask HN: Why do new(ish) programming languages eschew OOP features?

#119
post #76

Earlier quoted context omitted.

You have some good points. But have you tried Idris or Agda? My problem with OO is one of culture. If and only if you work with big codebases you start to feel that you can’t make assumptions about anything. For all I know the plus operator can send nukes. Then they say it doesn’t matter because they made the perfect lasagna with a million layers. I know there’s a million ways to code with oo to make it better. But I…

Cognitive overhead is the key word for me here - it can be just as difficult to reason about massively long function chains as a bunch of stateful classes, but usually in my experience an OO codebase follows conways law very tightly in that you get a history of how developers were split up - not discreet units of functionality with well defined interfaces. It’s hard to say something is objectively better, but it’s al…

That not an OO thing. That is Conway's law. It applies to all software.
Post reply on HN