Is your keyboard jammed, or are you just writing Haskell?

I’ve been getting back into Haskell lately because I’ve been using the XMonad window manager, which is written and configured in Haskell. Haskell has always held a special place in my heart; I taught myself Haskell by plowing through the ironically-named “Gentle Introduction to Haskell” several years ago, and it taught me more about clean side-effect free functional programming than any amount of Lisp.

A programming language must be considered in the context of its community, and Haskell has an exemplary one. #xmonad is without a doubt one of the friendliest and most helpful channels on IRC, without any of the elite condescension one usually finds on channels devoted to hardcore geek tools like Emacs. I have come to believe, however, that this polite exterior conceals a deep and consuming madness.

I refer to the Haskell community’s addiction to defining operators. Haskell permits virtually any string of nonword characters to be defined as a new operator. This in itself is not a problem, but Haskell programmers seem not to have absorbed the lesson that just because you can, doesn’t mean you should.

To make my point, I call upon Mark Twain, somewhat paraphrased:

In my note-book I find this entry:

July 1. — In the hospital yesterday, an operator of thirteen characters was successfully removed from a patient — a web developer from near Baltimore; but as most unfortunately the surgeons had opened him in the wrong place, under the impression that he contained a stack trace, he died. The sad event has cast a gloom over the whole community.

That paragraph furnishes a text for a few remarks about one of the most curious and notable features of my subject — the length and obscurity of Haskell operators. Some Haskell operators are so long that they have a perspective. Observe these examples:

  • -->
  • < &&>
  • |||

These things are not operators, they are symbolic processions. And they are not rare; one can open an xmonad.hs at any time and see them marching majestically across the screen — and if he has any imagination he can see the banners and hear the music, too. They impart a martial thrill to the meekest subject. I take a great interest in these curiosities. Whenever I come across a good one, I stuff it and put it in my museum. In this way I have made quite a valuable collection. When I get duplicates, I exchange with other collectors, and thus increase the variety of my stock. Here are some specimens which I lately bought at an auction sale of the effects of a bankrupt bric-a-brac hunter:

  • .|.
  • < +>
  • >>>
  • ^>>
  • +++

Of course when one of these grand mountain ranges goes stretching across the LCD screen, it adorns and ennobles that coding landscape — but at the same time it is a great distress to the new student, for it blocks up his way; he cannot crawl under it, or climb over it, or tunnel through it.

[ad#PostInline]

10 comments

  1. I really wouldn't see any benefit calling “>>>”, for instance, “compose” instead. A newbie would miss the semantics anyway. Having a weird operator name at least makes a new developer check the documentation first.

    PS: Great thing that you mentioned the 'ironically-named “Gentle Introduction to Haskell”' … I also had a hard time reading it as first introduction, mislead by its name 😉

    1. On that I'm afraid we must differ – I prefer an at least vaguely meaningful (and google-able!) name like “compose” to the completely opaque “>>>”.

      The “Gentle Introduction” is gentle like a kick to the back of the head. But you wind up a better programmer for it 🙂

  2. I totally and super-uber agree. Haskell is one of my favourite languages ATM, but all the operators kill me, not when writing, but when maintaining code. Perl & line-noise springs to mind.

    The fact that they cannot be googled/yahood etc. is also very annoying, although hoogle helped me out most of the time there.

  3. Isn't the message of Twain's essay exactly the opposite? Perhaps it could be a criticism of Forth, but isn't the message that infix operators (verbs) aid readability?

  4. I defined a '+++' in my code — for adding matrices. It looks 'plus-y'. + was already taken for numbers, ++ was already taken for lists, so I used three.
    I figured the meaning was evident and the readibility was nicer than looking at:
    a +++ b +++ c
    vs.
    matrixAdd (matrixAdd a b) c

    1. Why not use matAdd (notice the backquotes). That's what I don't understand, why do people need to use weird symbols instead of using the infix notations for binary functions? It's not that much additional typing (especially if you use shorter names for function), there's only 2 additional characters. The additional information you get is, however, exactly what the operator does. Think dot product for vectors, what's wrong with dot, or cross for crossProduct?

      1. Or why not define matrices as a Num instance? Maybe they don't quite fit, but that can't be much worse than having to use +++.

  5. Or why not define matrices as a Num instance? Maybe they don't quite fit, but that can't be much worse than having to use +++.

  6. totally agree and love the title. For those who disagree what is the meaning of the “+++” operator and how does a newbie find it?

Leave a Reply to dons Cancel reply

Your email address will not be published. Required fields are marked *