On 10/01/2011 08: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)
1) This was true in-between awesome 2 and 3 as far as I remember, I
often found my configurations faulty when updating to a new version.
awesome 3 however doesn't modify much of the configuration since the
base library and C API is considered sufficient for what you might want
to do. Anything beyond that should be implemented by yourself.
2) awesome itself has a very stable code-base, any segfaults I've
encountered has been due to faulty libraries or hardware.
3) Really? 'Cause I find haskell code not readable at all, but that's
because I don't know haskell. Obviously the author of these critics is a
haskell programer and loves the way the language structure is built. I
see that, I love python way more than Lua or PHP for instance, but that
doesn't make Lua less readable. It's a matter of taste and preference.
4) Yeah I feel that argument, I'd love to be able to interact deeper
with the awesome codebase, but that concept in my opinion introduces the
possibility for some really nasty bugs that could be quite hard to debug
if you don't know exactly what you're doing. Separating user stuff and
low-level stuff is a common and very old concept, old as in "computer
era" old. You wouldn't want all your software code to be run in
kernel-space right? (Explicitly exadurated example only to give a better
understanding of what I mean).
5) That I agree with, the Lua API has a poor documentation and could
really do some revamp. Lack of examples in the code and explicit usage
makes it somewhat hard during certain occasions.
I would however like to mention that the author isn't really independant
from his preferences during this, he obviously made up his mind in
advance on what arguments to put his power on and what not to.
--
To unsubscribe, send mail to [email protected].
