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

201–210 of 220 posts

Re: The Repeated Deaths of OOP (2015)

#201

Post by kaba0 »

valenterry wrote: post #198
kaba0 wrote: post #196

Earlier quoted context omitted.

I didn't want to repeat myself as the exact meaning was debated in two threads in this post already, for more details please have a look at them. And I agree, we do have to specify what is the denotation of an expression that shall remain constant after replacing a sub-expression with that part's denotation -- for example choosing value of expression after evaluation is not too interesting, as it is shared by the maj…

If you do not point out any contradictions even after being asked twice then I have to conclude that you simply cannot. You could have also referred specifically or quoted the important lines from the other threads, but you did neither. That's not helpful in a discussion. > Choosing the denotation as "value and side-effects" doesn't add much over saying simply that the language is pure You are aware that, regarding t…

https://news.ycombinator.com/item?id=27415670

https://news.ycombinator.com/item?id=27414992

> FP means that every expression (= part that can be evaluated) is referential transparent

> Referential transparency implies immutability

Both of these statements are false. As I said, Java is referentially transparent.

addOne(2)’s value is the same as the value of the last line in `var a = 2; addOne(a)`. And Java is most definitely not a pure FP language, and its referential transparency doesn’t imply immutability. You can argue that inserting `int two() { sideEffect(); return 2; }` ‘s invocation in place of 2 will change the semantics of the program but that is precisely the meaning of a side-effecting function — so using referential transparency is redundant in that meaning.

Re: The Repeated Deaths of OOP (2015)

#202

Post by Rochus »

carapace wrote: post #180
Rochus wrote: post #145

Earlier quoted context omitted.

Aren't turing machines and the lambda calculus equivalent, i.e. each can efficiently simulate the other?

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?

Re: The Repeated Deaths of OOP (2015)

#203

Post by tome »

slver wrote: post #171
tome wrote: post #138

Earlier quoted context omitted.

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.

It's very hard to make Haskell look attractive to me, I deal with open systems (i.e. systems which interact with many other heterogenous systems which evolve in time), and Haskell is optimized for precisely the opposite case (a walled garden built out of elaborate types for verifying correctness). Haskell is the weird introvert guy in an extrovert world.

Hmm, not really. See, for example, Clash, a Haskell compiler for synthesising hardware circuits, or Cardano, a massively distributed software system realising a cryptocurrency.

Re: The Repeated Deaths of OOP (2015)

#204

Post by ProfHewitt »

cout wrote: post #170
bob1029 wrote: post #94

In my experience, OOP works great until you run into a problem domain with circularly-dependent types that actually make sense as such to the business. Certainly, there are ways to manage this within the realm of OOP, but I strongly argue that these solutions are half-assed at best. Also, nesting of complex types (i.e. making assumptions about the shape of the domain model) also seems to be a large part of what cause…

Even the most fundamental types in smalltalk derivatives are circularly defined (using Ruby as an example: Object is an instance of Class, and Class inherits from Object). Circularity doesn't make this any less useful as a model, just more difficult to reason about. It's a tradeoff.

Axiomatization up to a unique isomorphism is the way out of the circularity.

Actors have been automatized up to a unique isomorphism.

See the following:

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

* https://papers.ssrn.com/abstract=3418003

Re: The Repeated Deaths of OOP (2015)

#205

Post by valenterry »

kaba0 wrote: post #201
valenterry wrote: post #198

Earlier quoted context omitted.

If you do not point out any contradictions even after being asked twice then I have to conclude that you simply cannot. You could have also referred specifically or quoted the important lines from the other threads, but you did neither. That's not helpful in a discussion. > Choosing the denotation as "value and side-effects" doesn't add much over saying simply that the language is pure You are aware that, regarding t…

https://news.ycombinator.com/item?id=27415670 https://news.ycombinator.com/item?id=27414992 > FP means that every expression (= part that can be evaluated) is referential transparent > Referential transparency implies immutability Both of these statements are false. As I said, Java is referentially transparent. addOne(2)’s value is the same as the value of the last line in `var a = 2; addOne(a)`. And Java is most def…

Thank you for explicitly pointing it out.

I disagree with you - I think you are using a different definition and there seems indeed to be discussion about what the definition really is. Wikipedia for examples uses the definition that I use, but in the Talk-section someone made a similar complaint to yours (or was that you :)). [https://en.wikipedia.org/wiki/Referential_transparency]

I stick to my definition though, because... I find it more useful and I think it is the more common one.

Re: The Repeated Deaths of OOP (2015)

#206

Post by [deleted] »

valenterry wrote: post #176
slver wrote: post #90

Earlier quoted context omitted.

> Tell me what the universally agreed foundation of OOP is. I'll deliberately avoid terms so we don't get to argue about words, but rather substance. 1. Objects have identity that's independent of their state (two objects with same state are still distinct). 2. Objects contain implementation which is hidden, including optionally mutable state. 3. Communication occurs through handlers/methods/calls, which provide only…

Doesn't 4 contradict 1? Or do you mean "can stand for one another in a certain context". That would be rather weak criteria then though.

[deleted]

Re: The Repeated Deaths of OOP (2015)

#207

Post by slver »

valenterry wrote: post #176
slver wrote: post #90

Earlier quoted context omitted.

> Tell me what the universally agreed foundation of OOP is. I'll deliberately avoid terms so we don't get to argue about words, but rather substance. 1. Objects have identity that's independent of their state (two objects with same state are still distinct). 2. Objects contain implementation which is hidden, including optionally mutable state. 3. Communication occurs through handlers/methods/calls, which provide only…

Doesn't 4 contradict 1? Or do you mean "can stand for one another in a certain context". That would be rather weak criteria then though.

1 is about object identity. 4 is about object type/function. I.e. polymorphism.

It may seem like a weak criteria if you're using to OOP/FP languages that provide typesafe, efficient polymorphism out of the box. But the reason we have Obj C and C++ is that polymorphism (while also maintaining encapsulation etc.) is a living nightmare in a language like C.

Re: The Repeated Deaths of OOP (2015)

#208

Post by pflanze »

tome wrote: post #101
pflanze wrote: post #79

Earlier quoted context omitted.

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

> Equivocation about purity, referential transparency, mutability, side effects etc. is not very interesting.

It's what the current discussion is about, since I explained why I explicitly didn't make a statement about immutability being required for FP.

> The operative point is that, in Haskell, firstly

> x = expression

> y = expression

> ...

> is the same as

> x = expression

> y = x

> ...

Sure but that's the pure part of a program.

    x
is not generally the same as

    x
and I pointed out that you can have such a program (i.e. with mutability) inside a function that is pure to the outside.

The interesting feature of Haskell / Monads is that you can have mutability be both inside and around pure expressions (impure code making use of pure code and then impure code again inside the implementation of pure code). Not everything in a Haskell program needs to be pure. Of course, pure expressions are good since they are easier to reason about. Also, they are the core idea of FP as I mentioned earlier. But, I want to avoid people taking away the impression that you then never can use mutable data structures, and that's why in my original comment I didn't make a statement about immutability being required for functional programming.

Functional programming has a core idea and that is pure expressions (referential transparency), and then features to help increase the area of programs which are pure expressions and increase the confidence / safety of them being so. With regards to that confidence, Haskell goes far (there's still unsafePerformIO (and non-total functions) so it's not completely perfect). And I'm not disputing that when I say that it still is and always was called functional programming when there were no language-provided features to give that confidence, or only "half-assed" ones if one wants to call them that. Or only culture and convention. My point in the whole discussion is to explain why functional programming doesn't mean the same thing for everyone, and how it can both be that @slver says "there's no clear definition of FP" and that there is at the same time. There is a clear definition for referential transparency, which is the core idea of FP. But the term FP also encompasses various approaches and tools with varying qualities to enable that core idea, and it's here where there's no clear definition.

Re: The Repeated Deaths of OOP (2015)

#209

Post by slver »

valenterry wrote: post #200
slver wrote: post #171

Earlier quoted context omitted.

It's very hard to make Haskell look attractive to me, I deal with open systems (i.e. systems which interact with many other heterogenous systems which evolve in time), and Haskell is optimized for precisely the opposite case (a walled garden built out of elaborate types for verifying correctness). Haskell is the weird introvert guy in an extrovert world.

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?

Re: The Repeated Deaths of OOP (2015)

#210

Post by majjgepolja »

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…

> What is definitional? Inheritance, encapsulation, methods.

I am probably missing something, but how is inheritance essential for OOP?

In my understanding, inheritance is not necessary. The point of OOP was probably encapsulation. At some time inheritance became popular for "code reuse", until a preference for composition over inheritance developed.

Emphasis on inheritance is what infuriates me about many traditional sources about Java programming etc.. My java textbook says "object model" is major detail and "typing" is a minor detail. I am like, WTF, you cannot understand java object model until you understand type system.

Post reply on HN