[Openmcl-devel] Is OpenMCL ready for use?

[Stonewall Ballard]

On 12/16/02 12:12 AM, "Gary Byers" <gb at clozure.com> wrote:

>...
> It's difficult to write compelling (or even interesting) applications
> in any environment; it's perhaps telling that my idea of an
> interesting application leads to something like OpenMCL's Cocoa demo.

One of the huge failings of environmental languages, particularly Smalltalk,
is the lack of a platform-native UI. The existence of the Cocoa binding was
what excited me about using OpenMCL for desktop apps.

> I honestly don't know (or at least don't know in great detail) what
> kind of infrastructure and support would be required to turn other
> kinds of compelling or interesting Lisp programs into "competitive
> desktop applications".

I'm looking at this the other way around. I like writing desktop apps, and
would prefer to use CL because I much prefer programming in DOOLs. I expect
to get a lot of leverage from using a DOOL, producing a
lower-development-cost, less-buggy app.

My interest is primarily in graphics applications, not in lisp per se.

>...
> I've been hung up on the fact that Cocoa isn't cross-platform: yes,
> GnuStep exists, but it's not as mature and not widely used.  I don't
> know how relevant that concern is: I don't know that many people are
> interested in delivering UI-rich applications under Linux.  If the
> Cocoa stuff had moved forward faster over the last several months,
> that might have better served the needs of more users.  (It's not
> clear that my thinking Deep Thoughts About The Cross-Platform UI Issue
> has gotten too far.)

I completely don't care about cross-platform. I left my last job because
they effectively killed off Mac product development (without saying so). I'm
interested only in building apps for Mac OS X.

> There are a lot of people for whom backward compatibility is a big
> concern.  MCL 5 certainly provides lots of backward compatibility;
> since they seem to have that issue pretty well covered, it seems that
> OpenMCL should ideally move in the other direction (faster than it's
> been doing so lately.)

Yes. The "other direction" is the right one for OpenMCL. At the very least,
I want to be able to use it to replace my Unix scripting in Perl. OpenMCL
launches impressively fast (at least, without the Cocoa stuff), so I think
that this should be possible.

I want OpenMCL to be as Mac OS X-native as possible.

>...

> 
>> I'm most concerned about the ability of OpenMCL to create
>> self-contained Cocoa apps. The package for the example Cocoa app
>> worked well, but I don't see any automatic way to rip out the
>> compiler or otherwise prune the image.  Is this hard to do?
> 
>...
> One approach to that problem is to present an MCL or OpenMCL image
> and say "do X, Y, and Z to turn that image into your deliverable
> application."  OpenMCL offers the alternate approach of saying
> "here are some sources/fasls and a framework for loading them;
> load the ones you need and make a deliverable application out of
> them."  Neither approach is that simple in practice, but the latter
> seems to offer a lot more flexibility.  It might be very hard to
> do that now, but it could be made easier.

This must be automatable. I need a push-button build process. In this case
"more flexibility" means "I have to write that myself". Fortunately, that's
possible.

The danger here is that I get sucked into building developer tools way too
easily. I've been involved in developing three major DOOL tool systems
(Smalltalk, Component Workshop, and Dylan), and don't see any signs that
I've kicked that addiction. :-)

I need to spend most of my time writing for my customers.

>...
> As I started to work on it, it became clear that there wasn't anything
> incremental about the process: the hard parts involved (to strain the
> analogy) the things that needed to happen right after the Big Bang:
> the GC needs to be different in a preemptively scheduled world,
> consing needs to be different, resource-contention problems need to be
> dealt with differently, the FFI has to change ...

Will this break code written to the current version?

>...
> If a preamble to the LGPL like the one under which Franz licensed
> AllegroServe:
> 
> <http://AllegroServe.sourceforge.net/license-allegroserve.txt>
> 
> were provided as part of OpenMCL's licensing terms, would that
> make our heads hurt less ?  (It might be fairly easy to get Digitool -
> as primary copyright holder - to agree to that, especially if it
> could be done in a way that didn't involve having to pay lawyers.)

That sort of answered my question. They say nothing about allowing end users
to replace the LGPL'd library. I have no problem with any of the rest of it,
so if it's recognized that the nature of Lisp precludes any sensible way of
exchanging library files without touching the code built on top of it, I'm
happy.

Thanks for your response. I'd love to hear from others too. How many people
are on this list?

 - Stoney



_______________________________________________
Openmcl-devel mailing list
Openmcl-devel at clozure.com
http://clozure.com/cgi-bin/mailman/listinfo/openmcl-devel