Live data from Hacker News

What I Wish I Knew When Learning Haskell

dev.stephendiehl.com

71–80 of 149 posts

Re: What I Wish I Knew When Learning Haskell

#71
post #70

Earlier quoted context omitted.

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 lite…

Agreed. Haskell is masters class in functional programming that is generally more interested in pushing theory forward (not necessarily a bad thing). If you are a .NET developer, F# is a wonderful language (based on OCaml) that allows you to ease in to FP since it supports functional, oop, and procedural programming. Plus, you have the whole .NET ecosystem as well. You can become very productive, very quickly.

A counter point: Haskell is pushing for practical applications of pure, statically typed lazy functional programming.

There is plenty of real-world Haskell code in production systems by industrial users.

The research is on practical applications.

Re: What I Wish I Knew When Learning Haskell

#73
post #67
post #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.

If I am not mistaken, Dijkstra advocated for Haskell to be used as a language of instruction at universities. There is an essay somewhere online about it. What I could find is this: [1]. Edit: Indeed, the PDF that is linked to in [1] looks like a scan of the original. [2] [1] https://chrisdone.com/posts/dijkstra-haskell-java/ [2] http://www.cs.utexas.edu/users/EWD/OtherDocs/To%20the%20Budg...

Thank you for mentioning, finding and linking to this!

Re: What I Wish I Knew When Learning Haskell

#74
post #62

Earlier quoted context omitted.

That is (infamously) not quicksort.

What's wrong with it?

Performance. Internal representation. You are not actually modifying things in place. Those are the equivalent of linked lists not arrays. That quicksort is not quick at all because the append operation in Haskell is linear. You can't use those lists to implement quicksort.

Re: What I Wish I Knew When Learning Haskell

#75
post #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.

I agree with this, learning Haskell was transformative for me. It changed the way I approached problems in every other language. I treat learning it as one of the 2 or 3 things that has most influenced my development skills. But the truth is that I still don't feel comfortable writing anything more than toy apps in Haskell. I'm not really sure how to unit test things when I'm passing complex monad transformers around…

I'm probably a lot lower than you but I feel I hit a similar wall. I naturally end up writing a function soup which feels super dirty.. as much as I dislike the term (uml-overload) there's a need for architecture that I don't know how to address in FP.

Re: What I Wish I Knew When Learning Haskell

#76

Earlier quoted context omitted.

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

As a counterpoint, I picked up (some) haskell pretty quickly. I read a lot of code and didn’t get bogged down reading explanations of what a monad is. I also avoided trying to understand too well what the evaluation semantics of the language were. When I read code, I focused on looking at the type signatures and understanding what they meant, then I would stare at the code and try to work out in my head why those def…

I would second this.

My experience is that people get scarred of so much new terms which get introduced in Haskell and that could feel overwhelming.

When beginning with Haskell, I would advice to just write code and try to intuitively understand bits, but not get down into unwrapping things or theory much. Stay high level and figure out how things interact as you would do in black box model. Don't open the box, but poke it and see what result you will get (in other words; just write code and do trial and error).

When you get comfortable with black-box learning then open the box and look for the details.

Re: What I Wish I Knew When Learning Haskell

#77
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 lite…

I’ve tried learning Haskell once or twice and it didn’t really click. However, I’m know knee deep in learning Lean, which is a dependently typed functional language that is also a theorem prover and it’s been a much easier ride. It’s not any less complex than Haskell but learning FP by essentially doing mathematics has made it a lot easier for some reason.

Re: What I Wish I Knew When Learning Haskell

#78

Earlier quoted context omitted.

What do you mean by "either do things the Haskell (way) or you don't do them"? Isn't that the same with every language? I still don't understand why people put all sorts of unfair labels on Haskell. By labelling Haskell with "fun", we almost make it sound like it can't be used in production.

For 99% of programmers, Haskell can't be used in production.

I wish I could give you a thumbs up for speaking plain truth here. Anyway programmers will find out for themselves how best to satisfy their customer need.

Re: What I Wish I Knew When Learning Haskell

#79

Earlier discussions: https://news.ycombinator.com/item?id=5546679 (2013) https://news.ycombinator.com/item?id=6868303 (2013) https://news.ycombinator.com/item?id=7637278 (2014) https://news.ycombinator.com/item?id=10209249 (2015)

https://news.ycombinator.com/item?id=14226310 (2017)

https://news.ycombinator.com/item?id=7904987 (2014)

Re: What I Wish I Knew When Learning Haskell

#80
post #67
post #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.

If I am not mistaken, Dijkstra advocated for Haskell to be used as a language of instruction at universities. There is an essay somewhere online about it. What I could find is this: [1]. Edit: Indeed, the PDF that is linked to in [1] looks like a scan of the original. [2] [1] https://chrisdone.com/posts/dijkstra-haskell-java/ [2] http://www.cs.utexas.edu/users/EWD/OtherDocs/To%20the%20Budg...

Note that Dijkstra recommendes Haskell over Java because Haskell is arcane and mathematical, which is good for learning computer science, not because it's good for writing software.
Post reply on HN