Where FP meets OO
christopherhunt-software.blogspot.com
christopherhunt-software.blogspot.com
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 true it is not very interesting - saying that everything is an object is saying nothing at all. I find OOP methodologically wrong. It starts with classes. It is as if mathematicians would start with axioms. You do not start with axioms - you start with proofs. Only when you have found a bunch of related proofs, can you come up with axioms. You end with axioms. The same thing is true in programming: you have to start with interesting algorithms. Only when you understand them well, can you come up with an interface that will let them work."
More discussion:
http://www.quora.com/Was-object-oriented-programming-a-failu...
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).
IMO, if you want to see what OOP is really about you should focus on its unique features: inheritance, subtype polymorphism, etc.
If you want to focus on unique features, then do that instead; Stepanov's argument was focused on thinking, not checkmarks.
Um, what? You have no FACTS to do proofs with without axioms; they are the fundamental statements one assumes to be true to define a logical system.
Somebody who insists that they need "multisorted algebras" while misunderstanding a fundamental definition in mathematical logic is exceptionally confused...
In mathematics, we certainly have ZFC as an axiom system now, but mathematics was performed for thousands of years without a "stable" axiomatic base. For example, calculus was developed before the axiomatic delta-epsilon definition for limits was created. The math was developed first, and it was only after the fact that mathematicians went back and set the theory on a stable theoretical footing.
Therefore, I believe Stepanov suggests a bottom up approach: You write an algorithm that performs your work first, and then once you have that, you can refactor the code into classes that encapsulate the various parts of your existing algorithm.
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...
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.
http://c2.com/cgi/wiki?AlanKaysDefinitionOfObjectOriented http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay...
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"?
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.
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. If someone claims that, this person doesn't understand FP or type systems.
OCaml and Standard ML are two examples of languages without higher kinded types but are just as good as Haskell for FP.
(Although they have a powerful module system to compensate for that).
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 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?
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...
You can do that in C#/F# too. There's nothing special about Scala from this point of view.
Last I checked you could not mix the two easily [0]
[0]: http://stackoverflow.com/questions/14280001/why-cant-we-use-...
PS And the linked question only describes the limitations of Visual Studio where you can have only one language in a given project.
Yeah just like C++ or Java now have "functional features". That doesn't make them functional languages, they don't promote functional programming to the extent that Scala does.
Aside from that, their type systems are much too unexpressive to allow for the style functional programmers are used to, not to mention they promote mutability.
Having lambdas makes you about as functional as C++ these days.
Functional/non-functional is a fuzzy distinction but C# is definitely not a functional language.
If it wasn't for nerfed imperative collection classes (to encourage functional solutions) in the standard library, you could totally just ignore the fact that Scala was a functional language at all; it is not in your face about it like Haskell.
It would probably be more correct to say that "Scala is the only language that does both FP and OOP very well." On marrying the paradigms....why not just use both as needed anyways? That is completely doable in C# as well, just not as well as in Scala.
If type preservation in distributed computing was a trivial engineering problem it would have already been solved and widely used. As it stands Akka is enjoying fairly widespread enterprise adoption in the distributed computing market, untyped-ness notwithstanding.
Interestingly, as saryant points out, Akka 3.0 apparently will be typed, although I was under the impression that the typed actor project was experimental/a long way off/not a sure thing. Guess things have changed for the better...
You can take it as standing on the outside and throwing stones, but it's not malicious. I want something better.
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.
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!
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.
But it's a bit of a niche product, not a LISP and more like Python.
Besides that, objects have structural typing, and you can even create objects without classes (somewhat similarish to anonymous classes, except instead of interfaces you have the structural typing to give you something like statically typed duck typing).
OCaml also has multiple inheritance and friend classes.
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))
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.
Care to explain? Doesn't make any sense to me...
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.
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.
In that toy example I should return an error, because '() is a legit value.
After about 53-th minute Odersky gets lost in side effects in a very simple code.
This is why there's nothing elegant about Scala.