I was going to purchase this but saw this fact and stopped myself. I get what the author is trying to do, but I'm not going to buy a book before it is completed. Especially with an unknown (to me) author.
It's like trying to sell me the Brooklyn bridge before it is even built.
I've been looking for more of a direct comparison of OO vs. FP with side-by-side examples. I think there are a lot of specific but concise examples for demonstrating the two paradigms. I tried to do a little bit of this in a recent post:
Would be interested to hear of any other resources that do something similar -- that show specific OO code and corresponding functional takes on the same code. I find that a lot of the discussions avoid getting down to specifics, with code.
The problem is that often there is no direct analogy. And even when there is an analogy, often they behave differently as far as modularity and extensibility are concerned.
OK let me be more specific (keep in mind that I am a little bit Haskell-minded right now so some of my examples apply to generic FP but some are more for Haskell):
As far as encapsulating state goes, you have objects in one side and closures in the other. Pretty straightfoward, if you see it in practice.
As far as control-flow goes, things are kind of very oposite. FP languages tend to use pattern matching (that is, switch statements / the observer pattern) on transparent types to do branching while OO languages settled to use message passing over opaque types. These two approaches are very much opposites - pattern matching makes it easy to add new functions and harder to add new "cases" and also forces types to be transparent. OO dispatching on the other hand, makes it easy to add new cases (classes) but makes it harder to add new methods. The objects are also opaque and encapsulated. (For more on this, search for the "expression problem")
As far as polymorphism goes, things tend to be pretty different. OO languages focus on subtyping, writing code that works seamlessly with a class and its subclasses. This is good for always being able to add new subclasses without breaking old code.
FP languages, on the other hand, tend to focus more on parameric polymorphism (generics, that is, writing code that doesn't care what types its manipulating) and Haskell handles ad-hoc polymorphism with type classes. Type classes are kind of like OO interfaces, but they allow type classes to be created after the types that "implement" them but do not allow you to turn previously monomorphic code into polymorphic code (so its kind of the opposite of OO in this sense).
----
Finally, if you are willing to go really academic on this, you can check out things like Cardeli's "A theory of Objects". Computer scientists inevitably end up translating everything back into the functional calculi they are confortable with and this leads to formal FP-to-OO translations, if that is what you are looking for. Just to warn you though, it turns out that some things like support for inheritance and dynamic dispatching can seriously complicate the final models.
The threshold question: what is your definition of FP, are you a schemer, ML, haskell, or maybe scala or F#?
I could recommend a lot of things to read, (but you've probably already read them), by language designers Wadler, John Hughes, X. Leroy, Odersky, Bertrand Meyer, Rich Hickey. Also the Channel 9 videos of Meijer, Bright, and Alexandrescu talking about D and haskell were terrific.
And for books, you probably know about Pierce's TAPL, but Harper's PL book is rarely mentioned
To anyone who hasn't, I recommend downloading the sample PDF - the available first chapter is a decent size and a great read. I am looking forward to seeing the rest of it!
Here's an excerpt:
I’ll start by teaching you just enough Clojure to be
dangerous. Then we’ll use that knowledge to embed an
object-oriented language within Clojure in a more-or-less
conventional way.
Now if that doesn't sound like an exciting start I don't know what does.
I would be interested in a review as well. Coming from an OO background, I've been looking for books/articles that focus more on "here's how you'd do that using functional programming" instead of just exercises going over syntax.
[+] [-] gphil|13 years ago|reply
Note that:
[+] [-] will_work4tears|13 years ago|reply
It's like trying to sell me the Brooklyn bridge before it is even built.
[+] [-] wellpast|13 years ago|reply
http://news.ycombinator.com/item?id=4154484
Would be interested to hear of any other resources that do something similar -- that show specific OO code and corresponding functional takes on the same code. I find that a lot of the discussions avoid getting down to specifics, with code.
[+] [-] ufo|13 years ago|reply
OK let me be more specific (keep in mind that I am a little bit Haskell-minded right now so some of my examples apply to generic FP but some are more for Haskell):
As far as encapsulating state goes, you have objects in one side and closures in the other. Pretty straightfoward, if you see it in practice.
As far as control-flow goes, things are kind of very oposite. FP languages tend to use pattern matching (that is, switch statements / the observer pattern) on transparent types to do branching while OO languages settled to use message passing over opaque types. These two approaches are very much opposites - pattern matching makes it easy to add new functions and harder to add new "cases" and also forces types to be transparent. OO dispatching on the other hand, makes it easy to add new cases (classes) but makes it harder to add new methods. The objects are also opaque and encapsulated. (For more on this, search for the "expression problem")
As far as polymorphism goes, things tend to be pretty different. OO languages focus on subtyping, writing code that works seamlessly with a class and its subclasses. This is good for always being able to add new subclasses without breaking old code.
FP languages, on the other hand, tend to focus more on parameric polymorphism (generics, that is, writing code that doesn't care what types its manipulating) and Haskell handles ad-hoc polymorphism with type classes. Type classes are kind of like OO interfaces, but they allow type classes to be created after the types that "implement" them but do not allow you to turn previously monomorphic code into polymorphic code (so its kind of the opposite of OO in this sense).
----
Finally, if you are willing to go really academic on this, you can check out things like Cardeli's "A theory of Objects". Computer scientists inevitably end up translating everything back into the functional calculi they are confortable with and this leads to formal FP-to-OO translations, if that is what you are looking for. Just to warn you though, it turns out that some things like support for inheritance and dynamic dispatching can seriously complicate the final models.
[+] [-] gtani|13 years ago|reply
I could recommend a lot of things to read, (but you've probably already read them), by language designers Wadler, John Hughes, X. Leroy, Odersky, Bertrand Meyer, Rich Hickey. Also the Channel 9 videos of Meijer, Bright, and Alexandrescu talking about D and haskell were terrific.
And for books, you probably know about Pierce's TAPL, but Harper's PL book is rarely mentioned
http://www.cs.cmu.edu/~rwh/plbook/book.pdf
http://channel9.msdn.com/Blogs/Charles/Alexandrescu-Bright-M...
http://lambda.jimpryor.net/translating_between_OCaml_Scheme_...
and a debate about monads, since nobody ever debates about them
http://haskell.1045720.n5.nabble.com/Martin-Odersky-on-quot-...
[+] [-] nickknw|13 years ago|reply
Here's an excerpt:
Now if that doesn't sound like an exciting start I don't know what does.[+] [-] Tashtego|13 years ago|reply
[+] [-] whichdan|13 years ago|reply