[Openmcl-devel] prompt-for-file (embarrassing question)

[Shannon Spires]

Re: CLIM vs. another CCL IDE

I'm much more in Matt's camp on this issue than the CLIM camp. The functionality of the CCL IDE on MacOS is pretty good but it's too dependent on Cocoa programming metaphors to be easily extensible. It needs to be redesigned for easy Lisp extensibility. CLIM, OTOH, has its own problems.

I used CLIM with MCL when it was briefly available for that platform. It worked, but barely. It was so buggy it would crash in a stiff breeze, and it was difficult or impossible to debug because CLIM is a huge mass of very macro-laden code. And Symbolics-style macro-heavy code is very hard to debug unless you have a Symbolics machine. Another thing I don't like about CLIM (and this is just a personal preference) is that it encourages a style of programming where the structure of your UI has to be reflected in the static structure of your source code, because it's so macro-focused. This is what happens when you code with nested with-this, with-that, and with-[the other thing] a lot. I very much prefer a more dynamic style of UI creation where the runtime structure of one's CLOS object graph gets reflected in the UI, and CLIM (in my experience) discourages such a style.

Finally, McCLIM has been around for over a decade and I've yet to see any real progress on it. That may have changed recently, and I certainly haven't been paying much attention so pardon my ignorance. People talk about how great CLIM is and how it uses whatever backend is available, but it seems that whenever anybody writes anything with it, the UI always ends up looking like X11.

I like what CLIM does (unification of model and view) but its architecture is very dated compared with modern (non-Lisp Machine) Common Lisp programming style, as well as modern UI style. CLIM needs to be allowed to die and its best ideas need to be retained and rearchitected for the modern age.

-Shannon Spires