Live data from Hacker News

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

news.ycombinator.com

121–130 of 234 posts

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

#121
post #109
post #89

Earlier quoted context omitted.

The analogy you describe is only broken if you're doing something that it doesn't work for. It's great for simulations and games, for instance.

Here you can find a series of blog posts discussing why OOP is not a good fit for games: https://ericlippert.com/2015/04/27/wizards-and-warriors-part...

I've read these before, they're great (and I'm going to read them again now for fun. :)

That said, "let’s write some classes without thinking about it!" pretty much sums up the criticism of OOP. You can't just throw your problem domain naively at some language structures and then blame the language when it doesn't work. I bet I could pick any programming paradigm and find a way to do it wronger than this.

(If I were doing an RPG of the sort in the articles, just off the top of my head, I'd probably end up with fairly abstract 'Creature', 'Item', and 'Action'/'Spell' classes, plus a big data table defining the various types of each of these and the ways they could interact. Your game designers shouldn't be worrying about compiling C++ in order to add a new type of dagger, after all!)

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

#122

Many systems people want to build with computers cannot be easily conceptualised as graphs of largely self-contained objects, interacting through swapping messages. These problems instead revolve around complex data processing, and are more easily conceptualised as data flowing through a network of functions, and into and out of containers. It is possible to build these systems using OO, by reifying the network of fu…

The current trend in computer game architecture is also away from OOP/inheritance and to Entity-Component-System designs where you have entities without behavior (often just an Id) that are composed of components (pure data structures) that are operated on by systems specialized to single or small sets of components (functions).

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

#123
You would have to ask the authors of those languages but I do not find it very surprising. If you take the whole set of features that commonly comprises object-orientedness it is a rather large set that also seems a bit arbitrary. Why would the same language construct known as a class support inheritance and static members and data hiding? Those are orthogonal things. It seems as such more logical to provide these and other features but not necessarily as a package deal.

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

#124
I don't know, and shouldn't comment, but I do anyway because I'm opinionated as heck.

Datastructures are important for storing data. Functions are important for manipulating data.

Just because they're both abou data, doesn't mean that they belong naturally together.

I personally find "moveEntity(player, x, y, z);" (and the implications) prettier than "player->move(x,y,z);"

Now, if only my C could have first-class functions, without any other consequences to the language or runtime, I'd be supper happy, but I'm sure there's some fundamental reason that's impossible.

Then again, I'm a pretty crappy software developer.

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

#126
post #67

IMO they just expose more of how OOP really works, giving you flexibility. Take Rust. Just because I like their pragmatic approach. They represent objects as structs with functions attached that have access to the struct data. In C++, Java, etc this is roughly how objects actually work underneath. They eliminate inheritance, replacing it with interfaces. Exposing the objects for what they really are, structs with fun…

I disagree with it being OO when it doesn’t have inheritance. No classes or class hierarkies, no passing things along to children. Seems very different than what those who invented OO had in mind. Structs with functions attached is easy, and not entirely uncommon in procedural and even functional languages.

Interfaces are inheritance, just without code. But interfaces definitely serve at least one role of an abstract base class.

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

#127
post #76

Earlier quoted context omitted.

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.

> usually in my experience an OO codebase follows conways law very tightly

grandparent comment is saying that OO codebases express conways law more fully (as it is definitely a spectrum).

I don't have an opinion on it either way (beyond stating that adherance to conways law is a spectrum rather than binary), just clarifying.

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

#128
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…

> OO can be abused to produce bad designs, of course, but that's not an indictment of its syntax. It is. The strength of a language isn't just in what allows you to do, but also in what it limits you to do. OO in the style of C++/C#/Java is extremely flexible in terms of code organization. This means that most codebases eventually grow towards a mess of different styles and inconsistent design patterns. One guy's abs…

> OO in the style of C++/C#/Java is extremely flexible in terms of code organization.

Is the problem perhaps that the wrong lessons were taken from earlier OOPs by later OOPs? Alan Kay in 2003:

> OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I'm not aware of them.

* http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay...

* https://news.ycombinator.com/item?id=19415983 (via)

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

#129

Many systems people want to build with computers cannot be easily conceptualised as graphs of largely self-contained objects, interacting through swapping messages. These problems instead revolve around complex data processing, and are more easily conceptualised as data flowing through a network of functions, and into and out of containers. It is possible to build these systems using OO, by reifying the network of fu…

If messages that are swapped contain data, I find that FP (functional programming), if implemented with type checking, can include as much or if not more boilerplate than OOP, where object methods implicitly access the data (object attributes).

This may sometimes lead to code that is difficult to reason out... but if you have a few objects and many functions, OOP can be less verbose than FP.

I say this as a stronger supporter of FP than OOP.

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

#130

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 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..

Was that the paradigm or the language implementation of the paradigm? The big two languages in the '90s were Java and C++ (later C#?).

If everyone was writings in Lisp/Smalltalk (or even Tcl), would things have turned out differently?

Post reply on HN