Live data from Hacker News

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

news.ycombinator.com

151–160 of 234 posts

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

#151

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…

I really like this take. Especially the idea that OOP is used for specific OOP use cases and not applicable to solving every problem at large. Data Processing is a great example

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

#152

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 gen…

I think another part of this is if you like what might be called classical OOP you don't need to make a new language.

Just use Java, or C#, or any of the dozen other mature, widely used languages that support it.

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

#153

Earlier quoted context omitted.

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.

That relates to my comment in what way?

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

#155
post #54
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 most upvoted answer begins with the words “Unpopular answer” and then continues with cynicism. That definitely feels very HN. (No offense, of course; just found it amusing.) Although you make some good points, I disagree with the premise that it’s pure fashion. Language syntax doesn’t prevent you from implementing various OO paradigms but when you combine syntax with community norms, things do tend to be constrai…

> The most upvoted answer begins with the words “Unpopular answer” and then continues with cynicism. That definitely feels very HN. (No offense, of course; just found it amusing.)

At least the top comment is about the actual topic, and not someone whining about the font color or the “clickbait” headline.

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

#156
post #150

Earlier quoted context omitted.

> OOP encourages adding layers of abstraction, indirection, and generic stuff [...] Generics/templates and indirection are not OOP. Procedural style encourages them as well. You can see that in C++ itself.

C++ is OOP, though.

No. OOP is just one aspect, but the most popular one.

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

#157
post #150

Earlier quoted context omitted.

> OOP encourages adding layers of abstraction, indirection, and generic stuff [...] Generics/templates and indirection are not OOP. Procedural style encourages them as well. You can see that in C++ itself.

C++ is OOP, though.

Depending on who you ask, some would say that C++ is not OOP because its encapsulation model is broken unless you use idioms such as PIMPL.

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

#158
post #150

Earlier quoted context omitted.

> OOP encourages adding layers of abstraction, indirection, and generic stuff [...] Generics/templates and indirection are not OOP. Procedural style encourages them as well. You can see that in C++ itself.

C++ is OOP, though.

C++ is multi-paradigm. While people can write OOP code in C++, they can also write header-only libraries, which is generic programming. In C++ generic programming, inheritance is merely a language feature to get what you want, not the main method of abstraction.

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

#159
> I have always struggled with OOP Said every one, I think this is the main reason.

In theory OOP is supposed to make it easier to do separation of concerns in reality separation of concerns is really hard and adding some syntax sugar didn't help.

It's hard to create an abstraction that isn't overboard or so specific it's not an abstraction.

It's hard to separate concerns if you just inherit those concerns.

Testing OOP inheritance is awkward so most people don't and use dependancy injected instead which kinda breaks the whole point of inheritance and OOP.

OOP makes it look like you have separated concerns but in reality you where concerned with the wrong thing (most likely nouns) and spread the real concern throughout the whole project.

I think the old school OOP of Classes is dead and the newer Traits and Object composition will take over, or functional programming which is very Gucci at the moment.

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

#160

Most people have a wishy washy view between the differences between FP and OOP. It is never clear why a map reduce is better than a for loop or vice versa. That being said iS an area where OOP is definitively worse than FP: In fact OOP (as defined by JAVA and C++) is Categorically less modular than FP. There is concrete and definitive reasoning behind why this is the case. I've explained it all in a thread before I'l…

> It is never clear why a map reduce is better than a for loop or vice versa.

to me map/reduce feel like a further development of structured programming. a map(...) call is less expressive / more constrained than a loop and that's the point; compare to how loops and if/else can all be written with goto, but we prefer the more structured alternative

Post reply on HN