On Thu, 10 Nov 2011 14:12:38 +0000, Weeble
I think I first installed xmonad via apt-get, and at some point had some problem that meant moving to cabal or darcs. That was a bit of a pain, especially trying to understand where each of these things had put files and knowing whether I'd successfully uninstalled them later. What is much more of a pain is months later when I try to change something and realise I need to upgrade and then I'm not even sure how I installed xmonad in the first place, so I'm not sure what I need to do to update it. After an upgrade to a new version of Ubuntu there's generally a period of a few weeks before I find the time to figure out how to get xmonad up and running again.
Yes, releasing a new version so the need to switch to darcs wouldn't arise so frequently/quickly would definitely be the right thing to do, but as you probably read in the other thread, there are a few problems on the way to making that happen at the moment. :)
Configuring xmonad is generally pretty mystifying. Even though I have a basic knowledge of Haskell, it's often very hard to untangle things in the config file or in examples. Problems I've had:
* Strange symbols, like ".|.", "|||", "-->", "=?", "<&&>". These can't be Googled for, so it's hard to find out what they do or where they're defined. Haskell already has lots of operators that aren't particularly familiar to programmers coming from other languages, so this just seems to add to the confusion.
Most of those are defined by xmonad, with the exception of ".|." which is also not built into the language, so this is not a problem (if it's a problem; see below on how to find information on those operators) with Haskell, but with possibly defining too many operators. FWIW: In my opinion, it doesn't take long to get used to them and afterwards the resulting code is a lot clearer than it would be if "normal" function names were used for those.
* Hard to find out where functions are defined. Example configuration files generally import all modules into the one big namespace. In Python, the equivalent construct, "from foo import *" is generally discouraged for this reason, but I don't know what's conventional in Haskell. It seems the forms "import Module (x,y,z)" or "import qualified Module" would be better for example configuration files, as they aid discoverability: then when I see a name used in a configuration file I can easily see which module it came from without having to grep through source files.
Not a perfect solution, but you can load your xmonad.hs into ghci (:l xmonad.hs) and run, for example ":i (|||)" or ":i doShift" to find out where those symbols are defined (and look up their documentation, if the name sounds cryptic or if it's an operator).
* Poor layout documentation. One of the things I was most interested when I was a new user was in finding out what layouts were available and how to compose them. I found the layout documentation to be very limited. There's no overview and there are no diagrams, just a great big list of layout names, so to find anything you pretty much have to try them all one by one. Even worse, some of them require arguments that they do not document. E.g. http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Layout-Dishes.html If there is somewhere that shows example screenshots of all these layouts, it would be good if it was more prominently linked from the docs.
That's a fair point, but the only reply that comes to mind is "patches/screenshots welcome", since at least screenshots don't require any knowledge of Haskell. :)
* Baffling failure messages. If you make a mistake in your xmonad configuration, or if you upgrade and the API for something has changed, the error messages are generally very hard to understand, and it can take quite a deep understanding of Haskell to realise that you just missed out an argument or used the wrong operator.
Aside from working on that directly by improving GHC, I don't think there's a lot that can be done about that in xmonad: If xmonad used a special configuration language, the error messages would probably be better, but I think that would mean giving up most of the flexibility that makes xmonad so nice to use/customize. Hypothetically, if xmonad used some dynamically typed language like Python or Lua, it would result in the window manager blowing up at runtime with error locations that might be far away from the actual source. If xmonad used a less "abstract" language (e.g. C) that allowed for more specific error messages (that is not to say that gcc's error messages are more understandable than GHC's though), I think the config file would be a lot more convoluted and a lot less fun to write, at least for me.
I think most of these things can be improved, though maybe not the error messages. I really love *using* xmonad, and I've not found another window manager that I'm nearly as happy with, but the horror of *configuring* xmonad wastes a lot of my time and makes me disinclined to recommend it to others.
Great to hear that you still like xmonad, despite your "perceived overexposure" to Haskell. :) If we finally manage to make a release, setting up xmonad on another machine should be as simple as copying over your old configuration file. Normally, config-breaking changes are quite rare. Cheers, Daniel