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

501–510 of 557 posts

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

#501

Post by keithasaurus »

cryptica wrote: post #467
keithasaurus wrote: post #185

Earlier quoted context omitted.

Ah yes, the classic "No True Scotsman" OOP defense.

I've provided a very specific definition of what good OOP requires so it's not fair to suggest that my argument is pointing to some vague characteristics or is evasive. I can look at any project's code and assign it a score in terms of cohesion and coupling of the classes/modules/components. Other people who are experienced with OOP can look at the same code and they will come up with a similar score.

The point of "No True Scotsman" is that you have your own definition of high quality OOP, which is not universal. Maybe yours is the right way of doing things, IDK. But I think others would probably prefer different definitions. For a lot of people, this variation in opinion of how OOP should be used can lead toward a conclusion that OOP in and of itself is a confusing concept and difficult to get "right".

Some people, myself included, just try to avoid this complication altogether, by separating data from logic.

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

#502

Post by agumonkey »

native_samples wrote: post #499
agumonkey wrote: post #498

Earlier quoted context omitted.

point 3 is exactly what I'm saying

But the concept of a factory is independent from whether you name it. In Java you can write a factory like this: () -> new Thing(foo, bar); Behind the scenes it's a class, but you don't write it as such and you don't name it. Nonetheless, it's still a factory.

It's vacuous concept.

Also you're leveraging anonymous function syntax which is, interesting, to say the least. In Java 8- you'd have to write boilerplate class named after a pattern. Lastly creating something from outside information was done since forever, it's trivial when you don't invent ceremony around it. Hence my conclusion, it's a waste of time and effort.

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

#503

Post by lamontcg »

tialaramex wrote: post #468
lamontcg wrote: post #167

Earlier quoted context omitted.

I think the major problem is that base classes are really two different interfaces (public and protected) combined with a default implementation, all exposed as a public symbol that anyone can reference. So if you have a Vehicle base class with Car and Truck that inherit from it people will naturally externally do things like pass around List and will extend functionality with Lorry : Vehicle and start using it. This…

> so far I don't know what Go or rust programmers do that is any different Rust doesn't have object inheritance. So Car and Truck can't inherit from a class named Vehicle. However its Traits have inheritance, so for Car and Truck you could write implementations of a trait named Vehicle or a trait MotorTransport which inherits from Vehicle (and so you'd need to implement Vehicle too in this case as MotorTransport reli…

If traits map to interfaces and you have concrete implementations of those which can be composed into Car then rust is still just subtractive and eliminating inheritance. There's nothing you can do in rust then that you couldn't fundamentally do in OO languages by avoiding inheritance.

Which gets to the point of if we should be talking about avoiding inheritance specifically? Because "OO" is somewhat ill-defined.

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

#504

Post by grumpyprole »

dvt wrote: post #373
grumpyprole wrote: post #353

Earlier quoted context omitted.

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).

Absolutely we do! For example, garbage collectors are complex beasts that are hard to tune and tough to scale. But of course some OOP languages have started using GC anyway, in which case, I honestly believe they might as well be functional programmers :)

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

#505

Post by branko_d »

ummonk wrote: post #211
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? As everyone is telling you, it’s a poor paradigm that makes the developer’s job harder compared to both non-OOP approaches and better approaches (mixins / multiple inheritance). That said, one should be cognizant of the reason it was created in the first place…

> single inheritance allows C++ to implement fast polymorphism via virtual function

Multiple inheritance can be implemented to be as fast as single inheritance regarding virtual function calls, and typically is in C++ by keeping multiple virtual table pointers per object. The problem this brings is that we can have pointers/references to the different parts of the same same object. A Child* may point to the start of the object, but Parent* may point to somewhere in the middle (because that's where the parent's vtable pointer happens to be). This also means that casting a pointer can change it. This can introduce some "interesting" bugs, as you can imagine.

OTOH, there are languages like C# that don't do that, but require 2 "hops" when calling an interface method, causing a slight performance penalty (a class can inherit from at most one other class, but can implement multiple interfaces). But a reference to an object always points to the object's start, which is very important for garbage collector.

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

#506

Post by ummonk »

jiggawatts wrote: post #456
ummonk wrote: post #367

Earlier quoted context omitted.

Are you claiming Rust is incapable of writing microservices, being run on K8s, using service buses or event streams, etc.? Why focus on building OOP functionality into the language, when it should be the infrastructure and API frameworks that should be built for OOP?

A1) No. A2) Because it's about 1,000x to 10,000x more efficient. An awful lot of the "ills" of modern development practices boil down to the lack of ingrained rules of thumb related to performance. The difference between a local function call -- virtual or not -- and a network call can easily be a factor of a million . This just isn't in the mental model of most developers. The terms "nanoseconds" or "clocks" are not…

I mean, if you really care about performance, object-oriented is a poor choice as it doesn't map well onto the GPU.

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

#507

Post by AshamedCaptain »

Jtsummers wrote: post #140
AshamedCaptain wrote: post #98

Earlier quoted context omitted.

For the record, the Linux kernel is not huge, just large. Just saying that because many people here show Linux as a model of a "huge" software project and yet it absolutely isn't. E.g., project-wide refactors/API changes are still performed multiple times per release and done usually by a single-person team, something which would just be unthinkable in huge software projects. Agreed with the point, though.

What is your distinction between "huge" and "large"? The Linux kernel is over 30 million SLOC now (though a lot of that is drivers). That's "just" large?

I am mostly talking about concurrent contributors, but yes, even 30 MSLOC is just "large", not "huge". Stories of commercial software projects having to build "overnight" on server farms are common.

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

#508

Post by dragonwriter »

sirwhinesalot wrote: post #493
nec4b wrote: post #482

Earlier quoted context omitted.

You are building a straw man from your misunderstanding of the OOP technique. As 'dragonwriter' tried to explain it to you that mathematical model of a square being a kind of a rectangle has nothing to do with OOP modeling. Liskov substitution principle tells you that a rectangle cannot be a super class of a square.

If modeling taxonomies of the world is not OOP modeling, what is exactly? The very reason Barbara Liskov had to point out the damn principle is that people were doing dumb stuff like this. They still do btw. Universities still teach that Mammals have a walk() method that you implement for Dog and Cat, except then you need to add a Whale and now you're screwed. Silly example, but real world cases are much more subtle.…

> If modeling taxonomies of the world is not OOP modeling, what is exactly?

It is, but modelling the taxonomy of a different domain than the one you are operating in is not. “An mutable object whose current state will always correspond to some square and can be mutated to correspond to any square” and “A mutable object whose current state will always correspond to some rectangle and can be mutated to represent any rectangle” (which are the entities in the domain being discussed) are not the same things as “a square” and “a rectangle” (entities in the domain of geometry), and taking the is-a relationship that holds between the latter and trying to apply it to the former is bad modelling at a level prior to how it reduces to implementation in any particular programming paradigm.

> Universities still teach that Mammals have a walk() method that you implement for Dog and Cat, except then you need to add a Whale and now you're screwed.

To the extent this is true, it's a pedagogical problem not an paradigmatic one.

> If you haven't done Domain-Driven Design, with cute UML diagrams and everything

DDD is at least 3 decades more recent than OOP, and is not equivalent to it.

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

#509

Post by softwarebeware »

tomtheelder wrote: post #487
softwarebeware wrote: post #481

That's because what people call OOP isn't OOP. > “I invented the term object oriented, and I can tell you that C++ wasn't what I had in mind.” —Alan Kay. Read here for more info: http://xahlee.info/comp/Alan_Kay_on_object_oriented_programi...

What people call OOP is OOP, literally by definition. Alan Kay may have coined the term, but his version of OOP has nothing to do with what is commonly understood today, and is therefore irrelevant.

> What people call OOP is OOP

That's silly and not how definitions work.

definition noun def· i· ni· tion | \ ˌde-fə-ˈni-shən

an explanation of the meaning of a word, phrase, etc. : a statement that defines a word, phrase, etc.

In other words: words or phrases have actual meanings, regardless of what people call them.

To give you an example, people use "their" instead of "they're" all the time. It doesn't mean that "their" means "they're".

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

#510

Post by Hercuros »

baryphonic wrote: post #283
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…

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…

Speaking as someone with experience with many of those things (PL theory/formal verification background), I don't think they're even close to being a silver bullet.

Coming up with the right abstractions and the right domain model is difficult (especially if you just sit down and try to come up with stuff, you're likely to get it wrong the first time around). Knowing about some of those things could help you come up with better abstractions, but it's neither necessary nor sufficient to ensure that you will.

Take dependent types for example. They allow you to express more program invariants or correctness properties in your types. But actually using them requires you to write proofs (at least, if you're using them to their full potential). And I do think that in general System F like type systems hit a nice sweet spot and are generally good enough for the stuff that you might actually want to handle on the type system level.

I've also run into similar "proof-like" situations with much simpler type systems like those of Haskell and Rust, where I was structuring my types to "make illegal states unrepresentable", but in the process ended up complicating my program due to having to match the structure of my program to the expected structure of the types. Sometimes it is nice to _not_ to have the type system enforce some of your invariants. (Such things are also doable with dependent types of course, but this is just an example of some of the tradeoffs involved).

You can also still have a shitty domain model even if you use all of those fancy tools. They just allow you to be very formal/precise about the domain model (and do perhaps encourage some more uniformity by making it more annoying to express ugly or complicated things).

Post reply on HN