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

221–230 of 234 posts

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

#221

Post by vinayms »

kamaal wrote: post #211
vinayms wrote: post #170

Earlier quoted context omitted.

> C++ was originally "C, with Classes", so OOP was the whole point of C++ existing in the first place This is like describing a middle aged man based on what he did in middle school. Things evolve. C++ has. Almost to a fault where one can legitimately call it a mutation.

I understand what you are saying, but really. Programmers don't change their ways when new features get added. I always remark that programming practices change when programmers retire, not when features get added. Most people learn these things through existing code bases, and these habits last ages into the future. This is why most of the times, you just start using a totally new language, that way you buy into a t…

> Programmers don't change their ways when new features get added.

The good ones do.

> This is why most of the times, you just start using a totally new language, that way you buy into a totally new set of programmers, practices and community.

What happens when that new language reaches a stage where it needs new features?

I think new languages are unnecessary unless they comprehensively solve the problems of the existing ones, and don't create new ones of their own. I have always felt that creating brand new languages is more of a personal taste driven rebellion against the language one uses. When they find that its too cumbersome for their taste, or the clique in committee refuses reforms etc, those who can will go ahead and create, some evangelize successfully (I feel this is the case because I have created a few half baked languages over the years to challenge C++ lol).

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

#222

Post by vinayms »

kamaal wrote: post #191
vinayms wrote: post #173

Earlier quoted context omitted.

I am self taught in C++. I learnt it when I realized my BE FORTRAN wasn't going to enable creating GUI simulation. I did have a few hiccups like any beginner but soon it was alright, so have no idea what it is like to be formally taught in class. As for Lisp and ML, being Indian, I had no access to these, even in CS section of the library, as you might understand. Many years ago I tried learning Scheme by/after watch…

>>As for Lisp and ML, being Indian, I had no access to these, even in CS section of the library, as you might understand. I understand being in the same situation myself. >>I tend to think those who stick to Scheme like languages and solve real world problems do it for bravado and cry when no one is looking lol. That's mostly because of lack of libraries and the amount of reading one has to do to learn totally new wa…

Sounds promising. Will have to check out some time.

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

#223

Post by mbrock »

danielscrubs wrote: post #63
ajross wrote: 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…

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…

Building a house rests on a long history of crafting and engineering. If working builders needed to understand abstract algebra we might have a lot fewer of them. The foundation of construction isn’t really mathematical. You can build a house without even doing a single measurement. Accessibility for beginner builders is in fact very important.

I’ve used Agda. It’s extremely difficult. Even pretty basic proofs can be extremely tricky; just figuring out how to use the transitive equality proof syntax is a challenge. You quickly run into the need for stuff like “universe polymorphism” which comes with a huge and terrifying theory. If this is the only way to make decent programs then we’re doomed!

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

#224

Post by verinus »

AnimalMuppet wrote: post #197
verinus wrote: post #108

Earlier quoted context omitted.

No on so many levels... Your first statement is horribly wrong!

A refutation is worth more than a bare denial.

True and i thought about writing one... but it would require much more time to write this essay and then there are several very good comments in this thread already. Furthermore there are numerous good blog posts about functional programming and why OO has failed (eg. on ploeh.dk).

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

#225

Post by repolfx »

chriswarbo wrote: post #207
repolfx wrote: post #204

Earlier quoted context omitted.

You can do that sort of thing in Kotlin, which is an OOP (well, multi-paradigm) language: inline fun String.fromString(): T { return when { T::class == String::class -> this T::class == Int::class -> Integer.valueOf(this) else -> TODO() } as T } val str: String = "abc".decode() val int: Int = "123".decode() You have to be careful with type inference: if there's no way for the compiler to figure out what type you want…

> You have to be careful with type inference: if there's no way for the compiler to figure out what type you want from the call site, you'll get an error. I'd say that's a feature, not a bug :) > You might say this isn't OOP in the strictest possible sense I would say it's not OOP in any sense. Having one function implement all the different behaviours, and pick which one to run by switching on some data (in this cas…

You can do that via reflection and other tactics, yes. You'd better do it with an interface and a cast, as of course "fromString" may not exist.

I also wouldn't use this pattern but, it is possible, and Kotlin is an OOP language.

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

#226

Post by apta »

nullwasamistake wrote: post #209
apta wrote: post #182

Earlier quoted context omitted.

> They eliminate inheritance, replacing it with interfaces. Exposing the objects for what they really are, structs with functions attached, makes this strategy easier. I don't see how this is not already achievable in Java or C#. No one is forcing you to use inheritance. And when you really need it, it's there for you to use instead of jumping through hoops.

That's basically true. Languages that use interfaces with structural typing are significantly easier to work with though. You can "implement" an interface implicitly by just having matching fields

This means you can't use interfaces as tags, which is a very important feature (e.g. see how it's used in Rust). It also means that you have several different types implementing your interface "by coincidence", making it difficult to use an IDE to find out the types of interest, not to mention what sorts of bugs might result because of this.

There are better solutions like what Kotlin and Scala use (and potentially C# in a future version).

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

#227

Post by dllthomas »

nullwasamistake wrote: post #8

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…

> Because who really cares what you name your ducks or which ducks they inherit from.

Who cares if it's an employee or a gun, as long as I can fire it.

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

#228

Post by cutler »

repolfx wrote: post #202
cutler wrote: post #135

Earlier quoted context omitted.

Why is modelling in OOP any more "real life" than with other programming paradigms? I've heard this many times from OOP zealots but I just don't get it. Most examples of this I've seen focus on physical objects such as cars which is just ludicrous as your average piece of software is morel likely to be dealing with a data structure, such as a user profile, than anything physical.

Game engines tend to model real life and they are usually very OOP.

According to John Carmack, the acclaimed expert in the field of game programming, "Functional Programming is the Future" - https://www.youtube.com/watch?v=1PhArSujR_A

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

#229

Post by AnimalMuppet »

verinus wrote: post #224
AnimalMuppet wrote: post #197

Earlier quoted context omitted.

A refutation is worth more than a bare denial.

True and i thought about writing one... but it would require much more time to write this essay and then there are several very good comments in this thread already. Furthermore there are numerous good blog posts about functional programming and why OO has failed (eg. on ploeh.dk).

OO has failed? In what sense?

It hasn't lived up to the hype? It's not the One Right Way to write all software? OK.

But it's still something that thousands of programmers find useful as a way to build their programs. That's not exactly "failure".

(BTW, ploeh.dk is inaccessible, at least to me.)

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

#230

Post by taneq »

h0l0cube wrote: post #220
taneq wrote: 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.

Actually, I spent a good 7 years in the video games industry, working everything from high level game logic to graphics programming to performance optimisation. On that last point, OOP is a complete dog when it comes to performance. If you have an update loop with a bunch of heterogeneous objects, you'll be increasing your instruction and data cache misses, by having to load vtables and method definitions. I haven't…

What games did you work on (or kinds of games, if that's too personally identifiable), if I may ask? I'd be curious what sort of games have so many objects flying around that the overhead of vtables and cache misses was a significant factor in your overall performance.

I worked in the industry myself for a year or so, on an MMO (back when they were the Next Big Thing) and while our game wasn't super optimized, OOP overhead wasn't even on our radar as an issue compared with rendering, wrangling art assets, Scaleform UI elements, dynamic loading of the same, and all the other bits and bobs.

(Not arguing that composition isn't often better, just that performance isn't usually a significant reason why.)

Post reply on HN