5 ms·

I'd say: just try it. After reading haskell-cafe for a day, I felt utterly incapable of ever learning Haskell. I started picking up the language using Real Worl

I'd say: just try it. After reading haskell-cafe for a day, I felt utterly incapable of ever learning Haskell. I started picking up the language using Real World Haskell (quite an acceptable book). I can read most programs now and crafted some short programs. I still find predicting memory/time use under a lazy-evaluation regime difficult. But it is certainly a nice experience ;)

eru 16y ago
The guys on Haskell Cafe delight in complex problems (and solutions). There's a list for beginners, too. You will enjoy the Haskell Cafe later. By the way, one small exercise (from a paper by Chris Okasaki): Write a function with the type Tree a -> Tree Int where data Tree a = Node a (Tree a) (Tree a) | Empty your function should all nodes in a tree with their position in level order traversal (also called breadth first search). E.g. (lot == lever order traversal) lot Empty = Empty lot (Node 'a' (Node 'b' Empty (Node 'c' Empty Empty)) (Node 'd' Empty Empty)) = (Node '0' (Node '1' Empty (Node '3' Empty Empty)) (Node '2' Empty Empty))
gaius 16y ago
The thing with RWH I found was, chapters 1-4 great, a nice introduction to the language, and I did all the exercises without too much head-scratching. Then chapter 5 is utterly incomprehensible. I didn't get any further. OCaml, that's a nice language, with much better introductary materials.
- gtani 16y ago
  Dont' give up: http://www.amazon.com/Programming-Haskell-Graham-Hutton/dp/0521692695/ http://www.amazon.com/Programming-Haskell-Graham-Hutton/dp/0... http://stackoverflow.com/questions/1012573/how-to-learn-haskell http://stackoverflow.com/questions/1012573/how-to-learn-hask... http://learnyouahaskell.com/ http://learnyouahaskell.com/
- anonymousDan 16y ago
  What did you find so hard about chapter 5 ("Writing a library: working with JSON data")? Doesn't seem too be such a big step up to me in comparison to other chapters in the book?
- anonymousDan 16y ago
  What did you find so hard about chapter 5 ("Writing a library: working with JSON data")? Doesn't seem too be such a big step up to me in comparison to other chapters in the book?
Natsu 16y ago
I can actually read some of the syntax. I guess that a mathematical background helps when you're accustomed to seeing function definitions that map one real to another real or some of the other constructs. And I certainly recognize interfaces from Java (and why they can be a lot nicer than C++ style inheritance). What still gets me are some of the basic functional programming concepts like monads and the y combinator, which obviously aren't unique to Haskell. Yeah, I've read Wikipedia on both of those (more than once). And several other things. I've even written some Lisp for my employer. But some of the concepts have yet to "click." I know monads encapsulate side effects or something (and the y combinator finds the fixed points of a function), but I feel like I just don't get the details of how it works. After all, you don't need to know anything about monads to call the print function.
- eru 16y ago
  Monads are easy to understand: A monad is exactly anything that satisfies the three monad laws. If you have worked with mathematical groups and have seen how mathematicians can look at very disparate things with their group-goggles and find similarities, you will appreciate monads. The y combinator is a nice parlour trick (if you define it in lambda calculus without using any other recursion primitives), and research vehicle. But I did not apply it once, yet. And I've tried. If you want to get combinatorial logic (including the y combinator), read "To Mock a Mockingbird". And do all the puzzles, of course. Actually you should read it, whether you want to learn anything about combinatorial logic or not. It is such a good book.
  - Natsu 16y ago
    Thanks, I'll read that.
Zaak 16y ago
> I still find predicting memory/time use under a lazy-evaluation regime difficult. It's not just you. Lazy evaluation makes predicting and understanding resource usage difficult.
- eru 16y ago
  Indeed. And that's the major shortcoming I see that could prevent me from using Haskell in a production environment. The guys who wrote XMonad got around it, so it is possible. You just need to be careful, and use enough strictness annotations.
  - intoverfl0w 16y ago
    Laziness is one of those features I can never make my mind up about. It is sometimes very convenient, but most of the time I never think about the fact that the semantics mean evaluation is lazy. Sometimes this negligence has bad consequences, and then one must invoke a carefully honed skill to correct the issue. Definitely doable, but it certainly feels like fighting the language (to me, anyway). One of the craziest things is that Haskell has decided that type families should also be lazily evaluated. So you can hop into the interactive interpreter to inspect some types and get not-so-useful information, like somevar :: SomeTypeFunction (SomeTypeFunction2 Int) (SomeTypeFunction3 (SomeTypeFunction 3 (SomeTypeFunction3 String))) which might actually evaluate to something simple like (String, Int), though you wouldn't know it without either tracing through the functions (yuck!) or writing some silly helper functions whose sole job is to force evaluation of the type functions (yuck!). I've never personally been thankful for this behavior.
    - eru 16y ago
      Interesting. I'll try to reproduce your example. Could you make something up that I can just copy-and-paste into ghci? Thanks! Chris Okasaki argues in "Purely Functional Data Structures" for making lazy evaluation optional, but easy to use. Some data structures have optimal asymptotics only when evaluated strictly and some only when evalutated lazily. With better strictness analysers most of the problems lazyness is causing at the moment, may go away. A Haskell compiler is free to make your program (or parts of it) strict, if it can prove that this preserves semantics.

eru 16y ago

The guys on Haskell Cafe delight in complex problems (and solutions). There's a list for beginners, too. You will enjoy the Haskell Cafe later. By the way, one small exercise (from a paper by Chris Okasaki): Write a function with the type Tree a -> Tree Int where data Tree a = Node a (Tree a) (Tree a) | Empty your function should all nodes in a tree with their position in level order traversal (also called breadth first search). E.g. (lot == lever order traversal) lot Empty = Empty lot (Node 'a' (Node 'b' Empty (Node 'c' Empty Empty)) (Node 'd' Empty Empty)) = (Node '0' (Node '1' Empty (Node '3' Empty Empty)) (Node '2' Empty Empty))

gaius 16y ago

The thing with RWH I found was, chapters 1-4 great, a nice introduction to the language, and I did all the exercises without too much head-scratching. Then chapter 5 is utterly incomprehensible. I didn't get any further. OCaml, that's a nice language, with much better introductary materials.

gtani 16y ago
Dont' give up: http://www.amazon.com/Programming-Haskell-Graham-Hutton/dp/0521692695/ http://www.amazon.com/Programming-Haskell-Graham-Hutton/dp/0... http://stackoverflow.com/questions/1012573/how-to-learn-haskell http://stackoverflow.com/questions/1012573/how-to-learn-hask... http://learnyouahaskell.com/ http://learnyouahaskell.com/
anonymousDan 16y ago
What did you find so hard about chapter 5 ("Writing a library: working with JSON data")? Doesn't seem too be such a big step up to me in comparison to other chapters in the book?
anonymousDan 16y ago
What did you find so hard about chapter 5 ("Writing a library: working with JSON data")? Doesn't seem too be such a big step up to me in comparison to other chapters in the book?

Natsu 16y ago

I can actually read some of the syntax. I guess that a mathematical background helps when you're accustomed to seeing function definitions that map one real to another real or some of the other constructs. And I certainly recognize interfaces from Java (and why they can be a lot nicer than C++ style inheritance). What still gets me are some of the basic functional programming concepts like monads and the y combinator, which obviously aren't unique to Haskell. Yeah, I've read Wikipedia on both of those (more than once). And several other things. I've even written some Lisp for my employer. But some of the concepts have yet to "click." I know monads encapsulate side effects or something (and the y combinator finds the fixed points of a function), but I feel like I just don't get the details of how it works. After all, you don't need to know anything about monads to call the print function.

eru 16y ago
Monads are easy to understand: A monad is exactly anything that satisfies the three monad laws. If you have worked with mathematical groups and have seen how mathematicians can look at very disparate things with their group-goggles and find similarities, you will appreciate monads. The y combinator is a nice parlour trick (if you define it in lambda calculus without using any other recursion primitives), and research vehicle. But I did not apply it once, yet. And I've tried. If you want to get combinatorial logic (including the y combinator), read "To Mock a Mockingbird". And do all the puzzles, of course. Actually you should read it, whether you want to learn anything about combinatorial logic or not. It is such a good book.
- Natsu 16y ago
  Thanks, I'll read that.

Zaak 16y ago

> I still find predicting memory/time use under a lazy-evaluation regime difficult. It's not just you. Lazy evaluation makes predicting and understanding resource usage difficult.

eru 16y ago
Indeed. And that's the major shortcoming I see that could prevent me from using Haskell in a production environment. The guys who wrote XMonad got around it, so it is possible. You just need to be careful, and use enough strictness annotations.
- intoverfl0w 16y ago
  Laziness is one of those features I can never make my mind up about. It is sometimes very convenient, but most of the time I never think about the fact that the semantics mean evaluation is lazy. Sometimes this negligence has bad consequences, and then one must invoke a carefully honed skill to correct the issue. Definitely doable, but it certainly feels like fighting the language (to me, anyway). One of the craziest things is that Haskell has decided that type families should also be lazily evaluated. So you can hop into the interactive interpreter to inspect some types and get not-so-useful information, like somevar :: SomeTypeFunction (SomeTypeFunction2 Int) (SomeTypeFunction3 (SomeTypeFunction 3 (SomeTypeFunction3 String))) which might actually evaluate to something simple like (String, Int), though you wouldn't know it without either tracing through the functions (yuck!) or writing some silly helper functions whose sole job is to force evaluation of the type functions (yuck!). I've never personally been thankful for this behavior.
  - eru 16y ago
    Interesting. I'll try to reproduce your example. Could you make something up that I can just copy-and-paste into ghci? Thanks! Chris Okasaki argues in "Purely Functional Data Structures" for making lazy evaluation optional, but easy to use. Some data structures have optimal asymptotics only when evaluated strictly and some only when evalutated lazily. With better strictness analysers most of the problems lazyness is causing at the moment, may go away. A Haskell compiler is free to make your program (or parts of it) strict, if it can prove that this preserves semantics.