[info-mcl] MCL Past vs. Future

[Pascal Costanza]

On 16 Oct 2007, at 23:39, Andrew Shalit wrote:

> On Oct 16, 2007, at 5:33 PM, Pascal Costanza wrote:
>
>> Personally, I think that Eclipse sucks big time. But that's just a
>> personal opinion.
>
> What sucks about it? We're dealing with 100% personal opinion here.

Hard to tell. But what annoys me mostly is that Eclipse has very  
strong ideas about how things should be done, and doesn't let me do  
things my way. It is also too much project-oriented - you have to do  
too much configuration before you can write your first line of code,  
and this is every time you want to write some programs.

Maybe that's not a big issue for commercial software development, but  
in my case, I need to be able to write throwaway programs, just to be  
able to try out ideas, and I want to be able to get as fast from idea  
to code as possible. In Eclipse, this generally takes too long, as  
far as I can tell.

But then again, this is also a problem which is, to a certain degree,  
inherently connected to Java. But, as a counter example, NetBeans was  
much more flexible in my experience, the last time I checked it.

Nowadays, I just use emacs / Aquamacs for experiments with Java.  
Since I don't do a lot with Java anymore, that's mostly sufficient.  
It'd be nice to have something better than emacs for Common Lisp,  
though. LispWorks is currently fine for me.

However, there are two issues that concern me:

(1) I typically develop my libraries in LispWorks first, and then  
regularly check them on several CL implementations. It's a pity that  
I have to do these checks outside of LispWorks, and it is especially  
a pity that every CL implementations has slightly different boundary  
conditions that restrict how test suites can be automated.

It would be great if there were a CL environment from which I could  
use several CL implementations. I don't like SLIME in that regard, it  
should indeed be a "real" development environment, with  
straightforward support for switching the underlying CL  
implementation on the go.


(2) There should be a CL implementation (and a related GUI library)  
that takes as much advantage of Mac OS X as possible. Cross-platform  
libraries already exist, but tightly integrated libraries +  
development environment are missing. I think there is a real gap  
there, which should be filled IMHO.

(Yes, I understand that previous MCL users with considerable amount  
of code who want it to just work on new Mac machines have slightly  
different concerns here...)


Pascal

-- 
Pascal Costanza, mailto:pc at p-cos.net, http://p-cos.net
Vrije Universiteit Brussel, Programming Technology Lab
Pleinlaan 2, B-1050 Brussel, Belgium