"Allen S. Rout" writes:

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.

You should also consider StumpWM, it's more like Emacs (in that it can be hacked at runtime) than Xmonad is: http://www.nongnu.org/stumpwm/

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?

If you install cabal (a Haskell package manager), dependencies are not a problem. I have certainly noticed very few. And even if you do not, rather using adistribution-provided xmonad/xmonad-contrib packages, those potential problems should already be taken care of. In fact, when configuring xmonad, you rarely care about new versions of things - there's enough already-written stuff to pick from that it'll keep you busy for quite a while. -- \ Troels /\ Henriksen

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