9 ms·

What I Wish I Knew When Learning Haskell 2.0

251 points by tenslisi 13y ago

tenslisi 13y ago
There's also a very detailed tutorial on writing a toy compiler with Haskell and LLVM on this site: http://www.stephendiehl.com/llvm/ http://www.stephendiehl.com/llvm/
leccine 13y ago
The main force holding me back from learning Haskell is the cryptic syntax. I totally understand that the type system is (supposed to be) superior to other languages but it simply make it really hard to find the time. I am also unsure how useful this language can be in every day use. There are so many great languages out there nowadays, Clojure, Go, Erlang. It is easy to cover the spectrum with these and I don't see where Haskell would be a better fit. maybe somebody could shed some light on the strengths of this ecosystem.
- platz 13y ago
  I don't think it takes any longer to learn Haskell syntax than all of Clojure's reader macros (you will need them and the semantics is not obvious), or Scala's type system which has a lot going on, and I'm not sure about Erlang but I hear grumblings about syntax. There isn't actually that much in the way of actual syntax in Haskell (LYAH is a great place to start, don't just try to eyeball random code snippets), and it becomes preferable after some familiarity. What will take time is learning new concepts, programming purely and learning the tools to manage effects.
  - im3w1l 13y ago
    This is not true at all in my experience. Theano, a machine learning library for the gpu uses pure programming with syntax extremely similar to numpy, took about an hour to understand and "do useful stuff with". I've spent more than 20 hours on Haskell syntax and feel like I am not even halfway there to "doing useful stuff". EDIT: And I think time to be able to do something useful is a very important benchmark because after that point, further learning takes little effort or motivation.
    - platz 13y ago
      While I havent used that library, there are plenty of ways to write obfuscated code in Haskell. Some libraries may define their own operators (Scala suffers from this too), which can be impenetrable. Some libraries are better than others. Although, I don't consider defining new operator names part of the syntax of the actual language itself. I guess I'd just hope one doesnt start out jumping in to a complicated library. Its easier to start with more foundational materials.
      - platz 13y ago
        * I can see your point about speed to attain proficiency. I wish I had a good answer for this.
    - GregBuchholz 13y ago
      Maybe it is the pattern matching aspect that is throwing you for a loop? Are you familiar with Prolog, Mathematica, Erlang, or syntax-case macros from Scheme? Or is the the dollar sign ($), or something else that may be bugging you? Maybe post a simple example of one of the worst offenders.
      - im3w1l 13y ago
        It is not one thing in particular. It is just that there are so many things.
    - the_af 13y ago
      Are you sure it's the syntax? Haskell can be pretty complex to understand due to the abstractions involved, especially if you are less familiar with FP, laziness, etc. When I struggle with Haskell it's more "I don't understand the type of this" than "I don't understand the syntax". Syntax is the easy part!
- jerf 13y ago
  "The main force holding me back from learning Haskell is the cryptic syntax." Then you should go ahead and start. The syntax is pretty thin. It's not what you're used to, but it's thin. It's hard to describe what Haskell would be good for without sounding overenthusiastic, so I'll confine myself to saying that Haskell will expand your brain in ways that few other languages will. That said, Clojure is potentially one of those few other languages (depends on your personal development history, though IMHO enough stuff has been stolen from Lisp over the years that it's less of a mind-blow than it used to be), and you ought to learn about modern concurrency from at least one of Haskell, Go, Erlang, or Clojure (or possible Scala via Akka). Haskell opens you to the most correctly-implemented modern concurrency paradigms at once but any of those will get you most of the experience you need.
  - pekk 13y ago
    Ah. So what isn't Haskell good for?
    - anon_d 13y ago
      Haskell is not a great language for programs that need to fit within tight memory or latency limits. It's also slower in some cases than C/C++, but it's definitely competitive with other high-level languages. Other than that, it's pretty excellent for everything.
    - jerf 13y ago
      Well, in all seriousness, a situation in which a mind-expanding language isn't called for, because the minds in question don't currently work that way, and I am being 100% serious. I really like Haskell. It's among my favorite languages. However, I don't advocate for it where I work and tend to sort of tamp down on anyone else who tries because despite the fairly polyglot nature of where I work, we don't have the background to use Haskell very effectively at scale. I do this even as I advocate to all and sundry that they learn it anyhow for the mind expansion. When one is fluent in Haskell I think the language naturally tends to drive you towards well-factored, reusable designs that can handle change well. I say "fluent" because I don't think one needs to be "expert" to get to this level, but certainly there's a level of experience required to be here. Beginners and pre-fluency intermediates in the language produce god-awful messes of code. (I know, because I have! Fortunately I had the foresight to do that to throwaway personal projects, rather than critical business projects.) I think a great deal of the Haskell propaganda is justified, but beware the Haskell enthusiast who recites the propaganda, but can't clearly explain in their own words the mechanisms that Haskell uses to accomplish it. Actually, scratch Haskell out of that. Beware any tech enthusiast who can't give a coherent explanation in their own words of why the tech stack has the claimed effects, but just repeats the propaganda again.
- ademarre 13y ago
  In this video Erik Hinton talks about using Haskell in the fast-paced New York Times environment: http://www.infoq.com/presentations/haskell-newsroom-nyt http://www.infoq.com/presentations/haskell-newsroom-nyt
  - arms 13y ago
    This is one of the better Haskell videos I've seen - it's nice to see use cases in a high speed environment like the NYT.
- thinkpad20 13y ago
  As to Haskell's syntax, I think it's really just as complicated as it needs to be to express the ideas Haskell embodies succinctly and precisely. It doesn't have any more syntax than most other languages; it's just a very different syntax than most non-functional languages. And this is precisely because the semantics of the language are also very different. Haskell, for example, is not block-structured, as nearly all imperative languages are. (It does simulate this with do-syntax, but this is only a simulation). I understand though - I find Clojure practically unreadable, and this has kept me away from it to a degree. As to where Haskell fits: you're correct, there are many other great languages out there. But I think Haskell is really unique in offering what it does. Clojure, Go, and Erlang are all great in their own regard, but none of them provides the degree of safety that Haskell does. For example, none of them enforce purity, and all three of them freely allow the use of `null` values (which is really quite surprising considering how many problems nulls cause). Clojure and Erlang avoid mutable state like Haskell does (though not to the same degree of rigor) but don't provide the elegant solutions for simulating mutable state that Haskell does with its monads, which almost allow you to "have your cake and eat it too" with state. None of them encourage the degree of abstraction that you'll find in Haskell. Also, at least according to the Computer Benchmark game, Haskell beats all three of them in terms of speed, as well. Haskell's "place" is in generating highly robust code with good performance, and also works as a beautiful language for expressing certain mathematical concepts. This doesn't make Haskell a perfect language, but it absolutely has a lot to offer that other languages don't. And it's so much different than other languages, that at the very least it can change your perspective on a lot of things.
  - platz 13y ago
    I think one has to be careful about performance claims. Of course you can tweak things to be fast in hakell, but to be able to actually program haskell in such a way to, beat other languages in performance, is not a trivial skill. There are numerous stackoverflow and r/haskell posts "Why is my haskell code 10x times slower than language X?" Or observe this set of web framework benchmarks: http://www.techempower.com/benchmarks/ http://www.techempower.com/benchmarks/
    - 13y ago
- nilkn 13y ago
  > The main force holding me back from learning Haskell is the cryptic syntax. [...] There are so many great languages out there nowadays, Clojure, Go, Erlang. Erlang's syntax is very similar to Haskell's, is it not?
  - dev360 13y ago
    Conceptually, theres a lot of stuff thats similar. I found Erlangs syntax to be a little unconventional so it depends on your background. If you just want to learn a FP language, I'd go with Haskell because you learn a pure FP language that teaches you all the concepts that you will encounter in half-breed languages :) .. people will love me for that comment.
    - kazagistar 13y ago
      Mixed breeds tend to be healthier then pure breeds. All the narrowing of the gene pool tends to lead to higher incidence of genetic disorders.
- dev360 13y ago
  Reading the Learn you a haskell book and digesting it really slowly was the way to go for me personally. I saw a lot of parallels with things I love in Python and that drew me in.
- sparkie 13y ago
  The plain Haskell language, without extensions, has a pretty small and trivial syntax. The Haskell report describes it in approx 250 lines[http://www.haskell.org/onlinereport/syntax-iso.html http://www.haskell.org/onlinereport/syntax-iso.html]. Admittedly, the syntax can be overwhelming when multiple extensions are involved because there is no single resource which explains them all in full as succinctly as the report. The difficulty one might find comprehending Haskell is probably because of the semantics rather than syntax - particularly if you have a background in languages like C++ and Java - the first thing you'll be attempting to do is find parallels between this new obscure syntax and what you already know - but they don't necessarily fit, because the language is fundamentally different. A common example of misunderstanding for beginners is function signatures - in Haskell, one simply defines a function name, followed by two colons, followed by a type declaration which states the function's type. It's as simple as add :: Int -> Int -> Int If you're attempting to draw the parallel to the equivalent in another language such as C#, you might think this is the same as int Add(int a, int b) { ... } While pretty close, the Haskell equivalent of that is really a coupled argument. add :: (Int, Int) -> Int The C# equivalent of the original is closer to this Func<int, Func<int, int>> add = a => (b => ...); At this point it should become a bit more obvious why that "cryptic" function signature is the way it is - it's because all functions in Haskell are secretly single argument functions, and additional arrows indicate that the return type is another function. In other words, the arrow, -> associates to the right, which makes it unnecessary to parenthesize the returned functions - but you can optionally write them for clarity: add :: Int -> (Int -> Int) As a result, you can partially apply add with a single value, e.g. `add 5`, and a valid function which adds 5 to its argument is returned, e.g. `(add 5) 6 == 11`, and because function application (denoted by a space) associates to the left, you can omit the parens and simply say `add 5 6`. Given that you have some Erlang background, the syntax for implementing functions should not be foreign to you, because they're quite similar, except perhaps "do-notation", which will won't be very intuitive until you grok monads.
  - arms 13y ago
    Thank you, I found this very helpful. I'm being selfish, but I'd love some more examples like this where you compare the basics in Haskell against more mainstream, imperative languages - it makes it easier to digest.
- ufo 13y ago
  I think this[1] blogpost has one of the best introductions to Haskell syntax that I have ever seen, and it doesn't get lost in other stuff. Perhaps you might find it useful. After some experience, I think the biggest pain point in Haskell's syntax is that it is very light on keywords so many things that would show up as syntax errors in other languages might show up as type errors in Haskell. For example, forgetting a comma in a list will result in a function application between the two list elements instead of a syntax error. [1] http://blog.ezyang.com/2011/11/how-to-read-haskell/ http://blog.ezyang.com/2011/11/how-to-read-haskell/
- copergi 13y ago
  >The main force holding me back from learning Haskell is the cryptic syntax Haskell doesn't have a cryptic syntax. The same complaint would be just as (in)valid leveled at any commonly used language. We're not talking APL here. >There are so many great languages out there nowadays, Clojure, Go, Erlang. Go does not belong in that list. >I don't see where Haskell would be a better fit For writing software. I realize that sounds snarky, but that really is the answer. To see the problem with your question, just turn it around. Where would clojure or go be a better fit than haskell?
- dserban 13y ago
  > It is easy to cover the spectrum with these and I don't see where Haskell would be a better fit. maybe somebody could shed some light on the strengths of this ecosystem. One of Haskell's unique selling points is the fantastic ease with which you can build software that is correct-by-construction and concise at the same time. For someone I'm mentoring, I recently came up with two examples of this [1][2]. I don't have time ATM to explain all the details (maybe someone else does), but based on them I intend to write in the near future a blog post titled "Using the expressive power of Haskell's type system to build software that is correct-by-construction". I'll submit the link to HN when that happens. It will be part 3 of this[3] ongoing series. [1] https://gist.github.com/dserban/11176875 https://gist.github.com/dserban/11176875 [2] https://gist.github.com/dserban/11139419 https://gist.github.com/dserban/11139419 [3] http://techblog.rosedu.org/haskell-part2.html http://techblog.rosedu.org/haskell-part2.html
  - BasDirks 13y ago
    This is not idiomatic code. Briefly: data Inches = MkInches Double deriving (Eq,Show) There is newtype for this. (MkInches u) \+/ (MkInches v) = MkInches ( u + v ) First two pairs of parens are redundant. from_inches_to_cm vin = MkCm (vin_as_pure_double * 2.54) where (MkInches vin_as_pure_double) = vin Surely you want: inchToCm (MkInches x) = MkCm (x * 2.54) In Haskell we use camelCase. Besides these fairly trivial mistakes there are simply better approaches for dealing with units.
platz 13y ago
Note that these are intermediate level Haskell topics, as intro describes.
thinkpad20 13y ago
I think it's kind of amusing that right after sternly warning the reader to avoid monad tutorials, he then proceeds to write a monad tutorial. I guess you just can't resist...
- gamegoblin 13y ago
  After I finally understood monads I thought about writing a tutorial. My thought process was "Well I understand it now, why couldn't someone have just explained it this way". Then I reevaluated and realized everyone has those thoughts. It's just a hard concept to grasp on the first try. One really just has to grind away and force themselves to use monads for a long enough time to really grok them.
  - username223 13y ago
    I wouldn't call monads "hard to grasp" so much as "hard to explain" or "easy to obfuscate." That's what the "mumble mumble endofunctors" joke is getting at: sometimes they're a useful generalization, but more often they're a way to make easy things sound hard, or to make bad teachers sound smart.
    - copergi 13y ago
      >"hard to explain" or "easy to obfuscate." I wouldn't call it either of those things. They are so general that people have a hard time getting them. That's all. >That's what the "mumble mumble endofunctors" joke is getting at: sometimes they're a useful generalization, but more often they're a way to make easy things sound hard, or to make bad teachers sound smart. That is not at all what the joke is getting at (and that doesn't even make sense).
    - kazagistar 13y ago
      I agree that they often make things seem harder then they really are. The monad tutorial that works best for me is the "don't mention monads" tutorial. Thats the one where you just show some specific task to complete, like composing (a -> Maybe b) functions, and show that there is a neat operator that does it. Then, at some future time, show another composition task, like composing (a -> [b]) functions, and show the same operator again. Starting with the abstract just messes people up and gets them confused. You don't start throwing around Kleisli Arrows and endofunctors right off the bat.
nilkn 13y ago
On a small monitor (11" MBA), not all the topics in the list are visible and the list does not seem to be scrollable.
gtani 13y ago
One thing that helps alot is the various undergrad course syllabuses that have been given with emphasis on type systems and aspects of FP, immutability, segregating and strictly marking side effects etc. http://shuklan.com/haskell/ http://shuklan.com/haskell/ http://www.cs.tufts.edu/~kfisher/teaching.html http://www.cs.tufts.edu/~kfisher/teaching.html https://www.inf.ed.ac.uk/teaching/courses/inf1/fp/ https://www.inf.ed.ac.uk/teaching/courses/inf1/fp/ (P Wadler) http://www.cs.princeton.edu/~dpw/cos441-11/schedule.htm http://www.cs.princeton.edu/~dpw/cos441-11/schedule.htm http://blog.davidterei.com/2011/10/stanford-haskell-course.html http://blog.davidterei.com/2011/10/stanford-haskell-course.h... http://www.seas.upenn.edu/~cis194/ http://www.seas.upenn.edu/~cis194/ ________________ also the Apress "Beginning Haskell" looks pretty good, tho the writing isn't perfectly clear. The example topics and sample code look good, and that's what mostly counts. http://www.amazon.com/Beginning-Haskell-A-Project-Based-Approach/dp/1430262508 http://www.amazon.com/Beginning-Haskell-A-Project-Based-Appr... The books by Hutton and Simon Thompson ("Craft of FP" 3rd ed)are good intros as well. Haskell school of music is really good, but not sure for people who aren't versed in music topics (harmony/theory, composition, MIDI, DSP. http://www.amazon.com/Programming-Haskell-Graham-Hutton/dp/0521692695 http://www.amazon.com/Programming-Haskell-Graham-Hutton/dp/0... http://haskell.cs.yale.edu/euterpea/haskell-school-of-music/ http://haskell.cs.yale.edu/euterpea/haskell-school-of-music/
- gtani 13y ago
  also (I think OP linked the #cabal anchor to highlight sandboxes and other cabal hygiene) take note of the 1.20 release, Dependency freezing and no relinking by default http://www.reddit.com/r/haskell/comments/23i6ih/announcing_cabal_120/ http://www.reddit.com/r/haskell/comments/23i6ih/announcing_c...
- coolsunglasses 13y ago
  I want to highlight this particular course: http://www.seas.upenn.edu/~cis194/ http://www.seas.upenn.edu/~cis194/ It's REALLY good and can be gone through quickly while still getting a feel for the "point" of Haskell.
- jcurbo 13y ago
  I like Hutton's book, it seems simple and elegant without the flair of LYAH (which is good too, don't get me wrong). I picked up the newer Beginning Haskell and it seems decent as well; it has a lot of material akin to Real World Haskell.
jonnybgood 13y ago
Haskell's a good language, but I would add to this list the use cases as to where Haskell is the right tool for the job. I think this would help a lot beginners get a better grasp of Haskell. For example, I wouldn't tell someone to write a web server backend in Haskell if it's going to be in production. Sure, you can do it, but there are more adequate tools for the job. On the other hand, if you were looking to create a DSL or write a parser, Haskell would be great. This is how Galois and Facebook are taking advantage of Haskell.
- coolsunglasses 13y ago
  Haskell happens to be excellent for writing programs.
  - jonnybgood 13y ago
    So is C++ and every other modern language. Every language has its positives and negatives depending on the implementation. Haskell is no different. This is why having some impartiality to languages is important. You use the right tool for the job.
    - laichzeit0 13y ago
      I would like to think so too, yet if you suggest e.g. using Perl or PHP on HN you'll have the typical backlash of "But why not Ruby or Python or etc. it's so much newer and better" This has been my personal observation since following HN for the past few years.
    - jfischoff 13y ago
      And what is right job for whitespace?
- gregwebs 13y ago
  There is greater leverage with Haskell in tackling hard problems or problems where there are existing quality libraries that can be leveraged (such as parsing). Haskell is probably not a good choice in comparison to C/Go/Java if having the best possible CPU performance is a requirement. I am not sure what you mean by a server backend, but that could potentially describe most Haskell code written in the modern networked world. I think the idea though that one language is objectively better at a certain task gets strongly warped by subjective factors. Ultimately language decision is more about the team of programmers you have, the available libraries and ecosystems, and the team's understanding of it. Perhaps not surprisingly, we have found that for programmers already experienced in Haskell, Haskell is a great language for most problems.
Kiro 13y ago
I thought this was supposed to be a list of things to learn _before_ learning Haskell but most of these are things you obviously have no idea what they are if you don't know at least a little Haskell.
fiatjaf 13y ago
Somehow related: For those who (like me) were searching for a long time for a quick and complete Haskell tutorial (but were left with very introductory guides for non-programmers like Learn You a Haskell for the Great Good), look at this tutorial: https://www.fpcomplete.com/school/to-infinity-and-beyond/pick-of-the-week/haskell-fast-hard https://www.fpcomplete.com/school/to-infinity-and-beyond/pic... Haskell Fast & Hard.
- platz 13y ago
  I reccomend LYAH even to programmers, there are enough things in the language that it makes sense to go slow at first. I think beginners get lost because they try to go too fast at first and get impatient. For example, see below about the guy who tried to do GPU programming early on and got frustrated.
  - fiatjaf 13y ago
    Maybe you're right. I'll never know because I've read LYAH almost entirely before getting to HF&H.
kyllo 13y ago
This was very timely and interesting to me as I just started learning Haskell. Thanks!

251 points by tenslisi 13y ago

There's also a very detailed tutorial on writing a toy compiler with Haskell and LLVM on this site: http://www.stephendiehl.com/llvm/ http://www.stephendiehl.com/llvm/

leccine 13y ago

The main force holding me back from learning Haskell is the cryptic syntax. I totally understand that the type system is (supposed to be) superior to other languages but it simply make it really hard to find the time. I am also unsure how useful this language can be in every day use. There are so many great languages out there nowadays, Clojure, Go, Erlang. It is easy to cover the spectrum with these and I don't see where Haskell would be a better fit. maybe somebody could shed some light on the strengths of this ecosystem.

platz 13y ago
I don't think it takes any longer to learn Haskell syntax than all of Clojure's reader macros (you will need them and the semantics is not obvious), or Scala's type system which has a lot going on, and I'm not sure about Erlang but I hear grumblings about syntax. There isn't actually that much in the way of actual syntax in Haskell (LYAH is a great place to start, don't just try to eyeball random code snippets), and it becomes preferable after some familiarity. What will take time is learning new concepts, programming purely and learning the tools to manage effects.
- im3w1l 13y ago
  This is not true at all in my experience. Theano, a machine learning library for the gpu uses pure programming with syntax extremely similar to numpy, took about an hour to understand and "do useful stuff with". I've spent more than 20 hours on Haskell syntax and feel like I am not even halfway there to "doing useful stuff". EDIT: And I think time to be able to do something useful is a very important benchmark because after that point, further learning takes little effort or motivation.
  - platz 13y ago
    While I havent used that library, there are plenty of ways to write obfuscated code in Haskell. Some libraries may define their own operators (Scala suffers from this too), which can be impenetrable. Some libraries are better than others. Although, I don't consider defining new operator names part of the syntax of the actual language itself. I guess I'd just hope one doesnt start out jumping in to a complicated library. Its easier to start with more foundational materials.
    - platz 13y ago
      * I can see your point about speed to attain proficiency. I wish I had a good answer for this.
  - GregBuchholz 13y ago
    Maybe it is the pattern matching aspect that is throwing you for a loop? Are you familiar with Prolog, Mathematica, Erlang, or syntax-case macros from Scheme? Or is the the dollar sign ($), or something else that may be bugging you? Maybe post a simple example of one of the worst offenders.
    - im3w1l 13y ago
      It is not one thing in particular. It is just that there are so many things.
  - the_af 13y ago
    Are you sure it's the syntax? Haskell can be pretty complex to understand due to the abstractions involved, especially if you are less familiar with FP, laziness, etc. When I struggle with Haskell it's more "I don't understand the type of this" than "I don't understand the syntax". Syntax is the easy part!
jerf 13y ago
"The main force holding me back from learning Haskell is the cryptic syntax." Then you should go ahead and start. The syntax is pretty thin. It's not what you're used to, but it's thin. It's hard to describe what Haskell would be good for without sounding overenthusiastic, so I'll confine myself to saying that Haskell will expand your brain in ways that few other languages will. That said, Clojure is potentially one of those few other languages (depends on your personal development history, though IMHO enough stuff has been stolen from Lisp over the years that it's less of a mind-blow than it used to be), and you ought to learn about modern concurrency from at least one of Haskell, Go, Erlang, or Clojure (or possible Scala via Akka). Haskell opens you to the most correctly-implemented modern concurrency paradigms at once but any of those will get you most of the experience you need.
- pekk 13y ago
  Ah. So what isn't Haskell good for?
  - anon_d 13y ago
    Haskell is not a great language for programs that need to fit within tight memory or latency limits. It's also slower in some cases than C/C++, but it's definitely competitive with other high-level languages. Other than that, it's pretty excellent for everything.
  - jerf 13y ago
    Well, in all seriousness, a situation in which a mind-expanding language isn't called for, because the minds in question don't currently work that way, and I am being 100% serious. I really like Haskell. It's among my favorite languages. However, I don't advocate for it where I work and tend to sort of tamp down on anyone else who tries because despite the fairly polyglot nature of where I work, we don't have the background to use Haskell very effectively at scale. I do this even as I advocate to all and sundry that they learn it anyhow for the mind expansion. When one is fluent in Haskell I think the language naturally tends to drive you towards well-factored, reusable designs that can handle change well. I say "fluent" because I don't think one needs to be "expert" to get to this level, but certainly there's a level of experience required to be here. Beginners and pre-fluency intermediates in the language produce god-awful messes of code. (I know, because I have! Fortunately I had the foresight to do that to throwaway personal projects, rather than critical business projects.) I think a great deal of the Haskell propaganda is justified, but beware the Haskell enthusiast who recites the propaganda, but can't clearly explain in their own words the mechanisms that Haskell uses to accomplish it. Actually, scratch Haskell out of that. Beware any tech enthusiast who can't give a coherent explanation in their own words of why the tech stack has the claimed effects, but just repeats the propaganda again.
ademarre 13y ago
In this video Erik Hinton talks about using Haskell in the fast-paced New York Times environment: http://www.infoq.com/presentations/haskell-newsroom-nyt http://www.infoq.com/presentations/haskell-newsroom-nyt
- arms 13y ago
  This is one of the better Haskell videos I've seen - it's nice to see use cases in a high speed environment like the NYT.
thinkpad20 13y ago
As to Haskell's syntax, I think it's really just as complicated as it needs to be to express the ideas Haskell embodies succinctly and precisely. It doesn't have any more syntax than most other languages; it's just a very different syntax than most non-functional languages. And this is precisely because the semantics of the language are also very different. Haskell, for example, is not block-structured, as nearly all imperative languages are. (It does simulate this with do-syntax, but this is only a simulation). I understand though - I find Clojure practically unreadable, and this has kept me away from it to a degree. As to where Haskell fits: you're correct, there are many other great languages out there. But I think Haskell is really unique in offering what it does. Clojure, Go, and Erlang are all great in their own regard, but none of them provides the degree of safety that Haskell does. For example, none of them enforce purity, and all three of them freely allow the use of `null` values (which is really quite surprising considering how many problems nulls cause). Clojure and Erlang avoid mutable state like Haskell does (though not to the same degree of rigor) but don't provide the elegant solutions for simulating mutable state that Haskell does with its monads, which almost allow you to "have your cake and eat it too" with state. None of them encourage the degree of abstraction that you'll find in Haskell. Also, at least according to the Computer Benchmark game, Haskell beats all three of them in terms of speed, as well. Haskell's "place" is in generating highly robust code with good performance, and also works as a beautiful language for expressing certain mathematical concepts. This doesn't make Haskell a perfect language, but it absolutely has a lot to offer that other languages don't. And it's so much different than other languages, that at the very least it can change your perspective on a lot of things.
- platz 13y ago
  I think one has to be careful about performance claims. Of course you can tweak things to be fast in hakell, but to be able to actually program haskell in such a way to, beat other languages in performance, is not a trivial skill. There are numerous stackoverflow and r/haskell posts "Why is my haskell code 10x times slower than language X?" Or observe this set of web framework benchmarks: http://www.techempower.com/benchmarks/ http://www.techempower.com/benchmarks/
  - 13y ago
nilkn 13y ago
> The main force holding me back from learning Haskell is the cryptic syntax. [...] There are so many great languages out there nowadays, Clojure, Go, Erlang. Erlang's syntax is very similar to Haskell's, is it not?
- dev360 13y ago
  Conceptually, theres a lot of stuff thats similar. I found Erlangs syntax to be a little unconventional so it depends on your background. If you just want to learn a FP language, I'd go with Haskell because you learn a pure FP language that teaches you all the concepts that you will encounter in half-breed languages :) .. people will love me for that comment.
  - kazagistar 13y ago
    Mixed breeds tend to be healthier then pure breeds. All the narrowing of the gene pool tends to lead to higher incidence of genetic disorders.
dev360 13y ago
Reading the Learn you a haskell book and digesting it really slowly was the way to go for me personally. I saw a lot of parallels with things I love in Python and that drew me in.
sparkie 13y ago
The plain Haskell language, without extensions, has a pretty small and trivial syntax. The Haskell report describes it in approx 250 lines[http://www.haskell.org/onlinereport/syntax-iso.html http://www.haskell.org/onlinereport/syntax-iso.html]. Admittedly, the syntax can be overwhelming when multiple extensions are involved because there is no single resource which explains them all in full as succinctly as the report. The difficulty one might find comprehending Haskell is probably because of the semantics rather than syntax - particularly if you have a background in languages like C++ and Java - the first thing you'll be attempting to do is find parallels between this new obscure syntax and what you already know - but they don't necessarily fit, because the language is fundamentally different. A common example of misunderstanding for beginners is function signatures - in Haskell, one simply defines a function name, followed by two colons, followed by a type declaration which states the function's type. It's as simple as add :: Int -> Int -> Int If you're attempting to draw the parallel to the equivalent in another language such as C#, you might think this is the same as int Add(int a, int b) { ... } While pretty close, the Haskell equivalent of that is really a coupled argument. add :: (Int, Int) -> Int The C# equivalent of the original is closer to this Func<int, Func<int, int>> add = a => (b => ...); At this point it should become a bit more obvious why that "cryptic" function signature is the way it is - it's because all functions in Haskell are secretly single argument functions, and additional arrows indicate that the return type is another function. In other words, the arrow, -> associates to the right, which makes it unnecessary to parenthesize the returned functions - but you can optionally write them for clarity: add :: Int -> (Int -> Int) As a result, you can partially apply add with a single value, e.g. `add 5`, and a valid function which adds 5 to its argument is returned, e.g. `(add 5) 6 == 11`, and because function application (denoted by a space) associates to the left, you can omit the parens and simply say `add 5 6`. Given that you have some Erlang background, the syntax for implementing functions should not be foreign to you, because they're quite similar, except perhaps "do-notation", which will won't be very intuitive until you grok monads.
- arms 13y ago
  Thank you, I found this very helpful. I'm being selfish, but I'd love some more examples like this where you compare the basics in Haskell against more mainstream, imperative languages - it makes it easier to digest.
ufo 13y ago
I think this[1] blogpost has one of the best introductions to Haskell syntax that I have ever seen, and it doesn't get lost in other stuff. Perhaps you might find it useful. After some experience, I think the biggest pain point in Haskell's syntax is that it is very light on keywords so many things that would show up as syntax errors in other languages might show up as type errors in Haskell. For example, forgetting a comma in a list will result in a function application between the two list elements instead of a syntax error. [1] http://blog.ezyang.com/2011/11/how-to-read-haskell/ http://blog.ezyang.com/2011/11/how-to-read-haskell/
copergi 13y ago
>The main force holding me back from learning Haskell is the cryptic syntax Haskell doesn't have a cryptic syntax. The same complaint would be just as (in)valid leveled at any commonly used language. We're not talking APL here. >There are so many great languages out there nowadays, Clojure, Go, Erlang. Go does not belong in that list. >I don't see where Haskell would be a better fit For writing software. I realize that sounds snarky, but that really is the answer. To see the problem with your question, just turn it around. Where would clojure or go be a better fit than haskell?
dserban 13y ago
> It is easy to cover the spectrum with these and I don't see where Haskell would be a better fit. maybe somebody could shed some light on the strengths of this ecosystem. One of Haskell's unique selling points is the fantastic ease with which you can build software that is correct-by-construction and concise at the same time. For someone I'm mentoring, I recently came up with two examples of this [1][2]. I don't have time ATM to explain all the details (maybe someone else does), but based on them I intend to write in the near future a blog post titled "Using the expressive power of Haskell's type system to build software that is correct-by-construction". I'll submit the link to HN when that happens. It will be part 3 of this[3] ongoing series. [1] https://gist.github.com/dserban/11176875 https://gist.github.com/dserban/11176875 [2] https://gist.github.com/dserban/11139419 https://gist.github.com/dserban/11139419 [3] http://techblog.rosedu.org/haskell-part2.html http://techblog.rosedu.org/haskell-part2.html
- BasDirks 13y ago
  This is not idiomatic code. Briefly: data Inches = MkInches Double deriving (Eq,Show) There is newtype for this. (MkInches u) \+/ (MkInches v) = MkInches ( u + v ) First two pairs of parens are redundant. from_inches_to_cm vin = MkCm (vin_as_pure_double * 2.54) where (MkInches vin_as_pure_double) = vin Surely you want: inchToCm (MkInches x) = MkCm (x * 2.54) In Haskell we use camelCase. Besides these fairly trivial mistakes there are simply better approaches for dealing with units.

platz 13y ago

Note that these are intermediate level Haskell topics, as intro describes.

thinkpad20 13y ago

I think it's kind of amusing that right after sternly warning the reader to avoid monad tutorials, he then proceeds to write a monad tutorial. I guess you just can't resist...

gamegoblin 13y ago
After I finally understood monads I thought about writing a tutorial. My thought process was "Well I understand it now, why couldn't someone have just explained it this way". Then I reevaluated and realized everyone has those thoughts. It's just a hard concept to grasp on the first try. One really just has to grind away and force themselves to use monads for a long enough time to really grok them.
- username223 13y ago
  I wouldn't call monads "hard to grasp" so much as "hard to explain" or "easy to obfuscate." That's what the "mumble mumble endofunctors" joke is getting at: sometimes they're a useful generalization, but more often they're a way to make easy things sound hard, or to make bad teachers sound smart.
  - copergi 13y ago
    >"hard to explain" or "easy to obfuscate." I wouldn't call it either of those things. They are so general that people have a hard time getting them. That's all. >That's what the "mumble mumble endofunctors" joke is getting at: sometimes they're a useful generalization, but more often they're a way to make easy things sound hard, or to make bad teachers sound smart. That is not at all what the joke is getting at (and that doesn't even make sense).
  - kazagistar 13y ago
    I agree that they often make things seem harder then they really are. The monad tutorial that works best for me is the "don't mention monads" tutorial. Thats the one where you just show some specific task to complete, like composing (a -> Maybe b) functions, and show that there is a neat operator that does it. Then, at some future time, show another composition task, like composing (a -> [b]) functions, and show the same operator again. Starting with the abstract just messes people up and gets them confused. You don't start throwing around Kleisli Arrows and endofunctors right off the bat.

nilkn 13y ago

On a small monitor (11" MBA), not all the topics in the list are visible and the list does not seem to be scrollable.

gtani 13y ago

One thing that helps alot is the various undergrad course syllabuses that have been given with emphasis on type systems and aspects of FP, immutability, segregating and strictly marking side effects etc. http://shuklan.com/haskell/ http://shuklan.com/haskell/ http://www.cs.tufts.edu/~kfisher/teaching.html http://www.cs.tufts.edu/~kfisher/teaching.html https://www.inf.ed.ac.uk/teaching/courses/inf1/fp/ https://www.inf.ed.ac.uk/teaching/courses/inf1/fp/ (P Wadler) http://www.cs.princeton.edu/~dpw/cos441-11/schedule.htm http://www.cs.princeton.edu/~dpw/cos441-11/schedule.htm http://blog.davidterei.com/2011/10/stanford-haskell-course.html http://blog.davidterei.com/2011/10/stanford-haskell-course.h... http://www.seas.upenn.edu/~cis194/ http://www.seas.upenn.edu/~cis194/ ________________ also the Apress "Beginning Haskell" looks pretty good, tho the writing isn't perfectly clear. The example topics and sample code look good, and that's what mostly counts. http://www.amazon.com/Beginning-Haskell-A-Project-Based-Approach/dp/1430262508 http://www.amazon.com/Beginning-Haskell-A-Project-Based-Appr... The books by Hutton and Simon Thompson ("Craft of FP" 3rd ed)are good intros as well. Haskell school of music is really good, but not sure for people who aren't versed in music topics (harmony/theory, composition, MIDI, DSP. http://www.amazon.com/Programming-Haskell-Graham-Hutton/dp/0521692695 http://www.amazon.com/Programming-Haskell-Graham-Hutton/dp/0... http://haskell.cs.yale.edu/euterpea/haskell-school-of-music/ http://haskell.cs.yale.edu/euterpea/haskell-school-of-music/

gtani 13y ago
also (I think OP linked the #cabal anchor to highlight sandboxes and other cabal hygiene) take note of the 1.20 release, Dependency freezing and no relinking by default http://www.reddit.com/r/haskell/comments/23i6ih/announcing_cabal_120/ http://www.reddit.com/r/haskell/comments/23i6ih/announcing_c...
coolsunglasses 13y ago
I want to highlight this particular course: http://www.seas.upenn.edu/~cis194/ http://www.seas.upenn.edu/~cis194/ It's REALLY good and can be gone through quickly while still getting a feel for the "point" of Haskell.
jcurbo 13y ago
I like Hutton's book, it seems simple and elegant without the flair of LYAH (which is good too, don't get me wrong). I picked up the newer Beginning Haskell and it seems decent as well; it has a lot of material akin to Real World Haskell.

jonnybgood 13y ago

Haskell's a good language, but I would add to this list the use cases as to where Haskell is the right tool for the job. I think this would help a lot beginners get a better grasp of Haskell. For example, I wouldn't tell someone to write a web server backend in Haskell if it's going to be in production. Sure, you can do it, but there are more adequate tools for the job. On the other hand, if you were looking to create a DSL or write a parser, Haskell would be great. This is how Galois and Facebook are taking advantage of Haskell.

coolsunglasses 13y ago
Haskell happens to be excellent for writing programs.
- jonnybgood 13y ago
  So is C++ and every other modern language. Every language has its positives and negatives depending on the implementation. Haskell is no different. This is why having some impartiality to languages is important. You use the right tool for the job.
  - laichzeit0 13y ago
    I would like to think so too, yet if you suggest e.g. using Perl or PHP on HN you'll have the typical backlash of "But why not Ruby or Python or etc. it's so much newer and better" This has been my personal observation since following HN for the past few years.
  - jfischoff 13y ago
    And what is right job for whitespace?
gregwebs 13y ago
There is greater leverage with Haskell in tackling hard problems or problems where there are existing quality libraries that can be leveraged (such as parsing). Haskell is probably not a good choice in comparison to C/Go/Java if having the best possible CPU performance is a requirement. I am not sure what you mean by a server backend, but that could potentially describe most Haskell code written in the modern networked world. I think the idea though that one language is objectively better at a certain task gets strongly warped by subjective factors. Ultimately language decision is more about the team of programmers you have, the available libraries and ecosystems, and the team's understanding of it. Perhaps not surprisingly, we have found that for programmers already experienced in Haskell, Haskell is a great language for most problems.

Kiro 13y ago

I thought this was supposed to be a list of things to learn _before_ learning Haskell but most of these are things you obviously have no idea what they are if you don't know at least a little Haskell.

fiatjaf 13y ago

Somehow related: For those who (like me) were searching for a long time for a quick and complete Haskell tutorial (but were left with very introductory guides for non-programmers like Learn You a Haskell for the Great Good), look at this tutorial: https://www.fpcomplete.com/school/to-infinity-and-beyond/pick-of-the-week/haskell-fast-hard https://www.fpcomplete.com/school/to-infinity-and-beyond/pic... Haskell Fast & Hard.

platz 13y ago
I reccomend LYAH even to programmers, there are enough things in the language that it makes sense to go slow at first. I think beginners get lost because they try to go too fast at first and get impatient. For example, see below about the guy who tried to do GPU programming early on and got frustrated.
- fiatjaf 13y ago
  Maybe you're right. I'll never know because I've read LYAH almost entirely before getting to HF&H.

kyllo 13y ago

This was very timely and interesting to me as I just started learning Haskell. Thanks!