[xmonad] xmonad for the Haskell unwashed?

[Norbert Zeh]

Allen S. Rout [2011.09.27 1014 -0400]:
> 
> Hi; I'm contemplating a tiling WM, and am drawn to xmonad because
> its customisation language is its implementation language;  I'm long
> accustomed to this in e.g. EMACS, so I feel it'd be a good fit.
> 
> But a friend, who's otherwise an outspoken Haskell advocate, put
> xmonad down in favor of awesome for reasons I'll summarize as
> 'dependency hell'.
> 
> I'm interested in the perspective of the xmonad clan on this: If I
> pick up xmonad simply because I want a hackable WM, how much Haskell
> janitorial work will I be taking on?  Is there a straightfoward and
> broadly accepted base of package repositories?   Are the
> participants in the module ecosystem pretty careful not to break
> stuff?    Do current versions of various xmonad packages all depend
> on the current versions of their dependencies?

To add my 2c to the discussion.  I came to xmonad via awesome.  Here are my
reasons for the switch, in no particular order.

1)  The xmonad community has a culture of making changes in a way that does not
    break existing configurations.  So you can happily upgrade to the latest
    version/pull patches from darcs without being afraid that it might hose your
    setup.  The awesome config file syntax is a moving target, changing with pretty
    much every major release.  This may have changed in the recent past.  If so,
    it was too late for me to consider to switch back.

2)  xmonad never once crashed on me, while awesome segfaulted at some very
    inopportune moments while I used it.  Again, stability may have improved
    in recent releases, but I'm not switching back only to find out.

3)  I always considered xmonad's configuration files much more readable than an
    awesome configuration file doing the same thing.  I guess that's a result of
    the greater expressive power of Haskell vs lua and, probably even more so, a
    result of the well thought-out interface provided by the base xmonad library.

4)  Using the same language for implementing xmonad and for configuring it
    blurs the line between configuring things and implementing new features.  In
    this instance, this is a good thing because it makes it much easier to add
    non-standard features and tinker with ideas that over time may grow into new
    add-on modules in XMonadContrib.  When I used awesome, I tried to apply the
    kind of heavy customization I apply to xmonad nowadays and I almost always
    found myself either hacking C or writing really clunky and round-about lua
    code.  Of course one may argue that, since xmonad is implemented in Haskell,
    writing non-trivial Haskell code in my configuration file is the same as adding
    to the C code base of awesome, but it's not because Haskell allows me to
    express myself at a much higher level of abstraction.

5)  The power of a DIY windowmanager such as xmonad or awesome depends heavily
    on the quality of the documentation.  In the case of xmonad, I find the base
    xmonad library and the vast majority of the modules in XMonadContrib to be
    extremely well documented and as a result easy to use.  In contrast, I find
    awesome's documentation nearly useless.  The wiki provides documentation by
    example without a comprehensive list of objects/functions that are available.
    The API documentation just strikes me as extremely terse and possibly incomplete.

There are two things where I would consider awesome to have the lead over xmonad:

1)  It is indeed less processor-hungry than xmonad, but when my normal desktop
    use of my machine does not push my processor utilization beyond 5% even using
    xmonad, does it really matter?

2)  xmonad does have more dependencies in the form of added haskell libraries, while
    awesome relies on little more than the plain XCB headers + library.  As other
    respondents said, though, the dependencies are absolutely unproblematic to handle
    using cabal.

Cheers,
Norbert