Live data from Hacker News

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

news.ycombinator.com

211–220 of 234 posts

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

#211
post #162

Earlier quoted context omitted.

You can do that in C, though. C++ was originally "C, with Classes", so OOP was the whole point of C++ existing in the first place.

> 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 totally new set of programmers, practices and community.

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

#212
post #81

Earlier quoted context omitted.

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.

>>I remember textbook examples of inheritance with shapes or animals

Man, I wonder how people went through this wondering, Who uses this? Can't they show us something real!

Eventually you just kind of tune out, because when you often meet the real world use cases, OO either descends to hierarchical verbosity from hell with layers and layers of generic abstract stuff when things should be more direct.

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

#213
OOP code bases tend to get messy with age, as layer upon layers of abstraction are added, as programmers come and go. State is fragmented and hidden in various places. If you need to solve a bug or understand what happens with state on a particular point in time, you have to do some diffing in a lot of different places.

Imperative programming coupled with data oriented design and Entity Component System tend to be much cleaner and a lot more efficient. Instead of thinking of how to apply a pattern to complicate things a bit, you focus on the problem to solve.

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

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

Mostly I guess speed matters there and you have fewer options apart from C++.

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

#215
post #184
post #118

Earlier quoted context omitted.

I'll disagree with your popular answer (it's the most upvoted right now). There is a certain degree of fashion, however pure functions and immutable values make data parallelism extremely easy, almost trivial. Our hardware has almost hit the ceiling on single core performance, so easy parallelism is the way to make use of this. I do believe that object orientation as a concept has value. A lot of concepts map easily…

Purity helps a lot but it's far from making automatic parallelism trivial. See for example how few FP languages do it. Not many.

You mean how few enforce it? About as many as enforce OOP. It's more of a strong suggestion, like using objects in Java.

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

#216

Earlier quoted context omitted.

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

If Alan Kay's definition is at odds with what 99% of the industry call OOP then it's not particularly useful, his definition sounds more like micro-services.

Funnily enough it also describes some of my more elaborate shell scripts with various messages flowing into and out of self contained processes.

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

#217

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…

> For programming tasks that actually are best conceptualised as objects, OO works quite well. These usually involve the provisioning of some largely static virtual environment, such as a UI, game world, or inversion of control container.

Actually data oriented design and entity component systems work much better for games. You don't have hidden states and data flows much nicer from system to system. Actually, ECS is a good solution for implementing GUIs, too.

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

#218
post #95

Earlier quoted context omitted.

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.

When I say class, I don't explicitly mean using the class keyword. Also when I say hierarchy, I don't mean only inheritance (composition is also a kind of hierarchy). In my statement, I mean class more like "a kind of structure from which you can create instances", prototypes are similar to classes in that way. Definitely you should still follow some kind of hierarchy when using prototypes... In fact you should be ev…

I do think you need well specified data.

My experience is that hierarchy is more trouble than worth.

And I did like the fun of trying to figure out a hierarchy for existing system. But after a year in use, I woul look at the hierarchy with the 'what was I thinking' look.

So I moved from nesting abstractions with classes to dependency injection to mostly passing well-defined data to functions.

Like, after I understood prototypes in js, I used them for a bit, but then I switched back to passing data-structures to functions :)

There might be another reason why new languages are moving away from this kind of specifying hierarchies. There are already several languages with ecosystems built around hierarchies, so if you are fine with java, you probably wouldn't jump to golang :)

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

#219

If you'd like to hear the case against OOP in modern programming, the Rich Hickey talks are a pretty good place to start: * The value of values * Simple made easy * Are we there yet? I'm on mobile, but you'll find these easily on the google.

Absolutely watch the talk "Are we there yet", it's my favorite of all time. In short OO gets time fundamentally wrong, is unable to represent a discrete succession of values, and entangles state with operation. OO has been ~35 year wrong turn for the software development industry.

OOP contains in-place mutable state because mutating state is extremely important in basically all computer systems.

FP has become fashionable in recent years and now it's gone to people's heads. But some difficult facts about computer science remain:

- CPUs are much faster at reading and writing to recently used locations. Mutating in place is fast compared to constantly copying things.

- Many of the most efficient data structures and algorithms require mutable state. There are entire areas of computer science where you cannot implement them efficiently without mutable state, like hash tables.

- Constantly copying immutable objects places enormous load on the GC. This is getting better with time (there are open source ultra-low-pause GCs now), but, Rich Hickey just sort of blows this off with a comment that the "GC will clean up the no longer referenced past". Sure it will: at a price.

- He repeats the whole canard about FP being the only way to exploit parallel programming. People have been claiming this for decades and it's not true. The biggest parallel computations on the planet not so long ago were MapReduce jobs at Google: written in C++. Yes, the over-arching framework was (vaguely) FP inspired. But no actual FP languages appeared anywhere, the content of the maps and reductions were fully imperative and the MapReduce API was itself OO C++!

Also note that Java has a rather advanced parallel streams and fork/join framework for doing data parallel computation. I never once saw it used in many years of reading Java. SIMD is a much more useful technique but nearly all SIMD code is written in C++, or the result of Java auto-vectorisation. FP programming, again, doesn't have any edge here.

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

#220
post #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.

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 seen a situation in a game update loop where composition couldn't provide better flexibility as well as performance benefits.
Post reply on HN