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

31–40 of 64 posts

Re: Where FP meets OO

#31

Post by abathologist »

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…

I'm not an expert or professional, but I'll offer some few cents here.

I think your feeling that the "goalposts have moved" is a result of mistaking 'Functional Programing' as the name for a set of language features. Instead, I understand FP to designate a far reaching paradigm encompassing language design, computer science research, and the design and development of particular programs.

As I understand it, the initial motive for FP was the development of an elegant, mathematically grounded programming style in which the human readable forms of expression neatly reflect the underlying computational model. This is evident in John McCarthy's 1962 "A basis for a mathematical theory of computation"[0], where he presents

> a formalism based on conditionals forms and recursive functions whereby the functions computable in terms of certain base functions can be simply expressed.

The same principles seem to persist right through to the current wikipedia article on FP:

> In computer science, functional programming is a programming paradigm, a style of building the structure and elements of computer programs, that treats computation as the evaluation of mathematical functions and avoids changing-state and mutable data.

Of course, over the course of 50+ years of ongoing research into FP, and roughly 80 years of research into the functional expression of mathematical foundations, there have been lots of developments and plenty of emergent insights that have altered the reigning implementations of FP languages. The fact that OO languages can keep incorporating features that emerge in FP languages is simply a testament to the fertility of the paradigm.

The advent of type-theoretic constructs (like higher-kinded-types) in FP is directly related to the central motives and inspirations of FP. It continues to draw inspiration from developments in maths. Contemporary FP incorporating ideas from type-theory is just like LISP incorporating ideas form the lambda calculus. Since both FP is an ongoing research and design paradigm, the features and approaches associated with it continue to develop. And unless the implementation of FP languages ever overtakes the ongoing research into functional foundations of mathematics, FP will continue to incorporate findings that emerge in the latter.

I may be mistaken, but I don't believe homoiconicity was ever a central feature of the FP paradigm. And, as you note, is is only associated with FP because LISPs were the paradigmatic FP language for so long. But homoiconicity is always a feature of the primordial OO and LP languages, SmallTalk and Prolog.

[0] - http://dspace.mit.edu/bitstream/handle/1721.1/6099/AIM-031.p...

Re: Where FP meets OO

#32

Post by mercurial »

ufo wrote: post #21
mercurial wrote: post #8

Earlier quoted context omitted.

OCaml was doing that before any of them.

Although I find it interesting how Ocamlers only rarely reach for the OOP bits of the language. I think that this is in part due to the powerful module system that language has.

Indeed. Also, the object system doesn't have the reputation of being very fast. That said, it lets you use structural typing, which is extremely handy once in a while.

Re: Where FP meets OO

#33

Post by the_af »

Denommus wrote: post #26
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…

Functional Programming is just composing a program with pure functions, nothing else. Immutability and closures are required for that, because mutability may break homoiconicity (which is required for purity), and lack of closures means you can't pass state around. Higher-kinded types are very useful for helping with lots of functional abstractions, but they are a type system feature and have nothing to do with FP. I…

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

Re: Where FP meets OO

#34

Post by tel »

virtualwhys wrote: post #23
tel wrote: 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.

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.

Re: Where FP meets OO

#35

Post by abathologist »

Denommus wrote: post #26
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…

Functional Programming is just composing a program with pure functions, nothing else. Immutability and closures are required for that, because mutability may break homoiconicity (which is required for purity), and lack of closures means you can't pass state around. Higher-kinded types are very useful for helping with lots of functional abstractions, but they are a type system feature and have nothing to do with FP. I…

> they are a type system feature and have nothing to do with FP

I suggested in a sibling reply that the use of type-theoretic notions in FP is a natural out growth of the initial motives of the FP paradigm. While I wouldn't think that FP languages must incorporate type-theoretic notions, it does seem to me fitting that many would, since type systems have been involved with the functional understanding of computation since quite early on. Do think that line of reasoning make sense?

Re: Where FP meets OO

#36

Post by abathologist »

the_af wrote: post #33
Denommus wrote: post #26

Earlier quoted context omitted.

Functional Programming is just composing a program with pure functions, nothing else. Immutability and closures are required for that, because mutability may break homoiconicity (which is required for purity), and lack of closures means you can't pass state around. Higher-kinded types are very useful for helping with lots of functional abstractions, but they are a type system feature and have nothing to do with FP. I…

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

Re: Where FP meets OO

#37

Post by abathologist »

abathologist wrote: post #31
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…

I'm not an expert or professional, but I'll offer some few cents here. I think your feeling that the "goalposts have moved" is a result of mistaking 'Functional Programing' as the name for a set of language features. Instead, I understand FP to designate a far reaching paradigm encompassing language design, computer science research, and the design and development of particular programs. As I understand it, the initi…

(Too late to edit, but, in the last line, s/always/also).

Re: Where FP meets OO

#38

Post by dragonwriter »

Denommus wrote: post #26
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…

Functional Programming is just composing a program with pure functions, nothing else. Immutability and closures are required for that, because mutability may break homoiconicity (which is required for purity), and lack of closures means you can't pass state around. Higher-kinded types are very useful for helping with lots of functional abstractions, but they are a type system feature and have nothing to do with FP. I…

Mutability directly breaks purity whether or not it breaks homoiconicity. This should be obvious because on of the best known and oldest FP language families is both homoiconic and impure due to mutation (the Lisp family.) So homoiconicity is a non-sequitur.

Re: Where FP meets OO

#39

Post by JoelMcCracken »

gclaramunt wrote: post #30
dschiptsov wrote: post #14

Earlier quoted context omitted.

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

> 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. Care to explain? Doesn't make any sense to me...

Assume a class Run that inherits from class Action.

If a message is sent to an instance of run Run that the Run class has no knowledge of, the message will be sent to the parent.

Thus, if message m is unknown to Run, see if the parent classes know it.

Re: Where FP meets OO

#40

Post by dschiptsov »

gclaramunt wrote: post #30
dschiptsov wrote: post #14

Earlier quoted context omitted.

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

> 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. Care to explain? Doesn't make any sense to me...

A protocol is like a set of rules. It it specifies, for example, that each object (a closure) has special bindings, which holds references to its class (which is also a closure) and to itself, so it could send a massage to its super or to self. Classes could have its own methods (inner closures).

Basically, when you send a message, you have to specify a symbol, that corresponds to a method name, and parameters. The protocol specifies the "routing", like if there is no method that corresponds to this name, then send (forward) the very same message to your superior (exactly like they do in army, which is an implementation of the actor model).

If supers doesn't know what to do with the message, then there is panic - an exception.

The protocol also specifies the rules of shadowing of symbols, such that a method could be redefined (shadowed) within a closure, so it "overrides" a method with the same name from its ancestors.

Object methods (inner closures) could send messages to classes (invoking class methods) and then doing something with a returned value. Usually, there is some syntactic sugar for that.

In short, inheritance is a set of rules, and these rules could be implemented using various mechanism, like explicit message-passing (a-la Erlang) or implicitly, using procedures calls.

Brian Harvey in classic Berkeley CS61A explained these ideas much better than me.

https://www.youtube.com/watch?v=7u3pp7JCAIU

Post reply on HN