So, after 2 months of activity:
From a whole bunch of developers, and unabated growth in the code base ..
;) Actually, unabated growth in comments in the code base:
xmonad 0.2 is released! Yay, a proper
tiling window manager in Haskell, ready to use. It's been a lot of fun
working on this project, and I think it's been a real success so far.
We've been able to develop very quickly and apply good Haskell
methodologies, such as strong typing, QuickCheck, and Neil's cool
`catch' pattern verifier, to a real-world program.
In fact, it has been remarkable how several times that, after large
refactoring and rewrites have taken place, once the code type checks and
the QuickChecks pass, the application hums along as if nothing changed.
We rewrote the entire core over a weekend a little while ago, and the
code just worked. It was scary!
There are lessons here, I think, for `agile' development.
We spent a bit of time early on building up a large set of generic window manager
properties, stated as QuickCheck predicates.
Once this was in place, it gave us the confidence to try out
experimental changes, because as long as the types check, and
the QC properties hold, things seem to just work.
Making code experiments safe really improves the development experience.
You feel more comfortable playing with the code, and pushing it in
unusual or radical directions. With strong types, and automated
testing, you have the machine support to move the code faster and
further..
We've been able to use a lot of automated testing because, although
xmonad would appear to be a very eventful, imperative program -- a
window manager -- it all runs on top of a purely functional core (the
xmonad `zipper' data structure). The imperative layer of the window
manager -- that part that talks to the X server -- is just a skin over
a referentially transparent core (which models the desktop state). And
with such a core, we can do a lot of automated testing. The core window
manager can be tested without even needing an X server (so we run
automated tests on each darcs commit). Keep your code
pure, so you can test harder, and the bugs will stay far
away.
Another interesting point: once we found the right data structure -- a
zipper of
workspaces (an xmonad workspace is a one hole context of a window list) -- the
code got far simpler (see the drop in the lines of code count around patch
300), the QC properties got stronger, and more invariants were
determined statically by the data structure itself.
Pick a data structure that embeds the semantics of the domain
you're modelling and your life will be easier.
I doubt we would have attempted such a radical experiment as the zipper
rewrite, without the QC properties in place first -- and for purely
political reasons: with the QC tests it is easier to gain the trust of
the other developers that the wacky idea of a complete rewrite, would be safe.
Other devs need not trust you, they can look at the QC properties, and
check for themselves that the code is ok. QuickCheck helps you win
friends and influence people ;-).
So, I think xmonad is now a serious, highly usable tiling window
manager. If you like dwm-style tiling, but need proper full screen, or
Xinerama support (or just like hacking Haskell), xmonad is the logical
choice, in this area. And weighing in at 1/40th the size of the Ion
window manager is a bonus.
And now, thanks to Jason Creighton, xmonad supports a true floating
layer per-workspace, as well:
The future looks pretty bright for xmonad, I think. Its remarkably
stable, small and simple. And becoming quite well documented. You can now tile
your windows, purely functionally!
/home ::
/haskell ::
permalink ::
rss