[Openmcl-devel] CCL is a mess

[Rainer Joswig]

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.

    http://www.cons.org/cmucl/hemlock/

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  
expecting?

* 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  
Builder, ...)?

* Emacs/SLIME-like?

* 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?

Regards,

Rainer Joswig


Rainer Joswig, Hamburg, Germany
http://lispm.dyndns.org/
mailto:joswig at lisp.de



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20090527/22912135/attachment.htm>