xmonad for the Haskell unwashed?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

xmonad for the Haskell unwashed?

Allen S. Rout

Hi; I'm contemplating a tiling WM, and am drawn to xmonad because its
customisation language is its implementation language;  I'm long
accustomed to this in e.g. EMACS, so I feel it'd be a good fit.

But a friend, who's otherwise an outspoken Haskell advocate, put xmonad
down in favor of awesome for reasons I'll summarize as 'dependency hell'.

I'm interested in the perspective of the xmonad clan on this: If I pick
up xmonad simply because I want a hackable WM, how much Haskell
janitorial work will I be taking on?  Is there a straightfoward and
broadly accepted base of package repositories?   Are the participants in
the module ecosystem pretty careful not to break stuff?    Do current
versions of various xmonad packages all depend on the current versions
of their dependencies?



- Allen S. Rout




Reply | Threaded
Open this post in threaded view
|

xmonad for the Haskell unwashed?

Troels Henriksen
"Allen S. Rout" <asr at ufl.edu> writes:

> Hi; I'm contemplating a tiling WM, and am drawn to xmonad because its
> customisation language is its implementation language;  I'm long
> accustomed to this in e.g. EMACS, so I feel it'd be a good fit.

You should also consider StumpWM, it's more like Emacs (in that it can
be hacked at runtime) than Xmonad is: http://www.nongnu.org/stumpwm/

> But a friend, who's otherwise an outspoken Haskell advocate, put
> xmonad down in favor of awesome for reasons I'll summarize as
> dependency hell'.
>
> I'm interested in the perspective of the xmonad clan on this: If I
> pick up xmonad simply because I want a hackable WM, how much Haskell
> janitorial work will I be taking on?  Is there a straightfoward and
> broadly accepted base of package repositories?   Are the participants
> in the module ecosystem pretty careful not to break stuff?    Do
> current versions of various xmonad packages all depend on the current
> versions of their dependencies?

If you install cabal (a Haskell package manager), dependencies are not a
problem.  I have certainly noticed very few.  And even if you do not,
rather using adistribution-provided xmonad/xmonad-contrib packages,
those potential problems should already be taken care of.  In fact, when
configuring xmonad, you rarely care about new versions of things -
there's enough already-written stuff to pick from that it'll keep you
busy for quite a while.

--
\  Troels
/\ Henriksen


Reply | Threaded
Open this post in threaded view
|

xmonad for the Haskell unwashed?

Brent Yorgey-2
In reply to this post by Allen S. Rout
On Tue, Sep 27, 2011 at 10:14:31AM -0400, Allen S. Rout wrote:

>
> Hi; I'm contemplating a tiling WM, and am drawn to xmonad because its
> customisation language is its implementation language;  I'm long
> accustomed to this in e.g. EMACS, so I feel it'd be a good fit.
>
> But a friend, who's otherwise an outspoken Haskell advocate, put
> xmonad down in favor of awesome for reasons I'll summarize as
> 'dependency hell'.
>
> I'm interested in the perspective of the xmonad clan on this: If I
> pick up xmonad simply because I want a hackable WM, how much Haskell
> janitorial work will I be taking on?  Is there a straightfoward and
> broadly accepted base of package repositories?   Are the participants
> in the module ecosystem pretty careful not to break stuff?    Do
> current versions of various xmonad packages all depend on the current
> versions of their dependencies?

Your friend must have stumbled upon a particularly bad combination of
things; most people do not have that much trouble, I think.  For the
optimal xmonad experience with the least dependency hell:

  1. Install the latest Haskell Platform
     (http://hackage.haskell.org/platform/).  It may be available through
     your OS's package manager.  This includes GHC and a bunch of
     common libraries and tools.

     (In particular, xmonad *doesn't* yet work well with GHC 7.2.1, so
     avoid that for now; use GHC 7.0.3 which is what comes with the
     latest Platform release.)

  2. Run

       cabal install xmonad-contrib

     and sit back and watch xmonad and all its dependencies compile
     automatically.  If you have trouble with this step (which I
     doubt) you can get help on this mailing list or in the #xmonad
     IRC channel on freenode.


Reply | Threaded
Open this post in threaded view
|

xmonad for the Haskell unwashed?

Norbert Zeh
In reply to this post by Allen S. Rout
Allen S. Rout [2011.09.27 1014 -0400]:

>
> Hi; I'm contemplating a tiling WM, and am drawn to xmonad because
> its customisation language is its implementation language;  I'm long
> accustomed to this in e.g. EMACS, so I feel it'd be a good fit.
>
> But a friend, who's otherwise an outspoken Haskell advocate, put
> xmonad down in favor of awesome for reasons I'll summarize as
> 'dependency hell'.
>
> I'm interested in the perspective of the xmonad clan on this: If I
> pick up xmonad simply because I want a hackable WM, how much Haskell
> janitorial work will I be taking on?  Is there a straightfoward and
> broadly accepted base of package repositories?   Are the
> participants in the module ecosystem pretty careful not to break
> stuff?    Do current versions of various xmonad packages all depend
> on the current versions of their dependencies?

To add my 2c to the discussion.  I came to xmonad via awesome.  Here are my
reasons for the switch, in no particular order.

1)  The xmonad community has a culture of making changes in a way that does not
    break existing configurations.  So you can happily upgrade to the latest
    version/pull patches from darcs without being afraid that it might hose your
    setup.  The awesome config file syntax is a moving target, changing with pretty
    much every major release.  This may have changed in the recent past.  If so,
    it was too late for me to consider to switch back.

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, but I'm not switching back only to find out.

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.

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.

There are two things where I would consider awesome to have the lead over xmonad:

1)  It is indeed less processor-hungry than xmonad, but when my normal desktop
    use of my machine does not push my processor utilization beyond 5% even using
    xmonad, does it really matter?

2)  xmonad does have more dependencies in the form of added haskell libraries, while
    awesome relies on little more than the plain XCB headers + library.  As other
    respondents said, though, the dependencies are absolutely unproblematic to handle
    using cabal.

Cheers,
Norbert


Reply | Threaded
Open this post in threaded view
|

xmonad for the Haskell unwashed?

Teika Kazura
In reply to this post by Allen S. Rout
On Tue, 27 Sep 2011 10:14:31 -0400, "Allen S. Rout" wrote:
> a friend, who's otherwise an outspoken Haskell advocate, put
> xmonad down in favor of awesome for reasons I'll summarize as
> 'dependency hell'.

I worder if you could give us more detail. And is it recent?
(I'm not a xmonad user either.)

Even if it's a rare case, it's good for xmonad community to share
information.

(Sorry Allen, I've replied to your address instead of xmonad list.)

Teika (Teika kazura)