Comment by pklausler | Hacker News Reader

Comment by pklausler | Hacker News Reader

Parent Full thread

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.

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.

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.)

>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/) 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 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) 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.

The thing I really took forever to grasp was how do-notation desugars (a la 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.

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.

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

Also see my other comment here which mentions the process we used: 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.h...

Oh cool, I'll check it out. Thanks for writing it!

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.

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.

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.

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

Reply on news.ycombinator.com