[Haskell-cafe] Line noise

[Andrew Coppin]

Philippa Cowderoy wrote:
> 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.
>   

One person complained that "case compare guess target of" was unclear. 
Of course, you and I know that "case" and "of" are actually language 
keywords, and hence this is really "case (compare guess target) of", 
which makes far more sense. (Your suggestion about syntax hilighting is 
relevant here!)

>> - 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.
>   

Haha! Nice...

I think "return" is a rather bad choice of name. But on the other hand, 
I can't think of a better one. And let's face it, anything has to be 
better than (>>=). (Most cryptic name ever?)

>> - 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.
>   

Idiomatic Haskell seems to consist *only* of single-letter variable 
names. When did you last see a pattern like (customer:customers)? No, 
it'd be (c:cs), which isn't very self-documenting. Ditto for type 
variables by the way. (Map k v, anyone?) It also seems to be Haskell 
convention to use "a" as a type variable; personally I always use "x". I 
guess that's the algebra in my blood or something...

>> 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 posted a snippet of code which included the phrase

  mapM_ (\(n,v) -> putStrLn $ "[" ++ show n ++ "] = " ++ show v) (zip 
[0..] vs)

To somebody familiar with Haskell, that is as clear as day. But to a 
newbie... well *you* try explaining that you start at the left end, take 
the thing in brackets, process it from left to right, then take the 
other thing in brackets, process the right side of it, then pass that to 
putStrLn, oh, but that thing right at the left edge is the argument 
list, and then pass the whole lot to mapM_, which is... are you still 
with me??

As one experienced C++ programmer put it, "there is no clear flow from 
left to right or right to left". Personally I found that a little ironic 
comming from the language that gave us

  while (*x++ = *y++) { }

which is every bit as non-linear! ;-)

> 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!
>   

I'd just like to mention that HPaste is invaluable here! ;-)

Oddly, nobody seemed to take much notice when I did this though. (I 
guess most people had seen "oh look, another Haskell thread" and hit the 
thread-kill button by that point...)

> Btw, (> x) reads much more easily as a predicate to most people than (x <=).
>   

Er, yeah, you're probably right. IIRC, (> x) is actually implemented as 
(flip (>) x), whereas (x <) isn't. I doubt there's any efficiency 
difference though. (Surely GHC would inline such a trivial function...)