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

151–160 of 220 posts

Re: The Repeated Deaths of OOP (2015)

#151

Post by tome »

kaba0 wrote: post #147
tome wrote: post #140

Earlier quoted context omitted.

I never quite understood Uday's objection. Any language can be referentially transparent if you consider it's denotation to be just its syntax. Then you can always replace equals with equals, but the only thing equal to an expression is the exact same sequence of characters! The whole point is to be referentially transparent with respect to as coarse a semantics as possible. Haskell gets some of the way there, yet ev…

I’m having a “debate” about it at another thread as well, so let me just point to a perhaps better explanation: https://elarib.com/item?id=22141647 So taking eg. Template Haskell, you actually loose referential transparency since then even the syntax itself matters and you can’t just replace it to an equivalent expression. I have no experience with Template Haskell itself so bare with me, but eg. having a macro m tha…

Firstly, I'm not sure you can even write that in Template Haskell. The syntax would actually be

    let a = 2 in $(m a)
and since `a` is not in scope at the time the TH splice runs compilation will fail. Secondly, even if you could write it, I don't really think something that contains Template Haskell should be called a "Haskell expression".

With regard to pron's comment, he has a long history of being technically correct with regard to Haskell. The operative point is

> What they mean is that the language is referentially transparent (like most language) and a term's reference (denotation) is an object value in the language

i.e. Haskell is referentially transparent with respect to a particularly coarse semantics (value semantics).

Anyway, your greater point that referential transparency doesn't imply immutability is completely correct.

Re: The Repeated Deaths of OOP (2015)

#152

Post by acdha »

ratww wrote: post #123
acdha wrote: post #105

Earlier quoted context omitted.

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 w…

Abstraction is good, but it's not a feature specific of OOP, though. From the perspective of Procedural Programming this also works well: brew(coffeemaker) , defrost(oven, "meat", "500g") , accelerate(car) . Same for FP: brewed(grains) , defrosted(meat, time) , withAcceleration(car) .

Nobody was claiming that it was unique - if you reread the thread, I was just pointing out that the dismissal of OOP not fitting the way people thinking about the world wasn’t necessarily approaching it correctly.

Re: The Repeated Deaths of OOP (2015)

#153

Post by jtdev »

valenterry wrote: post #74
jtdev wrote: post #70

Earlier quoted context omitted.

From the Swift docs regarding closures (I would have used Haskell doc reference, but the Haskell docs are so esoteric and vague as to be nearly useless): “A closure can capture constants and variables from the surrounding context in which it’s defined. The closure can then refer to and modify the values of those constants and variables from within its body, even if the original scope that defined the constants and va…

Swift is not a language that enforces code to be pure functional though.

FP = debating largely academic nuances that have almost zero material effect on software deliverables, purely for ego driven reasons.

Re: The Repeated Deaths of OOP (2015)

#154

Post by ProfHewitt »

A big challenge with OOP is that it was never rigorously defined.

Objects originate in Simula-67.

OOP derived from objects of Simula by its very name.

Simula does not have messages.

Instead Simula has virtual procedures attached to classes

such that each object is an instance of a class.

Furthermore, Simula does not have interfaces.

Actors originated in 1973 as the universal abstraction for

digital computation including concurrency, which was omitted

from Simula and subsequent OOP programming languages.

Furthermore, Actors differ from OOP objects in that they are

rigorously characterized up to a unique isomorphism.

Actors are computationally more powerful than the lambda

calculus and Turing Machines.

Re: The Repeated Deaths of OOP (2015)

#155

Post by cout »

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…

I agree; many OO models are built in a contorted way that does not reflect reality.

Still, the fact that you refer to the coffee machine as a noun and not a process tells me that you do think of that device as an object. And yes you do put the water into the machine and turn it on, then it produces coffee as an output. Some people might rightly say that makes it a function; others might rightly say that makes it an opaque object. That both views are common tells me that there is something natural about both ways of thinking.

Re: The Repeated Deaths of OOP (2015)

#156

Post by c-cube »

jcelerier wrote: post #68
chriswarbo wrote: post #25

Earlier quoted context omitted.

If this is the essence of OOP, would you consider modules/existential-types in StandardML to be OOP? As a followup, what about OCaml (is that "more OOP"?)

ML modules are definitely OO

See, that's just ridiculous and shows how undefined and vague "OO" is. The only relevant feature there is encapsulation, that most languages provide in some way. How is that OO?

I vote for just not using this term anymore and talk about class based langusges or prototype languages or whatever.

Re: The Repeated Deaths of OOP (2015)

#157

Post by ProfHewitt »

nailer wrote: post #2

As the article mentioned the meaning of OOP changed over time. Alan Kay has a description of OOP that sounds like the actor model used in erlang/elixir or mq and consuming services elsewhere.

Smalltalk evolved over time.

Is Smalltalk in 1972 an OOP programming language?

Re: The Repeated Deaths of OOP (2015)

#158

Post by ratww »

kaba0 wrote: post #139
ratww wrote: post #126

Earlier quoted context omitted.

> Though wouldn’t using arrays of structs kill the performance the same way as array of objects do (stack-allocated ones)? Not really. Components are long-lived so they're not allocated on the stack. And contiguous arrays of structs/objects is the best case for cache locality, that's the entire performance case of ECS.

A simple struct/object having in order an int, a string pointer and another int having 3 different things happening to them can in some case be worse than having all the ints next to each other, etc. ISIISI… vs III…SSS…III.. So for cache locality the latter is the best option.

Not really. There's no silver bullet when it comes to AoS or SoA. If you have a pair of integers, A and B, that are supposed to be always read/write together, the ABABAB of ECS beats AAA...BBB in terms of cache locality, hands down.

The advantage of ECS in this case is that it enforces data organisation to be coherent to the way data is used.

All this is mentioned on the seminal articles about Data-oriented Design, including the ones that popularised the terms AoS and SoA, and in lots of literature about modern ECS.

I suggest looking up what Entities and Components mean in ECS. It is doing all those things you're thinking of, but in a more optimal way.

Re: The Repeated Deaths of OOP (2015)

#159

Post by kazinator »

ncmncm wrote: post #116
locallost wrote: post #65

Earlier quoted context omitted.

He has been pretty clear in giving a lot of credit to the inventors of Simula, but that at the same his ideas derive more from Lisp. He even has a Quora answer where he explains that Lisp is the greatest language because he views it as a big shift in thinking. There is also a well known clear answer of his to the question of what is OOP to him. We ended up with something different in real life, but it's pretty silly…

On some people, Alan Kay's territorial claims to others' ideas leave a bad impression. Nobody begrudges him (with Dan Ingalls) Smalltalk, which represents a serious material improvement over Lisp syntax. But it looks like sour grapes to complain about C++, a language designed by a grad student of Kristen Nygaard that found success in industrial applications. Practical reasons for that success—independent programs tha…

> were chosen with careful deliberation

In actuality, it went probably closer to: "I'm gonna make a textual preprocessor for C that gives it Simula-like classes, for shits and giggles".

Re: The Repeated Deaths of OOP (2015)

#160

Post by throwaway894345 »

acdha wrote: post #150
throwaway894345 wrote: post #146

Earlier quoted context omitted.

> 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. (1) I'm not dismissing, I'm criticizing. (2) I'm very clearly not arguing that all OOP proponents are always acting in bad faith. > 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…

> I'm very clearly not arguing that all OOP proponents are always acting in bad faith. You made sweeping unqualified assertions which are hard to reconcile with that claim: “OOP proponents reliably turn the debate toward semantics rather than engaging with the substantial criticism” “We could have a more interesting, robust debate, but poorly defined terms + bad faith means we get the same no true Scotsman rhetoric o…

> If that’s what you believe going in, it’s unsurprising you’re not finding better quality outcomes.

It’s not what I believed going in, it’s a summary of my cumulative experiences.

Post reply on HN