MCL Application Framework

[cfry@MIT.EDU (Christopher Fry)]

> >>Sounds like 1 year until a Mac/windows version IF the project isn't killed
> >>by corporate merger/lawsuits and they keep to schedule
> 
> The Bedrock project is unlikely to be killed since it represents a vital piece
> of Apple's software strategy.
Most projects started in most corporations are touted by their champions to be vital
to the corpoation. I'd be surprised if someone at Apple didn't say this about the
Apple III or Lisa computers when they were at the stage that bedrock is now.
I'm not saying bedrock won't last forever, I'm just saying that because some press release
says its vital isn't much evidence that it will endure.
 
> >>The advantage of CLIM is that it is LISP specific where Bedrock is not.
> 
> The reality is that LISP will not be a popular option for delivering commercial
> quality applications given the memory and speed limitations of current
> hardware.
An old argument which I'm not sure is accurate anymore. Anybody got data on this?
I'd recommend that you read The Preface to the Dylan book. It discusses a bunch of
relevent issues here. 
> Developers who wish to gain from the development productivity of LISP should
> still be able to port their applications to C for delivery without having to
> port their application framework.
Hmm, porting is hard, often harder than rewriting from scratch. Maybe you know some tricks
that I don't. There are Lisp to C translators, but I bet they don't do very well
with object systems [ie CLOS to C++] o window system code. 
> >>The only thing that Bedrock appears to have over CLIM is
> internationalization.
> 
> Bedrock also contains a Virtual Memory Manager and a File Manager as well as
> who knows what else.
My above comment meant to say what Bedrock had IN ADDITION to what CL has.   
Bedrock is getting some of the things that have been in Common Lisp for years.
Good. I hope they steal lots more ideas from CL. In fact, why not steal CL itself!


> Bedrock is likely to be a much more complete application framework than
> anything developed by the CL community given the amount of resources of Apple
> and Symantec as compared to the CL community.
Potential resources of large corporations isn't much of a factor in
that corporation coming out with better software technology. I guess my
example of Coral Software producing MCL and AT&T producing C didn't convince you.
Take a look at the software that IBM ships and compare that with Apple.
For that matter take a look at some of the software that Apple ships in comparison to
much smaller 3rd party developers. Usually the best 3rd party developers are ahead
of Apple. For proof that even Apple believes this, obverve that Apple bought Coral because 
it had better software technology than anything in Apple. At the time, Coral was about 5 
people. Apple must have been several orders of magnitude bigger.
Same phenomenon in peripheral hardware.
> >>Its easier to add to CLIM than it is to make C++ & Bedrock as good as
> >>CL+CLIM. 
> 
> Designing a LISP interface to Bedrock is not an easy job,
Agreed. 
> but will result in a
> more complete and language portable application framework.
More complete than Apple currently ships, yes this is quite possible.
More complete than CL + CLIM2? That's the real debate. 
> Building a LISP interface to Bedrock would not be duplicate the efforts of
> Apple and Symantec in developing the best application development framework
> available on any of the host platforms.  
Since Apple has NO project to make a portable window system environment for MCL,
your right that Apple wouldn't be duplicating Apple efforts. The real question is,
given the larger picture, can we get more leverage off of existing CLIM implementations
or off of Bedrock? 
> It would also serve to increase the size of the LISP community by making LISP a
> more attractive development environment that does not lock the developer into
> delivering in LISP.
I don't understand this last point. I think you know something that I don't here
so perhaps you could discuss it further. 
You also might address another issue: If the developer is delivering stand-alone 
applications [as is possible with MCL now], the user doesn't know or care what
language the application was developed in [except if they want rapid bug fixes or
rapid extensions which are easier to do in Lisp than other languages.]

Maybe this debate is simply the religious issue of Lisp versus C.
If you believe C is better, go with Bedrock. No argument from me.
CLIM1 isn't everything we want. CLIM 2 is closer but will still need lots
of work to make really Macized. Garnet is another possibility that doesn't have
a good Mac implementation yet. In fact, I know of no existing good solution to this 
problem of portable window systems with CL. If CLIM and Garnet stayed still and
Bedrock moved fast, it could surpass both of them. Its a question of what your starting 
with, how easy is it to extend and what resources are directly applied to the problem.

I'd assess right now that both CLIM and Garnet are better in the first 2 categories
than Bedrock. This debate is about which vehicle should we give additional resources to.
Since ultimately I don't care which vehicle crosses the finish line first
[the finish line is a pretty complex one entailing ease of programming, flexibility, 
portability, extensibility, etc. and actually recedes as we approach it cause we want more 
functionality]
the question is, do you dump more gas into the current leader or try to help a
follower catch up?

For me it boils down to the simple fact that Bedrock, as its name implies, is built on 
Flintstones technology. If Bedrock ends up sucking up lots of MCL hacker resources
to develop, then I sincerly hope I'm wrong. Any solid portable window system is
better than none.