On Sun, 21 Sep 2008, Andrew Coppin wrote:
Actually, none of these things were mentioned. The things people have *actually* complained to me about are: - Haskell expressions are difficult to parse.
This is partly an "it's not braces, semicolons and function(application)" complaint, though not entirely.
- Several standard library elements have unhelpful names such as "elem", "Eq" and "fst". (My favourite has to be "Ix". I mean, WTH?)
- Several standard library functions have names which clash badly with the usual meanings of those names - e.g., "break", "return", "id".
For this one, I'm inclined to say "welcome to a new paradigm". Though having to tell my dad briefly that do isn't a loop construct was odd for a moment.
- Variable names such as "x" and "f" aren't fabulously helpful to lost programmers trying to find their way.
So don't use them? Though I think f in particular has its place in higher order functions.
The people I spoke to also seemed pretty confused about the usage of (.) and ($), even after I explained it a few times. Several people also voiced being puzzled about Haskell's layout rules.
Pointless style is definitely newbie-unfriendly. I can understand being puzzled by layout: ultimately I had to go read the description in the Report to be happy.
I'm not sure what we *do* with all this data, but I found it interesting so I thought I'd share. ;-) I've spent the last few years trying to convert a few people to The Haskell Way(tm), but so far I haven't succeeded in the slightest. I just get yelled at for pointing white noise. Heh. Oh well!
Have you tried showing people code that's been syntax highlighted? It's likely to help, especially with things like "does function application bind tighter?" where the highlighting is something of a cue. So is marking out = as important! Btw, (> x) reads much more easily as a predicate to most people than (x <=). -- flippa@flippac.org Sometimes you gotta fight fire with fire. Most of the time you just get burnt worse though.