Live data from Hacker News

What I Wish I Knew When Learning Haskell

dev.stephendiehl.com

41–50 of 149 posts

Re: What I Wish I Knew When Learning Haskell

#41
post #2

Great timing. I was just pondering what functional programming language I should attempt to learn in all my new downtime.

If you want to learn a functional language absolutely do not learn Haskell.

If you're interested in static functional programming, learn Elm and then F#/OCaml.

If you're interested in dynamically typed then learn Clojure or possibly Racket.

That's it. Spending time learning Haskell as your first (or even second) fp language is a terrible idea and has done more to slow FP adoption than anything.

You can learn Elm literally in a weekend it's so small and well organized (go to their site and follow the tutorial). The concepts you pick up will double the speed you learn any other static FP.

F# on .net core is cross platform and can run via a vs code plugin. Plus you have a batteries included full class library of practical needs via dot net.

Clojure is very productive, great concepts as well. A bit worse tooling / debuggingqgen you have to drop down to deal with java, but also had batteries included java libs.

Racket is probably the most isolated of the above. A scheme dialect and a bit closer to historical scheme and Lisp.

Don't learn Haskell it's a horrible use of time as a first language. You get 80% of the value in the above languages in somewhere between 1/10 to 1/4th the effort (depending on which lang you choose), and have learned a more practical language, and will actually learn that lang plus Haskell faster than if you had started in Haskell.

Re: What I Wish I Knew When Learning Haskell

#42
post #2

Great timing. I was just pondering what functional programming language I should attempt to learn in all my new downtime.

I tried to learn FP multiple times by learning haskell. Never clicked, tried clojure and I was productive after roughly 2 days.

Haskell is very much the deep end of learning functional programming - it's at an extreme end of the spectrum in purity and type system.

The language I recommend as a first step to most people is Elixir (or Erlang). It's fairly pure, data is immutable, relies on recursion at the lowest level etc. Good code in Elixir is structure in a similar to good code in a lot of other functional languages (and so teaches good habits), but being dynamically typed is avoids that immediate pain of learning about how to keep the compiler happy.

Re: What I Wish I Knew When Learning Haskell

#43

Earlier quoted context omitted.

I disagree. quicksort [] = [] quicksort (x:xs) = let smallerSorted = quicksort [a | a x] in smallerSorted ++ [x] ++ biggerSorted

Not that I know any Haskell, but wouldn't smallerSorted already include x due to edit: also, how is the pivot element selected there?

Both of your questions have the same answer. (x:xs) means x is the first element and xs is the rest.

Re: What I Wish I Knew When Learning Haskell

#44
post #25

Earlier quoted context omitted.

Haskell has a huge catalog of libraries you can reach for, so you don’t have to reinvent the wheel. That said, the Haskell way can seem very different than what you see in most languages. As an example, IO—or anything causing a side effect—has to happen in the IO Monad. There are good reasons for this, but it takes some getting used to.

The parent poster is not lamenting that Haskell lacks a trivial sorting function. They are lamenting that implementing a trivial sorting function in Haskell is difficult.

Spot on. There's a lot of wisdom in this comment.

Re: What I Wish I Knew When Learning Haskell

#45
post #2

Great timing. I was just pondering what functional programming language I should attempt to learn in all my new downtime.

I like to think that ML languages, in general, are good to start to learn FP with.

SML by Dan Grossman is a great resource because it explains the concepts very well. Anything that you learn after will be easier, does not matter if you go for Haskell or F# later.

https://www.youtube.com/watch?v=a1fkhDjCHB8&list=PL-eVNDa9MN...

Re: What I Wish I Knew When Learning Haskell

#46
Really just learn it.

It's a pity I don't use Haskell at work and yet learning Haskell was the single most bang for buck exercise I have ever done. "Parallel and Concurrent Programming in Haskell" is the best resource I have ever read on parallel and concurrent programming concepts.

Every programmer should learn this language even if they never plan/get to use it.

Re: What I Wish I Knew When Learning Haskell

#48
post #36

Earlier quoted context omitted.

Haskell has a huge catalog of libraries you can reach for, so you don’t have to reinvent the wheel. That said, the Haskell way can seem very different than what you see in most languages. As an example, IO—or anything causing a side effect—has to happen in the IO Monad. There are good reasons for this, but it takes some getting used to.

But let's say I want to print something in a deeply nested function which isn't of the return-IO-Monad-type. Now I have to convert the entire call-chain of functions into Monad style. Is there some tool to do this automatically?

For debug there is Debug.Trace which is about perfect.

For non-debug, you may be overestimating how useful it is to output from pure functions in production.

In general when you are in a situation where you need to change the Monad you're under, there's techniques and libraries for that (one way you define it once, give it a name, etc.).

The biggest pain tends to be going from pure to monadic in the first place, which last I used Haskell there wasn't much for but to just do it. There may be more tooling now, haven't seen.

Re: What I Wish I Knew When Learning Haskell

#49
post #25

Earlier quoted context omitted.

Haskell has a huge catalog of libraries you can reach for, so you don’t have to reinvent the wheel. That said, the Haskell way can seem very different than what you see in most languages. As an example, IO—or anything causing a side effect—has to happen in the IO Monad. There are good reasons for this, but it takes some getting used to.

The parent poster is not lamenting that Haskell lacks a trivial sorting function. They are lamenting that implementing a trivial sorting function in Haskell is difficult.

Different things are hard or easy in Haskell compared to other languages. Mergesort would be the first one I'd reach for in Haskell if I'm implementing from scratch.

Quicksort isn't really hard, you just do it in IO and it looks about like what you'd see in any imperative language. (or you can use ST, but then you have to know about ST).

Re: What I Wish I Knew When Learning Haskell

#50
post #36

Earlier quoted context omitted.

Haskell has a huge catalog of libraries you can reach for, so you don’t have to reinvent the wheel. That said, the Haskell way can seem very different than what you see in most languages. As an example, IO—or anything causing a side effect—has to happen in the IO Monad. There are good reasons for this, but it takes some getting used to.

But let's say I want to print something in a deeply nested function which isn't of the return-IO-Monad-type. Now I have to convert the entire call-chain of functions into Monad style. Is there some tool to do this automatically?

Why would you want to print inside a pure function though?
Post reply on HN