The Repeated Deaths of OOP (2015) • Hacker News Board

Re: The Repeated Deaths of OOP (2015)

#131

Post by ratww » Sun, Jun 06, 2021, 6:51 PM UTC

slver wrote: post #82

valenterry wrote: post #54

Earlier quoted context omitted.

FP means that every expression (= part that can be evaluated) is referential transparent. Nowadays the word "functional" is used different from the original meaning (which some now call "pure functional") > Some FP is lazy, some isn't. The definition of FP implies that laziness is irrelevant. A language can enforce a pure functional style without being lazy or not. > Some is immutable, some isn't That's wrong. And it…

> > Some is immutable, some isn't > That's wrong. And it is a good example of why FP is much clearer defined. OCaml and F# are two examples of functional languages with freely supported mutable data types. So maybe what I said is "wrong" about your personal idea of what FP is. But it's clearly not "wrong" about the fact some people see immutability as optional for FP, which is the very point I'm making.

> OCaml and F# are two examples of functional languages

Both OCaml and F# are multi-paradigm languages that have FP features, but are not restricted to FP. The support for mutability comes from their imperative/OOP ancestors, not from FP.

Re: The Repeated Deaths of OOP (2015)

#132

Post by gnufx » Sun, Jun 06, 2021, 6:57 PM UTC

Concerning the mention of closures:

… it does seem to me that … OOP represents the discovery by the mainstream community that it is a good idea to associate code with data, but, since they still don't know how to do closures, they have bodged it. — Robin Popplestone, , comp.lang.functional

Re: The Repeated Deaths of OOP (2015)

#133

Post by carapace » Sun, Jun 06, 2021, 7:09 PM UTC

Rochus wrote: post #39

ebingdom wrote: post #35

Earlier quoted context omitted.

I would say it doesn't have a formal 100% unambiguous definition, but it's certainly _more_ well-defined than OOP: a functional programming language is one which is based on lambda calculus.

Isn't every existing programming language eventually based on (or at least traceable to) lambda calculus? OOP is just another way to organize code. Human language is unsuitable for " glass clear ", unambiguous definitions, just because of its inherent fuzziness (which is nota bene an essential property for efficient communication).

> Isn't every existing programming language eventually based on (or at least traceable to) lambda calculus?

No.

Prolog et. al. is based on Horn Clause representation and evaluated using something called SLD resolution.

"Concatinative" languages (like Joy) are based on function composition (not application.)

(FWIW, the Turing machine is not based on Lambda calculus. Not that TMs are a programming language.)

Re: The Repeated Deaths of OOP (2015)

#134

Post by gnufx » Sun, Jun 06, 2021, 7:11 PM UTC

ratww wrote: post #128

mariodiana wrote: post #108

Earlier quoted context omitted.

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

That's a great definition, but it mostly applies only to Smalltalk itself and a subset of Smalltalk descendants, like Ruby. EDIT: changed ancestor to descendant, thanks gnufx!

[s/ancestor/descendent/]

Not Erlang (maybe depending on whether you consider something like Armstrong's universal server extreme late binding)?

Re: The Repeated Deaths of OOP (2015)

#135

Post by ratww » Sun, Jun 06, 2021, 7:15 PM UTC

gnufx wrote: post #134

ratww wrote: post #128

Earlier quoted context omitted.

That's a great definition, but it mostly applies only to Smalltalk itself and a subset of Smalltalk descendants, like Ruby. EDIT: changed ancestor to descendant, thanks gnufx!

[s/ancestor/descendent/] Not Erlang (maybe depending on whether you consider something like Armstrong's universal server extreme late binding)?

Good question! Alan Kay himself definitely thinks so:

https://www.quora.com/What-does-Alan-Kay-think-about-Joe-Arm...

Re: The Repeated Deaths of OOP (2015)

#136

Post by gnufx » Sun, Jun 06, 2021, 7:18 PM UTC

locallost wrote: post #130

ncmncm wrote: post #116

Earlier quoted context omitted.

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…

I've seen a couple of his talks and read some of his comments here and elsewhere. I've never seen any territorial claims, quite the opposite. Can you give me an example?

Indeed. He's said that Sutherland invented OOP (along with the other things Sutherland "didn't know was difficult"). Like most people, I guess, I found out about Sketchpad from Kay.

Re: The Repeated Deaths of OOP (2015)

#137

Post by carapace » Sun, Jun 06, 2021, 7:20 PM UTC

kaba0 wrote: post #117

valenterry wrote: post #54

Earlier quoted context omitted.

FP means that every expression (= part that can be evaluated) is referential transparent. Nowadays the word "functional" is used different from the original meaning (which some now call "pure functional") > Some FP is lazy, some isn't. The definition of FP implies that laziness is irrelevant. A language can enforce a pure functional style without being lazy or not. > Some is immutable, some isn't That's wrong. And it…

Sorry, it’s my pet peeve, but referential transparency doesn’t mean what many think it does — what you mean is simply side-effect freeness. See the top answer here: https://stackoverflow.com/questions/210835/what-is-referenti...

That answer is so informative and yet it completely misses the point.

The problem is even called out in the answer itself:

> For example, our example "Edinburgh has been the capital of Scotland since 1999" signifies the fact that "capital of Scotland" depends on the time at which it is being considered. Such context-dependence is a reality, both in natural languages and programming languages.

"Therein lies the rub." Such context-dependence doesn't have to be a reality in programming languages. "2 + 2 = 4" is an eternal verity, not subject to context-dependence. The whole point of FP (going back to Backus' Turing Award paper where he introduces and defines "FP") is to operate in the pure realm of [binary Boolean] logic.

Re: The Repeated Deaths of OOP (2015)

#138

Post by tome » Sun, Jun 06, 2021, 7:21 PM UTC

slver wrote: post #120

tome wrote: post #101

Earlier quoted context omitted.

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

I'm not deep into Haskell, but isn't the interpreter monad pattern effectively a language within the language that acts in a very conventional procedural way for interacting with IO and other external concerns? I just wonder... does Haskell really need syntactic segregation for this, and how is that better than any language which can declare/enforce pure functions/modules without the entire language being like that b…

Well, give it a go! Or alternatively, look for languages that have been successful in enforcing any kind of purity and that also permit unrestricted use of higher order functions.

Re: The Repeated Deaths of OOP (2015)

#139

Post by kaba0 » Sun, Jun 06, 2021, 7:28 PM UTC

ratww wrote: post #126

kaba0 wrote: post #124

Earlier quoted context omitted.

Thanks for the details! Though wouldn’t using arrays of structs kill the performance the same way as array of objects do (stack-allocated ones)? So, one would essentially have to have a SOA, or — the OOP abstraction: a class of arrays that enclose this hot loop of code, making the implementation opaque to a calling code.

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

Re: The Repeated Deaths of OOP (2015)

#140

Post by tome » Sun, Jun 06, 2021, 7:29 PM UTC

kaba0 wrote: post #122

tome wrote: post #118

Earlier quoted context omitted.

Many other languages are not expression based at all. for loops cannot be considered "lambda calculus", for example (although of course there is a translation of them into a lambda calculus equivalent).

While they do have statements as well, they usually also have expressions, which are referentially transparent (and yeah I know it’s not the usage most people use, but it is the correct one: https://stackoverflow.com/questions/210835/what-is-referenti... ). (They don’t employ currying though)

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 even

    let x = e
        y = e
    in ...

is not equivalent to

    let x = e
        y = x
    in ...

if your semantics can distinguish expressions by the time they take to evaluate.

Still (to address your original question) people do consider lambda calculi with effects, so if the expression-based fragment of an imperative language supports lambdas with lexical scoping then sure you could get away with saying that "their expression are based on lambda calculus".