Log in

No account? Create an account
tachikoma valentines

In the footsteps of wmii

dtlin@burnup:~$ wc dwm-3.8/*.[ch]
  402  1274  9459 dwm-3.8/client.c
   99   593  3859 dwm-3.8/config.arg.h
   97   588  3862 dwm-3.8/config.default.h
  136   448  2911 dwm-3.8/draw.c
  147  1003  6186 dwm-3.8/dwm.h
  365  1025  8124 dwm-3.8/event.c
  255   779  4816 dwm-3.8/layout.c
  325  1066  9123 dwm-3.8/main.c
  154   425  2836 dwm-3.8/tag.c
   54   142  1053 dwm-3.8/util.c
 2034  7343 52229 total
dtlin@burnup:~$ cat dwm-3.8/*.[ch] | gzip -9 | wc -c
dtlin@burnup:~$ wc xmonad/*.hs
   97   584  3787 xmonad/Config.hs
  184   848  5877 xmonad/Main.hs
  223  1242  7822 xmonad/Operations.hs
  179  1334  7148 xmonad/StackSet.hs
  114   567  3708 xmonad/XMonad.hs
  797  4575 28342 total
dtlin@burnup:~$ cat xmonad/*.hs | gzip -9 | wc -c

(I failed at counting the first time I tried to compare them.  Computers are really much better at this than I am.)

Both dwm and xmonad are minimalistic X11 window managers, roughly equivalent in goals.  Not that comparing anything to C is ever fair, but note that dwm, written in C, is nearly triple the line count of xmonad, written in Haskell.  xmonad even supports Xinerama, which dwm doesn’t do.

Surprisingly, dwm only contains about 20 lines dedicated to memory management and not much more dealing with linked list management, while xmonad contains 180 lines for a rotating stack data structure.  i.e., dwm is unusually small and xmonad is unusually large, for C and Haskell projects.




You managed to count the config file twice for dwm. There are two example files.

I should also note that "lines of code", especially in two such radically different languages, says little about overall simplicity of implementation. I've not seen a single post yet that actually looked at the code and gave their approximation in this regard.

Re: Er

Thanks.  I didn’t catch that I double-counted for dwm, so its measures are about 100 lines (4k text) too high.  And in the meantime, xmonad has grown to
  998  5820 36762 11398 (lines, words, bytes, gzip-9)
with its inaugural release.

And yes, of course comparing these languages in this fashion is completely unfair.  Everybody should know that stats lie, and I’m abusing them for promotional purposes here.

I am simply very happy to see demonstrated that Haskell is capable of system-level manipulation from a high-level perspective.  I have taken a look at the code; dwm is very well-written, but xmonad is far easier to comprehend: the data flow is much more obvious, and concerns are better separated.



Ridiculous comparison.

The goals of dwm and xmonad are not at all similar.

Dwm is a truly minimalist core, which users are expected to expand upon. You add to it with your own C code or patches produced by others. The goal is maximum efficiency.

Xmonad is a poster child for haskell, a language which otherwise lacks examples of usefulness in the real world. It comes pre-configured with many features that not all users will want, therefore it cannot be considered minimalist. It is similar to dwm in that one is expected to modify it, and that one must compile the code. However, dwm is written in the base language of UNIX/Linux (i.e. C), whereas Xmonad is written in some language from frickin' Mars. Xmonad brings with it not only the requirement to install an oddball compiler and associated dependencies, but the requirement to learn an oddball language (neither of which one will have use for, other than tinkering with their windows manager configuration).

In short, dwm is serious business, and Xmonad is a toy.