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

211–220 of 220 posts

Re: The Repeated Deaths of OOP (2015)

#211

Post by ncmncm »

bookofsand wrote: post #62
throwaway894345 wrote: post #32

Earlier quoted context omitted.

Every OO proponent seems to have their own definition of OO. Another I’ve heard is “message passing”, although that one even has many different flavors since it isn’t well defined and some argue that methods constitute message passing and others envision something closer to an Actor model. This is all well and good as long as people are clear about what their definition is (although it is weird how many proponents ha…

For yet another definition, OO is about encapsulated polymorphic interfaces. Which raises a communication difficulty: encapsulated polymorphic interfaces are very useful in some of the cases (ADTs, modules), and a misfeature for the other cases (data modeling). I have yet to see a conversation, especially an internet conversation, where participants reach a rough consensus on the contextualized upsides / downsides of…

Use it where it's useful, use something else otherwise.

It doesn't need much discussion.

If your language forces you to use mechanisms and organization inappropriate to the problem, the solution will be ugly and awkward. In that case a better language, or more usually a better job, is in order. The requirements might dictate the language, but they don't typically dictate you being the one to do it.

Re: The Repeated Deaths of OOP (2015)

#212

Post by carapace »

Rochus wrote: post #202
carapace wrote: post #180

Earlier quoted context omitted.

They're equivalent, but not identical. Lots of formal systems are Turing complete (e.g. Wang Tiles) and so can compute the same results as each other. Wolfram goes on about this some. I sometimes wonder about the possible form of the "Platonic Ideal" is that each of these systems represent. George Spencer-Brown's Laws of Form seems to me to be the ultimate concrete example, but that's not a universally held opinion.…

But doesn't that mean you can create a corresponding lambda calculus based version of a programming language, such as Landin did in his 1965 paper?

Of course, but you could do that with the other formal systems too.

It's like Roman numerals vs. base-10 numerals, eh? "XXIII" and "23" both denote the same number (which may or may not exist depending on your metaphysical outlook) but neither notation can be said to be "the" notation.

Re: The Repeated Deaths of OOP (2015)

#213

Post by Rochus »

carapace wrote: post #212
Rochus wrote: post #202

Earlier quoted context omitted.

But doesn't that mean you can create a corresponding lambda calculus based version of a programming language, such as Landin did in his 1965 paper?

Of course, but you could do that with the other formal systems too. It's like Roman numerals vs. base-10 numerals, eh? "XXIII" and "23" both denote the same number (which may or may not exist depending on your metaphysical outlook) but neither notation can be said to be "the" notation.

That's ok; my concern was just whether "every existing programming language eventually based on (or at least traceable to) lambda calculus" responding to the fellow which claimed that "a functional programming language is one which is based on lambda calculus".

Re: The Repeated Deaths of OOP (2015)

#214

Post by valenterry »

slver wrote: post #209
valenterry wrote: post #200

Earlier quoted context omitted.

Interesting - for me it is the opposite. Non-functional languages usually work better if there is no concurrency involved. And 3rd party systems always introduce a certain amount of concurrency, sometimes more, sometimes less. I would say pure FP languages such as Haskell are actually the best for such a case. Because in these languages the order/timing of lines of code are decoupled from the execution order/timing.

> I would say pure FP languages such as Haskell are actually the best for such a case. Because in these languages the order/timing of lines of code are decoupled from the execution order/timing. ... That's good in your opinion?

If your program is simple and LoC are executed one by one and that is totally fine, then FP just takes away the natural relation between LoC and execution and adds another layer of unnecessary complexity.

But when the percentage of concurrent code grows bigger, then it is better - because you lose the LoCexecution relation anyways.

You can for example see that in Python. Python makes it really hard to break out of that model and have a line of code running while another one is running. That's why paralle and async/concurrent programming is such a PITA in python.

So, in my opinion for some problems the FP style is much better, because instead of "working your way around", you embrace the fact that LoC and execution are inherently decoupled.

Re: The Repeated Deaths of OOP (2015)

#215

Post by samsquire »

bccdee wrote: post #179
samsquire wrote: post #149

Earlier quoted context omitted.

Functions grouped with data is inherently OOP. Even if you don't interact with a graph of objects in a class, you're still using OOP if you define methods on your class and use those methods to interact with fields.

A method on a class is just syntactic sugar for a function with an argument. It takes more than just "the presence of methods" for something to be OOP.

Isn't the grouping of methods with data a core fundamental principle of OOP? Even if it is syntactic sugar, Variables, Types, Classes, functions, method calls, structs are just syntactic sugar too. It just so happens that the syntactic sugar of grouping functions with data is OOP.

Re: The Repeated Deaths of OOP (2015)

#216

Post by aliasEli »

ProfHewitt wrote: post #162
Rochus wrote: post #48

Earlier quoted context omitted.

> The concept of a message is older than the actor model Publications by Hewitt or Sussman in the seventies even suggest that the concept traces back to lambda calculus. > so Smalltalk-style messages are still messages Only Smalltalk-72 had true "message passing" (i.e. arbitrary tokens sent to an object for interpretation); Smalltalk-76 onwards uses a virtual methods implementation similar to the one of Simula 67 or…

The tokens in Smalltalk-72 were not "messages" to Actors where whole messages are Actors. Since Actors are universal primitives of digital computation, it is possible to reframe all previous work as using messages, including Turing Machines and the lambda calculus. Lambda calculus was originally defined using string substitution. Both lambda calculus and Turing machines are computationally less powerful than Actors.

> Both lambda calculus and Turing machines are computationally less powerful than Actors.

Do you have a reference for that?

Re: The Repeated Deaths of OOP (2015)

#217

Post by aliasEli »

gnufx wrote: post #132

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

One of the very few things that most people can agree upon, is that SmallTalk is object-oriented. SmallTalk definitely has closures.

Also Java has them.

Re: The Repeated Deaths of OOP (2015)

#218

Post by gnufx »

aliasEli wrote: post #217
gnufx wrote: post #132

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

One of the very few things that most people can agree upon, is that SmallTalk is object-oriented. SmallTalk definitely has closures. Also Java has them.

I don't know what he considered the mainstream -- perhaps not Smalltalk -- but the comment pre-dates Java. (I think his POP-2 pre-dates Smalltalk.)

If you take the remark seriously, it's probably not just a question of having closures but what you (can reasonably) do with them. A Schemer might experiment with implementations of different object systems, Smalltalk-like, prototype-instance (about a page of code), and CLOS-like. Do people do so in Java (or even Smalltalk) and what does it look like if so?

Re: The Repeated Deaths of OOP (2015)

#219

Post by scroot »

gnufx wrote: post #218
aliasEli wrote: post #217

Earlier quoted context omitted.

One of the very few things that most people can agree upon, is that SmallTalk is object-oriented. SmallTalk definitely has closures. Also Java has them.

I don't know what he considered the mainstream -- perhaps not Smalltalk -- but the comment pre-dates Java. (I think his POP-2 pre-dates Smalltalk.) If you take the remark seriously, it's probably not just a question of having closures but what you (can reasonably) do with them. A Schemer might experiment with implementations of different object systems, Smalltalk-like, prototype-instance (about a page of code), and C…

In terms of Smalltalk, the answer is "yes". Some examples of what it looks like include the original Self language / environment [1], Newspeak [2], and even Tony Garnock-Jones' implementation of Actors [3].

Some of this has to do with the fact that the virtual machine for many Smalltalk implementations is implemented in Smalltalk itself. So you can start with Smalltalk and end up with something modified enough to be considered different.

[1] https://selflanguage.org/

[2] https://newspeaklanguage.org/

[3] https://tonyg.github.io/squeak-actors/about.html

Re: The Repeated Deaths of OOP (2015)

#220

Post by ProfHewitt »

aliasEli wrote: post #216
ProfHewitt wrote: post #162

Earlier quoted context omitted.

The tokens in Smalltalk-72 were not "messages" to Actors where whole messages are Actors. Since Actors are universal primitives of digital computation, it is possible to reframe all previous work as using messages, including Turing Machines and the lambda calculus. Lambda calculus was originally defined using string substitution. Both lambda calculus and Turing machines are computationally less powerful than Actors.

> Both lambda calculus and Turing machines are computationally less powerful than Actors. Do you have a reference for that?

See the following article:

https://papers.ssrn.com/abstract=3603021

Post reply on HN