From: Anthony Berglas
Subject: CMUCL/Dylan, Being pragmatic...
Date:
Message-ID: <14744@uqcspe.cs.uq.oz.au>
Given that CL and Dylan are similar (whether "related language" or
"dialect") I would expect that a large percentage of a Dylan
implementation could be taken from CMUCLs code. There are four
options:-
0. Write a new Dylan system from scratch, perhaps hacking chunks of
code out of CMUCL.
1. Write a Dylan to CMULisp translater.
2. Write a CMUCL to Dylan translater.
3. Factor out the common elements of Dylan and CL into a kernal and
then having different front ends.
Options 1 and especially 2 may require language extenstions to the
base language, which may or may not be pretty. Option 1 would not
produce a small clean system. Importantly, options 1, 2, and 3 have
the following advantages over option 0.
1. With care it should be possible to tightly couple CL and Dylan
code. I can ignore some of CL's uglyness but I cannot live witout
my favourite CL packages. This would be the major reason to
stick to CL and ignore Dylan systems.
2. Much of CMUCL's existing coding effort could be reused.
3. It would make it very easy and give a good research reason to
continue supporting CMUCL.
The danger, of course, is that the result will be a kludge, but that
would need to be shown.
Incidently, most important decisions and perceptions are made on
superficial grounds. People at Uni Qld cs won't go near Lisp because
they know that it is a primitive, interpretive language with lots of
parenthesis. A new syntax makes a new language. However, IMHO any Lisp
syntax MUST be fully and dynamically extensible so that programer
defined statements look the same as built in ones. This is not hard
to do as long as one avoids YACC style bottom up parsers!
I am also a little concerned about Apple (My Intellectual Property) Inc
effectively owning a programming language design.
--
Anthony Berglas
Rm 503, Computer Science, Uni of Qld, 4072, Australia.
Uni Ph +61 7 365 2812, Home 391 7727, Fax 365 1999
It is my understanding that Dylan is closer to Scheme than to Common LISP.
An object-oriented Scheme, at that.
--
==========================================================================
| Drew J. Asson | Space Telescope Science Institute |
| AI Senior Software Engineer | 3700 San Martin Drive |
| Advance Planning Systems Branch | Baltimore, MD 21218, USA |
| Internet: ·····@stsci.edu | (410) 338-4474 [338-1592 (fax)] |
==========================================================================
From: Anthony Berglas
Subject: Re: CMUCL/Dylan, Being pragmatic...
Date:
Message-ID: <14787@uqcspe.cs.uq.oz.au>
>>1. Write a Dylan to CMULisp translater.
>
>I think someone should so a Dylan to reasonably-portable-CL
>translator anyway. I may do one if I have time.
This would be probably be the easiest way to test the language
definition.
>>1. With care it should be possible to tightly couple CL and Dylan
>> code. I can ignore some of CL's uglyness but I cannot live witout
>> my favourite CL packages. This would be the major reason to
>> stick to CL and ignore Dylan systems.
>
>Well, I assume Dylan will eventually have libraries of good
>stuff of all sorts, maybe even some I/O.
But today, nobody uses Dylan because 1. it's different and 2. there
are no support packages. Thus there is no point in writing stuff for
them (and certainly not in converting my major application).
Thus tomorrow, nobody uses Dylan... This is why Cobol and C are
immortal.
I think that this is a realy important issue. Unless you produce a
language that is tangably and unquestionably different such as
4GLs vs Cobol or Prolog (:-)), it is difficult to get a new
language accepted because of this inertia. Consider:-
Fortran Successful, in first.
Cobol Successful, These programs couldn't be written in Fortran.
Algol 60/68 Failed. Just a clean Fortran.
4GLs Successful, again tangibly much more productive than
Cobol. (DBMS people don't know Lisp!).
Ada Marginal, despite having the biggest backer imaginable (DoD).
C Successful, Wirth Pascal couldn't do the job, rode on Unix's back.
C++ Successful, 100% upward compatible, and more
importantly culturally compatible.
CL Successful, brought together a wide community.
Scheme Failed.
Dylan ? Smells like Algol to me, unless it can be made compatible.
"Successful" here means widely used. New lisp languages could do well
to consider why C++ is by far the most widely used conventional OO
language.
The danger is that projects like Dylan will fragment the relatively
small CL community rather than helping it grow.
(An (optional) grammar is important because it makes a language
culturally compatible with the non lisp community. Tradition is
everything.)
>>Incidently, most important decisions and perceptions are made on
>>superficial grounds...
>
>This isn't just superficial; it's wrong...
It seems "smilies" are essential. Here are a few: :-) :-) :-) :-) :-) :-) :-).
>>Given that CL and Dylan are similar (whether "related language" or
>>"dialect") I would expect that a large percentage of a Dylan
>>implementation could be taken from CMUCLs code. There are four
>>options:-
>>
>There is an implementation of Dylan called Zimmerman which does just
>this. The author has ripped out substantial portions of CMUCL's
>compiler and used it to implement a Dylan compiler. The compiler and
>interepreter will be placed in the public domain. I saw a demo of
>the system last night at MacWorld. The implementation is a few months
>away from being ready for public consumption, but the author is firmly
>committed to the system being public domain and freely available.
This is exactly what I do not want to happen:- Copy code out of cmucl
and produce something completely divorced from it that can never be
"resynced". Far better, if feasible, to Share code with cmucl, so
that the shared code can be maintained once for both langauges.
This can involve some careful thought about just what the common bits
are to make the result elegant.
>>I am also a little concerned about Apple (My Intellectual Property) Inc
>>effectively owning a programming language design.
>>
>The people at Apple who are working on Dylan are very interested and
>committed to having multiple platform implementations of Dylan...
There must have been a revolution at Apple HQ. The people pushing
Look and Feel cases must have departed... Here it is: :-).
If the Dylan community decided Apple inc was a problem, could they
create a new language, Wumpus (say), that just happened to look
identical to Dylan execpt for some specific changes, without
having to consult their lawyers?
--
Anthony Berglas
Rm 503, Computer Science, Uni of Qld, 4072, Australia.
Uni Ph +61 7 365 2812, Home 391 7727, Fax 365 1999
In article <·····@uqcspe.cs.uq.oz.au>, ·······@cs.uq.oz.au (Anthony Berglas) writes:
|> CL Successful, brought together a wide community.
|> Scheme Failed.
|> Dylan ? Smells like Algol to me, unless it can be made compatible.
|> [...]
|>
|> The danger is that projects like Dylan will fragment the relatively
|> small CL community rather than helping it grow.
CL has some serious problems:
* the language is full of "undefined behaviors" (though, fortunately,
most implementations detect most errors)
* writing efficient numerical code is very difficult and requires
lots of trial and error and experience
* the module system is seriously broken
* there is a profusion of functionality, and much of it is usually
neither well implemented nor used very frequently (e.g., all the
different varieties of non-simple arrays)
* the object system and the "old" language are integrated less than
ideally; sequence functions and some of other functionality
should be based on the object system
* implementations and executables tend to be rather "fat"
* (there are probably more, but those are some of the problems that
come to mind immediately)
There are also a number of missing features, such as threads and a
foreign-function interface, that are important for many applications.
The CL community has had many years to address these problems without
much success. That's why some people have decided to take a fresh
approach. I don't see anything wrong with that. May the better
language win. If it turns out that this kind of competition will get
CL to address some of its problems and be competitive with the
newcomers, all the better.
Thomas.
I am not going to enter this debate, I am not going to enter this
debate, I am not going... oh, damn.
In article <············@life.ai.mit.edu> ···@idiap.ch writes:
>CL has some serious problems:
> [list of flaws]
If technical flaws had anything to do with a language's success, we
would not currently be burdened with C++ ("C With Pretensions"), which
even its proponents are often prepared to admit is a monstrous,
pus-filled blot on the language design landscape.
C++ and other popular languages (muse: are popular languages like
popular music?) happen to take a different stance than the Lisp
community has done on the appropriate tradeoffs between power,
expressiveness, simplicity and implementation efficiency. (See RPG's
"Worse is Better"). While some of us may believe that their decisions
should prevent them for ever from entering Programming Language
Heaven, they chose, and they are reaping the benefits.
So what's the solution? Well, you can attempt to find ways to avoid
those trade-offs (essentially what the CLOS MOP development did,
although that strategy isn't ready to be widely and automatically
applied); you can accept Lisp's place in the world and choose to carry
on working in it when appropriate; you can work at making Lisp beter
for what it's good at, and not for what it can never be; or you can
post endless flames to comp.lang.lisp about how, if Lisp only had a
decent foreign function interface, then Symbolics would have killed
off Microsoft, and Windows NT would have been written in Lisp.
You decide.
--
Rank Xerox EuroPARC, Cambridge Computer Science, University College London
<·······@EuroPARC.Xerox.COM> <·········@cs.ucl.ac.uk>
"Ain't they got no barbers where you come from, boy?"
In article <······················@ucl.ac.uk>, ·······@ucl.ac.uk (Paul Dourish) writes:
|> you can accept Lisp's place in the world and choose to carry
|> on working in it when appropriate; you can work at making Lisp beter
|> for what it's good at, and not for what it can never be;
In fact, I already know that CommonLisp can be very useful in many
areas where it is currently somewhat cumbersome to use. The problems
are not technical, but related to standardization. Standardization of
features like the meaning and effect of numerical declarations, of the
foreign function interface, and of error detection.
Thomas.
···@arolla.idiap.ch (Thomas M. Breuel) writes:
>CL has some serious problems:
There was a time when people from CMU would be defending CL from
attacks such as this. (E.g. from Gabriel and Brook's 84 Lisp
conference paper.)
Anyway, there are serious problems in may successful languages.
C has a number of undefined behaviors, some syntactic and semantic
non-orthogonalities, a limited and somewhat unsafe type system,
modules only by convention (a certain use of static and .h files),
etc. Languages that are carefully designed to get things right
are often unsuccessful.
Critics of Common Lisp tend to make strong, but not very specific,
claims. I've found that such critics who agree at this abstract level
often disagree about what's actually wrong. That is, instead of
their being a consensus about what's wrong with Common Lisp, there's
a disagreement.
And much of it reduces to CL being a different kind of language than
the critic is used to. For instance, it's not too hard to get
efficient numeric code in a fairly wide range of implementations.
What's more difficult is to get something that works in CL in general;
but part of the reason for that is that CL is implemented in a wider
variety of ways than "conventional" languages. So, for instance,
arithmetic doesn't have to be efficient at all. Even in C, you don't
necessarily get efficient aritymetic; floating point might be
implemented as procedure calls, for instance. Or C might be
translated into a Lisp, and then would be no more efficient than
Lisp. This isn't counted against C, however, because it's outside
the conventional range of C implementations.
> * the language is full of "undefined behaviors" (though, fortunately,
> most implementations detect most errors)
See above.
> * writing efficient numerical code is very difficult and requires
> lots of trial and error and experience
See above.
> * the module system is seriously broken
Nonspecific. See above.
> * there is a profusion of functionality, and much of it is usually
> neither well implemented nor used very frequently (e.g., all the
> different varieties of non-simple arrays)
And what else, other than FORMAT? Arrays are an easy target. I find
most things in CL to be useful, even such things as vector-push-extend.
I think it's good that there's a large standard library, and much
criticism would have been disarmed if it had been described as such.
(Just look at all tghe Prolog programmerw who write their own
append to see what happens if you're too minimal.)
> * the object system and the "old" language are integrated less than
> ideally; sequence functions and some of other functionality
> should be based on the object system
Less than ideally, sure, but how important is it to match the
ideal? Sequence functions and streams look like they should be
object-oriented and aren't, but what else? And why is this
worse than having libraries that don't use the object-oriented
capabilities of the language? Does C++ suck if I can use the
C standard I/O library, or X toolkits that don't use C++ classes?
> * implementations and executables tend to be rather "fat"
True, but a more telling criticism of the language would be to find
language features (rather than implementation traditions) that would
account for this.
> * (there are probably more, but those are some of the problems that
> come to mind immediately)
>There are also a number of missing features, such as threads and a
>foreign-function interface, that are important for many applications.
And missing from most other languages. There wasn't time for
everything. We have CLOS and conditions, we have Dylan and TELOS
in part because of CLOS. I don't think that's such a bad deal.
>The CL community has had many years to address these problems without
>much success. That's why some people have decided to take a fresh
>approach. I don't see anything wrong with that.
Many of them are the _same_ people. So what's your explanation
for why CL went wrong?
>May the better language win. If it turns out that this kind of
>competition will get CL to address some of its problems and be
>competitive with the newcomers, all the better.
Suppose that Scheme, EuLisp, Common Lisp, and any ISO Lisp all
die because of Dylan and that Dylan eventually changes enough so
that it's not usable as a Lisp either. Only someone who disliked
Lisp anyway would think this a good thing.
-- jd
·······@cs.uq.oz.au (Anthony Berglas) writes:
>Fortran Successful, in first.
>Algol 60/68 Failed. Just a clean Fortran.
Algol was in there pretty fast. Algol 60 was not the first version.
>C++ Successful, 100% upward compatible, and more
> importantly culturally compatible.
I thought it wasn't 100% upward compatible.
Anyway...
>>>I am also a little concerned about Apple (My Intellectual Property) Inc
>>>effectively owning a programming language design.
>>>
>>The people at Apple who are working on Dylan are very interested and
>>committed to having multiple platform implementations of Dylan...
What does "multiple platform" mean? Not on Macs? That's not nearly
enough for me. I want random people to be able to implement Dylan
and call it Dylan without paying anything to Apple. However, if
Apple requires that implementations pass a (fair) conformance test,
that would be fine with me.
-- jd
From: Ted "Theodore" W. Leung
Subject: Re: CMUCL/Dylan, Being pragmatic...
Date:
Message-ID: <249nm0$jft@cat.cis.Brown.EDU>
In article <··········@festival.ed.ac.uk>,
J W Dalton <····@festival.ed.ac.uk> wrote:
>>>>
>>>The people at Apple who are working on Dylan are very interested and
>>>committed to having multiple platform implementations of Dylan...
>
>What does "multiple platform" mean? Not on Macs? That's not nearly
>enough for me. I want random people to be able to implement Dylan
>and call it Dylan without paying anything to Apple. However, if
>Apple requires that implementations pass a (fair) conformance test,
>that would be fine with me.
>
There are two issues to address:
1) multiple platform implementations of Dylan, that is, Dylan on things besides
a Mac. Apple wants people to do this.
2) licensing fees for the use of the Dylan name. My understanding is that
if you pass the conformance test, you can use the name. Apparently, Apple
is willing to extend resources to help developers develop Dylan implementations.I have not heard anyone official say that there will be a charge to use the
name, and the impression I got from the *engineers* that I talked to was that
there would be no charges
Ted
--
Ted "Theodore" Leung | ···@cs.brown.edu
Brown Object-Oriented Database Group | ···@BROWNCS.BITNET
Box 1910, Brown Univerisity | uunet!brunix!twl
Providence, RI 02912-1910 | (401) 863-7673
In article <··········@cat.cis.Brown.EDU>, ···@cs.brown.edu (Ted "Theodore" W. Leung) writes:
> My understanding is that
> if you pass the conformance test, you can use the name. Apparently, Apple
> is willing to extend resources to help developers develop Dylan implementations.I have not heard anyone official say that there will be a charge to use the
> name, and the impression I got from the *engineers* that I talked to was that
> there would be no charges
Oh, but are the engineers *ever* the bad guys? There appears to be
little reason to believe that Apple's higher-ups may feel the same
way.
rodrigo vanegas
··@cs.brown.edu
·······@cs.uq.oz.au (Anthony Berglas) writes:
[ stuff deleted ]
>The danger is that projects like Dylan will fragment the relatively
>small CL community rather than helping it grow.
This is very real possibility, should we be concerned? Probably. Over
the past 3-4 years, many were forced to leave the CL fold in order to
earn a living, they now write C++ code (yuck). Some blame the delay(s)
in the ANSI/CL standard, others blame CL itself, i.e., it's too big,
not well integrated right now, lacks refinements like a FFI, etc., but
whatever the reason (gripe), it's not likely to be resolved by focusing
attention (energy) elsewhere. The CL community is small, possibly fragile,
Dylan (the "Igor" project) isn't the shot in the arm CL needs right now.
I'd like to believe that new discoveries obtained from an exploration of
Dylan could benefit CL, but then again, I'd also like to believe that
life is fair. Wanna buy a Betamax machine, real cheap?
I'm probing for the truth here, please flame away. ;-)
[ rest deleted ]
-- jpf.
···@wstar.mil.wi.us (John P. Flanagan) writes:
>·······@cs.uq.oz.au (Anthony Berglas) writes:
[...]
>>The danger is that projects like Dylan will fragment the relatively
>>small CL community rather than helping it grow.
>
>This is very real possibility, should we be concerned? Probably. Over
>the past 3-4 years, many were forced to leave the CL fold in order to
>earn a living, they now write C++ code (yuck). [...]
>The CL community is small, possibly fragile,
>Dylan (the "Igor" project) isn't the shot in the arm CL needs right now.
Hmm. I'm not sure whether or not Dylan will boost the CL community. However,
if I'm "forced to leave the CL [or Scheme or ML] fold in order to earn a
living", I'd sure rather leave it for Dylan than C++. If Apple, CMU (SEF),
and company are successful in getting Dylan in use for mainstream
applications, I would think that would increase the opportunities for
those of us who like and know about that style of programming but are
finding it hard to find the AI applications in CL that we are used to.
The Dylan FAQ of 12/92 says "The target audience for Dylan is software
application programmers, most of whom are currently using static languages
such as C and C++." Also, you can (or used to be able to) get a free manual
from ····················@cambridge.apple.com.
- Marty
(proclaim '(inline skates))
····@aplcenmp.apl.jhu.edu (Marty Hall) writes:
>···@wstar.mil.wi.us (John P. Flanagan) writes:
>>·······@cs.uq.oz.au (Anthony Berglas) writes:
>[...]
>>>The danger is that projects like Dylan will fragment the relatively
>>>small CL community rather than helping it grow.
>>
>>This is very real possibility, should we be concerned? Probably. Over
>>the past 3-4 years, many were forced to leave the CL fold in order to
>>earn a living, they now write C++ code (yuck). [...]
>>The CL community is small, possibly fragile,
>>Dylan (the "Igor" project) isn't the shot in the arm CL needs right now.
>Hmm. I'm not sure whether or not Dylan will boost the CL community. However,
>if I'm "forced to leave the CL [or Scheme or ML] fold in order to earn a
>living", I'd sure rather leave it for Dylan than C++. If Apple, CMU (SEF),
>and company are successful in getting Dylan in use for mainstream
>applications, I would think that would increase the opportunities for
>those of us who like and know about that style of programming but are
>finding it hard to find the AI applications in CL that we are used to.
>The Dylan FAQ of 12/92 says "The target audience for Dylan is software
>application programmers, most of whom are currently using static languages
>such as C and C++." Also, you can (or used to be able to) get a free manual
>from ····················@cambridge.apple.com.
Agreed, Dylan would certainly be preferable to C++, but I think we should
be asking ourselves do we really want to encourage being put into a situation
where we are forced to make this choice in the first place. In spite of the
Dylan FAQ, rather than draw C/C++ programmers, I think Dylan could end up
hurting CL by diverting precious talent (and energy) away from the CL community
at a time when we can least afford it. I hope I'm 100% wrong! ;-)
-- jpf.
···@wstar.mil.wi.us (John P. Flanagan) writes:
[...]
>Agreed, Dylan would certainly be preferable to C++, but I think we should
>be asking ourselves do we really want to encourage being put into a situation
>where we are forced to make this choice in the first place.
MANY people are already in that situation, IMHO.
>In spite of the
>Dylan FAQ, rather than draw C/C++ programmers, I think Dylan could end up
>hurting CL by diverting precious talent (and energy) away from the CL community
>at a time when we can least afford it. I hope I'm 100% wrong! ;-)
You certainly could be right; these things are impossible to predict.
While it is true that Dylan may not be successful in drawing C/C++ programmers,
I think people doing large AI applications in CL are unlikely to switch either,
since Dylan is aimed at smaller more mainstream applications. So if perchance
Dylan IS successful, it will give us opportunities in smaller, non-AI
applications that we didn't have previously.
Regarding diverting talent, certainly SEF and company did us all a great
service with CMU CL, among other things giving many places (eg Universities)
a good CL that they wouldn't have gotten if they had to pay a vendor, thus
exposing many students. However, since [D]ARPA wasn't going to fund that
anymore anyhow, I think we should all be glad that they are working on
another project of potential benefit to many of us.
Dylan might not fly, but then again it might. I don't see all that much
harm in a small percentage of the CL community working on it, even if it
fails. And I see great benefits if it succeeds. Let's hope it does!
- Marty
(proclaim '(inline skates))
····@aplcenmp.apl.jhu.edu (Marty Hall) writes:
>Regarding diverting talent, certainly SEF and company did us all a great
>service with CMU CL, among other things giving many places (eg Universities)
>a good CL that they wouldn't have gotten if they had to pay a vendor, thus
>exposing many students. However, since [D]ARPA wasn't going to fund that
>anymore anyhow, I think we should all be glad that they are working on
>another project of potential benefit to many of us.
How do you know DARPA wouldn't have funded an Igor project based on
CL?
>Dylan might not fly, but then again it might. I don't see all that much
>harm in a small percentage of the CL community working on it, even if it
>fails. And I see great benefits if it succeeds. Let's hope it does!
There are great benefits only if (1) it remains sufficiently like
Lisp, (2) Apple doesn't suddenly wake up one day and decide to charge
a real license fee, and (3) Apple doesn't patent enough techniques
that it becomes difficult to work on Lisp.
-- jd
In article <··········@aplcenmp.apl.jhu.edu> ····@aplcenmp.apl.jhu.edu (Marty Hall) writes:
>Also, you can (or used to be able to) get a free manual
>from ····················@cambridge.apple.com.
I got that book from a friend at Apple and am reading it now. He said
that the way it works is that you send the email, and long long long
after you are positive that they've completely forgotten about it, it
shows up in the mail.
In reference to the Dylan-availability topic, from what I've heard about
Zimmerman, it will be available on much the same terms as is X11. It
also generates either native code or C, so should be (and is supposed
to be) fairly portable.
D
I'm kinda surprised by all the attacks on the CMU group for switching
over to Dylan. Since I first started working with Lisp I've used NIL,
UCI-Lisp, Elisp, Xlisp, PSL, Interlisp-10, Interlisp-D, Common Lisp, and
probably a couple others that I forget about. These days I use Elisp,
Interlisp, and CL about equally. What's so sacred about CL? Do people
really believe that all development of Lisp-like languages must stop
because of a "standard"? I don't see people flaming Stallman for using
elisp for emacs, and I'd bet that there are more people who write
elisp code these days than there are people who write CL code. One of
Lisp's features is it's extendability and flexibility, and I don't
believe my brain's ossified to the extent that I can't pick up a new
dialect.
...arun
---------------------------------------------------------------------------
Arun Welch 1224 Kinnear Rd
Network Engineer Columbus, OH 43212
OARnet ·····@oar.net
·····@malgudi.oar.net (Arun Welch) writes:
>I'm kinda surprised by all the attacks on the CMU group for switching
>over to Dylan. Since I first started working with Lisp I've used NIL,
>UCI-Lisp, Elisp, Xlisp, PSL, Interlisp-10, Interlisp-D, Common Lisp, and
>probably a couple others that I forget about. These days I use Elisp,
>Interlisp, and CL about equally. What's so sacred about CL?
Nothing.
>Do people really believe that all development of Lisp-like languages must
>stop because of a "standard"?
No, but what is the relevance of this? New Lisp-likes might
expand the use of Lisp or not. If CL is seen as a failure,
what will be ther effect of that?
>I don't see people flaming Stallman for using
>elisp for emacs, and I'd bet that there are more people who write
>elisp code these days than there are people who write CL code. One of
>Lisp's features is it's extendability and flexibility, and I don't
>believe my brain's ossified to the extent that I can't pick up a new
>dialect.
Here I am a user of CMUCL, which is in some ways the best implementation
of CL, and indeed of Lisp, available to me. I'm hoping that it will
become even better in the future. Now, maybe, that won't happen.
This is nothing like Stallman using elisp in Emacs!
You might say, oh, you can use CMU Dylan instead. But not for my
Common Lisp programs. I don't particularly want to rewrite them,
even though I could. Moreover, who says Dylan's going to be usable
as a Lisp? Maybe Apple will change it until it isn't.
-- jd
In article <··········@festival.ed.ac.uk> ····@festival.ed.ac.uk (J W Dalton) writes:
[actually in an earlier message]
How do you know DARPA wouldn't have funded an Igor project based on
CL?
Because Scott's original message (<············@cs.cmu.edu>) said so.
Here I am a user of CMUCL, which is in some ways the best implementation
of CL, and indeed of Lisp, available to me. I'm hoping that it will
become even better in the future. Now, maybe, that won't happen.
Maybe. The sources are freely available, and people are welcome to
take them and develop them further. What you're losing is the free
development/support ride you were getting before, courtesy DARPA.
There are many instances that can be found where the original
developer of some piece of software dropped support and someone else
took over based on their own need and noticably improved it. KCL, for
example. PCL is another, with Trent Lange and Rick Harris picking it
up after Xerox dropped out. Further afield from the Lisp world is gcc
(or for that matter a lot of the GNU stuff, which is now community
supported). Just because CMU can't afford to keep funding it is no
reason to believe it's gonna die. The fact is that Scott no longer has
funding to support development and support, and Igor is something that
is funded.
...arun
---------------------------------------------------------------------------
Arun Welch 1224 Kinnear Rd
Network Engineer Columbus, OH 43212
OARnet ·····@oar.net
·····@malgudi.oar.net (Arun Welch) writes:
>I'm kinda surprised by all the attacks on the CMU group for switching
>over to Dylan. Since I first started working with Lisp I've used NIL,
>UCI-Lisp, Elisp, Xlisp, PSL, Interlisp-10, Interlisp-D, Common Lisp, and
>probably a couple others that I forget about. These days I use Elisp,
>Interlisp, and CL about equally. What's so sacred about CL? Do people
>really believe that all development of Lisp-like languages must stop
>because of a "standard"? I don't see people flaming Stallman for using
>elisp for emacs, and I'd bet that there are more people who write
>elisp code these days than there are people who write CL code. One of
>Lisp's features is it's extendability and flexibility, and I don't
>believe my brain's ossified to the extent that I can't pick up a new
>dialect.
I'm kinda surprised too, where (when) did all these so called "attacks"
on the CMU group (for switching over to Dylan) occur?
I've been following this thread from the beginning and what I've seen
is some understandable concern about the impact Dylan will have on CL.
No one is attacking the CMU group, they've made significant contributions
to the development and evolution of CL and it's only natural for those of
us who've benefited from their work to examine (and question) their most
recent course change.
You recite over a half dozen Lisp's that you've worked on over the years
(plus your current "working" trio) and suggest that to defend CL in this
context is to worship CL (hold it sacred). Maybe for a moment in time
we *should* hold CL sacred, at least while the ANSI finish line is in
sight. Let's give CL a fair shake. We're (hopefully) one public review
period away from an official ANSI "CL standard", but here we are chasing
the rabbit (no pun intended) into the next race (Dylan), pondering
failure in a race we haven't finished, let alone lost yet. No one has
said that development of Lisp-like languages must stop because of the
(pending) "standard", but shouldn't we first cross that proverbial
finish line (realize the standard) and thoroughly understand what it
offers (or doesn't offer) before we start running in the next race?
Tight integration of "objects" and "delivery issues" are certainly
problems that can be solved in CL, the question is whether we really
want to (have the will). It's very exciting to start fresh from a blank
piece of paper and proclaim all the wonderful things you're going to do.
It's much less appealing to continue working on something with ugly
scars left over from years of corrective surgery, change and practical
compromise, i.e., beauty is only skin deep.
Regarding Elisp, I don't see the connection. Elisp code gets written by
necessity as a consequence of the Emacs editor. If indeed there are
more people who write Elisp code than there are people who write CL code,
I'd say it's because there are more users of Emacs than there are users
of CL, not because more people prefer to do their Lisp work in Elisp.
Finally, I wouldn't dissuade anyone from exploring the Lisp landscape,
but a steady diet of new Lisp dialects could cause indigestion. ;-)
-- jpf.
·······@cs.uq.oz.au (Anthony Berglas) writes:
>Given that CL and Dylan are similar (whether "related language" or
>"dialect") I would expect that a large percentage of a Dylan
>implementation could be taken from CMUCLs code. There are four
>options:-
>0. Write a new Dylan system from scratch, perhaps hacking chunks of
> code out of CMUCL.
>1. Write a Dylan to CMULisp translater.
I think someone should so a Dylan to reasonably-portable-CL
translator anyway. I may do one if I have time.
>2. Write a CMUCL to Dylan translater.
Maybe. A lot of CMU CL is reasonably portable code (I use their
defpackage, loop, and trace in [A]KCL), so once I kernel CL was
available it could be treated as library.
>3. Factor out the common elements of Dylan and CL into a kernal and
> then having different front ends.
I think this would tend to merge with option 2.
>1. With care it should be possible to tightly couple CL and Dylan
> code. I can ignore some of CL's uglyness but I cannot live witout
> my favourite CL packages. This would be the major reason to
> stick to CL and ignore Dylan systems.
Well, I assume Dylan will eventually have libraries of good
stuff of all sorts, maybe even some I/O.
-- jd
·······@cs.uq.oz.au (Anthony Berglas) writes:
>Incidently, most important decisions and perceptions are made on
>superficial grounds. People at Uni Qld cs won't go near Lisp because
>they know that it is a primitive, interpretive language with lots of
>parenthesis.
This isn't just superficial; it's wrong. Lisp is not an interpretive
language. Nor is Basic, for that matter. It's entriely possible to
have a Basic compiler, and Dartmouth Basic (you know real, original
Basic) has always been implemented that way. Indeed, I'm not sure
there's any such thing as an interpretative language. There are
languages that are typically implemented as interpreters, but that's
about as far as it goes.
> A new syntax makes a new language.
No it doesn't. If it did, it wouldn't be possible to have a
language with two syntaxes.
>I am also a little concerned about Apple (My Intellectual Property) Inc
>effectively owning a programming language design.
That's ok, so long as they let other people implement it w/o
having to pay a license fee. They might impose a conformance
test, or something like that, which is no bad thing. But it's
true that the fate of trademarked languages has not always been
enspiring.
-- jd
From: Ted "Theodore" W. Leung
Subject: Re: CMUCL/Dylan, Being pragmatic...
Date:
Message-ID: <23u37v$e9o@cat.cis.Brown.EDU>
In article <·····@uqcspe.cs.uq.oz.au>,
Anthony Berglas <·······@cs.uq.oz.au> wrote:
>Given that CL and Dylan are similar (whether "related language" or
>"dialect") I would expect that a large percentage of a Dylan
>implementation could be taken from CMUCLs code. There are four
>options:-
>
There is an implementation of Dylan called Zimmerman which does just
this. The author has ripped out substantial portions of CMUCL's
compiler and used it to implement a Dylan compiler. The compiler and
interepreter will be placed in the public domain. I saw a demo of
the system last night at MacWorld. The implementation is a few months
away from being ready for public consumption, but the author is firmly
committed to the system being public domain and freely available.
>
>I am also a little concerned about Apple (My Intellectual Property) Inc
>effectively owning a programming language design.
>
The people at Apple who are working on Dylan are very interested and
committed to having multiple platform implementations of Dylan. There
is a group of vendors who are working on Dylan implementations, and
those people are involved in influencing aspects of the language
design.
Ted
--
Ted "Theodore" Leung | ···@cs.brown.edu
Brown Object-Oriented Database Group | ···@BROWNCS.BITNET
Box 1910, Brown Univerisity | uunet!brunix!twl
Providence, RI 02912-1910 | (401) 863-7673