Live data from Hacker News

Where FP meets OO

christopherhunt-software.blogspot.com

11–20 of 64 posts

Re: Where FP meets OO

#11
post #10

I'm not sure that OO-ness is a desired property. Alexander Stepanov, original creator of the STL: "I find OOP technically unsound. It attempts to decompose the world in terms of interfaces that vary on a single type. To deal with the real problems you need multisorted algebras - families of interfaces that span multiple types. I find OOP philosophically unsound. It claims that everything is an object. Even if it is t…

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

Re: Where FP meets OO

#12
Scala is the only language that I know of that marries the world of FP and OO and thus does not need to “throw the baby out with the bathwater”.

Have you had chance to try Swift yet. It could do with Tail Call Optimisation but I do think it can already be used for functional programming.

Re: Where FP meets OO

#13
While I'm reasonably open-minded about using some parts of OO at higher levels of organization (or at least just genuine modules), I'm not sure Akka is the right place to land there. Functions which are just typed as `a -> ()` have lost (or hidden) all their interesting structure.

Re: Where FP meets OO

#14

In CLOS.

Why there are so many ignorant idiots in the world?

According to Alan Kay, the essence of OO approach (or paradigm if you wish) is a synthesis of a few fundamental concepts (like a Lisp itself) where not a single one can be removed because harmony (or balance) would be destroyed, and an ugly, mediocre construction would emerge instead (Java).

The concepts are:

* First-class closures - isolated, share-nothing abstractions.

* Nesting of closures, so they could have an internal structure.

* Message passing as the only way of communication among closures.

As long as you follow these three principles, you have "generics" for free, because all the operations are mere messages.

These are three of four principles upon which Smalltalk has been built upon.

Here is an illustration, assuming that we are implementing message passing as simple as a procedures call.

   (define (kons x y)
      (lambda (m)
        (cond ((eq? m 'car) x)
              ((eq? m 'cdr) y)
              (else (error "bottom!")))))

   (define (kar x)
      (x 'car))

   (define (kdr x)
      (x 'cdr))
Notice that using only these abstractions we could implement a unified list structure of Lisps (recall Escher's hands).

This is (surprise!) the "core" of Erlang - extending of closure-based language with immutable data with explicit message-passing, to create first-class agents (servers, etc).

Where is inheritance? Inheritance is just a protocol which specifies what to do with unknown message instead of signaling an error or returning a bottom like in Haskell.

What is MOP could be found in Wikipedia. Smalltalk was its ancestor.

What is CLOS? It is a DSL embedded in a Lisp (based on structures made out of closures) which implements some or other subset of MOP. MIT Scheme, for example, has SOS.

So FP meet OP in CLOS.

Re: Where FP meets OO

#15

Scala is the only language that I know of that marries the world of FP and OO and thus does not need to “throw the baby out with the bathwater”. Have you had chance to try Swift yet. It could do with Tail Call Optimisation but I do think it can already be used for functional programming.

I think LiveScript does a good job too.

But it's a bit of a niche product, not a LISP and more like Python.

Re: Where FP meets OO

#17
post #13

While I'm reasonably open-minded about using some parts of OO at higher levels of organization (or at least just genuine modules), I'm not sure Akka is the right place to land there. Functions which are just typed as `a -> ()` have lost (or hidden) all their interesting structure.

Then it's a good thing Akka 3.0 will be typed.

Re: Where FP meets OO

#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 of favour with language geeks.

Does FP just mean "has features of my favorite self-proclaimed-functional-language"?

Re: Where FP meets OO

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

Re: Where FP meets OO

#20
post #10

I'm not sure that OO-ness is a desired property. Alexander Stepanov, original creator of the STL: "I find OOP technically unsound. It attempts to decompose the world in terms of interfaces that vary on a single type. To deal with the real problems you need multisorted algebras - families of interfaces that span multiple types. I find OOP philosophically unsound. It claims that everything is an object. Even if it is t…

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.

Post reply on HN