Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Repeated Deaths of OOP (2015)

loup-vaillant.fr

Post reply on HN
Print view View original

101–110 of 220 posts

Re: The Repeated Deaths of OOP (2015)

#101

Post by tome »

pflanze wrote: post #79
valenterry wrote: post #72

Earlier quoted context omitted.

> Most real-world programming requires handling of side effects somewhere, so such programs have parts which are not referentially transparent. That's not correct though. Look at Haskell (or even stricter Idris). This is real world application code that can do whatever Java, C++, ... can do, but it is pure functional and hence doesn't contain any non referentially transparent parts. Just because an application is wri…

It's funny that you defend your view using Haskell, as I was replying with Haskell in mind. If you use the state monad, you encode local side effects. Then you use runState in a function that has a non-monadic type--a pure function. Feel free to argue that the state monad is only having pure expressions because it can be represented using only pure functions and partial evaluation. For all practical purposes it is us…

Equivocation about purity, referential transparency, mutability, side effects etc. is not very interesting. The operative point is that, in Haskell, firstly

    x = expression
    y = expression
    ...
is the same as

    x = expression
    y = x
    ...
and that, secondly

    x = expression
    ...
is the same as

    ...
when x does not appear in ... . Those are the important properties of Haskell (with regard to this discussion). Whether this advances the discussion is another matter ...

Re: The Repeated Deaths of OOP (2015)

#102

Post by [deleted] »

ncmncm wrote: post #13

Classes were never definitional for OO, so prototypes, as originated in Self and adopted in JS, are not a violation of it. Function calls and messages are, fundamentally, isomorphic. Messages were never definitional. The notion of "purity", everything is an object, was never definitional. That was a Smalltalk conceit. Alan Kay named the idea, but stole it. So he doesn't get to impose his religion. What is definitiona…

[deleted]

Re: The Repeated Deaths of OOP (2015)

#103

Post by theknocker »

So there's this thing which one might call an "object" which is fundamental to any discrete thinking we ever do and is, in fact, prerequisite for "concept." There are some bad ideas in what we call "OOP," but if you think have a reason you don't need a thing in programming, then good luck to you.

Re: The Repeated Deaths of OOP (2015)

#104

Post by jayd16 »

ratww wrote: post #93
samsquire wrote: post #47

ECS is often implemented in an OOP language. I know of no ECS languages. You have objects that you iterate over and apply changes to the struct or object's fields like x and y coordinates in a game tick for the "next state" Essentially you end up with lots of global functions and very large API space that has no ordering. There's inherent ordering to global function application to produce the correct result. So it pr…

ECS can also be implemented in functional or imperative languages, and it often is. The fact that ECS can be implemented in OOP languages doesn't make it an OOP pattern, only that OOP languages have Turing-completeness. You could also write Pure-FP code or implement Prolog in an OOP language, or vice-versa. > If you move the global functions to the entity objects themselves, you end up with OOP. You're probably talki…

Why do critics think looping over an array is somehow incomprehensible in OO and must be replaced with inheritance or something? Most ECS implementations are in OO languages. In Unity/C#, those systems are objects those arrays holding component information are even objects!

Its really not a stretch for OOP. Its just a design pattern.

Re: The Repeated Deaths of OOP (2015)

#105

Post by acdha »

mercer wrote: post #91
cout wrote: post #36

Earlier quoted context omitted.

Why do you consider inheritance definitional? Is it definitional by de facto, or is there an authoritative definition that you are using? The reason OO is a powerful organizational too is because it mirrors how many people naturally think about the real world. But inheritance as adopted by most simula-derived languages does not exist in the real world. What does exist in the real world is prototypal inheritance (spec…

> The reason OO is a powerful organizational too is because it mirrors how many people naturally think about the real world. I've never found myself thinking that my pan fries an egg. I fry an egg and use the pan and the stove to do it. I've also not found myself thinking that my pan hits an intruder and dents itself. I hit the intruder (well, if I had the courage) and the resulting 'data/object' now has 'dent' as a…

On the other hand, when you make coffee you probably aren’t thinking about how to heat the water, measure the temperature, adjust the flow rate, etc. When you use the microwave you don’t think about cycling the magnetron to hit the power level appropriate for the settings or spin the turntable. When you drive a car, you accelerate, brake, steer, etc. without directly manipulating all of the parts & microcontrollers which respond to those control changes.

You just call coffeemaker.brew(), oven.defrost(“meat”, “500g”), or car.accelerate(). From that perspective the OOP model works pretty well.

Re: The Repeated Deaths of OOP (2015)

#106

Post by kaba0 »

mercer wrote: post #91
cout wrote: post #36

Earlier quoted context omitted.

Why do you consider inheritance definitional? Is it definitional by de facto, or is there an authoritative definition that you are using? The reason OO is a powerful organizational too is because it mirrors how many people naturally think about the real world. But inheritance as adopted by most simula-derived languages does not exist in the real world. What does exist in the real world is prototypal inheritance (spec…

> The reason OO is a powerful organizational too is because it mirrors how many people naturally think about the real world. I've never found myself thinking that my pan fries an egg. I fry an egg and use the pan and the stove to do it. I've also not found myself thinking that my pan hits an intruder and dents itself. I hit the intruder (well, if I had the courage) and the resulting 'data/object' now has 'dent' as a…

In your first paragraph you have examples where you are indeed the actor. In the case of the coffee machine though, you are only the actor initiating an action (eg. the main method calling a given CoffeeMachine’s createCoffee method). And here is the great thing about OOP, you don’t have to know what exactly happens inside the machine, the way it heats up water, grinds coffee beans, etc, you only know what result you want and how to initiate an action, everything else is the responsibility of the machine.

And frankly, I don’t see the divide between “data structures and how we operate on them” vs OOP. They are not mutually exclusive. Some problems are data-first, others are behavior-first — so just be familiar with both and use the correct tool for the problem.

Re: The Repeated Deaths of OOP (2015)

#107

Post by teknopaul »

zepto wrote: post #87
cout wrote: post #36

Earlier quoted context omitted.

Why do you consider inheritance definitional? Is it definitional by de facto, or is there an authoritative definition that you are using? The reason OO is a powerful organizational too is because it mirrors how many people naturally think about the real world. But inheritance as adopted by most simula-derived languages does not exist in the real world. What does exist in the real world is prototypal inheritance (spec…

> is because it mirrors how many people naturally think about the real world I’ve seen this said, but never justified. Is there anything that supports it?

Interesting question. Objects with functions that they perform seems to be a construct post technology.

It's a good fit for a microwave but not for a door.

It's a good fit for a person or anything with intelligence but arguably OO is _not_ a good fit for an object.

Re: The Repeated Deaths of OOP (2015)

#108

Post by mariodiana »

Hermel wrote: post #16
ncmncm wrote: post #13

Classes were never definitional for OO, so prototypes, as originated in Self and adopted in JS, are not a violation of it. Function calls and messages are, fundamentally, isomorphic. Messages were never definitional. The notion of "purity", everything is an object, was never definitional. That was a Smalltalk conceit. Alan Kay named the idea, but stole it. So he doesn't get to impose his religion. What is definitiona…

The essence of OOP is not inheritance, that’s a nice to have. The essence of OOP is to encapsulate the data and the functions that operate on that data into an object and hide the internal state of the object from the rest of the program.

"OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late binding of all things." – Alan Kay

Re: The Repeated Deaths of OOP (2015)

#109

Post by acdha »

throwaway894345 wrote: post #42
kstenerud wrote: post #14

It sounds a lot like he's trying to claim victory via semantic quibbling. We've learned a lot and incorporated a lot of ideas, machines, and concepts into the mainstream over the past few decades. But one thing that hasn't stayed the same is what set of things fits into what grab bag encompassed by a word someone came up with decades ago to describe the state of things at the time. Once you start arguing "OOP" vs xyz…

> Once you start arguing "OOP" vs xyz or "FP" vs xyz, you've missed the point. I think if we were intellectually honest in our arguments this would be fine—we could manage that OOP is poorly defined. Instead almost every debate about OOP takes this form: someone criticizes things which are exclusive to OOP (e.g., inheritance) or very common in OOP (kingdom of nouns, everything having references to everything else i.e…

> We could have a more interesting, robust debate, but poorly defined terms + bad faith means we get the same no true Scotsman rhetoric over and over, and it’s hopelessly dull.

If you want a healthy and robust debate, dismissing defenders of the most popular paradigm as always acting in bad faith is not how you get there.

This would also be a good way for you to learn more about the field. For example, is “just bad code” actually more prevalent due to OOP or because it’s the default paradigm for the most popular languages (Java, C#, Python, even JavaScript although that’s messy) and especially those used by the legions of lower-skilled developers cranking out business logic? Does FP reliably produce better results or is that more a function of the areas where the style is the most popular and, especially, a selection bias for developers with training & motivation to work on more than basic Jira-mill projects? (Lisp had a similar challenge for comparison: a large chunk of the developers you could hire were graduates of elite CS programs who would have performed above average with anything and it’s really hard to run a control study where, say, half of them spent a year building the same system in VB)

Note that I don’t think there’s a simple Boolean answer to any of those questions. I think FP is a useful technique but, like any tool, it is not perfect and a good developer should have enough experience to be flexible based on the problems and resources.

Re: The Repeated Deaths of OOP (2015)

#110

Post by ratww »

jayd16 wrote: post #104
ratww wrote: post #93

Earlier quoted context omitted.

ECS can also be implemented in functional or imperative languages, and it often is. The fact that ECS can be implemented in OOP languages doesn't make it an OOP pattern, only that OOP languages have Turing-completeness. You could also write Pure-FP code or implement Prolog in an OOP language, or vice-versa. > If you move the global functions to the entity objects themselves, you end up with OOP. You're probably talki…

Why do critics think looping over an array is somehow incomprehensible in OO and must be replaced with inheritance or something? Most ECS implementations are in OO languages. In Unity/C#, those systems are objects those arrays holding component information are even objects! Its really not a stretch for OOP. Its just a design pattern.

ECS is doing a bit more than looping over arrays, though. In modern production ECS systems there's often the case where a System acts over two or more Components is very common, and looping itself is not good enough for those cases (because you get O(n^2), O(n^3), O(n^4), etc, etc complexity), so it's nowhere near as simple as that.

Like I said, it's possible to implement anything that is computable in any Turing-complete language. The fact that there are some ECS implementations in OOP languages speaks more to the popularity of those languages, rather than their capabilities or suitability to having ECS implemented in it. Of course ECS is going to need classes in languages that don't allow structs. Of course ECS is going to need classes in languages that don't allow freestanding functions. But that's doesn't mean that everything that is implemented in an OOP language can be considered just another OOP pattern.

ECS is a more foundational way of organising code, in the same space as OOP itself.

One of OOP features is encapsulation: data and methods living together. ECS enforces the complete opposite: complete separation. Another OOP feature is inheritance. ECS removes inheritance and replaces with composition.

If one says that ECS a just another design pattern, then it's only fair to say that OOP is also just a design pattern in itself, since I could implement OOP itself in C (see Linux Kernel), Haskell or ECS if I wanted.

Post reply on HN