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

431–440 of 557 posts

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

#431

Post by rbanffy »

jshen wrote: post #188
taurath wrote: post #91

Earlier quoted context omitted.

> This is primarily because of inheritance, which seems counter-intuitive I agree that inheritance creates a lot more problems, but the usages of non-static methods and internal state even in classes with no usage of inheritance can feel just as bad, when you have a high level method utilizing instantiated objects. Internal state as a whole can be avoided fairly often

I don’t see much difference between some_state.do_stuff() do_stuff(some_state)

The second one scares me. It implies some_state is mutated (or not, we may just be logging something) by the do_stuff function while the first makes it very clear that some_state is in charge of doing stuff and that the implementation is aware of how some_state is implemented itself.

OTOH, the second one would be much better (and imply immutability) if it were written as

  new_state = do_stuff(some_state)
But it'd also allocate a new state.

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

#432

Post by jiriro »

baryphonic wrote: post #350
wpietri wrote: post #305

Earlier quoted context omitted.

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…

I've had largely the same experience as you, but I have seen some hints that real simplicity could be possible. If the domain is technology itself, there may be no underlying simplicity. Ultimately, I think we have to make a trade-off between simplicity and easiness. The approach I outlined would be incredibly expensive because the tooling for that approach isn't quite good enough yet, and stakeholders wouldn't even…

Could you please elaborate on Hickey’s and Kay’s key ideas and how to try them hands on?

I know about Smalltalk (Squeak) so I guess that is the playground for Kay’s. Would just playing with Clojure do the same for the Hickey’s?

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

#433

Post by EdwardDiego »

Draiken wrote: post #424
jay_kyburz wrote: post #345

Earlier quoted context omitted.

This is probably a bad habit, but I've been writing tests so that I don't have to actually navigate though my app, put it in the correct state, and push a button to see if the feature works or not. Writing the test is just faster.

This is one of the major sources of bugs in my experience. People write unit tests that are perfect and pass, but only pass because you give it exactly the right input to make it pass in the first place. Then when running the actual app, the data is not exactly like on the unit test and you have bugs. To cover those scenarios, we use integration/acceptance tests. So I always come back to the same question: then why s…

I use unit tests primarily for a) verifying my edge cases (like the old joke goes, "a tester walks into a bar and orders -1, 0, jkhkhkhjkh...") and b) preventing regressions.

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

#434

Post by rbanffy »

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…

> OOP as frequently implemented

This is the real issue with OOP. Abusing a type system, using inheritance when composition or interfaces would be more appropriate, etc.

I've seen pretty much every programming silver bullet implemented in the most horrifying ways by people who didn't understand the reasoning behind each approach.

You can write great FORTH and terrible LISP. You can write readable FORTRAN or APL (I'm stretching it a bit here) and elegant 6502 assembly. You can even write resilient and reusable JavaScript and PHP if you have the discipline to do it.

> If you're writing a service doing requests, you want as minimal state as possible.

The service can have a lot of state. What you really don't want is your client trying to keep track of it. When tempted to do so, you need to change the service.

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

#435

Post by jerome-jh »

ctxc wrote: post #130
zozbot234 wrote: post #20

This is basically a survey of a bunch of posts, and doesn't do much to provide a consistent critique. Regardless, the true weak point of OOP is arguably implementation inheritance, which just doesn't leave you with a consistent semantics that's open to extension and changes in the basic/derived classes (that is, the well-known "fragile base class" problem is still a showstopper). But that has always been a pretty ad-…

I still don't understand why it's bad! Feels like spaghetti sentences tied together as a single article. Why is OOP so bad, anybody? With scenarios, code samples or alternate implementations?

Inheritance in itself conflicts with encapsulation. First because it gives access to protected members of the super class. So it breaks encapsulation to the letter. Secondly because it hurts code locality so much. To such an extend it is difficult for the average programmer to determine what is going on by simple looking at the program. We have a recrutement test on this. Although candidates usually have a good intuition at what the test program does, it is amusing how easy it is to make them doubt by asking simple questions. Dynamic dispatch principle in itself is well understood but it opens so many questions about member access, non virtual methods access, overloaded method access to which people usually have no firm answer.

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

#436

Post by raspasov »

dwohnitmok wrote: post #351
raspasov wrote: post #323

Earlier quoted context omitted.

You can "solve" global mutable state with an IDE until you bring concurrency plus parallelism into the mix. Then all bets are off for mutable global state. In the case of Clojure, the map that you pass to a function is a value. It is guaranteed not to change underneath you and it can be freely shared with anybody.

Well to keep my contrarian hat on... > concurrency plus parallelism into the mix The hard part of concurrency is writing or writing+reading, not just reading, so an immutable map isn't going to solve everything. Instead the hope is that you confine the mutability to one place with various transactional guarantees (in Clojure's case, this is usually atoms) and then everywhere else you don't have to worry about it. But…

Those are well reasoned points.

I'm not going to delve into STM because that can be a whole book worth of discussion :). It's a fascinating universe, I've spent many hours (weeks, months?) exploring it, and I don't consider myself even close to an expert.

You are absolutely correct about the trade-off about atoms in Clojure.

Practically speaking, to start seeing retries you'd have to have a big number of updates going on at the same time. You can push a huge number of updates through a single thread. If you do have the need to do big throughput, you can explore not-so-idiomatic options like atoms-in-atoms, like you said.

IMO, the biggest unique benefit of combining atoms with immutable persistent data structures, comes from the fact that you can get unlimited number of consistent readers virtually for free. Any thread can look at (aka, deref) an atom, while the state/world keeps moving forward. I don't think any amount of tooling can solve that case for mutable data. A snapshot of a mutable data structure would require copying the whole data structure while using some sort of a locking strategy to stop writers while the read is taking place.

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

#437

Post by chadcmulligan »

_dain_ wrote: post #410
chadcmulligan wrote: post #368

Earlier quoted context omitted.

I always think the best argument for OOP is avoiding name space collisions - with procedural programs you have a bunch of functions that could be named the same - how do you separate them? OOP gives you the ability to wrap things together - their variables along with the methods that make sense for the objects - little collections of things that go together. Then once you have an object, sometimes you'll want to make…

Isn't that just polymorphism? There are lots of ways to get that.

don't think so - https://stackify.com/oop-concept-polymorphism/

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

#438

Post by bsenftner »

tonyedgecombe wrote: post #388
jcranberry wrote: post #247

Earlier quoted context omitted.

I've actually never really encountered issues with operator overloading. Is it just ADL, or are there any other canonical operator overloading issues?

It was abused a lot in C++, mostly because of weaknesses in other parts of the language.

Bullshit, it was the weakness in those developer's minds that screwed their use of this perfectly fine language feature.

This is a propaganda war, people. We are being told we are too dumb to handle knives. And the truth is, our industry lets incompetents play our roles, and we (those smart enough to use knives) must suffer the ramifications of those who stab themselves repeatedly and they cry out "it's the language!"

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

#439

Post by rbanffy »

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 smalltalk ideal of OOP lives on in all sorts of ways, but the deep inheritance chain version that gets taught in classes?

What is the deepest chain we find in SmallTalk itself? I can't check it right now, but I'm sure it's not as deep as some classroom examples I've seen. Inheritance makes a lot of sense when you are modelling the world, but most structures we see in the real world aren't that deep.

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

#440

Post by sirwhinesalot »

sirwhinesalot wrote: post #405
nyanpasu64 wrote: post #250

Earlier quoted context omitted.

Do relational models support sum types? I find them an essential feature in programming languages, nearly as important as structs or rows.

Unfortunately many don't. Standard Datalog for example doesn't have disjunction which you need to model sum types as relations. My preference is to have sum types modeled separately from relations as just a complex type that can be related as well. This is the approach taken by Souffle, a C++ Datalog implementation which supports sum types.

For some reason I cannot edit the post above, but I misspoke on Datalog, since it has disjunctions, just not in the head of rules. You can go pretty far with disjunctions in the body which suffices for most cases of modelling "sum types".

For example:

Stakeholder(X) :- Shareholder(X); Customer(X); CEO(X).

It's still a lot better to model them separately from the relations, for the same reason that you want to model relations between points as actual relations between points not between X, Y and X, Y.

Post reply on HN