[Openmcl-devel] CCL is a mess
joswig at lisp.de
Wed May 27 09:59:41 PDT 2009
Am 27.05.2009 um 17:20 schrieb Alexander Repenning:
> I agree, the curb appeal of the CCL/IDE is not great right now. I
> wonder if the person making the comment actually does like any of
> the existing Lisp IDEs such as LispWork or Allegro. I am guessing he/
> she would not like them either. Even the Mac version of LispWorks
> does not really try to deal with Apple's HIG. I actually think CCL
> does already a better job at that. With some more work the
> instability will hopefully go away but some of the other issues
> raised would probably require a much more significant redesign.
Personally I never liked the later implementation of FRED that much.
It was mixed with lots of platform specific code - that's also the
reason it is difficult to extract it from MCL (incl. Carbon aka
Toolbox). It was tweaked a lot, but it dies with the platform it was
written for. It also never provided a special foundation to edit
different types of text (C, Lisp, Text, ...). The most useful thing
was that FRED could also be used in views - but that was also not
clearly 'engineered' - more grown and optimized around whatever Apple
did do with the Toolbox/Carbon. Also remembered that the original MCL
user interface was written in Object Lisp (and not CLOS which did not
exist at that time). We should also remember that MCL was having
quite a bit more usage in the area of GUI apps - including from Apple.
CCL is far from that usage level and level of bug fixing / enhancing
in the GUI area.
CMUCL has a Hemlock user and implementors manual. The Hemlock in CCL
is stripped down and lacks various modes and commands. When I edit an
editor command, I use M-x Edit Command and then edit the command.
That's quick. CCL doesn't have that command active. Generally I think
the core of Hemlock is better than some people seem to think.
Question to the UI experts: is there an agreed way to use Cocoa from a
multi-threaded language/implementation (like CCL), in an interactive
development environment and in a robust way? Is that even possible?
That's a real question - it is not clear to me. What good is a Lisp
development environment if I can't really debug the main thread
interactively or when it is easy to screw up the main thread which the
whole IDE depends on - assuming Cocoa?
Everybody who has ever written a non-trivial GUI app knows that the
'test department' has an easy target. It is really really hard to make
a GUI application robust against 'normal' users. Here we have a
development tool, with hairy error handling, probably faulty code
during development, endless loops, errors popping up, incremental
modifications, etc. I'd guess that it takes quite a bit effort to get
that right with lots of testing and fixing.
Then we have the issue that the development environment and the
application(s) under development are running in the same Lisp
application. That also adds to instability. In Eclipse one creates an
app that gets started and debugged externally. Same for Emacs/SLIME/CCL.
Apple HIG. For me the issue is not that CCL looks or feels different.
The largest issue is that it is far from exploiting the facilities
offered by Cocoa. The natural way for CCL is to implement the
development tools GUI based. The editor is just one tool. The
inspector, debugger, class browser, etc. would not be (or already are
not) editor based. CCL can exploit Cocoa if that's what the IDE is
based on (and if supporting Windows, Gnome, KDE, ... is not a goal).
The next question is 'user expectation'. What kind of IDE are users
* Eclipse-like, because the users are students and know mostly
Eclipse? An MCL-like IDE will not do it for them. They want windows
full of widgets, wizards, tiled windows, large preference dialogues,
lots of XML configuration files, ...
* MCL-like, because the users are homeless ex-MCL users?
* XCode-like, because the CCL IDE users are on the Mac anyway?
* Somehow integrating with Xcode and some of its tools (Interface
* Something new?
* None? Because they use Emacs/SLIME or Eclipse with Lisp support?
The expectation of the average Java user (say, a student with Java
experience) would be that one edits a while, interacts with
repositories, checks out, deploys, runs a test suite, merges in code,
edits more, ... The original Lisp model of development (think MCL)
of interactively and incrementally modifying the app from within the
app is strange for them ('how do you move ALL the changes made in a
listener to the files in the repository?'). If we move away from that,
why use Lisp? If we keep this model how is it explained so that new
users can unlearn Eclipse/Netbeans/Jbuilder/Visual Studio/..., can
understand why there is a difference and can be made productive?
Rainer Joswig, Hamburg, Germany
mailto:joswig at lisp.de
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openmcl-devel