Hacker News Reader

Comment by chrisdone | Hacker News Reader

That's definitely a pattern I'm seeing; people don't like the way "let" is introduced. I think in writing it I hoped it would be intuitive. I think, actually, someone suggested that I spend a few examples demonstrating it to ease the idea into the reader's brain. It seems people don't mind weird things as long as you explain them. Interesting lesson. Thanks for the feedback and thanks for trying!

View on HN

I like everything up to but not including step 7. (http://tryhaskell.org/#7)

The syntax

  let villain = (28,"chirs") in fst villain

is not obvious to me, and the tutorial doesn't explain what each piece of the new syntax means, and quickly moves on to something new in step 8.

Only through experimentation, I find:

  fst (28,"chirs")
  => 28
  snd (28,"chirs")
  => "chirs"

So I gather the let is equivalent to:

  (let ((villain '(28 "chirs")))
    (first villain))

But without parens, line breaks or semicolons I have difficulty determining where one expression ends and another begins.

Plus, the arbitrary shortening of "first" to "fst" doesn't help, and should probably be clarified.

You seem to only check the return value to determine when to skip to the next step in the tutorial, since in step10, you want me to type:

  ['a','b','c'] == "abc"

But it skips ahead when I play around and return True from a different expression:

  'a' : 'b' : [] == "ab"
  => True

I have exactly the same complaint. Also, the use of "let" seems completely superfluous here. No motivation for writing

  let villain = (28,"chirs") in fst villain

rather than the much shorter

  fst (28,"chirs")

is given.

I think the lack of any sort of typographical indication of when one expression ends is really a Haskell issue, not an issue with the tutorial, though perhaps newlines could be inserted for readability. (Or does Haskell care where newlines appear?)

I've read a number of Haskell tutorials in the past, and despite having no problem with a variety of syntax types, including C-family, Lisp-family, and even having done some coding in ML way back when, I find the Haskell syntax really hard to read.

I don't think this is something a tutorial can "fix", per se, but it'd be nice if there was a tutorial that took this into account and explained how to actually decompose Haskell code without just throwing code snippets at you and hoping that you'll intuit their meaning. "Haskell Parsing for Humans" is what I want. The part at the beginning of this tutorial where it explains numbers, strings, lists and tuples is actually a good start, but "let", "=", and "in" are never explained, nor is "fst".

Hey, thanks for the feedback! Definitely let's syntax is a bit ambiguous to the newbie. I'll take a couple steps in the tutorial for explanation and experimentation. I think I'll take your advice and just go with

    fst (28,"chirs")

and then do a "small detour" (2 steps) to explain the "let" syntax, because it gets used in later chapters. Unlike the math stuff which is intuitive, I agree it needs explicit description.

Cheers!

It's definitely better. You might want something longer to type than 4 in the example, though.

Explaining the let syntax only after the user has had to use it once felt a bit funny to me, though I guess that's the pattern of the rest of the tutorial. I'm one of those people who tends to learn more from references than tutorials, so that might be saying more about my learning style than your tutorial.

Hey, I've updated the tutorial from your feedback. Hopefully my explanation is more fuller now! Give it a go?

Are fst and snd the standard haskell functions? It doesn't seem worth saving a few characters for how awkward it makes it to read the code, but then again, if we can get used to car, cdr and so on, I guess its not bad. Though in the case of the tutorial, it should definitely state what fst and snd are.

They are standard. There's also `first` and `second`, but they do something different:

    Prelude> :m + Control.Arrow 
    Prelude Control.Arrow> :t first
    first :: (Arrow a) => a b c -> a (b, d) (c, d)
    Prelude Control.Arrow> first (2 +) (1, 4)
    (3,4)

In this case the Arrow instance is just (->), the function type constructor, so you could read that strange type signature as `first :: (b -> c) -> ((b, d) -> (c, d))`. But I've said too much.

...if we can get used to car, cdr and so on, I guess its not bad.

Common Lisp (and MzScheme) users can use first (and second, and third...) and rest, and probably should do so when using simple lists.

My Lisp of choice is Clojure, which also uses first, second and rest.

Hey, I will explain fst and snd. In fact I go into them in some detail in later chapters, but I'll mention their use and why they're short at this step too!

Cool. Good work on the site anyway, I had a quick look at it and it seems like a nice and easy way to learn haskell.

Hey, cheers! I've updated the tutorial to explain fst, let, etc. hopefully it's a bit more friendly now.

OK, if I explain the let syntax with some examples before demonstrating with fst and snd, will that be OK?

Actually it just checks the type of the result on that step! I'll do a syntactic check to make sure you have to type it out in that step.

Thanks for the feedback, I'll fix this today!

Reply on news.ycombinator.com