Live data from Hacker News

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

news.ycombinator.com

81–90 of 234 posts

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

#81
post #30

Earlier quoted context omitted.

This, basically. People should stop thinking about "composition vs. inheritance" and start thinking of implementation-inheritance and thus OOP in a strict sense as "composition plus open recursion". Open recursion (viz. the fact that methods defined on your "base" classes can invoke 'virtual' methods on self and end up depending on behavior that may have been overridden at any level in the class hierarchy) is quite o…

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 stability much more easily.

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

#82
post #35
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…

The times i've ever actually needed 'runtime' polymorphism (usually implemented w/ subtype & virtual methods) are utterly dwarfed by the times I'd been able to make use of parametric polymorphism, which I find far easier to reason about and use.

[deleted]

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

#83

People just don't have enough experience with Functional Programming to really know how awful it is. So now it is the new kid on the block (in terms of going mainstream) so people think it is the best thing ever. The most telling sign is how many FP languages are in existence today. If it was such a good thing we wouldn't need them all. It is a mess that cause many other types of problems without any clear benefit. I…

Has Python actually "won"? I was under the impression that both languages are popular with data scientists.

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

#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 world, nor does it map well to information systems.

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

#85

Client-side moats and rise of the Web. A big idea of OOP is to allow components to evolve independently. Java ensures that today's code would run on next year's JVMs and class libraries. Your user's upgrade their OS and your app keeps running, and now supports dark mode. Rad, right? But new languages like Rust/Go/etc have bincompat as a non-goal. A minor version bump means fix the compiler errors, recompile the unive…

I agree with your thoughts on how everybody neglects the desktop, but an independent evolution of components can also be achieved without OOP. Also OOP doesn't guarantee future compatibility - it can make it easier, if implemented with that intention in mind.

However, it looks like ensuring backward compatibility is an enemy now: users are forced do upgrade, sometimes every day, so obviously in the eyes of those corporations backward compatibility can be completely ignored.

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

#86
post #64
post #21

Depending on who you ask, "trend" could be replaced with "progression". I'm with you in that I never really found the OOP style to mesh well with my brain. I always felt like I had to fight it and dealing with massive chains of class inheritance can make it really hard to reason about and change code. I've spent years building web apps with Python and Ruby too. Having only spent a short while with Elixir, I'm finding…

I don't have a huge social circle but in it among the professional devs I am the sole person for whom OOP style does not mesh well with their brain. I've known most of these folks since the '80s and something that we've discussed a few times is wondering if it's when we got serious about computers, what platform (e.g. C64 or Apple II), or continuous employment in the field (I have a history of going off to do other t…

A lot of people have been working for decades and can’t imagine the idea of having to not deal with entire classes of bugs and defects. It causes a lot of strain at some companies I’ve worked at where people who’ve experienced “better” have a very hard time going back. I can’t say I think they’re wrong.

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

#87

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…

That isn't an inherent issue of composition though. You could say {...students(ajaxDb), ...teachers(ajaxDb)} to create an object that can handle both students and teachers. Or you could say public class StudentsAndTeachers extends Students implements IStudents, ITeachers { private _teachers; public constructor(Database db, Teachers teachers) { super(db); _teachers = teachers; } public getTeacher(TeacherId teacherId)…

Composition is entirely capable of creating an ad-hoc informally specified bug-ridden slow implementation of inheritance.

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

#88

People just don't have enough experience with Functional Programming to really know how awful it is. So now it is the new kid on the block (in terms of going mainstream) so people think it is the best thing ever. The most telling sign is how many FP languages are in existence today. If it was such a good thing we wouldn't need them all. It is a mess that cause many other types of problems without any clear benefit. I…

R was used by statisticians, but python was used by every non-cs researcher who needed something more than matlab. Python didn't beat R because it's OO. It won because of its existing popularity (with many people learning it in their intro programming class) and the massive amounts of open source software built for it. > People just don't have enough experience with Functional Programming to really know how awful it…

> Python didn't beat R because it's OO ...

My point that it beat R although it is OOP. This is to show that OOP is not inherently bad. Many people find it useful to the point the 'preserved' advantages of FP are not worth the effort.

> This is just anecdotal ...

My anecdote story is very different than yours. To the point if one of my engineers will ever suggest FP again he will get fired on the spot.

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

#89

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.
Post reply on HN