4 ms·

Haskell is such a distinct mix of features that make it great to use once you know them but somewhat difficult to learn from scratch. One big fat clue that I w

Haskell is such a distinct mix of features that make it great to use once you know them but somewhat difficult to learn from scratch. One big fat clue that I wish I had been given when I was starting to try to figure it out on my own back in the 90's is that Haskell is kind of loaded up with syntactic sugar, beneath which is a relatively small core language that might be an easier point of entry into the language. To be specific: infix operators, sections, multi-argument functions, partial application, 'where' clauses, multiple definitions of the same function with different patterns, implicit braces and semicolons inferred from layout, 'do' statements, if/then/else, [lists] -- all of these, and probably more, are great to use, but they all boil down to something like func = \arg -> let { ... } in case arg of { pat | guards -> f x y; ... } and perhaps fully grokking these essential constructs before moving on to using them indirectly through all the layers of pretty syntax would have helped me understand all those features better. ADDENDUM to forestall my inevitable hog-piling by pedants: yes, I know that 'let' isn't strictly essential, and I neglected to mention record fields, record updates, type classes, &c. Sorry. And I know that the Haskell standards have always defined higher-level constructs in terms of a core language. My point is that, at least for me, Haskell might have been easier had I been exposed to just that core language at first.

nickpsecurity 10y ago
Interestingly, most educational resources start with a core language or concepts then build on them. So your gripe seems intuitively correct.
tel 10y ago
To do some reverse pedantry, actually that let is necessary but it's the one binding `func` that gets more use. It's a really interesting part of how ML-like languages do type inference that makes `let`s completely necessary.
SatvikBeri 10y ago
Completely agree. This is one of the things I really like about the book Functional Programming in Scala, which builds from the ground up. I haven't found an equivalent book in Haskell.
- pklausler 10y ago
  The world might be a better place if we could exchange a few hundred of the existing monad tutorials for a post or two that just explained Haskell pattern matching really well.
- coolsunglasses 10y ago
  I'd submit that our book builds from the ground up and covers dramatically more than FPiS, you can see our chapter listing here: http://haskellbook.com/progress.html http://haskellbook.com/progress.html Also see my other comment here which mentions the process we used: https://news.ycombinator.com/item?id=12214430 https://news.ycombinator.com/item?id=12214430 The book covers so much because wanted it to work for people who 1. Weren't necessarily familiar with FP or at all, or in some cases, programming period. 2. Would be able to apply Haskell or learn more advanced concepts on their own after working through the book. #2 required covering much more of the intermediate stuff than any of the existing books available. I wrote the book because of the problems detailed in this blog post with the pre-existing materials: http://bitemyapp.com/posts/2014-12-31-functional-education.html http://bitemyapp.com/posts/2014-12-31-functional-education.h...
  - SatvikBeri 10y ago
    Oh cool, I'll check it out. Thanks for writing it!
- mastratton3 10y ago
  I've just finished my first pass through the book (kind of... have to go back through some stuff.) and I concur that its a great read. I do wish there was a companion that had some code examples of some of this stuff in the real world. For instance, intuitively state traversals or using product monoids for folding lists seem to have tons of real world applications that I've been looking for something to solve, but I find it still takes lots of exploration.
tene 10y ago
When I was first learning Haskell, through Real World Haskell and LYAH, I was very frustrated that they never seemed to actually give definitions for anything, but instead just vaguely implied definitions by listing examples. What finally worked well for me was using the Haskell Report 2010 as a reference, and looking things up there every time I got frustrated by the lack of a solid, detailed definition.
- pklausler 10y ago
  The Haskell Reports, especially the 2010 edition, have been clear, readable, and straightforward documents whose contributors and editors should be commended. If only other language standards were so clear! (C'89 and Fortran are also really excellent documents.)
gh02t 10y ago
The thing I really took forever to grasp was how do-notation desugars (a la https://en.wikibooks.org/wiki/Haskell/do_notation https://en.wikibooks.org/wiki/Haskell/do_notation ). For the longest time I understood logically/conceptually how to deal with monadic operations, but was confused on the syntax. For a while, do-notation and also applicative style were opaque mysteries until I managed to figure out what was going on under the hood.
coolsunglasses 10y ago
>and perhaps fully grokking these essential constructs before moving on to using them indirectly through all the layers of pretty syntax would have helped me understand all those features better. This is the approach we take in our book, Haskell Programming from First Principles. (http://haskellbook.com/ http://haskellbook.com/) The book starts with a _brief_ introduction to lambda calculus and builds on what the reader knows incrementally. You can see in our chapter listing: http://haskellbook.com/progress.html http://haskellbook.com/progress.html what order we do things in. Importantly, it's not just show & tell. The book has _a lot_ of exercises and detailed explanation for the concepts covered. I'd worked with and taught quite a few people before starting the book, in addition to maintaining a fairly popular guide (https://github.com/bitemyapp/learnhaskell https://github.com/bitemyapp/learnhaskell) for learning Haskell and helping people working through the recommended materials. Further, my coauthor on the book was completely new to programming when she began working with me. What we cover and in how much detail is influenced by working with her, our ~10 deep-dive reviewers, and the over 1,300 emails of feedback/questions we've gotten from readers. What I did in the book is based on that experience and data. If I could've written less and still solved the same problems, I would've. Maybe a future edition will be shorter after we refactor some things.

nickpsecurity 10y ago

Interestingly, most educational resources start with a core language or concepts then build on them. So your gripe seems intuitively correct.

tel 10y ago

To do some reverse pedantry, actually that let is necessary but it's the one binding `func` that gets more use. It's a really interesting part of how ML-like languages do type inference that makes `let`s completely necessary.

SatvikBeri 10y ago

Completely agree. This is one of the things I really like about the book Functional Programming in Scala, which builds from the ground up. I haven't found an equivalent book in Haskell.

pklausler 10y ago
The world might be a better place if we could exchange a few hundred of the existing monad tutorials for a post or two that just explained Haskell pattern matching really well.
coolsunglasses 10y ago
I'd submit that our book builds from the ground up and covers dramatically more than FPiS, you can see our chapter listing here: http://haskellbook.com/progress.html http://haskellbook.com/progress.html Also see my other comment here which mentions the process we used: https://news.ycombinator.com/item?id=12214430 https://news.ycombinator.com/item?id=12214430 The book covers so much because wanted it to work for people who 1. Weren't necessarily familiar with FP or at all, or in some cases, programming period. 2. Would be able to apply Haskell or learn more advanced concepts on their own after working through the book. #2 required covering much more of the intermediate stuff than any of the existing books available. I wrote the book because of the problems detailed in this blog post with the pre-existing materials: http://bitemyapp.com/posts/2014-12-31-functional-education.html http://bitemyapp.com/posts/2014-12-31-functional-education.h...
- SatvikBeri 10y ago
  Oh cool, I'll check it out. Thanks for writing it!
mastratton3 10y ago
I've just finished my first pass through the book (kind of... have to go back through some stuff.) and I concur that its a great read. I do wish there was a companion that had some code examples of some of this stuff in the real world. For instance, intuitively state traversals or using product monoids for folding lists seem to have tons of real world applications that I've been looking for something to solve, but I find it still takes lots of exploration.

tene 10y ago

When I was first learning Haskell, through Real World Haskell and LYAH, I was very frustrated that they never seemed to actually give definitions for anything, but instead just vaguely implied definitions by listing examples. What finally worked well for me was using the Haskell Report 2010 as a reference, and looking things up there every time I got frustrated by the lack of a solid, detailed definition.

pklausler 10y ago
The Haskell Reports, especially the 2010 edition, have been clear, readable, and straightforward documents whose contributors and editors should be commended. If only other language standards were so clear! (C'89 and Fortran are also really excellent documents.)

gh02t 10y ago

The thing I really took forever to grasp was how do-notation desugars (a la https://en.wikibooks.org/wiki/Haskell/do_notation https://en.wikibooks.org/wiki/Haskell/do_notation ). For the longest time I understood logically/conceptually how to deal with monadic operations, but was confused on the syntax. For a while, do-notation and also applicative style were opaque mysteries until I managed to figure out what was going on under the hood.

coolsunglasses 10y ago

>and perhaps fully grokking these essential constructs before moving on to using them indirectly through all the layers of pretty syntax would have helped me understand all those features better. This is the approach we take in our book, Haskell Programming from First Principles. (http://haskellbook.com/ http://haskellbook.com/) The book starts with a _brief_ introduction to lambda calculus and builds on what the reader knows incrementally. You can see in our chapter listing: http://haskellbook.com/progress.html http://haskellbook.com/progress.html what order we do things in. Importantly, it's not just show & tell. The book has _a lot_ of exercises and detailed explanation for the concepts covered. I'd worked with and taught quite a few people before starting the book, in addition to maintaining a fairly popular guide (https://github.com/bitemyapp/learnhaskell https://github.com/bitemyapp/learnhaskell) for learning Haskell and helping people working through the recommended materials. Further, my coauthor on the book was completely new to programming when she began working with me. What we cover and in how much detail is influenced by working with her, our ~10 deep-dive reviewers, and the over 1,300 emails of feedback/questions we've gotten from readers. What I did in the book is based on that experience and data. If I could've written less and still solved the same problems, I would've. Maybe a future edition will be shorter after we refactor some things.