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

Case against OOP is understated, not overstated (2020)

boxbase.org

Post reply on HN
Print view View original

551–557 of 557 posts

Re: Case against OOP is understated, not overstated (2020)

#551

Post by Supermancho »

eternalban wrote: post #165
Supermancho wrote: post #29

Earlier quoted context omitted.

> ends up creating so much more. This is primarily because of inheritance, which seems counter-intuitive. In a meta-analysis of OOP-based designs, inheritance is used as the primary form of composition with other strategies being either last-resort or added later when the inheritance is already deeply embedded as part of the design. Inheritance is a brittle form of a composition (no-reinherit) that nests state in a d…

> In a meta-analysis of OOP-based designs, inheritance is used as the primary form of composition Whose meta-analysis came up with that? Like to see that. > Ironically, almost anything added after the base class (and maybe some abstracts above that) is a cross cutting concern added after the core functionality is established. That's a bold statement (unless you have a novel definition of "cross cutting concerns") and…

> Whose meta-analysis came up with that? Like to see that.

You'll have to dig into each language that has expanded it's composition capability and the reasoning, but the outcome is self-evident. Many languages started with simple inheritance (eg PHP, Java, VB, C++, et al) and expanded composability mechanisms over time.

> That's a bold statement (unless you have a novel definition of "cross cutting concerns") and actually backwards: ... A cross cutting concern is a 'general' concern.

I'm not going to argue about how you wish to redefine things.

Good luck with whatever.

Re: Case against OOP is understated, not overstated (2020)

#552

Post by Ma8ee »

unnouinceput wrote: post #234
kloch wrote: post #177

Earlier quoted context omitted.

> Performance approaching that of statically-typed languages like C I might have to give this a try. Is there any language other than assembly that can beat the performance of C?

It's not about the programming language per se, but the compiler/linker optimization(s). C/C++ have this magic aura of being fast because it has the most worked on compiler/linker. Once other programming languages come around that are attracting more programmers, then theirs compiler/linker will be the best from optimization point of view. Also CPU's/architecture's change all the time so even if now C/C++ have the be…

The programming language certainly has something to do with it. If your programming language has things like garbage collection or dynamic dispatch, it's very hard to generate as fast code for the simple reason that your programming language is trying to do more things during runtime.

Re: Case against OOP is understated, not overstated (2020)

#553

Post by dopidopHN »

shepherdjerred wrote: post #516
dopidopHN wrote: post #291

Earlier quoted context omitted.

Would you have any resource on functional Java? My experience with 8 and onward is better for sure. I find myself writing more robust filtering / map-reduce logic. But that’s kind of it. For instance I don’t feel like function are first class citizen still. ( I almost never user higher order function in Java, even if it’s possible )

Effective Java [0] is the single most important book I can recommend for any Java programmer. This article [1] gives an overview of some of the primitives you can use for writing functional Java. Lombok [2] is a very common library that makes writing functional Java much more ergonomic with its `@Value` annotation, but that might not be needed anymore with Java 14's Record types [3]. The book Clean Code [4] helped me…

Thanks for your answer, I think I’m stuck with Java for the time being but I least I now cater to a modern codebase. I think it’s … alright. But I miss the function being truly a first class citizen.

Those advice ring familiar or interesting. I need to give effective Java a second look. It’s been year and I’m a different dev now.

Re: Case against OOP is understated, not overstated (2020)

#554

Post by dopidopHN »

shepherdjerred wrote: post #516
dopidopHN wrote: post #291

Earlier quoted context omitted.

Would you have any resource on functional Java? My experience with 8 and onward is better for sure. I find myself writing more robust filtering / map-reduce logic. But that’s kind of it. For instance I don’t feel like function are first class citizen still. ( I almost never user higher order function in Java, even if it’s possible )

Effective Java [0] is the single most important book I can recommend for any Java programmer. This article [1] gives an overview of some of the primitives you can use for writing functional Java. Lombok [2] is a very common library that makes writing functional Java much more ergonomic with its `@Value` annotation, but that might not be needed anymore with Java 14's Record types [3]. The book Clean Code [4] helped me…

God. Those example how to archive currying or composition are painful to read. Not wonder why I never write code this way in Java. Still. I want to be more diligent in that domain because I know it pays off down the line.

Re: Case against OOP is understated, not overstated (2020)

#555

Post by t00 »

ajuc wrote: post #478
hardolaf wrote: post #464

Earlier quoted context omitted.

People also moved away from that paradigm because databases are slow. I work in the world of optimizing TLP level communications over PCI-e buses. To me, a database access is already in the world of "why bother?".

We moved from DB Front end to DB APP SERVER FRONT END I don't think it's any faster :)

Simple reason - add local or distributed cache to the app server, scale it along front end horizontally and you can handle several orders of magnitude more traffic.

Re: Case against OOP is understated, not overstated (2020)

#556

Post by AtlasBarfed »

reificator wrote: post #117
taurath wrote: post #14

In my mind, state is the real enemy impacting: comprehension, brittleness towards making changes, and the surface area exposed to potential bugs. OOP as frequently implemented, while claiming to encapsulate state, ends up creating so much more. In accordance with this view, I think project architecture should be approached with an emphasis around how much state is necessary for it to run. This is why simulations like…

> This is why simulations like say someone making a game or simcity with like relatively independent entities that map to something in real life use OOP. I don't think this is the case, or at least it hasn't been for quite awhile. Any gamedev I've known in the last decade or so would reach for an ECS[0] if they wanted to clone SimCity, in other words they would design it somewhat like a normalized database. Each char…

Does Freeciv use this approach? Or any other significant open source game or roguelike?

ECS sounds somewhat like how I was thinking of a civ-like game engine while falling asleep a couple months ago when I was thinking why Civ scaled so poorly under some circumstances: traditional games used to have everything in memory, but civ type stuff could just have a database with some indexes and spatial indexes for quick lookups, but otherwise just sweep the various tables. Thus the size of your game was more constrained by disk space than RAM.

Per your discussions with cache conservation/thrash avoidance, does ECS work well for mapping entities to specific processors so that cache-hopping doesn't occur in modern multicore processors and NUMA stuff?

Re: Case against OOP is understated, not overstated (2020)

#557

Post by AtlasBarfed »

reificator wrote: post #132
taurath wrote: post #122

Earlier quoted context omitted.

I appreciate that info! Its an abstraction that I had used in the past to demonstrate to other engineers that I have thought seemed somewhat useful about OOP, but as I was typing I thought to myself I'd bet that modern performant games wouldn't use active mutable entities but rather abstract into systems that change state at certain ticks so state can be much more easily managed, reasoned about and optimized. This so…

> This sort of begs the question: where does classical OOP, the one taught to all undergrad CS majors in programs that use Java or C++, really fit in nowadays? I have no idea. The smalltalk ideal of OOP lives on in all sorts of ways, but the deep inheritance chain version that gets taught in classes? I don't think it has a place apart from maintaining existing code.

The deepest inheritance chains I saw in practice were the OOP GUI programming toolkits, they'd go six-seven deep and invariable started needing to clone logic to avoid diamond issues (they were always single inheritance it seemed).

Honestly OOP did a lot better in those than the procedural toolkits they replaced in many ways. It was generally "better".

So if we're going to dump OOP for ??? I would say that a really amazing GUI toolkit that is pretty clearly better than the classical OOP inheritance model would really underscore the point. I can see a compositional interface GUI toolkit that is great.

I have since those days not done a native UI, so all of the modern ones, from KDE/Qt, GNOME, whatever the hell replaced MFC on windows, etc I am clueless about.

Plus all UIs are kind of dominated by HTML/CSS/javascript style of code, which is its own special evolutionary tree at this point.

Post reply on HN