4 ms·

Ah, powerpoint presentations where the truth is somewhere between the bullet points. I would have preferred a blog post which gives the author enough breathing

• prof_hobart 14y ago
  I think that one of its biggest problems has been the vast majority of the "Teach Yourself Haskell" books/articles. When I first had a go at learning it, I ran into two common problems with them. Firstly they usually did a great job of showing you how to write a quicksort or a Fibonacci sequence but then struggled to explain how it applied to most every day challenges (things like i/o - and yes, I sort of understand the complexity around that in Haskell, but as a developer, it's one of the key things I'm likely to want to do). The other problem was that examples were typically full of what I would consider appallingly named/abbreviated functions,parameters etc "fib' (f, g) p" for example. When you're already struggling to understand langauge concepts, having your code full of "f,g, and p" and trying to remember what they mean really doesn't help. I think it's improving (Learn You a Haskell looks pretty good, but I've not had a serious attempt to re-learn since that appeared), but it's always been a bit of stumbling block for me in the past.
  • adimitrov 14y ago
    The other problem was that examples were typically full of what I would consider appallingly named/abbreviated functions,parameters etc. That's mostly due to the mathematical or computer-science background of most people who wrote these articles in the early days. It's entirely normal in mathematics etc. to use brief variable names, and it carried over into Haskell because of the large cultural overlap between Haskellers and academics. For short examples, I hugely prefer the short notation with "appalling" names, but that might be due to my background in formal logic and mathematics. It doesn't help in software development, and it's poison in larger applications, that's for sure. But for short examples, you get used to it pretty quickly. You should check out both Real World Haskell and Learn You a Haskell (both are also freely available online.) They're really well-written, and part of why Haskell's community is so awesome.
  • dbaupp 14y ago
    > The other problem was that examples were typically full of what I would consider appallingly named/abbreviated functions,parameters etc As adimitrov points out, this is in many ways a carry over from mathematics. However, this isn't the only factor. For the parameters: Expressions and functions in general are usually much shorter in Haskell than in other languages, so one can see how the variable is being used, e.g. the conventional definition of map is: map f [] = [] map f (x:xs) = f x : map f xs One can tell that f is a function and that it's doing something to the first element of second argument, and then recurring on the rest of that list. That is much much nice, than (at worst) map function list = if null list then [] else ((function (head list)):map function (tail list)) Secondly, the types tell a lot about a function and it's parameters, for the above map :: (a -> b) -> [a] -> [b] one can easily see that the first argument is a function and the second is a list, and the specific types mean that there is a single sensible way to combine them: apply the function to every element of the list. (Lastly, there are conventions, which take a little time to learn, but they help. E.g. f, g, h for parameters which are functions, (x:xs), (y:ys) for head/tails of lists.) However, naming the functions poorly is a problem. (But type do help with this too, especially with Hoogle[1].) [1]: http://haskell.org/hoogle http://haskell.org/hoogle
    • prof_hobart 14y ago
      The x:xs one is fine as long as it's properly explained in the tutorial - e.g. it's a list of items, with x being the first item and xs being all other items in the list. The map :: (a -> b) -> [a] -> [b] may well be abundantly clear once you understand Haskell's types, but is rather less so when you're first learning. In that particular case, I'm not entirely sure I could come up with a clearer set of names, but there's plenty of times when I was first learning that I really struggled with getting to grips with a concept simply because the naming left me wondering why I was passing an A into a Q to get a list of Zs (or whatever it was).
      • wonderzombie 14y ago
        I'm not sure how specific to Haskell this actually is, though. Think of templates in C++ (esp. template functions) or generics in Java. You use T or whatever as a placeholder for actual types. Any time you need more than one type, you're forced to make a similar decision about how to describe a type about which you know very little. It's is a heck of a lot more concise than either of those, though. Might this be the actual stumbling block? You're saying a lot about map -- in a very precise way, mind you -- without writing a lot.
• lucian1900 14y ago
  I wouldn't say Clojure has a more familiar syntax than Haskell. If anything, it's the opposite.