On 7/7/12 Jul 7 -3:53 PM, Christophe Rhodes wrote:
Mariano Montone marianomontone@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 ;-)