In article <··········@jabba.ess.harris.com> ···@mercury.Harris-ATD.com (Mike McDonald) writes:
We were talking about Unix, at least that's what Barry Margolin says you have
to support because of all of those UNIX applications.
AH! but there are also a "few" applications out in the DOS and MAC worlds.
Yes, I agree that's it's
REAL hard to write a very complicated application that's portable between Unix,
Dos, Mac, MVS, ...
My large discrete-event simulation package written in Common Lisp
is"complex" in some senses of the word. It runs source-unchanged on
various Unix's, Mac System-7, Dos 5.0 and Windows 3.1. I haven't tried
it on MVS, but Lucid has it's Lisp there...
I believe that it is doable (at least for the kinds of
applications I'm interested in) across Unix platforms. As an example, I've
written, originally for a Sun3, a plotting program that does contour plot,
three dimensional surface plots, and standard 2d line plots. I didn't think
anything at all about portability when I wrote it. The only platform specific
code in the whole thing is whether to use getcwd() or getwd(). The rest of the
thing ports and works on Sun 3s and 4s, HP snakes, and PCs running Linux. Just
between the Suns and the HPs is 60 percent of the Unix workstation market and
I didn't have to do a thing.
My stuff runs on your list of Unix boxes AND Pcs AND Macs...
"and I didn't have to do a thing."
Everything one needs to use my program is readily
available from at least two different sources with at least one being free!
Everything one needs to use my program is readily available from at least four
different sources with at least two being free.
No, portability isn't my ultimate goal. I'd like to reach as big a user
community as I reasonably can though. Using C and X (Xaw) under Unix does allow
me to reach a much larger audience than using Lisp under Unix.
There may be (are!) other factors that affect the market reach of a piece
of software!!! But, if your requirement is to reach "as big a user community as
you reasonably can," then Lisp allows one application to be run on a much
wider set of platforms than C. If you wish to discuss those other marketing
and perceptual factors that effect the situation, then that is a worthwhile
discussion. However, technically, your statement above is false.
Now, don't
misinturpret me, I prefer Lisp as a language to C. But applications are made up
of more that just the language they're written in.
Now we are getting much closer to the real problem. If Lisp actually does
provide much better portability (and thus a potential larger market) than
C, why isn't Lisp used more??
A major component is the
libraries that are readily available for use by that language. With C under Unix,
there exists a wider range of "standard" libraries available for use than with
Lisp.
You may (note MAY) find printf on most platforms, but (to beat a dead horse just
one more time) I can't seem to find "select" in my Borland Turbo C++ library
anywhere. OK, bad example. It isn't in Lisp either. How about portable pathname
interfaces? Lisp is a large language, in part, because most of these optional
libraries are part of the language standard.
The Lisp "libraries" tend towards data manipulation, things like the
fifteen gazillion ways to map a sequence. C libraries tend not to address the
data manipulation area at all.
But, I thought that the big push in the C++ world was getting classes that describe
generic sequences and lists and stuff.
They tend towards user interfaces and system
functions such as IPC, select(), ... For the applications I write, the user
interface is very important. Format isn't very useful for doing surface plots.
My CLIM interfaces run on all my above-mentioned platforms. They work on
X, MS-Windows, and the Mac. Source unchanged.
Skip Egdorf
···@lanl.gov
In article <····················@zaphod.lanl.gov>, ······@zaphod.lanl.gov (Skip Egdorf) writes:
|> In article <··········@jabba.ess.harris.com> ···@mercury.Harris-ATD.com (Mike McDonald) writes:
|>
|> We were talking about Unix, at least that's what Barry Margolin says you have
|> to support because of all of those UNIX applications.
|>
|> AH! but there are also a "few" applications out in the DOS and MAC worlds.
|>
|> Yes, I agree that's it's
|> REAL hard to write a very complicated application that's portable between Unix,
|> Dos, Mac, MVS, ...
|>
|> My large discrete-event simulation package written in Common Lisp
|> is"complex" in some senses of the word. It runs source-unchanged on
|> various Unix's, Mac System-7, Dos 5.0 and Windows 3.1. I haven't tried
|> it on MVS, but Lucid has it's Lisp there...
I wouldn't know if Lucid provides all I need or not. They were too stingy to
let us evaluate their lisp. Even if it does, I now have to convince all of my
potential users to purchase a copy for a couple of K. (Unless, of course, Lucid
has changed thier policy on distributing applications.)
|> I believe that it is doable (at least for the kinds of
|> applications I'm interested in) across Unix platforms. As an example, I've
|> written, originally for a Sun3, a plotting program that does contour plot,
|> three dimensional surface plots, and standard 2d line plots. I didn't think
|> anything at all about portability when I wrote it. The only platform specific
|> code in the whole thing is whether to use getcwd() or getwd(). The rest of the
|> thing ports and works on Sun 3s and 4s, HP snakes, and PCs running Linux. Just
|> between the Suns and the HPs is 60 percent of the Unix workstation market and
|> I didn't have to do a thing.
|>
|> My stuff runs on your list of Unix boxes AND Pcs AND Macs...
|> "and I didn't have to do a thing."
|>
|> Everything one needs to use my program is readily
|> available from at least two different sources with at least one being free!
|>
|> Everything one needs to use my program is readily available from at least four
|> different sources with at least two being free.
What two free sources of Lisp graphics are you using? I've been looking for
just one of these forever. The closest I can find is Garnet. Looks nice, seems to
work well too. On the bad side is yet another object oriented system to learn.
|> No, portability isn't my ultimate goal. I'd like to reach as big a user
|> community as I reasonably can though. Using C and X (Xaw) under Unix does allow
|> me to reach a much larger audience than using Lisp under Unix.
|>
|> There may be (are!) other factors that affect the market reach of a piece
|> of software!!! But, if your requirement is to reach "as big a user community as
|> you reasonably can," then Lisp allows one application to be run on a much
|> wider set of platforms than C. If you wish to discuss those other marketing
|> and perceptual factors that effect the situation, then that is a worthwhile
|> discussion. However, technically, your statement above is false.
Not unless Lucid allows me to give copies of their system away for free. I
seriously doubt they'd appreciate me doing that. :-)
|> Now, don't
|> misinturpret me, I prefer Lisp as a language to C. But applications are made up
|> of more that just the language they're written in.
|>
|> Now we are getting much closer to the real problem. If Lisp actually does
|> provide much better portability (and thus a potential larger market) than
|> C, why isn't Lisp used more??
That's precisely what this discussion started as. Not a C vs Lisp religous war.
I've been arguing (not very well, I might add) that the current state of the
industry makes it easier for programmers to write applications.
Advantages for C (under Unix):
Availability. C comes with every Unix machine that I'm aware of. May not
be their best compiler but there's one there. GCC is freely available for a large
number of machines.
Graphics. All Unix workstations I'm aware of (I'm sure someone is going
to point out one that doesn't) now comes with X. The sources for the X libraries
are freely available from the X Consortium.
IPC. Not quite as nice here. You either get sockets or streams. All of
the workstations we have support sockets so that's what I use.
Advantages for Lisp (under Unix):
Libraries. Lisp contains a large and versatile set of routines for data
manipulation.
Interactive. Testing, debugging, prototyping are all easier (IMNSHO) in
Lisp.
Now, if I could get Lisp with the graphics and IPC libraries from C, then I
might be able to get somewhere.
|> A major component is the
|> libraries that are readily available for use by that language. With C under Unix,
|> there exists a wider range of "standard" libraries available for use than with
|> Lisp.
|>
|> You may (note MAY) find printf on most platforms, but (to beat a dead horse just
|> one more time) I can't seem to find "select" in my Borland Turbo C++ library
|> anywhere. OK, bad example. It isn't in Lisp either. How about portable pathname
|> interfaces? Lisp is a large language, in part, because most of these optional
|> libraries are part of the language standard.
|>
|> The Lisp "libraries" tend towards data manipulation, things like the
|> fifteen gazillion ways to map a sequence. C libraries tend not to address the
|> data manipulation area at all.
|>
|> But, I thought that the big push in the C++ world was getting classes that describe
|> generic sequences and lists and stuff.
Who said anything about C++? Certainly not me! I only write the stuff because
NRL forces me to. I don't think you're every going to hear me arguing in the
favor of C++, unless just to cause trouble! :-)
|> They tend towards user interfaces and system
|> functions such as IPC, select(), ... For the applications I write, the user
|> interface is very important. Format isn't very useful for doing surface plots.
|>
|> My CLIM interfaces run on all my above-mentioned platforms. They work on
|> X, MS-Windows, and the Mac. Source unchanged.
|>
|> Skip Egdorf
|> ···@lanl.gov
So where do I find those two free sources of CLIM? CLIM is a good example of
Lisp bucking the general industry trends. Everyone one else is on the "Open
Systems" kick. And what's the Lisp communittee up to, a closed, propriertarty
graphics system. When ILA and the rest make the sources available for free, then
I might use CLIM.
Mike McDonald Advanced Technology Dept.
Harris Corp.
Email: ···@trantor.harris-atd.com M.S. 16-1912
Voice: (407) 727-5060 P.O. Box 37
Fax: (407) 729-3363 Melbourne, Florida 32902
Date: Thu, 13 May 1993 12:44 EDT
From: Mike McDonald <···@mercury.harris-atd.com>
So where do I find those two free sources of CLIM? CLIM is a good example of
Lisp bucking the general industry trends. Everyone one else is on the "Open
Systems" kick. And what's the Lisp communittee up to, a closed, propriertarty
graphics system. When ILA and the rest make the sources available for free, then
I might use CLIM.
CLIM isn't a "closed, proprietary graphics system". It is a UI toolkit
built on top of other graphics toolkits.
Furthermore, the fact that no vendors give away the CLIM sources hardly
"buck[s] the general industry trends". Motif and OSF/1 are "open"
systems, right? Try to get the sources for them for free. In fact, try
to get the sources for them for even a moderate amount of money. Try to
get the sources to the windowing and graphics code for MicroSoft Windows
or MacOS for any amount of money. While I am sympathetic with your
desire to have the sources to everything, I hardly think that the Lisp
community is bucking any trends. Quite the contrary -- it's one of the
few communities where people feel they can rightly complain when they
cannot get the sources to things.
--------
BTW, ILA hasn't been in the CLIM business for quite a while now.
>>>>> On Fri, 14 May 1993 13:57:00 GMT, ···@stony-brook.scrc.symbolics.com (Scott McKay) said:
> CLIM isn't a "closed, proprietary graphics system". It is a UI toolkit
> built on top of other graphics toolkits.
>
> Furthermore, the fact that no vendors give away the CLIM sources hardly
> "buck[s] the general industry trends". Motif and OSF/1 are "open"
> systems, right?
The situation is not quite equivalent. First of all, I can use Motif
with any C/C++ compiler, including GNU CC. But I can use CLIM only
with the CommonLisp that it came with. This means I can't run
CLIM-dependent code on implementations like AKCL, CLISP, or CMU
CommonLisp, or if my CommonLisp vendor decides to drop CLIM support at
some point because something better has come along.
In addition, for C/C++, I can get a number of free, usable UI
toolkits, among them Xaw, Tk, and Interviews. For CommonLisp, there
is nothing equivalent. There are some toolkits built for research
purposes, but, while they have interesting features, they seem neither
efficient nor mature enough for the kinds of straightforward,
responsive user interfaces without bells and whistles that most people
seem to want to build.
Altogether, I see the UI toolkit situation for CommonLisp as being
still quite bleak, and I think that is to the detriment of the whole
Lisp community.
Thomas.
PS:
> Quite the contrary -- it's one of the few communities where people
> feel they can rightly complain when they cannot get the sources to
> things.
Again, that's probably because compiled Lisp code is so much more
implementation and version dependent than compiled C code.
In article <··········@jabba.ess.harris.com>
···@mercury.Harris-ATD.com (Mike McDonald) responds to me:
|>
|> My CLIM interfaces run on all my above-mentioned platforms. They work on
|> X, MS-Windows, and the Mac. Source unchanged.
|>
|> Skip Egdorf
|> ···@lanl.gov
So where do I find those two free sources of CLIM? CLIM is a good example of
Lisp bucking the general industry trends. Everyone one else is on the "Open
Systems" kick. And what's the Lisp communittee up to, a closed, propriertarty
graphics system. When ILA and the rest make the sources available for free, then
I might use CLIM.
I have been trying to get the message to the CLIM folks for some time
that the NUMBER ONE thing that they could do to increase their
revenues would be to put CLIM into the public rather than trying to
get $1K per pop (ok, $.5K on the Mac).
I wish I could figure out how to convince Franz, Lucid, Symbolics, and
all the rest, that funding CLIM code development and putting that code
on an ftp server somewhere would MAKE THEM MONEY!!!
CLIM is just about the greatest thing since sliced bread! It moves the
notion of Graphical User Interface toolkits from the current level
(Here is a bag of gadgets. Hook them to your application someway. It's
your problem) to a much more appropriate level of design and specification.
(As you design your system, consider how you present different views of
your application to your users and accept aspects of your application
from those users.) Just about all of the mail that I have been getting
in response to my comments above have been of the form "OK, Lisp is
great, but C has all these GUI Libraries available." A freely available
CLIM would fix this! It just might be the catalyst needed to make Lisp
really take off!
CLIM's problem is that it costs a bundle to get a copy. This is not
just the cost of the CLIM license; You have to be running one of the
for-bucks Lisps in order to buy a copy. This means a small user
community, and Franz, Lucid, Symbolics, et al can hardly afford to
keep Scott McKay in Peanut Butter and Blue Jeans.
Now, I have no problem with buying licenses that I need for my work.
I have a successful enough system that I have both Allegro and Lucid
on my Sun, Both CLOE and Allegro CL/PC on my 486, and MCL on my Mac (I
have a full office). My stuff seems important enough that Los Alamos
doesn't quibble about my toys. However, What about the hoards of
programmers out there not in my fortunate situation? How about my
wanting to do something a little extra-curricular on my 486/Linux box
at home? It has CLISP and Gnu Emacs. I wish I could run CLIM on it.
I have tried in the past to suggest to the CLIM developer companies
that they look at other successful software:
Microsoft got its first big break when lots of folks pirated Bill
Gates' Basic. Since everyone was using it, every microcomputer company
licensed it in order to be compatible. It wasn't the fees from the end
users that finally counted.
Sun released RPC code to the world, and made the NFS spec public as
well. Soon, I could get an NFS from ILA for the Symbolics, and
everyone else in the world was running it too. What happened to those
other ten or twelve remote file systems that were floating around at
about the same time? Is Sun better or worse off today because of
its decision to give away the NFS and RPC stuff?
It is quite arguable that had Sun released James Gosling's SUNDEW code
to the world, X would have died on the vine, and we would all be running
NeWS today.
So, Franz, Lucid, Symbolics, all the rest...
1. Put the CLIM 2.0 code on an ftp server somewhere with an
X-Windows-style copyright. I'll even volunteer. I've lots of
spare disk.
2. Grit your teeth, think of those few tens or hundreds of license
sales you are loosing. Grit your teeth some more, give Scott a
raise. Make sure that CLIM stays being actively developed.
3. Notice that CLIM is now running on CLISP on Linux and DOS, on
CMU-CL on Sparcs, on AKCL... Funny thing, you guys are still competative
in the same way that a public free CLOS implementation hasn't really
hurt your sales.
4. Notice that LOTS of folks are suddenly writting applications using
CLIM.
5. Notice that you are starting to get LOTS more request of the form
"We at Los Alamos need a few hundred more licenses for Allegro. Seems
that there is this neat package..." "You now have Genera on the Alpha?
Does it run CLIM? we have all this code..." "You say that you have
tuned the performance of CLIM on Lucid 5.0 so that it runs a lot
faster than the public version? Is it still compatible? Great! Let's
talk site license."
6. Compare your increasing bottom line (lots more sales minus some
cost for the CLIM development) with what might have been had you not
freed up CLIM and made it popular. (All the Franz folks back at
Berkeley teaching the wonders of C and X-Windows, Dick Gabriel and
Jonl White working on Visual Basic for Microsoft...)
How do we get the word to them???
Skip Egdorf
···@lanl.gov
In article <····················@zaphod.lanl.gov> ······@zaphod.lanl.gov (Skip Egdorf) writes:
Newsgroups: comp.lang.lisp
....
CLIM's problem is that it costs a bundle to get a copy. This is not
just the cost of the CLIM license; You have to be running one of the
for-bucks Lisps in order to buy a copy. This means a small user
community, and Franz, Lucid, Symbolics, et al can hardly afford to
keep Scott McKay in Peanut Butter and Blue Jeans.
.... However, What about the hoards of
programmers out there not in my fortunate situation? How about my
wanting to do something a little extra-curricular on my 486/Linux box
at home? It has CLISP and Gnu Emacs. I wish I could run CLIM on it.
....
1. Put the CLIM 2.0 code on an ftp server somewhere with an
X-Windows-style copyright. I'll even volunteer. I've lots of
spare disk.
...
How do we get the word to them???
Skip Egdorf
···@lanl.gov
I subscribe to the content of the above posting. I suppose the first
thing to do would be to get email addresses for Symbolics, ILA, Franz,
Lucid, Harlequin and whoever else is in the CLIM business.
--
Marco Antoniotti
-------------------------------------------------------------------------------
Robotics Lab | room: 1219 - tel. #: (212) 998 3370
Courant Institute NYU | e-mail: ·······@cs.nyu.edu
...e` la semplicita` che e` difficile a farsi.
...it is simplicity that is difficult to make.
B. Brecht
From: Jeff Dalton
Subject: Re: CLIM (was Re: The New Lisp Machine)
Date:
Message-ID: <8764@skye.ed.ac.uk>
In article <·····················@maya.nyu.edu> ·······@cs.nyu.edu (Marco Antoniotti) writes:
>In article <····················@zaphod.lanl.gov> ······@zaphod.lanl.gov (Skip Egdorf) writes:
> CLIM's problem is that it costs a bundle to get a copy. This is not
> just the cost of the CLIM license; You have to be running one of the
> for-bucks Lisps in order to buy a copy.
> ....
> 1. Put the CLIM 2.0 code on an ftp server somewhere with an
> X-Windows-style copyright. I'll even volunteer. I've lots of
> spare disk.
I also think it's unfortunate that CLIM was developed this way
or (if you'd prefer) that there is no successful free alternative.
Compare with X, for instance. Sure, Motif costs, but everyone
has Athena widgets, etc. It's a shame that Lisp, a language that
began the 80s with a huge lead in windows and graphics, should now
lag behind C. There really isn't any reasonably standard way to
do windows and graphics in Lisp above the CLX level.
Another question for those looking at CLIM, of course, is whether CLIM
does what they want to do. There's no point in pressuring CLIM
vendors otherwise.
In article <····@skye.ed.ac.uk>, ····@aiai.ed.ac.uk (Jeff Dalton) writes:
|> In article <·····················@maya.nyu.edu> ·······@cs.nyu.edu (Marco Antoniotti) writes:
|> >In article <····················@zaphod.lanl.gov> ······@zaphod.lanl.gov (Skip Egdorf) writes:
|>
|> > CLIM's problem is that it costs a bundle to get a copy. This is not
|> > just the cost of the CLIM license; You have to be running one of the
|> > for-bucks Lisps in order to buy a copy.
|> > ....
|> > 1. Put the CLIM 2.0 code on an ftp server somewhere with an
|> > X-Windows-style copyright. I'll even volunteer. I've lots of
|> > spare disk.
|>
|> I also think it's unfortunate that CLIM was developed this way
|> or (if you'd prefer) that there is no successful free alternative.
|> Compare with X, for instance. Sure, Motif costs, but everyone
|> has Athena widgets, etc. It's a shame that Lisp, a language that
|> began the 80s with a huge lead in windows and graphics, should now
|> lag behind C. There really isn't any reasonably standard way to
|> do windows and graphics in Lisp above the CLX level.
|>
|> Another question for those looking at CLIM, of course, is whether CLIM
|> does what they want to do. There's no point in pressuring CLIM
|> vendors otherwise.
I agree that it is unfortunate that no free Lisp window toolkit ever
become popular. TI's CLUE seemed like a good candidate (essentially a
free CLOS version of the XToolkit), but never went anywhere, probably
because TI stopped work on it, and also because CLIM was being promoted.
The problem with CLIM was that it was not a object-based toolkit, but
more a "framework" or monolithic system that required all the pieces
to work together correctly before it would work at all. This prevented
the independent development of smaller classes into working subsets,
or specialized classes for specialized purposes, and thus preventing people
creating small useful lisp-based interfaces.
In CLIM's defense, it was designed primarily to be very compatible with
Symbolic's window system, which was the right thing to do for commercial purposes.
-Kelly
Date: Thu, 20 May 1993 15:48 EDT
From: Kelly Murray <···@prl.ufl.edu>
In article <····@skye.ed.ac.uk>, ····@aiai.ed.ac.uk (Jeff Dalton) writes:
|> In article <·····················@maya.nyu.edu> ·······@cs.nyu.edu (Marco Antoniotti) writes:
|> >In article <····················@zaphod.lanl.gov> ······@zaphod.lanl.gov (Skip Egdorf) writes:
|>
|> > CLIM's problem is that it costs a bundle to get a copy. This is not
|> > just the cost of the CLIM license; You have to be running one of the
|> > for-bucks Lisps in order to buy a copy.
|> > ....
|> > 1. Put the CLIM 2.0 code on an ftp server somewhere with an
|> > X-Windows-style copyright. I'll even volunteer. I've lots of
|> > spare disk.
|>
|> I also think it's unfortunate that CLIM was developed this way
|> or (if you'd prefer) that there is no successful free alternative.
|> Compare with X, for instance. Sure, Motif costs, but everyone
|> has Athena widgets, etc. It's a shame that Lisp, a language that
|> began the 80s with a huge lead in windows and graphics, should now
|> lag behind C. There really isn't any reasonably standard way to
|> do windows and graphics in Lisp above the CLX level.
|>
|> Another question for those looking at CLIM, of course, is whether CLIM
|> does what they want to do. There's no point in pressuring CLIM
|> vendors otherwise.
I agree that it is unfortunate that no free Lisp window toolkit ever
become popular. TI's CLUE seemed like a good candidate (essentially a
free CLOS version of the XToolkit), but never went anywhere, probably
because TI stopped work on it, and also because CLIM was being promoted.
The problem with CLIM was that it was not a object-based toolkit, but
more a "framework" or monolithic system that required all the pieces
to work together correctly before it would work at all. This prevented
the independent development of smaller classes into working subsets,
or specialized classes for specialized purposes, and thus preventing people
creating small useful lisp-based interfaces.
In fact, CLIM II's architecture and the implementation of CLIM 2.0 is
not particularly monolithic. I believe that I know exactly how to slice
up the CLIM 2.0 implementation a bit more in order to make use of things
like PROVIDE/REQUIRE, autoloading, and "tree shaking". My guess is that
this would be about 1 to 2 weeks of effort, and would result in a CLIM
that works (almost) exactly the way you want.
In CLIM's defense, it was designed primarily to be very compatible with
Symbolic's window system, which was the right thing to do for commercial purposes.
CLIM 1.0 was designed with this goal. Not CLIM II.
In article <····················@SUMMER.SCRC.Symbolics.COM>, ···@stony-brook.scrc.symbolics.com (Scott McKay) writes:
|> Date: Thu, 20 May 1993 15:48 EDT
|> From: Kelly Murray <···@prl.ufl.edu>
|> >>....
|> The problem with CLIM was that it was not a object-based toolkit, but
|> more a "framework" or monolithic system that required all the pieces
|> to work together correctly before it would work at all. This prevented
|> the independent development of smaller classes into working subsets,
|> or specialized classes for specialized purposes, and thus preventing people
|> creating small useful lisp-based interfaces.
|>
|> In fact, CLIM II's architecture and the implementation of CLIM 2.0 is
|> not particularly monolithic. I believe that I know exactly how to slice
|> up the CLIM 2.0 implementation a bit more in order to make use of things
|> like PROVIDE/REQUIRE, autoloading, and "tree shaking". My guess is that
|> this would be about 1 to 2 weeks of effort, and would result in a CLIM
|> that works (almost) exactly the way you want.
|>
|> In CLIM's defense, it was designed primarily to be very compatible with
|> Symbolic's window system, which was the right thing to do for commercial purposes.
|>
|> CLIM 1.0 was designed with this goal. Not CLIM II.
Not that I want to antagonize, but I do wonder why, if it only takes
1-2 weeks, you haven't already done it. Surely, even CLIM II has been worked
on for quite some time now, hasn't it?
Is it because you don't think it is a good idea?
I would speculate the reason is that Symbolic's compatibility doesn't require it.
-Kelly
Date: Fri, 21 May 1993 14:32 EDT
From: Kelly Murray <···@prl.ufl.edu>
In article <····················@SUMMER.SCRC.Symbolics.COM>, ···@stony-brook.scrc.symbolics.com (Scott McKay) writes:
|> Date: Thu, 20 May 1993 15:48 EDT
|> From: Kelly Murray <···@prl.ufl.edu>
|> >>....
|> The problem with CLIM was that it was not a object-based toolkit, but
|> more a "framework" or monolithic system that required all the pieces
|> to work together correctly before it would work at all. This prevented
|> the independent development of smaller classes into working subsets,
|> or specialized classes for specialized purposes, and thus preventing people
|> creating small useful lisp-based interfaces.
|>
|> In fact, CLIM II's architecture and the implementation of CLIM 2.0 is
|> not particularly monolithic. I believe that I know exactly how to slice
|> up the CLIM 2.0 implementation a bit more in order to make use of things
|> like PROVIDE/REQUIRE, autoloading, and "tree shaking". My guess is that
|> this would be about 1 to 2 weeks of effort, and would result in a CLIM
|> that works (almost) exactly the way you want.
|>
|> In CLIM's defense, it was designed primarily to be very compatible with
|> Symbolic's window system, which was the right thing to do for commercial purposes.
|>
|> CLIM 1.0 was designed with this goal. Not CLIM II.
Not that I want to antagonize, but I do wonder why, if it only takes
1-2 weeks, you haven't already done it. Surely, even CLIM II has been worked
on for quite some time now, hasn't it?
Is it because you don't think it is a good idea?
The reason I personally haven't done anything about it is because it
does not benefit the Symbolics implementation at all, and there have
been other important things for me to work on.
I would speculate the reason is that Symbolic's compatibility doesn't require it.
Actually, Symbolics compatibility has nothing to do with this.