Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Where FP meets OO

christopherhunt-software.blogspot.com

Post reply on HN
Print view View original

41–50 of 64 posts

Re: Where FP meets OO

#41

Post by jowiar »

ufo wrote: post #20
seanmcdirmid wrote: post #11

Earlier quoted context omitted.

OO is more about naming and relating things than the fundamental truthiness of math (and likewise FP). They are just as much about communicating with humans when coming up with a solution as they are about actually getting the computer to act on the solution. Algorithms don't even come into much play in many typical programming tasks, so the premise of Stepanov's observation is probably flawed (or assumes certain tas…

I don't agree with that. Naming things and communicating well is something you have to do in every programming paradigm and is not specific to OOP. IMO, if you want to see what OOP is really about you should focus on its unique features: inheritance, subtype polymorphism, etc.

To me, OOP is, first and foremost, about messages. Everything else is negotiable.

Re: Where FP meets OO

#42

Post by tracker1 »

jowiar wrote: post #41
ufo wrote: post #20

Earlier quoted context omitted.

I don't agree with that. Naming things and communicating well is something you have to do in every programming paradigm and is not specific to OOP. IMO, if you want to see what OOP is really about you should focus on its unique features: inheritance, subtype polymorphism, etc.

To me, OOP is, first and foremost, about messages. Everything else is negotiable.

Messages, across boundaries is more FP than OO though... it actually adds complexity to do this in an OO paradigm.

Re: Where FP meets OO

#43

Post by virtualwhys »

tel wrote: post #34
virtualwhys wrote: post #23

Earlier quoted context omitted.

Certainly Haskell, for example, is one of the few languages richly endowed with a non-existent module system, but I personally don't know of a distributed computing environment that does preserve types across machine boundaries in any language. I must be missing something, please enlighten. If type preservation in distributed computing was a trivial engineering problem it would have already been solved and widely use…

I'm not claiming it's a solved problem; I'm claiming that the current solutions are lacking. You can take it as standing on the outside and throwing stones, but it's not malicious. I want something better.

Yeah, I know, same deal with type safe database query DSLs, none have hit the mark yet, including M$'s Linq to Sql, Scala's Slick, Haskell's Esqueleto and Opaleye, etc.

Seems we're on the brink of a completely type safe distributed stack, but argghingly not quite there. Maybe in another couple of years the computing community will have turned the corner.

FWIW, from the outside looking in Haskell seems to be kicking ass in terms of language evolution (7.8 and 7.10 in particular). Here on the Scala side of the fence we've got a ways to go, probably 4 years or so until the dust settles with various compiler forks and research work brings a (hopefully) vastly improved Scala into being.

Re: Where FP meets OO

#44

Post by tracker1 »

tel wrote: post #19
Pxtl wrote: post #18

Am I the only one who finds the goalposts gave moved for FP? it used to be lambdas/lexical closures that were the big must-have FP feature, then it was immutability. Now that we're seeing traditionally-OO languages sport a raft of immutable types and good support for lexical closures, now it's all about higher-kinded-types. For a while, the big feature was homoiconicity and tail-call-optimization until lisp fell out…

FP isn't a technical definition—it's a social phenomenon. As soon as you see it that way you'll never be confused by the use of the term again.

I've just tried not to be dogmatic about it... You can use a functional style without relying on immutable types or tail call optimization.

I think it comes down more to a personal style... we tend to conflate programming to engineering, which it rarely is. More often it is a craft discipline. It's more style, taste and personal preference.

That said, when you have to grow something past a few million users a day, or start to hit C10K/C10M barriers. Even then, there are ways to do that... to break up the load.

Re: Where FP meets OO

#45

Post by otas »

Alan Kay was inspired by the real world, mostly biology back when psychotropic substances were rather popular. That's were the problems start. The real world systems are: 1) unpredictable - except for those who can forecast the future. 2) Unreliable 3) Slow 4) Uncoordinated - except if you believe someone runs the world. 5) Unmaintainable - just ask someone on human maintenance (drug research etc). 6) Naturally autonomous

Point 6 is very critical, because in von-neumann architectures you will end up having a shared memory and trying to give an autonomous memory to each agent, will end up very suboptimal, and no zipper, COW of any other FP trick can change that.

You just cannot afford to write your software like the real world, and you don't even have intelligent agents of human ability as building blocks...

Re: Where FP meets OO

#46

Post by abathologist »

abathologist wrote: post #36
the_af wrote: post #33

Earlier quoted context omitted.

> because mutability may break homoiconicity (which is required for purity) Are you sure you meant that? My (admittedly weak) understanding of homoiconicity is that it's unrelated to either purity or (im)mutability. Isn't homoiconicity related to the program text and its AST? Aren't there languages such as Haskell which encourage pure functions but are not homoiconic? I'm pretty sure you meant something else...

I bet "referentiality" was meant. It would make sense as a replacement for "homoiconicity".

I bet "referential transparency" was meant. It would make sense as a replacement for "referentiality". oops :(

Re: Where FP meets OO

#47

Post by Denommus »

abathologist wrote: post #36
the_af wrote: post #33

Earlier quoted context omitted.

> because mutability may break homoiconicity (which is required for purity) Are you sure you meant that? My (admittedly weak) understanding of homoiconicity is that it's unrelated to either purity or (im)mutability. Isn't homoiconicity related to the program text and its AST? Aren't there languages such as Haskell which encourage pure functions but are not homoiconic? I'm pretty sure you meant something else...

I bet "referentiality" was meant. It would make sense as a replacement for "homoiconicity".

Yes, that's what I meant, I don't know why I got it wrong.

Re: Where FP meets OO

#48

Post by tel »

virtualwhys wrote: post #43
tel wrote: post #34

Earlier quoted context omitted.

I'm not claiming it's a solved problem; I'm claiming that the current solutions are lacking. You can take it as standing on the outside and throwing stones, but it's not malicious. I want something better.

Yeah, I know, same deal with type safe database query DSLs, none have hit the mark yet, including M$'s Linq to Sql, Scala's Slick, Haskell's Esqueleto and Opaleye, etc. Seems we're on the brink of a completely type safe distributed stack, but argghingly not quite there. Maybe in another couple of years the computing community will have turned the corner. FWIW, from the outside looking in Haskell seems to be kicking a…

Yeah! I want to see an EDSL impl of a nicely typed Tutorial D sometime already!

Personally, I don't know that I care about the distributed part of the stack. I want something like Erlang's actor model in Haskell even on one machine. I think if there was a nicely typed way to do that (and see pipes-concurrent and mvc for nice examples) there'd be some fantastic "large scale" application operating space that would get opened up.

Akka does this somewhat below par with Erlang. I'd wonder if a GHC implementation of straightforward single machine Erlang's semantics could do better with typed effects and true asynchronous exceptions. This would be nice even with just effect typing (e.g. untyped channels and lots of living in some IO-alike) and could be a good interpreter target for simpler strongly-typed organizational designs.

I started fiddling with this (under the name hotep) a few months ago and got sidetracked but it keeps coming up!

Re: Where FP meets OO

#49

Post by seanmcdirmid »

ufo wrote: post #20
seanmcdirmid wrote: post #11

Earlier quoted context omitted.

OO is more about naming and relating things than the fundamental truthiness of math (and likewise FP). They are just as much about communicating with humans when coming up with a solution as they are about actually getting the computer to act on the solution. Algorithms don't even come into much play in many typical programming tasks, so the premise of Stepanov's observation is probably flawed (or assumes certain tas…

I don't agree with that. Naming things and communicating well is something you have to do in every programming paradigm and is not specific to OOP. IMO, if you want to see what OOP is really about you should focus on its unique features: inheritance, subtype polymorphism, etc.

You mean, objects aren't really about objects, since every programming paradigm has them? Well yah, that is kind of the point: it is hard to not think in terms of them, that is what 100k years of evolved linguistic capabilities have given us.

If you want to focus on unique features, then do that instead; Stepanov's argument was focused on thinking, not checkmarks.

Re: Where FP meets OO

#50

Post by seanmcdirmid »

otas wrote: post #45

Alan Kay was inspired by the real world, mostly biology back when psychotropic substances were rather popular. That's were the problems start. The real world systems are: 1) unpredictable - except for those who can forecast the future. 2) Unreliable 3) Slow 4) Uncoordinated - except if you believe someone runs the world. 5) Unmaintainable - just ask someone on human maintenance (drug research etc). 6) Naturally auton…

For point 6, that wasn't Kay but the simula crowd who invented OOP before Kay.

FP is like math: it isn't based on biology or natural human thought, but rather the truth of math. OOP is much more fuzzy, you can say things that you can't nescessarily prove are true via biased naming and relating (just like you could say and think as a person). Math is great and useful, but there is a reason we haven't evolved into straight up Vulcans yet.

Post reply on HN