Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

news.ycombinator.com

Post reply on HN
Print view View original

91–100 of 234 posts

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

#91

Post by TeMPOraL »

taurath wrote: post #81
barrkel wrote: post #30

Earlier quoted context omitted.

Open recursion is pretty much core to the most useful OOP idiom, which I would assert is UI component toolkits. UI heavily relies on a large number of conventions that the user learns to expect to cat in certain ways. You can parameterize a UI widget that encapsulates these conventions with function pointers or overridden methods, but the end result is pretty much the same. I'll strongly agree however that far too fe…

When the goal is to model something “in real life” OOP tends to map decently well and it’s easy to teach. When you’re trying to make sure your program isn’t going to go off the rails, limits on mutation is one of the first places to look. When your software has 50mm+ valid states, one should hopes they have a large manual QA team. If you have all the possible states held in their own subsystem, you can automate stabi…

Not even there.

Classical OOP forces you to organize around a single and very specific taxonomy; things "in real life" are usually the very opposite of that. I remember textbook examples of inheritance with shapes or animals, both of which actually show clearly why it's a bad idea.

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

#92

Post by pojzon »

wwright wrote: post #38
userbinator wrote: post #33

Earlier quoted context omitted.

but composition is much, much easier to understand and work with. The article you linked mentions IMHO the biggest disadvantage: One common drawback of using composition instead of inheritance is that methods being provided by individual components may have to be implemented in the derived type, even if they are only forwarding methods Code whose only purpose is to "appease the design" and otherwise does absolutely n…

How often do you need to write methods just to forward to another method that _stay_ that way, and don’t evolve more logic later on? I avoid inheritance like the plague, but I feel like I don’t really write forwarding methods very often.

Few of design patterns work exactly like that: forward to another method. Evolving that API afterwords is not a lot of hassle. I really fail to see the argument here..

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

#93

Post by Sharlin »

taneq wrote: post #89
h0l0cube wrote: post #84

OOP is a subset of the broader category of polymorphism, and it premised on a broken analogy, which posits that data and the transformations that can be applied to them are similar to actions upon 'objects', and that specializations of objects are perfect subset of ideal 'class' categories. This analogy is vaguely useful to introducing basic programming to uninitiated, but the analogy is neither true in the real worl…

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.

I'm not so sure about that. Naively the "Dog is-an Animal" inheritance hierarchy based ontology is a great match for games, but basically every beginning OO game programmer quickly finds out that it doesn't scale at all and composition is the way to go almost every time. Indeed, the currently fashionable game engine architecture patterns (data-oriented design, entity-component systems) explicitly eschew object-oriented thinking.

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

#94

Post by cryptica »

a-saleh wrote: post #90

I would say Rust, Go and maybe even Nim are fairly Object Oriented. Only thing that is going away are class hierarchies as a method to structure programs, because it seems they are more trouble than worth?

Class hierarchies are the best way to structure OOP programs. The main reason why people started moving away from OOP is precisely because those people didn't know how to structure their programs correctly. With functional programming, you can write correct code without any structure... It's extremely hard to follow the logic but it works. IMO full functional programming is a bandaid patch which allows incompetent developers to write correct code... Until it becomes a giant idempotent, functionally transparent but impossible to comprehend mess and it's impossible to add new features.

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

#95

Post by a-saleh »

cryptica wrote: post #94
a-saleh wrote: post #90

I would say Rust, Go and maybe even Nim are fairly Object Oriented. Only thing that is going away are class hierarchies as a method to structure programs, because it seems they are more trouble than worth?

Class hierarchies are the best way to structure OOP programs. The main reason why people started moving away from OOP is precisely because those people didn't know how to structure their programs correctly. With functional programming, you can write correct code without any structure... It's extremely hard to follow the logic but it works. IMO full functional programming is a bandaid patch which allows incompetent de…

SmallTalk would beg to differ. Javascript as well.

And I worked with large, fairly OO-oriented codebases in JS, and it was fine and I didn't miss inheritance.

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

#96

Post by H8crilA »

paulhodge wrote: post #48

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 hierarchy that I've seen in a sensible project. I've seen some that are not sensible.

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

#97

Post by nec4b »

enriquto wrote: post #79

Because, as it has been said countless [1] times before, 1. OOP is technically unsound 2. OOP is philosophically unsound 3. OOP is methodologically wrong 4. OOP is a hoax [1] http://www.stlport.org/resources/StepanovUSA.html

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

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

#98

Post by lkrubner »

There was always some criticism of OOP, even when it was at its peak in the era 1995-2005. Paul Graham, and many others, wondered why OOP was enjoying such a vogue. But after 2005 the focus began to shift. I tried to cover a bit of this history (the long term trends) back in 2014 when I wrote “Object Oriented Programming Is An Expensive Disaster Which Must End”

http://www.smashcompany.com/technology/object-oriented-progr...

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

#99

Post by Falkon1313 »

I was a big fan of OOP in theory when I learned it in the 90s and I still use it quite often, but in practice, any sizable OOP codebase that I've had to work with is _way_, _way_, more difficult than a non-OOP codebase that just directly solves the problem in a straightforward way.

OOP encourages adding layers of abstraction, indirection, and generic stuff that sounds great if you're trying to create some kind of generic underlying framework for everything. But it makes a huge mess when you're just trying to solve a specific problem, fix a bug, or make one tiny change. Now you have to debug trace through 65 layers of unrelated generic abstract stuff to try to figure out where/why something's going wrong.

I suspect one of the reasons that some new languages don't give you that gun to shoot yourself in the foot with is because the people that made them had worked on large OOP codebases and suffered from similar problems. They're making languages to more simply solve problems in a straightforward and direct manner.

Of course, you could do that with OOP. But people don't. Given OOP, (and that book of patterns that they found), they get fancy and make it way more over-complicated than it needs to be. The result is, ironically, unmaintainable software that takes way longer to work on, and has unexpected bugs throughout the system causing bugs in distant unrelated places - exactly the sorts of problems that OOP was supposed to address. I don't think that's an inherent problem of OOP, but just our human nature. We can screw up anything.

So new systems with more constraints can help reduce the ways that we can screw things up. And if you really need to get stuff done, the more constraints you can place on it, the better. Static typing, non-OOP programming, limited-palette artwork - it all comes down to less ways for you to screw it up, and easier to fix if you do.

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

#100

Post by enriquto »

nec4b wrote: post #97
enriquto wrote: post #79

Because, as it has been said countless [1] times before, 1. OOP is technically unsound 2. OOP is philosophically unsound 3. OOP is methodologically wrong 4. OOP is a hoax [1] http://www.stlport.org/resources/StepanovUSA.html

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

A real tragedy of our time.
Post reply on HN