qunfeng wang wrote:I have 2 questions about the book.
1. From the sample chapter, it's a book about FP. Scala is just a vehicle. Why do you choose Scala, a multi-paradigm language? Isn't it better to use some pure FP languages like Closure, Haskell?
2. Which paradigm do you usually use in your daily work? OO, FP or combined? and the reason?
Scala is not just pure FP, but rather a mix of OOP and FP and that makes sense as it plays very nicely with the plethora of existing Java libraries, given the fact that it compiles to the JVM. All the benefits of Java is available to you at hand which is not the case with Clojure or Haskell. If you are writing Scala code, try writing it in a functional style.
SCJP 1.4, SCWCD 1.4 - Hints for you, Certified Scrum Master
Did a rm -R / to find out that I lost my entire Linux installation!
Joe Harry wrote:All the benefits of Java is available to you at hand which is not the case with Clojure or Haskell.
Actually Clojure is a JVM language as well so I think there is pretty thorough interoperabiity in both directions with Java, although it looks a bit strange because you really are shifting paradigms between OOP and FP with Clojure, unlike Scala which is also an OO language and still looks a lot like Java.
Even though Scala is a multiparadigm language, it works well for purely functional programming, and writing the book with Scala would lets us reach a different, wider audience than if we wrote the book using a language like Haskell. Scala has a nice adoption story precisely because it is multiparadigm, interoperates with Java, and does not impose any particular programming style - people can start out using Scala as if it were Java with different syntax, and gradually incorporate more FP into their work. Runar and I also really felt like there was an unfilled niche, in that there were various books about Scala, but not really any books that deeply explored using Scala as a purely functional language, which was how we were using it.
Personally, I use Scala as a purely functional language in my day to day work. We usually refer to functional programming in contrast to imperative programming, not in contrast to OOP. People mean lots of different things by OO, but to the extent that it is well-defined, I think it relates more to how one organizes code, rather than whether side effects are used.
Paul Chiusano wrote:
We usually refer to functional programming in contrast to imperative programming, not in contrast to OOP. People mean lots of different things by OO, but to the extent that it is well-defined, I think it relates more to how one organizes code, rather than whether side effects are used.
I would say that abstraction (primarily through encapsulation) is one of the main features of OOP, which couples very well with abstractions available in FP (higher order functions and function composition). It can become an effective pair.
Scala gives you lot of freedom in how you organize your code. This is a nice feature because you can experiment. But it also blurs the ways to better combine both natures of the language.
I believe it will get even better when time and experience will provide us the insights necessary to pick out the most profitable combinations.