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

171–180 of 220 posts

Re: The Repeated Deaths of OOP (2015)

#171

Post by slver »

tome wrote: post #138
slver wrote: post #120

Earlier quoted context omitted.

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.

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.

Re: The Repeated Deaths of OOP (2015)

#172

Post by valenterry »

Zababa wrote: post #96
valenterry wrote: post #58

Earlier quoted context omitted.

Yes, please see my other answer - it is much stricter/clearer defined than any OOP definition that I've seen.

If I understood you correctly, you say that functional programming is what people usually call "pure fonctional programming"? If that's the case, the definition is better than OOP, but I don't think it's a property of functional programming but just that OOP is talked about more by more diverse people.

Yeah - the term "functional programming" is nowadays as unclear as OOP. But "pure functional programming" is not - there is no equivalent in the OOP world.

Re: The Repeated Deaths of OOP (2015)

#173

Post by valenterry »

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

Why are you so quickly assuming that you know better what I mean than I do?

Could you point out a specific point in my answer that is not compatible / or contradcits with the common definition of referential transparency?

Re: The Repeated Deaths of OOP (2015)

#174

Post by valenterry »

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…

> For all practical purposes it is used to write code that exerts (local) side effects into the state maintained by the state monad.

Yes, but as long as this is done with only pure expressions, then the whole program is pure functional - that is what the definition is about.

> You can a function in say, OCaml, that fills an array via mutation using only function arguments to deduct the contents, and then returns that array. That function is pure (it exerts no side effects outside and is not exposed to side effects from the outside, its result value only depends on the function argument values). Yet how is that not using mutation, non-referentially transparent parts inside?

The guarantee or at least convention of referential transparency for every expression has benefits. It means I as a developer can make certain assumptions about code that I could not make otherwise. I can do certain refactorings and changes while being sure that it will not change the program semantics.

As soon as parts of the program is not pure anymore, I know have to always re-assure myself that I'm currently working with the pure part of the code. Same for any tooling that I build.

As I said, you can make that choice and sometimes it is the best thing to do - but you cannot call your application "pure functional" anymore when you do.

Re: The Repeated Deaths of OOP (2015)

#175

Post by ncmncm »

kazinator wrote: post #159
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…

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

C++ was never at any stage a preprocessor.

It was, instead, the first of what became many, many compilers that generated C from its AST as the target assembly language, relying then on the C compiler's optimizer and machine-code generator.

Nowadays, LLVM IR fills exactly the role C once did, for new languages like Rust and Zig. Zig is just now in the middle of transitioning to its own optimizer and machine-code generator.

Preprocessors were also common at the time, e.g. m4, Ratfor, and Cpp ("C preprocessor", which initially was a separate program), so it is not surprising that Cfront was mistaken for one, back then.

That is not a reason to repeat the falsehood.

You don't get a runaway success for four decades by accident.

Re: The Repeated Deaths of OOP (2015)

#176

Post by valenterry »

slver wrote: post #90
ebingdom wrote: post #60

Earlier quoted context omitted.

To all the people downvoting me: if you really think OOP is as well understood as FP, learn some programming language theory. Tell me what the universally agreed foundation of OOP is. You won't be able to, but I can tell for FP it's lambda calculus.

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

Re: The Repeated Deaths of OOP (2015)

#177

Post by ncmncm »

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?

Kay has promoted many different definitions of "object-oriented", over the years, and many disjoint variations on Smalltalk's early history. It is probably best to stick to the very oldest interviews if you care to learn the real history.

Re: The Repeated Deaths of OOP (2015)

#178

Post by kazinator »

ncmncm wrote: post #175
kazinator wrote: post #159

Earlier quoted context omitted.

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

C++ was never at any stage a preprocessor. It was, instead, the first of what became many, many compilers that generated C from its AST as the target assembly language, relying then on the C compiler's optimizer and machine-code generator. Nowadays, LLVM IR fills exactly the role C once did, for new languages like Rust and Zig. Zig is just now in the middle of transitioning to its own optimizer and machine-code gener…

> generated C from its AST as the target assembly language, relying then on the C compiler's optimizer and machine-code generator.

That qualifies as a preprocessor to me.

You can get the sources to it, as late as 3.0.3 from 1994 here.

http://www.softwarepreservation.org/projects/c_plus_plus/ind...

Re: The Repeated Deaths of OOP (2015)

#179

Post by bccdee »

samsquire wrote: post #149
bccdee wrote: post #125

Earlier quoted context omitted.

Being written in an object-oriented language doesn't make code object-oriented. I could write Java using classes as (namespaces for stateless functions) XOR (structs with no methods), and while it'd still technically all be objects and methods, in practice it wouldn't embody the spirit of OOP at all. It is in keeping with the spirit of OOP to wrap up different entities' data in separate objects and have them interact…

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.

Re: The Repeated Deaths of OOP (2015)

#180

Post by carapace »

Rochus wrote: post #145
carapace wrote: post #133

Earlier quoted context omitted.

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

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

Post reply on HN