Hacker News Reader

Comment by Kiro | Hacker News Reader

Would you recommend starting with Scala before Haskell if one want to learn FP?

I want to add some color to the other answers saying "no". If your medium-term goal is to use FP for business problems (e.g. perhaps you are responsible for technology decisions), then the OP's path of "Scala for the Impatient" -> "Functional Programming in Scala" -> "Learn You a Haskell" will likely provide the easiest transition and expose you to "real world" solutions in FP. Learning F# will give a similar pragmatic path (although its complications are due to .NET rather than the JVM).

However, if you are interested to "learn FP", as in see what all the fuss is about, then there are more direct routes. My own recommendations are for Graham Hutton's "Programming in Haskell" and "Real World OCaml" (https://realworldocaml.org). There are many other good (albeit verbose) resources but these two are the shortest path (IMO) to understanding the "common denominator" and historical underpinnings of functional programming languages and functional programming. Dan Grossman's "Programming Languages" course at Coursera was also quite accessible and comprehensive, but I think it may be closed now.

No. Scala does some interesting things, but it adds a lot of complexity in order to interact with typical JVM code.

Haskell doesn't have that kind of baggage, so at its heart it's a very very simple language (Lambda Calculus + algebraic datatypes + typeclasses). There are a bunch of extensions, but they can be mostly ignored while getting to grips with the basics.

Programming in Haskell can involve a lot of unfamiliar concepts like monoids, functors, monads, etc. but these are just the APIs used by libraries; the language itself doesn't care about them (except for "do" notation). Just like you don't need to understand design patterns to learn how Java works.

And yet that complex JVM interaction makes one possible way to "get toes wet" is to wrap existing lower level java processes (and libraries and things) in a larger functional wrapper. Top down. Assuming you have some experience, confidence, or sample code in java that you can use or understand in the problem domain. So rather than trying to find a way to use recursive functional definition of a factorial in your code (bottom up) it Might be possible to work top down and make the "main loop" or whatever of your java program a functional construct of some sort.

I am in no way claiming this is the best way, only way, or even a good way to learn FP concepts but it is a possible way to at least get feet wet, plus or minus your personal characteristics. It is merely an alternative to the extremely popular nearly universally pushed educational strategy of bottom up introduction of FP.

Because Scala is a hybrid language, I feel it doesn't really try to teach FP, but some amalgamation of the two. So you'll end up thinking about case classes, traits, companion objects, unapply, etc... it's a way to solve problems in a unique way, but in comparison with the other more traditional FP languages, it doesn't present the same feel and can obscure which features are the ones necessary for FP - which is important to know if you're specifically trying to learn FP.

You are technically correct in your observations, but I think we're both stuck in a classic "glass is half empty" "glass is half full" observational trap. Both the good news and the bad news simultaneously about a hybrid language is you can implement the same solution two different ways.

If you did both intentionally for educational purposes, it might be fun. I like the many "koan projects" and a side fork that focuses intentionally on doing something two ways might be interesting, if its not already been added while I wasn't looking.

A 3rd "no" from here. Scala is unnecessarily complex because of the Java/JVM compatibility. It's not built from ground up on functional principles, but rather "augments Java" with functional features.

My recommendation is that start with Haskell or Scheme.

No. Actually it would be easier to learn Haskell without knowing any imperative language at all. For me Scala also was "gateway drug to Haskell" and after using Haskell for some time I got some good FP habits which made my Scala/JS/whatever code better.

Haskell made my C code better.

To jump on this bandwagon, no. From personal experience, FP concepts only clicked for me when I was forced to use them. Scala always has that imperative escape hatch; can't think of how to write this immutably? Just make it mutable and move on. And the language is huge, with a lot of OO bits you need to learn and work around.

If your goal is to learn FP, Haskell is a better option, since it will really force you to think functionally in a way that 'softer' FP languages don't. With Scala there is always the temptation to do things the 'obvious' procedural way each time you get stuck on something.

No. What I've found with Scala projects is that it ends up as a typical OO app but with some FP constructs. Yes you see a reduction in the amount of code written but with added complexity.

I would go with Clojure (if you still want to leverage Java libraries) or Haskell personally.

If you want to focus on FP and not worry about the existence of libraries, I'd say to go with Clojure. The learning curve is not that steep and it's a very pragmatic language.

Schema or Clojure would be a good first FP language. It has very simple syntax and structure that allow you to concentrate on the FP ideas.

Reply on news.ycombinator.com