xmonad as an outsider
I have been reading the xmonad development thread, and it got me to thinking about my experiences with xmonad. I definitely think things could be improved, but I'm not sure how would be best. Maybe it's all a documentation thing, or maybe some of it could be new or changed APIs. I'll just try to explain how I have experienced xmonad, and what gave me problems. First of all, as background, I am a programmer. I did a little Haskell at university, but not much and I use it so rarely that I can never remember the syntax. Mostly I program in C#, C++, Python and a little bit of Coffeescript. I run Ubuntu on a laptop and mostly only install stuff via apt-get. I like the command-line and vim, but I'm no anti-mouse purist and spend a lot of time using only the mouse or the touchpad while browsing the web. 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. 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. * 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. * 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. * 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. 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. Weeble.
On 10 Nov 2011, Weeble wrote:
[snip]
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.
Weeble.
Reading that you find Haskell problematic, I feel a bit better that I, as a non-programmer with no formal computer training, was pretty much stymied. I just copied examples I found on the net but without really understanding them. Have you looked at dwm, written in C? It was the forerunner of xmonad and functionally and visually the two are quite similar. I was able to modify it pretty easily by editing config.h and patching the code even though I know no C. -- Anthony Campbell - ac@acampbell.org.uk Microsoft-free zone - Using Debian GNU/Linux http://www.acampbell.org.uk - sample my ebooks at http://www.smashwords.com/profile/view/acampbell
On 11/10/2011 12:34 PM, Anthony Campbell wrote:
Have you looked at dwm, written in C? It was the forerunner of xmonad and functionally and visually the two are quite similar. I was able to modify it pretty easily by editing config.h and patching the code even though I know no C.
While I'm still also an outsider, I figure I can say this: Posting signs to the help list for X that folks should use competing product Y is likely to eventually generate friction. Seeing the comment I experience an awkward embarrassment, like seeing a fellow guest insult the host's cooking. I'd suggest it would be more polite to make that reply private. As for being mystified by haskell itself: I share some of that befuddlement, but take it as an interesting tinkering opportunity. Playing in a domain which I know well, with an unfamiliar toolset, is pleasant. So I don't anticipate being an outsider long. :) - Allen S. Rout
Allen S. Rout [2011.11.10 1539 -0500]:
On 11/10/2011 12:34 PM, Anthony Campbell wrote:
Have you looked at dwm, written in C? It was the forerunner of xmonad and functionally and visually the two are quite similar. I was able to modify it pretty easily by editing config.h and patching the code even though I know no C.
While I'm still also an outsider, I figure I can say this:
Posting signs to the help list for X that folks should use competing product Y is likely to eventually generate friction. Seeing the comment I experience an awkward embarrassment, like seeing a fellow guest insult the host's cooking. I'd suggest it would be more polite to make that reply private.
As for being mystified by haskell itself: I share some of that befuddlement, but take it as an interesting tinkering opportunity. Playing in a domain which I know well, with an unfamiliar toolset, is pleasant. So I don't anticipate being an outsider long. :)
I like your attitude, Allen. We'll make a Haskeller of you yet ;) Back on topic, I don't really understand why xmonad continually gets so much heat for being implemented and configured in Haskell. I understand that Haskell is a language that's very different from the vast majority of languages out there that differ mostly in syntax but not in what's easy to express in them and what's not. And, indeed, when I first started to learn Haskell, the learning curve was steep to say the least. Now, however, I appreciate the advantages that result from implementing xmonad in Haskell and using the same language for its configuration: I just slapped together a fairly complex new extension module for xmonad, and it took me two evenings. Trying to do the same in a language like C/C++, which doesn't provide the same high level of abstraction, would have been painful if not impossible in the same time frame, at least for me. Then I would have had to support parsing of new configuration constructs, if the configuration language is some custom-made home brew, or at least export the right interface, if lua or something similar was used to configure the WM. Arguably, much of this may still simply be a matter of personal preference and not an objective reason why Haskell may have been a good language to choose for implementing xmonad. However, that's beside the point. I also like openbox very much, which is configured using an XML configuration file, and I detest XML. Do I go screaming to the openbox developers and complain about having to use XML to configure the window manager? No. It was the developers' choice and it is pointless to argue about it because they won't go back and revert their choice unless they see a really good reason for it. If I like the window manager enough, I get over whatever I don't like about how to configure it and learn what I need to use it effectively, even if it means to learn Haskell (you actually won't have to learn much Haskell to configure xmonad). If the configuration syntax bothers me enough to detract me from the window manager, I move on and find one that suits me better. Cheers, Norbert
On 11/10/2011 05:13 PM, Norbert Zeh wrote:
Now, however, I appreciate the advantages that result from implementing xmonad in Haskell and using the same language for its configuration: I just slapped together a fairly complex new extension module for xmonad, and it took me two evenings.
IMO, The problem is simply the learning curve to get started. I've been failing to convince people to work with EMACS on that basis for decades. The two cases actually have deep congrence: Complex and subtle applications with a minimal core, customized (and mostly composed) of functional-language forms on top of that core. No real barrier between a 'collection of tweaks' and a 'contrib module' and an 'extension'. - Allen S. Rout
Allen S. Rout [2011.11.14 1335 -0500]:
On 11/10/2011 05:13 PM, Norbert Zeh wrote:
Now, however, I appreciate the advantages that result from implementing xmonad in Haskell and using the same language for its configuration: I just slapped together a fairly complex new extension module for xmonad, and it took me two evenings.
IMO, The problem is simply the learning curve to get started. I've been failing to convince people to work with EMACS on that basis for decades. The two cases actually have deep congrence: Complex and subtle applications with a minimal core, customized (and mostly composed) of functional-language forms on top of that core.
My colleagues always get amazed at what I use emacs for ;) The learning curve was steep indeed, but now I wouldn't want to miss its power. The same goes for xmonad.
No real barrier between a 'collection of tweaks' and a 'contrib module' and an 'extension'.
Indeed. This is exactly where I think xmonad's strength lies: I have a full-blown programming language at my disposal even in my configuration file. This makes the possibilities to tweak it exactly how I want it limitless. Once my tweaks mature into something general that would be worthwhile to share with the community, the fact that the language I implemented my tweaks in is exactly the same the core and the contrib modules are written in makes turning my tweaks into a contrib module so much easier. Cheers, Norbert
On 10 Nov 2011, Allen S. Rout wrote:
On 11/10/2011 12:34 PM, Anthony Campbell wrote:
Have you looked at dwm, written in C? It was the forerunner of xmonad and functionally and visually the two are quite similar. I was able to modify it pretty easily by editing config.h and patching the code even though I know no C.
While I'm still also an outsider, I figure I can say this:
Posting signs to the help list for X that folks should use competing product Y is likely to eventually generate friction. Seeing the comment I experience an awkward embarrassment, like seeing a fellow guest insult the host's cooking. I'd suggest it would be more polite to make that reply private.
[snip] Well, it was you who brought the subject up in the first place :)
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.
People debate the advantages and disadvantages of Debian vs other distributions on the Debian users mailing list without anyone taking offence. That seems to me to be in tune with the philosophy of the free software movement. Anyway,for the record, I too think that xmonad is brilliant and I had no intention of starting a flame war. I merely thought that it was worth mentioning that dwm, from which xmonad derives, works in much the same way and is perhaps easier to configure for newcomers. I recommend both on my blog. But if anyone is offended, I apologise and shall not mention it again. -- Anthony Campbell - ac@acampbell.org.uk Microsoft-free zone - Using Debian GNU/Linux http://www.acampbell.org.uk - sample my ebooks at http://www.smashwords.com/profile/view/acampbell
On 11 Nov 2011, Anthony Campbell wrote:
Well, it was you who brought the subject up in the first place :)
Sorry, I got the authorship of the thread mixed up - it wasn't you whom I quoted, it was Weeble. -- Anthony Campbell - ac@acampbell.org.uk Microsoft-free zone - Using Debian GNU/Linux http://www.acampbell.org.uk - sample my ebooks at http://www.smashwords.com/profile/view/acampbell
On Thu, Nov 10, 2011 at 5:34 PM, Anthony Campbell
Reading that you find Haskell problematic, I feel a bit better that I, as a non-programmer with no formal computer training, was pretty much stymied. I just copied examples I found on the net but without really understanding them.
I always feel kind of guilty for not being better at reading Haskell. I actually really enjoyed it at university, and I have a great fondness for functional programming. I have no philosophical objections to it. I just find it very hard to guess what an unfamiliar piece of code does.
Have you looked at dwm, written in C? It was the forerunner of xmonad and functionally and visually the two are quite similar. I was able to modify it pretty easily by editing config.h and patching the code even though I know no C.
I've tried a few others, but not dwm. I think I tried awesome. I haven't tried anything I liked more than xmonad. If anything were to steal me away from xmonad, it would need to match the flexibility and either make it easier to configure or provide compelling features (e.g. a tiling compositing WM to do zooming or pretty highlighting). I wouldn't trade off xmonad's features just for easier configuration.
On 11 Nov 2011, Weeble wrote:
I always feel kind of guilty for not being better at reading Haskell. I actually really enjoyed it at university, and I have a great fondness for functional programming. I have no philosophical objections to it. I just find it very hard to guess what an unfamiliar piece of code does.
Have you looked at dwm, written in C? It was the forerunner of xmonad and functionally and visually the two are quite similar. I was able to modify it pretty easily by editing config.h and patching the code even though I know no C.
I've tried a few others, but not dwm. I think I tried awesome. I haven't tried anything I liked more than xmonad. If anything were to steal me away from xmonad, it would need to match the flexibility and either make it easier to configure or provide compelling features (e.g. a tiling compositing WM to do zooming or pretty highlighting). I wouldn't trade off xmonad's features just for easier configuration.
Point taken. You are obviously much more sophisticated in computer terms than me - I have no formal instruction at all and have just picked things up, or not, as I went along. Haskell was a pretty tough nut for me and I would have to put in a lot of work to get even a slight acquaintence with it. That's not to say that it wouldn't be worth while, but life is short, art long ... -- Anthony Campbell - ac@acampbell.org.uk Microsoft-free zone - Using Debian GNU/Linux http://www.acampbell.org.uk - sample my ebooks at http://www.smashwords.com/profile/view/acampbell
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
On Thu, Nov 10, 2011 at 09:12, Weeble
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
This should be better documented, but not necessarily in the sense you mean; that particular argument set is common in xmonad, and is documented in XMonad.Layout (see the Tall layout). -- brandon s allbery allbery.b@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms
participants (6)
-
Allen S. Rout -
Anthony Campbell -
Brandon Allbery -
Daniel Schoepe -
Norbert Zeh -
Weeble