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

371–380 of 557 posts

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

#371

Post by ahartmetz »

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…

I have come to the same conclusion. State is the problem. State should be:

- minimal (amount and lifetime)

- well conceptualized (~= easy to understand the organization)

- well named

- minimally exposed

- coherent by construction (make inconsistency impossible by design of the format or by offering updating functions that ensure the invariants)

OOP can actually help with some of these things! I develop mainly in C++, which doesn't encourage a purely OOP style like Java.

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

#372

Post by raducu »

jackblemming wrote: post #242
butwhywhyoh wrote: post #166

Earlier quoted context omitted.

The problem I have with talks like this is that they sound fantastic on the surface. They almost sound self-evident! "Duh! I want to make simple things, not easy things! That was great!" But where are the examples? Not a single example of something easy versus simple, or how something "easy" would resist change or be harder to debug. All of these concepts sound fantastic until you begin to write code. How do I apply…

Easy things work until you have to extend them or do anything the least bit complicated. Think of SQL or most "easy" declarative APIs. Or even worse, ORM engines. Simple things are normally also easy to use, but you may have to write some more boilerplate and there's less "magic". Steve wrote a simple CRUD API that gets some data and returns it. Bob tried to be clever and write a loosly typed declarative cluster fuck…

A bit like haiku, wonderful when you read it, extremely hard to maintain conversations in haiku.

Or like an improv exercise where you have to improvise a dialogue, but only by using questions, no afirmations.

Can it be done? Sure, but not by most people, not in real time. Again, wonderful when you see it done right.

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

#373

Post by dvt »

grumpyprole wrote: post #353
dvt wrote: post #347

Earlier quoted context omitted.

> Proper state encapsulation would be to use mutable state internally for efficiency, but for that state to be unobservable externally. This is literally how private/public keywords work, so I think your criticism is unfounded. However, I do agree with the overall sentiment that OOP implementations tend to "leak" way too much state than they need to.

I think you misunderstood my point. Private may protect direct access to mutable state, but the object may still have mutable state that is observable externally and must be reasoned about. In which case, the mutable state is not truly encapsulated.

Ah, I see what you mean, though I do think that immutability purists like yourself have their own monsters to contend with (even apart from the obvious performance hit).

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

#374

Post by vbezhenar »

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…

What is state? Every local variable is state. I can convert any global variable to a local variable or function argument with trivial changes. Does it mean that every local variable is the real enemy? Only empty program is perfect. But useless.

I'd say that not just state is the real enemy. It's all about life time of a particular bytes. `(x, y) => (x + y)` is a good function. Its state is discarded pretty fast. `(x, y) => (z) => (x + y * z)` probably is a bad function, its state is preserved for a long time. Global variable state is preserved during the whole program run. Database state is preserved during the whole software lifecycle or may be even more.

And that's not even about state is enemy. It's about how much time do you need to design this particular code. When you're thinking about database structure, that's a real deal. Take a lot of time, that's important and decisions will have impact for years or even decades. When you're designing pure function which does not leak any state, you don't need to think at all, just slap something and move on, you can easily replace it later if need arises.

TLDR: prefer state with short life time, be very careful with code that works with long time state.

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

#375

Post by kaba0 »

grumpyprole wrote: post #362
kaba0 wrote: post #355

Earlier quoted context omitted.

That is not hidden by immutable data either - the state is just global in the latter case, in a way. There is no getting away from essential state, from a theoretical point of view. In my opinion the often leaky partial encapsulation of state is still one of the better ways to deal with it. And immutability is another axis so of course the frequent case where it makes sense should be adhered to, but not religiously.

It is much easier to reason about immutable state than mutable state, both for humans and compilers, especially in a distributed setting (any modern piece of hardware). The problem with "leaky" encapsulation as you put it, is the combinational explosion of the state space as many stateful objects are composed. Most mainatream programming languages are still unfortunately not well geared up for working with immutable…

> The problem with "leaky" encapsulation as you put it, is the combinational explosion of the state space as many stateful objects are composed.

I don’t think it has to be necessarily more than with an immutable approach. Like, there is an essential amount of state you will have to have either case and it is not clear to me that immutability is always the better choice.

But don’t get me wrong, I also default to immutable data structures, I’m just saying that 1) OOP is not incompatible with FP 2) not every problem is solved better with FP-idioms. It’s not accidental that haskell has state monads as well.

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

#376

Post by raducu »

mujina93 wrote: post #365
usrusr wrote: post #96

Earlier quoted context omitted.

That time part is what you are wrestling with when you are battling with state. So it's natural to think about it that way. But there's also this somewhat dumbed down version of the argument: every piece of state a method reads is like an additional function argument and every state it writes an additional return value. What a mess.

This made me think: if we wrote object oriented code methods where all the members that we access are passed explicitly as parameters, as well as all the members that we modify (as out references), then we at least would immediately identify the real complexity of some methods! I'll try to do this, I'm curious to see how that would look like.

> I'll try to do this, I'm curious to see how that would look like.

That looks like a terrible mess.

The problem is not state, but messy access to it.

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

#377

Post by ummonk »

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…

General purpose quantum processors are likely more than a decade away (assuming they're popular in the first place).

But vanilla C/C++ is already obsolete for performance - if you're writing high performance code it needs to be in CUDA, or some language / library that compiles down to CUDA.

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

#378

Post by ummonk »

emrah wrote: post #220

Here is a different take: OOP is not evil. State is not evil. They exist for a good reason: Procedural is "linear" while OOP is "layered". One could write code either way but OOP better resembles the physical world and since brains have grown up in the physical world, layered code is easier to grok. It can hide/show pieces such that you can inspect functionality in a controlled way. Of course procedural can do the sa…

> OOP better resembles the physical world and since brains have grown up in the physical world

The part about OOP which doesn't resemble the physical world though is encapsulation. Encapsulation is like pretending the world functions in passive voice, with objects doing things to themselves.

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

#379

Post by kaba0 »

taeric wrote: post #259
lostcolony wrote: post #19

Earlier quoted context omitted.

I think in a lot of ways you're correct. FP and imperative code tends to makes state explicit; OOP hides state. The latter MAY make things "easy"; it never makes it simple.

To continue my hot take from earlier, OO wasn't supposed to "hide" it anymore than FP was supposed to. Rather, OO was supposed to be about changing the metaphor of the program as you are writing it. This is most easily seen if you consider a TON of the domain specific languages out there. Logo, PostScript, DVI, GCode, etc. Many of these are "move to X" "put down pen", "move to Y", "pick up pen", etc. Very imperative…

I think you are exactly right. There is a huge difference between data-oriented and behavior-oriented parts of a program. OOP is only a great tool for the latter but it does allow for immutability besides it, it is not either-or.

Wrap the behavior in classes and have data as data. Hopefully this will be indeed the direction taken by Java with its records and other new TBD features.

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

#380

Post by magpi3 »

wpietri wrote: post #305
baryphonic wrote: post #283

Earlier quoted context omitted.

If you want functioning, robust, maintainable software (or even better, software that doesn't require maintenance), then spend a long time modeling the problem domain. Build it as a system of types, a protocol, perhaps even a language (or at least an AST with semantics). Prove things about this model, particularly some useful things about soundness, consistency and (in)completeness. Learn all the funky symbols people…

What sort of domains do you see as sufficiently well-understood and stable where this process is even achievable? A lot of my career has been in domains where we are exploring problems by building and shipping things to see what really works for users and customers. And other times there's domain volatility driven by changes in technology and competitive landscape. Even for domains that are stable and knowable, I hav…

Compilers maybe?
Post reply on HN