[xmonad] xmonad for the Haskell unwashed?
nzeh at cs.dal.ca
Tue Sep 27 22:40:15 CEST 2011
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
More information about the xmonad