[mcclim-devel] Why is CLIM dead

[Robert Goldman]

On 7/7/12 Jul 7 -3:53 PM, Christophe Rhodes wrote:
> Mariano Montone <marianomontone at gmail.com> writes:
> 
>> So I was wondering why CLIM is dead. It looks like it doesn't have any
>> activity at all. And I think it is a pity, because when I first looked at
>> Listener/Climacs/Debugger/Inspector stuff, I thought it would be a very
>> nice replacement for SLIME, for instance. I'm SLIME user, but I think
>> there's lot of room for improvements in the Lisp tools area, and the CLIM
>> tools + usability improvements + possibilities to extend the tools very
>> easily sounds very good to me.
> 
> Well, one argument is that things don't start out equal.  Yes, the
> Listener, Climacs, Debugger and Inspector are pretty good, but they have
> to compete with other tools out there, not only for functionality but
> also for maintenance time.  Put bluntly, CLIM is sleeping (maybe not
> dead, because interesting ideas never die :) because there was a lack of
> person power to keep it awake.  I agree that there's a lot of potential
> in the tools, but there's a lot of potential in all sorts of things and
> only a limited amount of time to spend developing that potential.

A particularly challenging aspect of McCLIM is the need to support
multiple back-ends for multiple different platforms (X, Mac, gtk, qt,
Windows), which are not designed to be CLIM-compatible.  This requires a
lot of non-Lisp expertise, and multiplies the number of active
developers required.  Toolkits aimed at a widget level, rather than at
the primitive level needed to support CLIM widgets may make this
particularly challenging.
> 
>> Does anyone know why CLIM is not used anymore? Does it have any very bad
>> design decisions? I'm not really sure about output recording/redisplay, etc
>> (I haven't seen theme elsewhere, as if that could be automatically handled
>> in general). Don't know about composability and layout yet (I'm still
>> struggling a bit with that now). And I also see some bugs, like some
>> refreshing problems when scrolling, but bugs should be fixable.
> 
> It's not got terrible design decisions: there are a couple of problems
> in some layers of the stack, but nothing that couldn't be worked
> around.  Output recording and incremental redisplay are brave ideas,
> output recording somewhat more salvageable than incremental redisplay,
> but they don't cost too much if you don't use them.  I don't think
> there's anything fundamentally wrong with CLIM, or fundamentally better
> in other toolkits: it's just that the pool of talent and energy to
> perform the pretty thankless task of making it all work to the extent of
> its potential seems currently unavailable.

In addition, the fact that CLIM takes novel directions (some of them
novel in a very good way), means that it takes some retraining to start
to use CLIM.  It's hard to justify the effort in rethinking one's UI
designs onto a platform that is not fully functional.

I found that it was hard to predict which parts of the CLIM spec were
fully supported in McCLIM, which added to the difficulty of using the
platform.  This is an inevitable consequence of how big the CLIM
definition is: a smaller, less functional API (compare Tk), is a lot
easier to fully support.  But it's a disincentive to use CLIM, and it's
hard to keep up enthusiasm without programmers coding to it.

I'm not sure if there is an easy-to-identify core of CLIM that could be
established as the bit that one would focus on, and make solid, to make
it more predictable for programmers trying to use McCLIM.

> 
> What would it take?  Money, or graduate students, I think.

The problem with getting graduate students on board is that CLIM is no
longer research.  The unit of currency for graduate students is the
minimal publishable increment, and it's not clear how many of those
remain in CLIM ;-)