Live data from Hacker News

OOP Is Dead, Long Live OOP

gamedev.net

301–310 of 357 posts

Re: OOP Is Dead, Long Live OOP

#301
post #171
post #114

Earlier quoted context omitted.

OOP has no built-in facilities to deal with multi-threading. It's orthogonal to it and that's a problem. Thread safety can't be expressed or enforced and you can't grab a bunch of classes from somewhere and assume anything about their fitness for multi-threaded code. Typically one has to carefully design a class for multi-threaded use. Reasoning about state inside objects then quickly becomes infeasible.

Which _paradigm_ has those facilities? Not a language, but a paradigm?

Pure functional programming has this property by its nature. Anything immutable cannot be changed during another threads execution.

Re: OOP Is Dead, Long Live OOP

#302
post #3

One thing that I'm surprised this doesn't cover, especially since it's so C++-centric, is that modern C++ OOP is much more defined by lifetime/scope management than anything else. What defines something as an object is the fact that it doesn't exist until it is constructed, and doesn't exist after it gets destructed (which is the case even for fundamental types, with the exception of char/std::byte, btw). Hot take: R…

RAII is a very powerful technique. However, it has actually very little to do with object-orientation. To my knowledge, the only other langages having it are D (multi-paradigm) and Rust (explicitly non-object oriented).

Re: OOP Is Dead, Long Live OOP

#303
post #9

If we just had made inheritance as something to be avoided unless absolutely needed then OOP would have probably never got such a bad reputation. All the other concepts make perfect sense.

And don’t use a class if it holds no state.

This is not so simple. What about "NullLogSink" and "StdoutLogSink", both being implementations of "ILogSink"?

Classes are very well suited to statically formalize the communication points (aka "interfaces", "protocols") between the various parts of your program.

The fact that a concrete class might have a state is actually irrelevant (indeed, we generally make all of our data members "private").

Re: OOP Is Dead, Long Live OOP

#304

Earlier quoted context omitted.

OOP is linked strongly to mutable objects, which is inherently thread-unsafe. Sure you can get thread-safety in OOP, but it’s hard. It’s the same reason why global variables are bad but worse. Mutability is rarely needed and often makes things more complicated than needed.

Well, my original point is that thread-safety is easy with the right abstractions, and that choosing your abstractions is a conscious thing. So I don't see how mutability is "inherently thread-unsafe." Rather, programmers are "inherently thread-unsafe" and we have a responsibility to understand the problem domain and choose abstractions that make sense to us and that actually solve the problems we're encountering. No…

I just doubt that those abstractions are easy and would say that they often break. Blaming the programmer for thread-unsafety in e.g. Java is like blaming programmers for memory unsafety in C.

I agree if you stay in purely functional programming languages you run into points that are solved better with mutability. However those parts of a program are small and most parts are expressed better by pure functions.

Re: OOP Is Dead, Long Live OOP

#305
post #10

Earlier quoted context omitted.

I think this relates to what you're saying. I've never felt any frustration that OOP feels like the wrong tool when I'm using languages that give me the choice to use it or not (like Python, and JavaScript). But when I'm using Java, as one example, it often feels like I'm really locking myself into a design up front. In Python, especially. I'll find myself starting off all experiments or simple projects with function…

But that's the whole point of JAVA. It's an opinionated platform with a hyper-standardized workflow. Sure, that limits creativity, but in many business contexts, the last thing you want is your programmers getting "cute". There's a straight line from requirements to implementation; no meandering involved. At least that's the theory. In practice...

When faced with complexity you have to use with whatever 'opinionated hyper-standardized workflow' to build 'un-opinionated hyper-unstandardized workflows'. The net result is like trying to build sculpture with glass with chisel and hammer.

Its then you realize you had better started with clay.

Re: OOP Is Dead, Long Live OOP

#306

Earlier quoted context omitted.

OOP is linked strongly to mutable objects, which is inherently thread-unsafe. Sure you can get thread-safety in OOP, but it’s hard. It’s the same reason why global variables are bad but worse. Mutability is rarely needed and often makes things more complicated than needed.

I'm not aware of such "linking". It's very common to write classes of which instances are immutable or thread-safe.

It is doable, but it is a concerted effort, like doing OOP in C. It’s hard to keep the discipline especially when new people start working on the code

Re: OOP Is Dead, Long Live OOP

#307
This is a pretty good discussion and I’m surprised that while discussing OOP not much was brought up in the way of managing private versus shared memory which I think depending on the platform is not as universal as we all hoped it would be by now. Marshalling objects with pointers accessing vtables over uneven terrain is how it goes down. I think here is a good example: https://trac.webkit.org/wiki/WebKitIDL

And to further that point there is no more Safari on Windows for this reason among many others. Remember MemMaker? It’s crazy there were so few applications we managed some of the memory ourselves but it worked very well didn’t it? OOP really took off back then too and then memory utilities were not needed and didn’t last too long. The convenience of not worrying about it is one of the many things OOP was able to solve as it advanced. It is still pulling off the same tricks today in a much more complex and metered way. OOP does so much more than just this of course but the solutions developed with it for managing memory are intense and as much art as science. So we should question it and many paradigms to make this better. A mentor of mine when explaining this would compare it to juggling...and then proceed to actually start juggling while talking about his code. He’d stop and look up, just pause, and say that’s all we are doing here just juggling.

Re: OOP Is Dead, Long Live OOP

#308
post #257

Becoming a professional Haskell and Erlang developer really shifted my view on OOP (let OOP denote class based OOP as found in Java or C++). In my view, OOP is prove a poor model for computation, and the result has been that OO code is almost always significantly more complex and error prone than an equivalent computation written in a concurrent, functional, or structured paradigm. Recent trends in language design (s…

Interesting view. How should i, as a sysadmin who just writes bash and powershell scripts, start to learn _serious_ programming? Is it still worth to force myself into OOP?

If you want to get a job, yes.

The world is built on OOP, it's just that too many like to use it as a punching bag.

Re: OOP Is Dead, Long Live OOP

#309
post #308
post #257

Earlier quoted context omitted.

Interesting view. How should i, as a sysadmin who just writes bash and powershell scripts, start to learn _serious_ programming? Is it still worth to force myself into OOP?

If you want to get a job, yes. The world is built on OOP, it's just that too many like to use it as a punching bag.

10/10

Re: OOP Is Dead, Long Live OOP

#310

Earlier quoted context omitted.

> I have a hard time getting on board with the "waste" or loc argument. . The things that matter most to me are readability, organization, maintainability, etc I think people also have different ideas on readability. Some prefer a single file with 2k lines and some prefer 40 small files in 12 folders with 50 lines each. Like the parent says you can often write the same code in 4x length, be it to prepare for future f…

Maybe. I suspect most people who say they prefer the java style are simply wrong. I don't think they've spun up on enough new projects to notice the extra weight that increased size and scale brings. Or they're assuming that the extra complexity is all necessary, and they're mistaken the same way I was while grading those assignments. (Aside: Isn't it super weird how reading code is so rarely encouraged at school?) I…

The use case I gave is not a simple website, it's a code base with millions of lines of code. I agree that a simple website or small school project is a different situation with different needs.
Post reply on HN