> 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].)
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).
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.
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:
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) Secondly, the types tell a lot about a function and it's parameters, for the above 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