I mostly agree with Pontus that the original poster was just looking for
arguments to justify the usage of his Haskell-written system. The
arguments came up pretty weak.
1) Moving to Lua in third major release was a nice decision. After that
no big changes happened that I'm aware of. Maybe the deprecation of
hooks broke some code but there was much time given to get rid of them.
2) I hear many issues about awesome stability but I haven't ever seen
any. Of course my widgets crash from time to time but that's
understandable. The awesome itself is very stable.
3) Once again, if you know Haskell you'll find XMonad configuration
enlightening. If you don't you'll find it alien as hell. As for me, I'm
a determined Lisp programmer, but I still like Awesome over StumpWM. The
reason is that in order to script my WM I want a scripting language -
not the one which requires you to implement zygohistomorphic
prepromorphisms just to create a tag (pun for Haskellers intended). When
I was writing awesompd Lua offered me enough scripting capabilities and
even beyond.
4) Pontus said about this enough already. I totally agree with him.
On 10/01/2011 09:15 AM, Teika Kazura wrote:
Hi. A comment critical on Awesome appeared in xmonad mailing
list[1]. I also often came across these points browsing web. Some may
be outdated, as he says, and for Awesome's sake, it's worth
correcting, if possible. (And add them to the FAQ.) So please advocate
Awesome. (I'm not an Awesome user.)
[1]http://permalink.gmane.org/gmane.comp.lang.haskell.xmonad/11551
On Tue, 27 Sep 2011 17:40:15 -0300, Norbert Zeh wrote:
I came to xmonad via awesome. Here are my reasons for the switch,
in no particular order.
1) [...] The awesome config file syntax is a moving target, changing with
pretty
much every major release. This may have changed in the recent past.
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, [...]
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.
Let me deepen this point a bit. I'm a user of Sawfish and Emacs, and
I understand what he says about Xmonad. But a good structure to harness
your own hack and upstream codes is lacking. (For example, I override
/usr/share/emacs/.../paren.el with my own code. But upgrading Emacs
is a bit of headache.) I think there should be "something" in this point.
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.
This person also says there's pros of Awesome over Xmonad, but I omit
them. See the reference URL above.
With best regards.
Teika (Teika kazura)
--
To unsubscribe, send mail to [email protected].
