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?
OOP Is Dead, Long Live OOP
301–310 of 357 posts
Re: OOP Is Dead, Long Live OOP
#302One 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…
Re: OOP Is Dead, Long Live OOP
#303If 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.
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
#304Earlier 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 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
#305Earlier 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...
Its then you realize you had better started with clay.
Re: OOP Is Dead, Long Live OOP
#306Earlier 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.
Re: OOP Is Dead, Long Live OOP
#307And 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
#308Becoming 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?
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
#309Earlier 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.
Re: OOP Is Dead, Long Live OOP
#310Earlier 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…