[Haskell-cafe] Things to avoid (Was: Top 20 ``things'' to know in
thjaeger at gmail.com
Thu Feb 10 08:51:43 EST 2005
On Thu, 10 Feb 2005 12:50:16 +0100 (MET), Henning Thielemann
<lemming at henning-thielemann.de> wrote:
> On Thu, 10 Feb 2005, [ISO-8859-1] Thomas Jäger wrote:
> > Altogether, the spirit of the page seems to be "use as little
> > syntactic sugar as possible" which maybe appropriate if it is aimed at
> > newbies, who often overuse syntactic sugar (do-notation).
> This overuse is what I observed and what I like to reduce. There are many
> people advocating Haskell just because of the sugar, which let interested
> people fail to see what's essential for Haskell. When someone says to me
> that there is a new language which I should know of because it supports
> definition of infix operators and list comprehension, I shake my head and
> wonder why he don't simply stick to Perl, Python, C++ or whatever.
I don't believe that Haskell advocacy usually happens on such a
superficial level, in fact most users of curly-braced languages hate
Haskell's syntax, so that won't be an argument for Haskell anyway.
Looking at it closer, syntax often makes a huge difference. Haskell is
an many ways similar to mathematical notation, which allows to express
complicated concepts in a concise way and happens to use a lot of
syntactic sugar. There should be no doubt about that 1 + 2 + 3 is
easier for humans to parse than (+ (+ 1 2)).
This becomes especially important when you are embedding a domain
specific language into Haskell. Allowing combinators to be used infix
make code more readable, better understandable, reduces parenthesis,
and sometimes resolves the question in which order the arguments of
the functions appear. It's not strictly necessary, but is a big
advantage over postfix-languages.
> What I forgot: Each new syntactic sugar is something more, a reader must
> know, a compiler and debugger developer must implement and test, a source
> code formatter, highlighter, documentation extractor or code transformer
> must respect. We should try harder to reduce these extensions rather than
> inventing new ones. Leave the award for the most complicated syntax for
> C++! :-]
Ideally, new syntactic sugar is self-explanatory, and this is the case
for most of Haskell's sugar (maybe in contrast to C++). The fact that
some tools get a little more complicated doesn't bother me much if it
helps me write my program in a more concise way.
> That's why I want to stress that the syntactic sugar is much less
> important or even necessary than generally believed. I hope that the
> examples clarify that.
Yeah, as long as it is explained and clearly marked as an opinion (as
it is now), that's ok. One reason that I got so excited about that is
because I don't like the current situation with (n+k)-patterns:
Everybody says they're evil, but hardly anybody can explain why he
More information about the Haskell-Cafe