It would seem to me to be a very worthy university project to
build a portable Dylan implementation on top of Common Lisp.
Would someone please do it?
Benefits:
* Dylan would be instantly available to more people
* I expect a lot of useful framework code to be written in
Dylan, and it would be wonderful to be able to use it in
Common Lisp!
* Who knows, such a thing might give some impetus to adding
Dylan's worthwhile optimization features to standard CL.
* If Lisp-to-Dylan syntax translation is part of the package,
we CL fans could work in the Dylan-enhanced CL, then export
our code in Dylan syntax for porting to the sure-to-come
plethora of native Dylan compilers.
In article <··········@news.internex.net>, ····@rclsgi.eng.ohio-state.edu (Dave Yost) writes:
>> It would seem to me to be a very worthy university project to
>> build a portable Dylan implementation on top of Common Lisp.
>> Would someone please do it?
>>
This would be a good idea. Is it possible to define a Common Lisp
subset that would map into Dylan? Then all that is needed is
the CommonLisp-to-Dylan syntax translation, which I think would
be easy. Hmm, isn't nil /= false in Dylan. That's hard to fix in syntax.
If the CL->Dylan mapping isn't 100%, maybe we could
push hard to get Dylan changed so it would be.
Why not make it CL-subset-able?
-Kelly Murray
In article <·····················@franz.com> ···@prl.ufl.edu (Kelly Murray) writes:
In article <··········@news.internex.net>, ····@rclsgi.eng.ohio-state.edu (Dave Yost) writes:
>> It would seem to me to be a very worthy university project to
>> build a portable Dylan implementation on top of Common Lisp.
And a very worthy university has done this, sort of. The Gwydion
project's first toy implementation of Dylan was on top of CMU CL, with
which we have some familiarity. This was back when Dylan had a
Lisp-like syntax, so that wasn't a problem, but there were enough
small differences to make the resulting Dylan-ish system pretty
unusable for development of real Dylan code. We decided to abandon
this effort in favor of Mindy. The () vs. #f issue was one nasty
problem we ran into. I don't remember all the others, but there were a
bunch of them.
If the CL->Dylan mapping isn't 100%, maybe we could
push hard to get Dylan changed so it would be.
Push all you like. It won't happen. Having a Dylan-in-CL for some
transitional period is not a good enough reason to preserve all the
accumulated small irritations that have built up in Lisp over the
decades.
-- Scott
===========================================================================
Scott E. Fahlman Internet: ····@cs.cmu.edu
Principal Research Scientist Phone: 412 268-2575
School of Computer Science Fax: 412 268-5576
Carnegie Mellon University Latitude: 40:26:46 N
5000 Forbes Avenue Longitude: 79:56:55 W
Pittsburgh, PA 15213 Mood: :-)
===========================================================================
In article <··········@cantaloupe.srv.cs.cmu.edu>, ···@CS.CMU.EDU (Scott Fahlman) writes:
>>
>> If the CL->Dylan mapping isn't 100%, maybe we could
>> push hard to get Dylan changed so it would be.
>>
>> Push all you like. It won't happen. Having a Dylan-in-CL for some
>> transitional period is not a good enough reason to preserve all the
>> accumulated small irritations that have built up in Lisp over the
>> decades.
>>
My apologies if this has already been hashed over 1m times.
It's my opinion that non-CL users would not be irritated
by such things as nil == false, etc. It's only CL users who really
care about these things. I mean if they can deal with C++ ...
I've keep no secret of my opinion that a CL-subset is the best
way forward. I agree the new-Dylan syntax is right for the unsophisticated,
especially if there is a CL->dylan mechanical translation for delivery.
But leaving CL behind for the sake of getting rid of "small irritations"
just seems, well, foolish. I can't help but think the task of creating
a whole new language is too ambitious, even for Apple Computer,
unless it really offers something that can't be done with another one,
which isn't going to be the case, unless Apple really makes it proprietary.
Just my opinion -- I guess even one M1 tank can't push hard enough..
In any case, a Dylan-on-CL would be great. Perhaps the Scheme-on-CL
implemenation would be a good place to start.
-Kelly Murray
From: Jeff Dalton
Subject: Re: A Dylan implemented on Common Lisp
Date:
Message-ID: <D5345w.3xC@cogsci.ed.ac.uk>
In article <··········@cantaloupe.srv.cs.cmu.edu> ···@CS.CMU.EDU (Scott Fahlman) writes:
>
> If the CL->Dylan mapping isn't 100%, maybe we could
> push hard to get Dylan changed so it would be.
>
>Push all you like. It won't happen. Having a Dylan-in-CL for some
>transitional period is not a good enough reason to preserve all the
>accumulated small irritations that have built up in Lisp over the
>decades.
Contrary to the impression created by Scott's anti-Lisp propaganda,
Common Lisp eliminated most of the small irritations that had built
up over the years. (E.g. interpreters using different scope rules
than compilers) Some of the remaining "small irritations" (e.g.
nil being false) are not universally considered irritations.
In any case, a Dylan-in-CL can handle nil vs #f (Scott's example),
as Schemes-in-CL have shown.
Note that Scott Fahlman was one of the designers of Common Lisp
and had plenty of opportunities to eliminate any irritations that
irritated him.
-- jd
In article <··········@cogsci.ed.ac.uk> ····@aiai.ed.ac.uk (Jeff Dalton) writes:
>In article <··········@cantaloupe.srv.cs.cmu.edu> ···@CS.CMU.EDU (Scott Fahlman) writes:
[...]
>>Having a Dylan-in-CL for some
>>transitional period is not a good enough reason to preserve all the
>>accumulated small irritations that have built up in Lisp over the
>>decades.
>
>Contrary to the impression created by Scott's anti-Lisp propaganda,
>Common Lisp eliminated most of the small irritations that had built
>up over the years. (E.g. interpreters using different scope rules
>than compilers) Some of the remaining "small irritations" (e.g.
>nil being false) are not universally considered irritations.
>In any case, a Dylan-in-CL can handle nil vs #f (Scott's example),
>as Schemes-in-CL have shown.
In early versions of NIL there were distinct symbols for NIL and
false. This was eventually found to be more of an irritation
than combining them. It may not satisfy a mathematical purist,
but it works well in practice.
>Note that Scott Fahlman was one of the designers of Common Lisp
>and had plenty of opportunities to eliminate any irritations that
>irritated him.
>
>-- jd
And means that his criticism of Common Lisp can't be
dismissed as easily the complaints made by people who have only
used Basic or Cobol.
-Chris Eliot
From: Jeff Dalton
Subject: Re: A Dylan implemented on Common Lisp
Date:
Message-ID: <D550vz.CM1@cogsci.ed.ac.uk>
In article <··········@kernighan.cs.umass.edu> ·····@cs.umass.edu (CHRISTOPHER ELIOT) writes:
>In article <··········@cogsci.ed.ac.uk> ····@aiai.ed.ac.uk (Jeff Dalton) writes:
>>Note that Scott Fahlman was one of the designers of Common Lisp
>>and had plenty of opportunities to eliminate any irritations that
>>irritated him.
>
>And means that his criticism of Common Lisp can't be
>dismissed as easily the complaints made by people who have only
>used Basic or Cobol.
Sure, but his former relative lack of opposition to various supposed
irritants does rather suggest that they didn't irritate him all that
much.
-- jd
In article <··········@cogsci.ed.ac.uk> ····@aiai.ed.ac.uk (Jeff Dalton) writes:
Contrary to the impression created by Scott's anti-Lisp propaganda,
Common Lisp eliminated most of the small irritations that had built
up over the years.
It eliminated some. Many others were kept for compatibility reasons.
I feel kind of funny being cast in the role of an anti-Lisp
propagandist, just because I believe that Common Lisp is not perfect
and that Dylan can do better in certain respects, both large and
small.
I still use Common Lisp and like it. In an earlier post to
comp.lang.dylan I pointed out several areas in which CL will have an
advantage over Dylan, at least for some time to come. But after many
years of hard work trying to make Common Lisp a mainstream success, I
have given up on that goal. I think Dylan has a better shot at
achieving this goal -- it keeps most of what is good about Lisp while
abandoning some bad ideas and a lot of excess baggage. Many other
former Lispers share this perception. Your mileage may vary.
Obviously Dylan incorporates a lot of ideas from Lisp -- not
surprising since most of the Dylan designers have a Lisp background.
But it is different in important ways, and we want people to evaluate
the language on its own merits -- not dismiss it because they dislike
Lisp (for valid reasons or not) and think that Dylan is just more of
the same.
Note that Scott Fahlman was one of the designers of Common Lisp
and had plenty of opportunities to eliminate any irritations that
irritated him.
Not exactly true. The over-riding concern of the people designing
Common Lisp was to come up with a design that N different groups, all
with different agendas and different existing implementations, could
agree on. Keeping small crocks and kludges in the language was very
often the price for keeping some group or other from jumping off the
bandwagon. I am sure that any one of the major Common Lisp designers
could have designed a more elegant and beautiful Lisp dialect, but
then it would not have been common. The result is a language that
served an important purpose for many years (and continues to do so,
though it's fading a bit) but that not even its mother could love.
Like the camel, Common Lisp is a horse designed by committee. Camels
do have their uses.
-- Scott
===========================================================================
Scott E. Fahlman Internet: ····@cs.cmu.edu
Principal Research Scientist Phone: 412 268-2575
School of Computer Science Fax: 412 268-5576
Carnegie Mellon University Latitude: 40:26:46 N
5000 Forbes Avenue Longitude: 79:56:55 W
Pittsburgh, PA 15213 Mood: :-)
===========================================================================
In article <··········@cantaloupe.srv.cs.cmu.edu>, ···@CS.CMU.EDU (Scott Fahlman) writes:
>>
>> In article <··········@cogsci.ed.ac.uk> ····@aiai.ed.ac.uk (Jeff Dalton) writes:
>>
>> Contrary to the impression created by Scott's anti-Lisp propaganda,
>> Common Lisp eliminated most of the small irritations that had built
>> up over the years.
>>
>> It eliminated some. Many others were kept for compatibility reasons.
>>
>> I feel kind of funny being cast in the role of an anti-Lisp
>> propagandist, just because I believe that Common Lisp is not perfect
>> and that Dylan can do better in certain respects, both large and
>> small.
>>
I'll just add one more thing to my M1 tank approach on this topic.
While CL may have its quirks,
creating a new untested language will most certainly end up having
it's share of "irritations" as well, they'll just be different ones.
There is the obvious c:=a+b isn't the same as c := a + b, which will
bite lots of people I'm sure, and the (no)macros.
Scheme has it's own little problems too, like no straightforward
object system due to it's "fixing" of the two-namespace "irritation".
To really get on my soap box, I'm reminded of when I helped psychology
students enter experiment results into data files on the Cyber to run SPSS.
They always wanted to start over on a new file when they made
a data-entry mistake, instead of trying to use the editor
(often 1st time computer users). I'd tell them they would just
make a different mistake in the new file, and it would be faster to
take the time to learn to use the editor, but alas it took a couple
retries before they gave up and used the editor to fix the original file.
>> [..]
>> But it is different in important ways, and we want people to evaluate
>> the language on its own merits -- not dismiss it because they dislike
>> Lisp (for valid reasons or not) and think that Dylan is just more of
>> the same.
It won't be more of the same if it really addresses the issues that
CL put off as unimportant:
(a) unfamiliar syntax (b) C-like image footprint and execution speed.
With a new name, new syntax, and small image size and good execution speed,
I find it hard to believe that being compatible with CL will stop non-CL
people from taking a look. You don't need to make CL compatibility
a feature of the language when marketing it. However, it just might turn
out to be a great feature that a CL system can be used to develop
Dylan programs.
I could have sworn I saw this horse still twitching...
-Kelly Murray
In article <··········@cantaloupe.srv.cs.cmu.edu>, ···@CS.CMU.EDU (Scott
Fahlman) wrote:
> I still use Common Lisp and like it. In an earlier post to
> comp.lang.dylan I pointed out several areas in which CL will have an
> advantage over Dylan, at least for some time to come. But after many
> years of hard work trying to make Common Lisp a mainstream success, I
> have given up on that goal. I think Dylan has a better shot at
> achieving this goal -- it keeps most of what is good about Lisp while
> abandoning some bad ideas and a lot of excess baggage. Many other
> former Lispers share this perception. Your mileage may vary.
>
And a lot of non-Lispers think this is true also. Some of us non-Lispers
don't like Lisp because it has too many parentheses. I don't have that
problem. I just have trouble sseing what it is good for. When you ask
people what they are using Lisp for, most answer with some form of AI
problem. I currently don't work on AI. None of the programs that I work on
need to use AI techniques. I really don't have a need for Lisp. (Please
don't flame me on this. If you have the need to explain to me why I'm
wrong or have examples send me email. I'd really like to see it.
Especially systems programming examples. Give enough detail so that I can
see why using Lisp is better than using say C.)
In Dylan I see a language that feels like a static language that has
borrowed all the best features of Lisp. This makes it attractive as a more
general programming language. A language like C makes a good application
programming language. But try writting an expert system in it. Conversely,
Lisp is a great language to write AI type programs in. But try writing a
word processor with it. It would be just as easy to write a word processor
in Dylan as it is to do in C. And it would be just as easy to write an
expert system in Dyaln as it is in Lisp.
geoff
·········@keps.com
In article <·························@155.50.21.58> ········@keps.com (Geoffrey Clements) writes:
>In article <··········@cantaloupe.srv.cs.cmu.edu>, ···@CS.CMU.EDU (Scott
>Fahlman) wrote:
>
>And a lot of non-Lispers think this is true also. Some of us non-Lispers
>don't like Lisp because it has too many parentheses. I don't have that
>problem. I just have trouble sseing what it is good for.
[...]
>In Dylan I see a language that feels like a static language that has
>borrowed all the best features of Lisp. This makes it attractive as a more
>general programming language. A language like C makes a good application
>programming language. But try writting an expert system in it. Conversely,
>Lisp is a great language to write AI type programs in. But try writing a
>word processor with it.
I *have* written a word processor in Lisp. It was far more customizable
and extensible than any "modern" word processor. This was before CL
and bitmapped displays, so it did not handle things like multiple
fonts, but it could have.
Basically, if you have a language in which you can write programs
that model human reasoning, you can model anything.
>It would be just as easy to write a word processor
>in Dylan as it is to do in C. And it would be just as easy to write an
>expert system in Dyaln as it is in Lisp.
>geoff
>·········@keps.com
Personally, I'm not happy with anything that does not have prefix
notation.
-Chris Eliot
In article <·························@155.50.21.58> ········@keps.com (Geoffrey Clements) writes:
>In Dylan I see a language that feels like a static language that has
>borrowed all the best features of Lisp. This makes it attractive as a more
>general programming language. A language like C makes a good application
>programming language. But try writting an expert system in it. Conversely,
>Lisp is a great language to write AI type programs in. But try writing a
>word processor with it.
My favourite editor was written in a language called POP-2, which you can
think of as Lisp with Pascal syntax. Recently, I have been doing some
statistical calculations. What language have I been using? Xlisp-Stat.
[See "Lisp-Stat, an Object-Oriented Environment for Statistical Computing
and Dynamic Graphics"; Luke Tierney; published by Wiley in 1990.]
One reason for using it: it's free.
Another reason for using it: I can use it on a PC, Mac, or UNIX+X system,
with none of the nasty porting problems I get with C code. (Note in
particular, the graphics stuff may not be flashy, but it's the _same_ on
all platforms. I don't have to know X or Mac Toolbox to program it.)
Another reason for using it: the system is extensible. I can easily build
new stuff using old components.
Another reason for using it: I _have_ written some of the stuff in C, but
all things considered, I've got more done in less time using XlispStat
on a macintosh (and I'm using the old version without even the byte-code
compiler, so we're talking _interpreted_ lisp on a 68020 here) than using
optimised C on a big SPARC. My time is as important as the computer's.
As for word processors specifically, the Xerox D-machines running Interlisp
(one integrated environment) included a word processor called TEdit that I
would still use if I could, and that was written entirely in Interlisp. It
was a very capable component for its size.
--
"The complex-type shall be a simple-type." ISO 10206:1991 (Extended Pascal)
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.
In article <·························@155.50.21.58> ········@keps.com (Geoffrey Clements) writes:
When you ask
people what they are using Lisp for, most answer with some form of AI
problem. I currently don't work on AI. None of the programs that I work on
need to use AI techniques. I really don't have a need for Lisp.
This is one of the big misperceptions about Lisp that we're hoping
won't become a big misperception about Dylan. The area of Lisp's
greatest advantage is not the small number of constructs built-in to
make symbolic programming ("AI") easier -- those could easily be added
to C or whatever -- but rather the "dynamic" orientation of the whole
language.
By "dynamic orientation", I mean that Lisp and Smalltalk and Dylan are
optimized to make it easy to get a prototype program running quickly
and easy to change things later, even on the fly. Many elements go
into this: automatic storage management, incremental everything, a
not-too-restrictive, hierarchical, extensible type system, a lot of
high-level facilities so that the user is not constantly twiddling
pointers and word-lengths, and so on. (Yes, some of these things,
under some conditions, have a cost in efficiency. Often the benefits
of fast, flexible development outweigh that cost.)
This is hard to add on after the fact -- just ask the
people who were trying to build Energize, Lucid's attempt to build a
dynamic C++ environment. (Yes, there have been some partial successes
in similar projects.)
These dynamic languages are ideal for "evolutionary" or "exploratory"
or "incremental" software development, by which I mean any software
development in which you don't know exactly what you want before you
start programming. It can be argued that practically ALL programming
is of this kind, and that we should stop fighting that idea and start
building tools to make it work better.
It is perhaps not surprising that most of these dynamic langauges grew
up in and around AI research groups. AI is one of the fields where
the evolutionary nature of software development is right there in your
face and can't be avoided. AI people can't even pretend that they
know what they are doing, unlike Software Engineers, who can pretend.
and sometimes even convince others. :-)
Anyway, the goal of Dylan is to get most of the benefits of this more
dynamic, evolutionary approach, while minimizing the extra cost that
keeps these languages from being more widely used.
Please don't flame me on this...
I don't think this is a flame, but feel free to take it as one if you
like. As the ancient proverb says: "If you can't take the heat, don't
tickle the dragon."
-- Scott
===========================================================================
Scott E. Fahlman Internet: ····@cs.cmu.edu
Principal Research Scientist Phone: 412 268-2575
School of Computer Science Fax: 412 268-5576
Carnegie Mellon University Latitude: 40:26:46 N
5000 Forbes Avenue Longitude: 79:56:55 W
Pittsburgh, PA 15213 Mood: :-)
===========================================================================
From: Scott McLoughlin
Subject: Re: A Dylan implemented on Common Lisp
Date:
Message-ID: <m32P2c3w165w@sytex.com>
···@CS.CMU.EDU (Scott Fahlman) writes:
> These dynamic languages are ideal for "evolutionary" or "exploratory"
> or "incremental" software development, by which I mean any software
> development in which you don't know exactly what you want before you
> start programming. It can be argued that practically ALL programming
> is of this kind, and that we should stop fighting that idea and start
> building tools to make it work better.
>
Howdy,
For various reasons, I've been hacking around in a popular
4GL RDBMS language on a Unix box. It's been a while since
I've sat down at a programming environment like this.
It immediately strikes me how much more simple, fast and
powerful Lisp would be to use as the 4GL (once you get
used to (+ a b) ). The 4GL is pretty darn slow, has
rather stupid and limmited string handling which leads
to all sorts of gratuitous string copying, etc.
Of course, the 4GL has few nifty constructs for
interacting with the database, but these could be
tacked onto Lisp as easily as tacking them on
to the clunky langauge.
Anyway, I think a flexible language that is very
expressive if not the fastest bit twiddler in the
world (e.g., Lisp) is an appropriate language
for many programming tasks.
=============================================
Scott McLoughlin
Conscious Computing
=============================================
In article <·························@155.50.21.58> ········@keps.com (Geoffrey Clements) writes:
.... I currently don't work on AI. None of the programs that I work on
need to use AI techniques. I really don't have a need for Lisp. ...
In Dylan I see a language that feels like a static language that has
borrowed all the best features of Lisp. This makes it attractive as a more
general programming language. A language like C makes a good application
programming language. But try writting an expert system in it. Conversely,
Lisp is a great language to write AI type programs in. But try writing a
word processor with it. It would be just as easy to write a word processor
in Dylan as it is to do in C. And it would be just as easy to write an
expert system in Dylan as it is in Lisp.
In many respects, Lisp is a superior general programming language than
C/C++. One example is the exception handling system, which provides a more
powerful model for handling recoverable errors (those that don't terminate
the application) than C/C++. I have built large database style applications
having very high reliability and recovery characteristics using the Lisp
condition system. Sure, the core of these systems was an AI system, but the
reason the were useable was high reliability/recovery. The power of the
Lisp condition system was the main reason it was economically feasible to
put these characteristics into these applications.
My general observation has been that C/C++ apps don't try to include good
error recovery into apps unless it's absolutely critical. More often, the
application tries to terminate gracefully and puts the recovery burden on
the user. The reason is cost. It's quite a bit of work to put good error
recovery into a C/C++ app.
Lisp has its downsides as a general purpose programming language, such as
image footprint. I no longer build systems for small numbers of well paying
customers who can buy Sparcstations, and instead develop shrink-wrapped
MS-Windows software. It's built in C++, for reasons such as image footprint
size. But to conclude that Lisp is an AI programming language without
significant advantages for general purpose programming is incorrect.
My hope, of course, is that Dylan will be able to eliminate some these
downsides while retaining the advantages of Lisp. If the Lisp vendors can
do it also, great! By the way, the Dylan manual has an excellent writeup on
exception handling.
--Jon Degenhardt
DocuMagix Inc.
From: Shriram Krishnamurthi
Subject: Re: A Dylan implemented on Common Lisp
Date:
Message-ID: <3jttuf$rjq@larry.rice.edu>
········@keps.com (Geoffrey Clements) writes:
> When you ask people what they are using Lisp for, most answer with
> some form of AI problem.
That's indeed a difficulty: with people, not with the language. I
suspect many such responses come from people who aren't themselves
frequent Lisp programmers (such as the people that write
survey-of-programming-languages textbooks, and the people who believe
those books).
> I'd really like to see it. Especially systems programming
> examples. Give enough detail so that I can see why using Lisp is
> better than using say C.)
Much of the traffic of any program -- including a "systems" program --
has to do with maintaining data structures, defining abstractions, and
handling control. In each of these, a language like Lisp or Scheme is
virtually unmatched. Automatic memory management of data structures
is a big win. First-class functions (closures, really) are too. And
so are continuations, engines, catch/throw and so forth. In addition,
you get type safety, which is a *huge* win over C. Finally, if you
want to provide "extended languages" to your users, hygenic macros are
done better nowhere else.
Much of the difficulty in writing a word processor, say, in a Lisp-ish
language is having access to the underlying system. This a problem
because the underlying systems -- themselves usually written in
something like C -- need to be interfaced with. Simple libraries
usually solve this problem effectively. For instance, at Rice, we
have implemented an interface to X using Chez Scheme's foreign
procedure interface; a few hundred lines of mostly repetitive
type-definition code, and the programmer never sees the underlying X
system now. GNU Emacs's Elisp is a good example of what such a system
might look like (though itself very far from ideal). To see how far
you could go if you do* have easy access to the underlying system,
take a look at most any Lisp Machine. I don't believe we've still
matched some of the functionality of those systems in our contemporary
interfaces.
'shriram
From: Dave Yost
Subject: Lisp Machine considered paragon
Date:
Message-ID: <3k1h7m$ir@Yost.com>
In article <··········@larry.rice.edu>,
Shriram Krishnamurthi <·······@europa.cs.rice.edu> wrote:
>········@keps.com (Geoffrey Clements) writes:
>
>To see how far
>you could go if you do* have easy access to the underlying system,
>take a look at most any Lisp Machine.
You know, we hear this a lot.
Yet my guess is that about 17 people worldwide
who haven't already done this will do so sometime in the future.
Is there a good survey article on the web somewhere you can
point people to instead of making rhetorical exhortations?
A book on the subject would be a very good thing.
It could be subtitled:
"The UNIX Hater's Manual Companion: A Better Way"
Dave Yost
@ .com
····@Yost.com (Dave Yost) writes:
> Is there a good survey article on the web somewhere you can
> point people to instead of making rhetorical exhortations?
These aren't "rhetorical exhortations". These are statements made
from personal experience, from reading papers that have talked about
these things, and from discussions with people who have spent many
years working on such machines.
> A book on the subject would be a very good thing.
> It could be subtitled:
> "The UNIX Hater's Manual Companion: A Better Way"
Guess what? There's a book with almost this very title. I haven't
read it yet, but from the excerpts I've seen, it seems to very much be
of this spirit. Take a look at
http://www.research.microsoft.com/research/analysts/daniel/unix-haters.html
It's The UNIX-HATERS Handbook [sic], by Simson Garfinkel, Daniel Weise
and Steve Strassmann.
'shriram
From: Dave Yost
Subject: Re: Lisp Machine considered paragon
Date:
Message-ID: <3k30n9$nb@Yost.com>
In article <··········@larry.rice.edu>,
Shriram Krishnamurthi <·······@asia.cs.rice.edu> wrote:
>····@Yost.com (Dave Yost) writes:
>
>> Is there a good survey article on the web somewhere you can
>> point people to instead of making rhetorical exhortations?
>
>These aren't "rhetorical exhortations". These are statements made
>from personal experience, from reading papers that have talked about
>these things, and from discussions with people who have spent many
>years working on such machines.
I meant exhorting people to go and sit down at a Lisp Machine,
an act which is far too hard to accomplish.
>> A book on the subject would be a very good thing.
>> It could be subtitled:
>
>> "The UNIX Hater's Manual Companion: A Better Way"
>
>Guess what? There's a book with almost this very title. I haven't
>read it yet, but from the excerpts I've seen, it seems to very much be
>of this spirit.
The title I suggest is intentionally derivitave of
"The UNIX Hater's Manual"
which is a great book, a great catharsis, a warning to present
and future system designers that a similar polemic fate awaits them.
My first impulse was
"The UNIX Hater's Manual Answer Book"
Dave Yost
@ .com
In article <·········@Yost.com>, Dave Yost <····@Yost.com> wrote:
>
>I meant exhorting people to go and sit down at a Lisp Machine,
>an act which is far too hard to accomplish.
that's for sure. i've read in many places how lisp machines are/were
extraordinary, and i'd love to see one. better yet, i'd like to see
someone using one---a fancy interface is worthless if all it does is
look good.
-matt
--
http://www.rme.com/
In article <··········@larry.rice.edu>, ·······@asia.cs.rice.edu (Shriram
Krishnamurthi) wrote:
> Guess what? There's a book with almost this very title. I haven't
> read it yet, but from the excerpts I've seen, it seems to very much be
> of this spirit. Take a look at
>
> http://www.research.microsoft.com/research/analysts/daniel/unix-haters.html
>
> It's The UNIX-HATERS Handbook [sic], by Simson Garfinkel, Daniel Weise
> and Steve Strassmann.
>
> 'shriram
I have read it. One of the first tidbits in the book is an email from
someone who is forced to give up his Lisp machine for a Sun UNIX
workstation. He really liked his Sun because it booted really fast in
comparison to his Lisp Machine. In fact the Sun would spontaneously boot
itself just to remind you of how fast it could boot. B-) The book is
hilarious. Well worth the money. It even comes with it's own UNIX barf
bag.
geoff
>>>>> "Geoffrey" == Geoffrey Clements <········@keps.com> writes:
Geoffrey> In article <··········@larry.rice.edu>,
Geoffrey> ·······@asia.cs.rice.edu (Shriram Krishnamurthi) wrote:
>> Guess what? There's a book with almost this very title. I
>> haven't read it yet, but from the excerpts I've seen, it seems
>> to very much be of this spirit. Take a look at
>>
>> http://www.research.microsoft.com/research/analysts/daniel/unix-haters.html
>>
>> It's The UNIX-HATERS Handbook [sic], by Simson Garfinkel,
>> Daniel Weise and Steve Strassmann.
>>
>> 'shriram
Geoffrey> I have read it. One of the first tidbits in the book is
Geoffrey> an email from someone who is forced to give up his Lisp
Geoffrey> machine for a Sun UNIX workstation. He really liked his
Geoffrey> Sun because it booted really fast in comparison to his
Geoffrey> Lisp Machine. In fact the Sun would spontaneously boot
Geoffrey> itself just to remind you of how fast it could boot. B-)
Geoffrey> The book is hilarious. Well worth the money. It even
Geoffrey> comes with it's own UNIX barf bag.
Geoffrey> geoff
This is a true story, honest. I bought this book sometime last year &
had it in my car when I was driving down to Cincinnatti with my
wife. My wife was pregnant at that time & actually put the `barf bag'
that came along with the book to good use. Of course she doent know
Unix, (let alone Lisp machines) but felt that a nerdy book with a barf bag
was a neat idea all the same.
Anyhow the book is fairly entertaining if you dont begin to take it
too seariously. I guess you got to be kidding yourselves if you
believed that the Lisp machines were going to take over the world (no
flames please).
--
Ganesh Kumar,
Ford Motor Company,
Powertrain Electronics Development,
MS #74, POEE Building,
21500 Oakwood Blvd., 1 313 594 2594 (w)
Dearborn, MI 48121. ·····@pt9498.ped.pto.ford.com
In article <··········@larry.rice.edu> ·······@asia.cs.rice.edu (Shriram Krishnamurthi) writes:
It's The UNIX-HATERS Handbook [sic], by Simson Garfinkel, Daniel Weise
and Steve Strassmann.
"[sic]" [sic]. UNIX-HATERS is the name of the mailing list on which
the book is based. There is nothing wrong with the title.
From: Shriram Krishnamurthi
Subject: Re: A Dylan implemented on Common Lisp
Date:
Message-ID: <3k5jdp$4gs@larry.rice.edu>
·····@neves.ils.nwu.edu (David Neves) writes:
> It is easy for the user to write this manipulation code as well --
> you don't have to be an expert in parsers. The Lisp READ function
> does the parsing for you.
To pick a nit: this isn't really true. I view a parser as being able
to tell me (a) that a piece of code is well-formed, and (b) some
information about the bindings (in a lexically-scoped language) --
particularly the former. READ will do neither for me: I could READ
(assuming LET hasn't been re-bound)
(let (x y z))
without complaint. (Oh, maybe this means something in some Lisp
implementation. I think you get my point, though.)
This is complicated by macros: you need a macro expander which has
certain characteristics to be able to reasonably manipulate code.
In summary, yes, READ is a powerful tool, but it's a reader, not a
parser. Hence the name.
'shriram
···@CS.CMU.EDU (Scott Fahlman) writes:
> Not exactly true. The over-riding concern of the people designing
> Common Lisp was to come up with a design that N different groups, all
> with different agendas and different existing implementations, could
> agree on. Keeping small crocks and kludges in the language was very
> often the price for keeping some group or other from jumping off the
> bandwagon. I am sure that any one of the major Common Lisp designers
> could have designed a more elegant and beautiful Lisp dialect, but
> then it would not have been common. The result is a language that
> served an important purpose for many years (and continues to do so,
> though it's fading a bit) but that not even its mother could love.
> Like the camel, Common Lisp is a horse designed by committee. Camels
> do have their uses.
Sounds *exactly* like C++ and the process that turned C into it.
From: Jeff Dalton
Subject: Re: A Dylan implemented on Common Lisp
Date:
Message-ID: <D577F5.1H7@cogsci.ed.ac.uk>
In article <··········@hoult.actrix.gen.nz> ·····@hoult.actrix.gen.nz (Bruce Hoult) writes:
>···@CS.CMU.EDU (Scott Fahlman) writes:
>> Not exactly true. The over-riding concern of the people designing
>> Common Lisp was to come up with a design that N different groups, all
>> with different agendas and different existing implementations, could
>> agree on.
That was not the over-riding concern when I was a member of X3J13.
At least it was not my over-riding concern. Perhaps it was the over-
riding concern of some other members, such as Scott and the other
folk now working on Dylan. If so, that says more about them than
about Common Lisp.
>> Keeping small crocks and kludges in the language was very
>> often the price for keeping some group or other from jumping off the
>> bandwagon.
I haven't seen Scott's original message yet, but does he actually
list any of these crocks and kludges?
You know, crocks and kludges are crocks and kludges regardless
of why they were put in the language. Scott would like us to
think Common Lisp is a poor language because the design process
involved discussions among a number of people and -- heaven
forbid -- actual votes. But in fact, Common Lisp is a poor
language only if its properties as a language make it poor.
Let's see the Dylan-based attackers deal with the actual
properties of the language rather than engaging in innuendo
about the design process.
-- jd
From: Andrew Dinn
Subject: Re: A Dylan implemented on Common Lisp
Date:
Message-ID: <D584q4.2E8@cee.hw.ac.uk>
Jeff Dalton (····@aiai.ed.ac.uk) wrote:
: You know, crocks and kludges are crocks and kludges regardless
: of why they were put in the language. Scott would like us to
: think Common Lisp is a poor language because the design process
: involved discussions among a number of people and -- heaven
: forbid -- actual votes. But in fact, Common Lisp is a poor
: language only if its properties as a language make it poor.
: Let's see the Dylan-based attackers deal with the actual
: properties of the language rather than engaging in innuendo
: about the design process.
I can attack Common Lisp without defending Dylan. Common Lisp almost
killed of lisp application development because i) the fact that it is
such a fat language (thanks to all those proponents of {Mac, Inter,
Franz, Zeta, Foo, Bar, ...}Lisp who wanted all their favourite
features retained) combined with ii) the fact that all this fat
functionality was not layered as a series of libraries included as and
when you need them. The consequence of Common Lisp being defined as a
ball of mud was that a full Common Lisp implementation required, circa
1988, about 12 Mb of VMem before you even started defining your own
functions.
If you add on top of this the overheads for CLOS (which is also not
layered and hence made Common Lisp an even bigger ball of mud) then
you can change thet 12 Mb to 20 Mb.
*Circa 1988* those were big numbers, hence the death of Common
Lisp. They still are quite big, actually.
C does not have these problems (remember that Unix Labs proverb
'Language design is library design; and vice versa'). C++, with its
current template technology does have such problems - templates are
still a crock - but it's not as bad as the mess in Common Lisp. If
Dylan can avoid falling into this pit then it might have a chance.
Remember C may be a bitch to program it can be made to run lean and
fast on cheap hardware and most developers think the cost is just the
salaries of a few good (cheap) C hackers i.e. it answers their
priority numero uno and they cannot see the drawbacks. Common Lisp and
CLOS may be better to program in, more elegant, safer, reusable
etc. but it is never going to run lean and will only be fast on
expensive hardware (don't quote me benchmarks for tak, think about
cache/real memory residence and paging overheads) and will require use
of either expensive or inexperienced programmers.
Andrew Dinn
-----------
O alter Duft aus Maerchenzeit / Berauschest wieder meine Sinne
Ein naerrisch Heer aus Schelmerein / Durchschwirrt die leichte Luft
In article <··········@cee.hw.ac.uk>, ······@cee.hw.ac.uk (Andrew Dinn) wrote:
> If you add on top of this the overheads for CLOS (which is also not
> layered and hence made Common Lisp an even bigger ball of mud) then
> you can change thet 12 Mb to 20 Mb.
I don't know what system you're talking about, but MCL only takes up about
2-3 MB even with CLOS, an entire optimizing *compiler*, and all the
Macintosh interface glue.
> Remember C may be a bitch to program it can be made to run lean and
> fast on cheap hardware and most developers think the cost is just the
> salaries of a few good (cheap) C hackers i.e. it answers their
> priority numero uno and they cannot see the drawbacks. Common Lisp and
> CLOS may be better to program in, more elegant, safer, reusable
> etc. but it is never going to run lean and will only be fast on
> expensive hardware (don't quote me benchmarks for tak, think about
> cache/real memory residence and paging overheads) and will require use
> of either expensive or inexperienced programmers.
Programmer salaries are much more expensive than hardware.
An inexperienced Lisp programmer is generally more productive than
an inexperienced C programmer.
Maintenence of C programs is a killer.
--Rob.
In article <·······················@slip-2-32.ots.utexas.edu>,
······@cs.utexas.edu (Rob Browning) wrote:
> Programmer salaries are much more expensive than hardware.
True. But most companies are willing to let a programmer flounder around
on a crappy old piece of hardware than buy new stuff all the time. His/her
salary is going to show up either way but buying hardware is a capital
expenditure. B-)
geoff
In article <·······················@slip-2-32.ots.utexas.edu>
······@cs.utexas.edu "Rob Browning" writes:
> In article <··········@cee.hw.ac.uk>, ······@cee.hw.ac.uk (Andrew Dinn) wrote:
>
> > If you add on top of this the overheads for CLOS (which is also not
> > layered and hence made Common Lisp an even bigger ball of mud) then
> > you can change thet 12 Mb to 20 Mb.
>
> I don't know what system you're talking about, but MCL only takes up about
> 2-3 MB even with CLOS, an entire optimizing *compiler*, and all the
> Macintosh interface glue.
Whereas to develop with Visual C++ 2.0 under NT 3.5 you _really_ need 24Mb.
I have 20Mb and it shows. Would take Common Lisp anyday, given the choice.
--
Pete Ward
Mondas IT Ltd
In article <············@mondas.demon.co.uk>, ····@mondas.demon.co.uk wrote:
> In article <·······················@slip-2-32.ots.utexas.edu>
> ······@cs.utexas.edu "Rob Browning" writes:
>
> > In article <··········@cee.hw.ac.uk>, ······@cee.hw.ac.uk (Andrew
Dinn) wrote:
> >
> > > If you add on top of this the overheads for CLOS (which is also not
> > > layered and hence made Common Lisp an even bigger ball of mud) then
> > > you can change thet 12 Mb to 20 Mb.
> >
> > I don't know what system you're talking about, but MCL only takes up about
> > 2-3 MB even with CLOS, an entire optimizing *compiler*, and all the
> > Macintosh interface glue.
>
> Whereas to develop with Visual C++ 2.0 under NT 3.5 you _really_ need 24Mb.
> I have 20Mb and it shows. Would take Common Lisp anyday, given the choice.
> --
I mostly agree with you. However ...
There _is_ a difference here that changes the perception of the problem.
Lisp does not make a clean separation of the modes(?) of software
development, i.e. compilation, linking, execution, and debugging. In
Lisp, all these steps are mixed together in a single environment (which is
one of the strengths of Lisp). The classical languages, like C/C++,
separate execution from the other modes. So, even though it takes me 24MB
to develop a Visual C++ application, I can (easily?) deliver an
application requiring less than one MB. This means that the size, power,
... of the machines my users use can be significantly less than that for
the machines my developers use. If I am in an environment with hundreds
or thousands of users with varying combinations of old and new systems
this becomes a _big_ issue.
I think the ability of Dylan to deliver "Hello World" (a well-recognized
wholely unrealistic application) in an image that takes less than, say,
half a MB would go a long way toward creating a positive perception in the
marketplace of Dylan as a serious development language.
Chris
The above opinions are my own and not MITRE's.
Chris Reedy, Workstation System Engineering Center, Z667
The MITRE Corporation, 7525 Colshire Drive, McLean, VA 22102-3481
Email: ······@mitre.org Phone: (703) 883-7183 FAX: (703) 883-6991
······@mitre.org (Chris Reedy) writes:
[...]
>I think the ability of Dylan to deliver "Hello World" [...] in an
>image that takes less than, say, half a MB [would be a good thing].
This, in a few words, is what is wrong with compilers today.
--Pat "code bloat"
In article <··········@news.cs.brandeis.edu>, ·····@cs.brandeis.edu
(Patrick Tufts) wrote:
> ······@mitre.org (Chris Reedy) writes:
> [...]
>
> >I think the ability of Dylan to deliver "Hello World" [...] in an
> >image that takes less than, say, half a MB [would be a good thing].
>
> This, in a few words, is what is wrong with compilers today.
>
> --Pat "code bloat"
Apple was showing off Dylan at the MacWorld Expo last Jan. One of the
things they demonstrated was "Hello World" in a window.
The stand alone application was 58k.
In article <·······················@garges.ucsc.edu>,
Kenneth Garges <······@cats.ucsc.edu> wrote:
>In article <··········@news.cs.brandeis.edu>, ·····@cs.brandeis.edu
>(Patrick Tufts) wrote:
>
>> ······@mitre.org (Chris Reedy) writes:
>>
>> >I think the ability of Dylan to deliver "Hello World" [...] in an
>> >image that takes less than, say, half a MB [would be a good thing].
>>
>> This, in a few words, is what is wrong with compilers today.
>>
>Apple was showing off Dylan at the MacWorld Expo last Jan. One of the
>things they demonstrated was "Hello World" in a window.
>
>The stand alone application was 58k.
These demos are on develop CD #21.
The 'hello' application is 56K on disk, it has to load the Dylan
framework which is 524K, the main Dylan library 465K, the mac toolbox library
which is 57K. Time from double clicking the hello application on the hard
disk (I copied it all to the HD from the CD before running it) until 'Hello,
Dylan!' appears is 22 seconds on a PowerMac 8100/80. When looking at
'About this Macintosh' in the Finder it reveals that 'hello' is running
in a 2000K partition which is about 75% full.
The README states that all this will be improved upon, so who knows what
will be.
--- james mccartney
[James McCartney]
| The 'hello' application is 56K on disk, it has to load the Dylan
| framework which is 524K, the main Dylan library 465K, the mac toolbox
| library which is 57K. Time from double clicking the hello application
| on the hard disk (I copied it all to the HD from the CD before running
| it) until 'Hello, Dylan!' appears is 22 seconds on a PowerMac
| 8100/80. When looking at 'About this Macintosh' in the Finder it
| reveals that 'hello' is running in a 2000K partition which is about 75%
| full.
you may not recall that I tried to show the C fans that their "small
footprint" C programs actually incur shared libraries, memory allocation,
etc, on behalf of the program that rocket their 50K "disk image" into much
larger memory images, and enjoy special operating system support that other
languages will have to put in shared libraries. I guess the reason for the
confusion is that people can't differentiate "program" from "process".
programs sit on disk, processes run in memory. I think the latter is more
important than the former, as disk is still _way_ cheaper than RAM, so I
consider disk footprint to be red herring.
#<Erik>
--
miracle of miracles. look what the Net dragged in.
In article <·················@naggum.no> Erik Naggum <····@naggum.no> writes:
| you may not recall that I tried to show the C fans that their "small
| footprint" C programs actually incur shared libraries, memory allocation,
| etc, on behalf of the program that rocket their 50K "disk image" into much
| larger memory images, and enjoy special operating system support that other
| languages will have to put in shared libraries.
First of all, under Linux, a shared library "hello, world" program is
15k, a statically linked program is 43k.
Second, saying that there is "special operating system support" for C
is a misrepresentation. C libraries often have stub routines to make
OS calls using a non-C calling convention C compatible. That doesn't
take a lot of overhead in C, and it shouldn't take a lot of overhead
in any language.
OS interfacing does take a lot of code and reduce efficiency in
CommonLisp because CommonLisp isn't just content with interfacing with
the OS. Instead, it isolates the programmer from the OS.
| I guess the reason for the
| confusion is that people can't differentiate "program" from "process".
| programs sit on disk, processes run in memory. I think the latter is more
| important than the former, as disk is still _way_ cheaper than RAM, so I
| consider disk footprint to be red herring.
"hello, world" in C has a SIZE of 28kbytes and an RSS of 128kbytes
under Linux. By modern standards, that seems pretty modest. Of
course, much more space efficient implementations have existed in the
past.
Thomas.
In article <··········@cee.hw.ac.uk> ······@cee.hw.ac.uk (Andrew Dinn) writes:
I can attack Common Lisp without defending Dylan. Common Lisp almost
killed of lisp application development because i) the fact that it is
such a fat language (thanks to all those proponents of {Mac, Inter,
Franz, Zeta, Foo, Bar, ...}Lisp who wanted all their favourite
features retained) combined with ii) the fact that all this fat
functionality was not layered as a series of libraries included as and
when you need them. The consequence of Common Lisp being defined as a
ball of mud was that a full Common Lisp implementation required, circa
1988, about 12 Mb of VMem before you even started defining your own
functions.
If you add on top of this the overheads for CLOS (which is also not
layered and hence made Common Lisp an even bigger ball of mud) then
you can change thet 12 Mb to 20 Mb.
*Circa 1988* those were big numbers, hence the death of Common
Lisp. They still are quite big, actually.
C does not have these problems (remember that Unix Labs proverb
'Language design is library design; and vice versa'). C++, with its
current template technology does have such problems - templates are
still a crock - but it's not as bad as the mess in Common Lisp. If
Dylan can avoid falling into this pit then it might have a chance.
Remember C may be a bitch to program it can be made to run lean and
fast on cheap hardware and most developers think the cost is just the
salaries of a few good (cheap) C hackers i.e. it answers their
priority numero uno and they cannot see the drawbacks. Common Lisp and
CLOS may be better to program in, more elegant, safer, reusable
etc. but it is never going to run lean and will only be fast on
expensive hardware (don't quote me benchmarks for tak, think about
cache/real memory residence and paging overheads) and will require use
of either expensive or inexperienced programmers.
Right on, dude!
Fortunately, there are alternatives for those who like the
productivity and the parentheses but can't stand the size. Our
commercial product Ilog Talk has a minimum application overhead (on
most 32 bit machines) of 600k of code in a shared library and 400k of
dynamic data; we're looking to make it even smaller. This basic
library includes a full-featured Lisp runtime with a MOP-based object
system. Other libraries are also available.
For more information, check out our Web page at
<URL:http://www.ilog.com/> or write to ····@ilog.com.
-- Harley Davis
--
------------------------------------------------------------------------------
Harley Davis net: ·····@ilog.fr
ILOG S.A. tel: +33 1 46 63 66 66
2 Avenue Galli�ni, BP 85 fax: +33 1 46 63 15 82
94253 Gentilly Cedex, France url: http://www.ilog.com/
Ilog Talk information: ····@ilog.com
From: Jeff Dalton
Subject: Re: A Dylan implemented on Common Lisp
Date:
Message-ID: <D58KBE.s0@cogsci.ed.ac.uk>
In article <··········@cee.hw.ac.uk> ······@cee.hw.ac.uk (Andrew Dinn) writes:
>Jeff Dalton (····@aiai.ed.ac.uk) wrote:
>
>: You know, crocks and kludges are crocks and kludges regardless
>: of why they were put in the language. Scott would like us to
>: think Common Lisp is a poor language because the design process
>: involved discussions among a number of people and -- heaven
>: forbid -- actual votes. But in fact, Common Lisp is a poor
>: language only if its properties as a language make it poor.
>: Let's see the Dylan-based attackers deal with the actual
>: properties of the language rather than engaging in innuendo
>: about the design process.
>
>I can attack Common Lisp without defending Dylan.
I can attack Common Lisp too. Indeed, there are many things I
would rather were different. However, I've also found Common Lisp
to be a useful language, and many of the complaints we see on the
net get it wrong. For instance, you say:
> Common Lisp almost
>killed of lisp application development because i) the fact that it is
>such a fat language (thanks to all those proponents of {Mac, Inter,
>Franz, Zeta, Foo, Bar, ...}Lisp who wanted all their favourite
>features retained)
That's just false. Common Lisp is not a collection of favorite
features of random Lisp varieties. Common Lisp is very clearly
in the MacLisp branch of Lisp and is in line with the way that
branch was developing via LM-Lisp/ZetaLisp and various NILs.
If anything, it's a cleanup relative to ZetaLisp and MacLisp
(e.g. by having uniform scoping rules). Moreover, a number of
things that were in MacLisp or ZetaLisp were left out of Common
Lisp.
The "Common" in "Common Lisp" refers to commonality between various
MacLisp successors, not to all of Lisp. Indeed, the list of InterLisp
features that are not in Common Lisp is about as long as the list of
InterLisp features. (Where are the spaghetti stacks, DWIM, CLISP,
DEDIT, etc?) Franz Lisp, by the way, is basically MacLisp, and
there are no specifically Franz Lisp features in Common Lisp.
As for Foo, Bar, etc, tell me something that was put in Common Lisp
because of, say, PSL or Cambridge Lisp.
> combined with ii) the fact that all this fat
>functionality was not layered as a series of libraries included as and
>when you need them.
That much is ok, in part. But the implementations you usually
see are not the only ones possible. Common Lisp has been packaged
as a shared library (WCL), just for instance.
>The consequence of Common Lisp being defined as a
>ball of mud
You're either misunderstanding or misrepresenting how that phrase
is normally used. It does not mean everything is built-in rather
than in libraries. Indeed, for much of Lisp's history, a library
technology called autoloading was fairly common, as were libraries
that had to be explicitly requested (e.g. environment in Franz
Lisp).
> was that a full Common Lisp implementation required, circa
>1988, about 12 Mb of VMem before you even started defining your own
>functions.
Bull. I've used Common Lisp since 1985, and I've always been able
to use implementations that are smaller than that.
>C does not have these problems (remember that Unix Labs proverb
>'Language design is library design; and vice versa'). C++, with its
>current template technology does have such problems - templates are
>still a crock - but it's not as bad as the mess in Common Lisp.
I have less trouble w/ running out of swap space than the C++
programmers here do.
>Remember C may be a bitch to program it can be made to run lean and
>fast on cheap hardware [...] Common Lisp and
>CLOS may be better to program in, more elegant, safer, reusable
>etc. but it is never going to run lean and will only be fast on
>expensive hardware (don't quote me benchmarks for tak, think about
>cache/real memory residence and paging overheads)
It runs reasonably fast on my PC (given the speed of the PC).
If a 386 is expensive hardware, I wonder what you think is cheap.
>and will require use
>of either expensive or inexperienced programmers.
Sure, let's get rid of all the expensive programmers. Should
we kill them off or just let them die in the street once they
all lose their jobs?
-- jd
In article <·········@cogsci.ed.ac.uk>, Jeff Dalton <····@aiai.ed.ac.uk> wrote:
>In article <··········@cee.hw.ac.uk> ······@cee.hw.ac.uk (Andrew Dinn) writes:
>>
>>I can attack Common Lisp without defending Dylan.
>
>I can attack Common Lisp too. Indeed, there are many things I
>would rather were different.
Guys, we can *all* attack Common LISP; I've been doing it noisily for
years. But even I have at last come to the conclusion that if we kill
Common LISP now, we've probably killed LisP for all real world
commercial purposes. If you're happy to do that I can't stop you.
But I'd counsel you not, at least until we've got something which
suits us *as LisP hackers* to replace it with. Perhaps Dylan will be
that thing, but I'm suspicious of anything which moves *away* from
LisP syntax with the idea of making things better.
Simon
--
------- ·····@rheged.dircon.co.uk (Simon Brooke)
'graveyards are full of indispensable people'
From: John P. Flanagan
Subject: Re: A Dylan implemented on Common Lisp
Date:
Message-ID: <3jskca$q42@wstar.mil.wi.us>
······@cee.hw.ac.uk (Andrew Dinn) writes:
>I can attack Common Lisp without defending Dylan. Common Lisp almost
>killed of lisp application development because i) the fact that it is
>such a fat language (thanks to all those proponents of {Mac, Inter,
>Franz, Zeta, Foo, Bar, ...}Lisp who wanted all their favourite
>features retained) combined with ii) the fact that all this fat
>functionality was not layered as a series of libraries included as and
>when you need them. The consequence of Common Lisp being defined as a
>ball of mud was that a full Common Lisp implementation required, circa
>1988, about 12 Mb of VMem before you even started defining your own
>functions.
>If you add on top of this the overheads for CLOS (which is also not
>layered and hence made Common Lisp an even bigger ball of mud) then
>you can change thet 12 Mb to 20 Mb.
This is a tiresome argument, shared libraries solve this problem.
>*Circa 1988* those were big numbers, hence the death of Common
>Lisp. They still are quite big, actually.
Maybe it needs a kick in it's *big* behind, but Common Lisp is certainly
*not* dead. Granted, it's not cuddly and cute like Dylan is now, but
instead of delivering last rights, why not breath life into this new
standard by focusing on the handful of corrections needed to make Common
Lisp a mainstream delivery vehicle. We should be resolving all the
fixes needed for the next Common Lisp standard, not planning for a
funeral. Scott Falhman gave up on the process, not the language.
--
jpf.
Well, even unreconstructed paren-lovers can look forward to a new
language. I don't feel particularly personally threatened by a hopeful
new experiment, though I certainly have my crotchety preferences. Before
the weapons come out, however, it might be wise to remember the old saw:
"All babies are born beautiful."
Even CL had its sort of beauty, which was the possibility of a Lisp
dialect in a mainstream use, not just for AI labs. There was a good bit
of excitement surrounding the process of defining CL, along with the
inevitable ohmygawd recognitions of the necessity of making best choices
among ugly alternatives. That excitement carried on to an ANSI standard
and DOD approval, which may not be metrics of elegance, but certainly are
of serious intent.
Paul (longtime Lisp lurker, and former CL teacher)
-
--
Paul Weiss | Workstation TechTrans | Portland, OR
"Unix Workstation Engineering Training Specialists"
System Interface/TLI/Sockets/XDR/RPC/C/C++/Internals/Development
Methodology/Shell pgmg/SVR4/SunOS/MultiThread
From: Jeff Dalton
Subject: Re: A Dylan implemented on Common Lisp
Date:
Message-ID: <D5t237.D5B@cogsci.ed.ac.uk>
In article <··········@newsbf02.news.aol.com> ·········@aol.com (PaulWeiss) writes:
>Well, even unreconstructed paren-lovers can look forward to a new
>language. I don't feel particularly personally threatened by a hopeful
>new experiment, though I certainly have my crotchety preferences.
I like a number of different languages. Dylan isn't especially
interesting to me unless it becomes a practical alternative to C++.
Unfortunately, it's taking so long for Dylan to get going that
I'm not optimistic. Meanwhile, and also unfortunately, Dylan has
become another catalyst for criticism of Lisp.
> Before
>the weapons come out, however, it might be wise to remember the old saw:
>"All babies are born beautiful."
>
>Even CL had its sort of beauty, which was the possibility of a Lisp
>dialect in a mainstream use, not just for AI labs. There was a good bit
>of excitement surrounding the process of defining CL, along with the
>inevitable ohmygawd recognitions of the necessity of making best choices
>among ugly alternatives. That excitement carried on to an ANSI standard
>and DOD approval, which may not be metrics of elegance, but certainly are
>of serious intent.
Common Lisp is not as bad as people like to suggest. In many ways,
it's a cleaner language than the major Lisps that preceded it. The
idea that some earlier, nicer language was compromised by a process
of "design by committee" and political log-rolling does not really
hold up. (This is not, of course, to say that politics was not
involved.)
True, the language produced by X3J13 was more cluttered, with more
odd corners and byways, than the language of CLtL I. But it was
also better in many ways as well. Anyone who could start over would
clean things up in various ways, but when we look at the resulting
languages (chiefly EuLisp and Dylan), a great deal has been retained.
Indeed, I was noticed this strongly when reading the Dylan Interim
reference manual. There was more of Common Lisp than I'd expected,
and, apart from the syntax, the differences were just the sort I'd
expect in a post-CL Lisp: more thoroughly integrated object system;
no eval; modules; things to help compilation (sealing); less emphasis
on support for redefinition; object-oriented iteration; simplified,
generalized and more OO treatment of "sequences".
-- jd
From: Scott McLoughlin
Subject: Re: A Dylan implemented on Common Lisp
Date:
Message-ID: <gw3T2c2w165w@sytex.com>
···@wstar.mil.wi.us (John P. Flanagan) writes:
> instead of delivering last rights, why not breath life into this new
> standard by focusing on the handful of corrections needed to make Common
> Lisp a mainstream delivery vehicle. We should be resolving all the
> fixes needed for the next Common Lisp standard, not planning for a
> funeral. Scott Falhman gave up on the process, not the language.
> --
> jpf.
Howdy,
This sounds like a very reasonable suggestion to me. Lisp is a
wonderful language. I don't think that being the best bit
twiddler is a prerequisite for being a popular, general purpose
language. Lisp has been around long enough that lisp vendors
and users should have a pretty good idea of where it comes
up short, how it might be tweaked to compensate for these
short comings, how it might be modularized or layered, how
it might better interact with popular host operating systems,
etc.
=============================================
Scott McLoughlin
Conscious Computing
=============================================
[no crosspost, but just to comp.lang.lisp]
> Maybe it needs a kick in it's *big* behind, but Common Lisp is certainly
> *not* dead. Granted, it's not cuddly and cute like Dylan is now, but
> instead of delivering last rights, why not breath life into this new
> standard by focusing on the handful of corrections needed to make Common
> Lisp a mainstream delivery vehicle. We should be resolving all the
> fixes needed for the next Common Lisp standard, not planning for a
> funeral. Scott Falhman gave up on the process, not the language.
Common Lisp is far from dead, though it certainly isn't used nearly
as widely as we all hoped it would. I agree a big issue is
the size and speed for delivered applications to compete with C.
I agree with the idea that its better to start small, and add things,
rather than start big and remove things. So instead of tree shaking,
I think a well-defined CL-subset is required, one that
will *insure* that you get a small-footprint if only the subset is used.
Obviously no compiler, no eval, no run-time intern, maybe not even
have symbols at all!
Libraries might be defined for large free-standing utilities,
such as sorting,hashtables,bit-vectors,etc, though at some point,
just use full Common Lisp.
The key is to have the subset standardized so all vendors support it,
and thus developers are sure to get what they expect when delivery
time comes.
Someone has done some or a lot of this subset work. I forget who,
but I think it was something called CL/0 done by a group outside
the USA, I remember because the code comments were not in english,
so i couldn't deal with it. Could these folks remind me?
-- [posting from my old address, the new one is ···@franz.com]
-Kelly Murray (···@prl.ufl.edu) <a href="http://www.prl.ufl.edu">
-University of Florida Parallel Research Lab </a>
···@prl.ufl.edu (Kelly Murray) writes:
# I think a well-defined CL-subset is required, one that
# will *insure* that you get a small-footprint if only the subset is used.
# Obviously no compiler, no eval, no run-time intern, maybe not even
# have symbols at all!
#
# Someone has done some or a lot of this subset work. I forget who,
# but I think it was something called CL/0 done by a group outside
# the USA, I remember because the code comments were not in english,
# so i couldn't deal with it. Could these folks remind me?
I believe you're talking about the APPLY project and CL_0. You can
ftp the specification at:
··········@ftp.informatik.uni-kiel.de:/pub/kiel/apply/CL0.ps.Z
The basic idea is to remove reflective operations symbols.
--
Brent Benson
Concentra Corporation
From: Fernando Mato Mira
Subject: Re: A Dylan implemented on Common Lisp
Date:
Message-ID: <3k9tea$7q@disunms.epfl.ch>
In article <··········@no-names.nerdc.ufl.edu>, ···@prl.ufl.edu (Kelly Murray) writes:
> rather than start big and remove things. So instead of tree shaking,
> I think a well-defined CL-subset is required, one that
> will *insure* that you get a small-footprint if only the subset is used.
Given the amount of memory that people put in workstations
now, and how fat Unix and C++ apps have become, I think
that starting out with a 20Mb image is less of an issue
in this environments. The real things are:
1. CLOS should be able to approach the speed of C++
with appropriate declarations, freezing options, etc.
(fortunately for implementors,
lots of people are "post-incrementing" from C).
2. Using C libraries should be as easy as from C or C++
3. CLX either:
a. dies
b. it's actively supported so as not to lag behind
X developments and to be as efficient as the Xlibs
found in the different platforms.
c. It is reimplemented as a _thin_ abstraction
layer on top of Xlib.
4. Compilers catch up with upgraded microprocessor
architectures (eg: MIPS 4)
5. Lisp `multiprocessing' extensions take advantage of symmetric
multiprocessiong architectures and are made compatible
with POSIX extensions, so that a system can contain
shared memory processes written in other languages.
--
F.D. Mato Mira http://ligwww.epfl.ch/matomira.html
Computer Graphics Lab ········@epfl.ch
EPFL FAX: +41 (21) 693-5328
······@cee.hw.ac.uk (Andrew Dinn) wrote:
> The consequence of Common Lisp being defined as a
> ball of mud was that a full Common Lisp implementation required, circa
> 1988, about 12 Mb of VMem before you even started defining your own
> functions.
>
> If you add on top of this the overheads for CLOS (which is also not
> layered and hence made Common Lisp an even bigger ball of mud) then
> you can change thet 12 Mb to 20 Mb.
>
Er um, not quite: Allegro PC (1.0) image, including the "Ball of Mud" CLOS
and CommonGraphics as well as few implementation functions
like editors, debugger, inspectors etc. is about 3Mb! I think you
should talk to your implementor rather than the language designers!
This tired old argument is wearing a bit thin by now, along with
the GC problem etc, try basing your arguments on observations rather
than dogma!
Some common-lisp implementations are fat, some are thin.
CLOS is part of the language definition now, not an overhead.
If you want a bare functional language (with parens) try Scheme,
then you can invent your own brand of fatness so as not to feel
left out.
Simon
From: Keith M. Corbett
Subject: Re: A Dylan implemented on Common Lisp
Date:
Message-ID: <2F64F456kmc@specialform.com>
In article <··········@xenon.bt-sys.bt.co.uk> Simon Beaumont wrote:
>Er um, not quite: Allegro PC (1.0) image, including the "Ball of Mud" CLOS
>and CommonGraphics as well as few implementation functions
>like editors, debugger, inspectors etc. is about 3Mb! I think you
>should talk to your implementor rather than the language designers!
Right on!
And Allegro CL for PC provides a nifty procedure for creating a runtime
image with provisions for removing specified classes and/or packages.
Of course the system removes development tools and eval.
(Reminds me of long nights spent trimming down a Lambda world dump.)
My current project takes output from the sgmls parser and builds document
collections based on HTML and Interleaf document chunks. Not a very big
app, but not tiny. Without trying very hard at all I've produced a 2.7mb image
that runs under the 250k LISP.EXE. This is without explicitly removing any
system packages or classes except the reader.
······@cee.hw.ac.uk (Andrew Dinn) writes:
> ....
> I can attack Common Lisp without defending Dylan. Common Lisp almost
> killed of lisp application development because i) the fact that it is
> such a fat language (thanks to all those proponents of {Mac, Inter,
> Franz, Zeta, Foo, Bar, ...}Lisp who wanted all their favourite
> features retained) combined with ii) the fact that all this fat
> functionality was not layered as a series of libraries included as and
> when you need them. The consequence of Common Lisp being defined as a
> ball of mud was that a full Common Lisp implementation required, circa
> 1988, about 12 Mb of VMem before you even started defining your own
> functions.
This memory hunger was surely more a matter of implementations than
of the language.
Poplog common lisp can run in under 4 Mbytes (and that includes the
VED editor and full Pop-11 compiler). I seem to recall that Procyon
common lisp was even more compact.
Aaron
---
--
Aaron Sloman, ( http://www.cs.bham.ac.uk/~axs )
School of Computer Science, The University of Birmingham, B15 2TT, England
EMAIL ········@cs.bham.ac.uk OR ········@bham.ac.uk
Phone: +44-(0)121-414-4775 Fax: +44-(0)121-414-4281
In article <··········@hoult.actrix.gen.nz>, ·····@hoult.actrix.gen.nz
(Bruce Hoult) wrote:
> Sounds *exactly* like C++ and the process that turned C into it.
Heh. Good analogy!
-Paul-
--
Paul R. Potts - Software Engineer - Fry Multimedia
······@frymulti.com - http://frymulti.com/~ppotts
From: Jeff Dalton
Subject: Re: A Dylan implemented on Common Lisp
Date:
Message-ID: <D5qxvM.MIG@cogsci.ed.ac.uk>
In article <·······················@198.11.57.140> ······@frymulti.com (Paul R. Potts) writes:
>In article <··········@hoult.actrix.gen.nz>, ·····@hoult.actrix.gen.nz
>(Bruce Hoult) wrote:
>
>> Sounds *exactly* like C++ and the process that turned C into it.
>
>Heh. Good analogy!
Not very. For instance, what played the part of C to Common Lisp's C++?
It can't be Lisp, because there were a number of different Lisps of
various sizes and shapes (many of them quite small, btw). MacLisp is
probably as close as you'll get, but then the move to Common Lisp
was not very like the process that turned C into C++.
-- jd
From: Christopher B. Browne
Subject: Re: A Dylan implemented on Common Lisp
Date:
Message-ID: <3klho2$hnb@ionews.io.org>
In article <··········@cogsci.ed.ac.uk>,
Jeff Dalton <····@aiai.ed.ac.uk> wrote:
>In article <·······················@198.11.57.140> ······@frymulti.com (Paul R. Potts) writes:
>>In article <··········@hoult.actrix.gen.nz>, ·····@hoult.actrix.gen.nz
>>(Bruce Hoult) wrote:
>>
>>> Sounds *exactly* like C++ and the process that turned C into it.
>>
>>Heh. Good analogy!
>
>Not very. For instance, what played the part of C to Common Lisp's C++?
This is the problem with analogies. They're tantalizing but too often
deceiving. I know some fellows who are into Optimal Control Theory
who love arguments, and particularly trashing arguments involving
analogies. "Apparently similar," the usual state of affairs, is a
whole different animal from (typically implied) "causally alike."
While I'd agree with the notion that one could draw parallels between
(say) C/C++ and Scheme/Common Lisp, there are a whole lot of parallels
that do *not* apply.
The development of the C "family" of languages was very different from
the development of the LISP "family" of languages, and it does not
make sense to try to analogize them into the same thing.
It would be one thing if there were some truly "deep" way in which
the developments were similar, but I just can't see that that is the
case.
--
Christopher Browne - ·······@io.org
Fatal Error: Found [MS-Windows] System -> Repartitioning Disk for Linux...
In article <·········@percy.cs.bham.ac.uk> ········@cs.bham.ac.uk (Aaron Sloman) writes:
From: ········@cs.bham.ac.uk (Aaron Sloman)
Newsgroups: comp.lang.dylan,comp.lang.lisp,comp.lang.lisp.mcl
Date: 3 Apr 1995 23:39:35 GMT
Organization: School of Computer Science, University of Birmingham, UK
Lines: 28
······@cee.hw.ac.uk (Andrew Dinn) writes:
> ....
> I can attack Common Lisp without defending Dylan. Common Lisp almost
> killed of lisp application development because i) the fact that it is
> such a fat language (thanks to all those proponents of {Mac, Inter,
> Franz, Zeta, Foo, Bar, ...}Lisp who wanted all their favourite
> features retained) combined with ii) the fact that all this fat
> functionality was not layered as a series of libraries included as and
> when you need them. The consequence of Common Lisp being defined as a
> ball of mud was that a full Common Lisp implementation required, circa
> 1988, about 12 Mb of VMem before you even started defining your own
> functions.
This memory hunger was surely more a matter of implementations than
of the language.
Poplog common lisp can run in under 4 Mbytes (and that includes the
VED editor and full Pop-11 compiler). I seem to recall that Procyon
common lisp was even more compact.
Not to speak of the wonderful Mac Common Lisp (nee Coral) which run
(in 1987) in <= 1Mb.
--
Marco Antoniotti - Resistente Umano
-------------------------------------------------------------------------------
Robotics Lab | room: 1220 - 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.
Bertholdt Brecht
From: Lee Schumacher
Subject: Re: A Dylan implemented on Common Lisp
Date:
Message-ID: <D53J7v.9oB@sybase.com>
In article <··········@cogsci.ed.ac.uk>, ····@aiai.ed.ac.uk (Jeff Dalton) writes:
|> In article <··········@cantaloupe.srv.cs.cmu.edu> ···@CS.CMU.EDU (Scott Fahlman) writes:
|> >
|> > If the CL->Dylan mapping isn't 100%, maybe we could
|> > push hard to get Dylan changed so it would be.
|> >
|> >Push all you like. It won't happen. Having a Dylan-in-CL for some
|> >transitional period is not a good enough reason to preserve all the
|> >accumulated small irritations that have built up in Lisp over the
|> >decades.
|>
|> Contrary to the impression created by Scott's anti-Lisp propaganda,
|> Common Lisp eliminated most of the small irritations that had built
|> up over the years. (E.g. interpreters using different scope rules
|> than compilers) Some of the remaining "small irritations" (e.g.
|> nil being false) are not universally considered irritations.
|> In any case, a Dylan-in-CL can handle nil vs #f (Scott's example),
|> as Schemes-in-CL have shown.
|>
|> Note that Scott Fahlman was one of the designers of Common Lisp
|> and had plenty of opportunities to eliminate any irritations that
|> irritated him.
|>
|> -- jd
I'm sorry, but you have no standing to criticize Fahlman here. First of
all, CL was largely design by commitee, and no one had any absolute power
over it. Secondly, if anyone did have that power it was Guy Steele, who
wrote the manual, and not Scott. Thirdly, Scott has devoted years of his
life to cmu cl, which is one of the most complete and robust lisps ever
seen and is free to all. Have you made even 1% of that contribution
to lisp world ? I don't think so. Finally, Dylan is not public domain -
its owned by Apple. He doesn't make the decisions, and the opinions
of the lisp world are not sufficiently important to affect them ...
Lee.
--
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ Lee Schumacher Sybase, inc. +
+ (510) 922-4861 2000 Powell St, 5th floor +
+ ··············@sybase.com Emeryville, CA 94608 +
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ "There is no standing still, there is only moving forward or +
+ moving backward." - Fujisawa Shuko +
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
From: Barry Margolin
Subject: Re: A Dylan implemented on Common Lisp
Date:
Message-ID: <3jjvpl$bvh@tools.near.net>
In article <··········@sybase.com> ········@sybase.com (Lee Schumacher) writes:
>all, CL was largely design by commitee, and no one had any absolute power
>over it. Secondly, if anyone did have that power it was Guy Steele, who
>wrote the manual, and not Scott.
Not to belittle Guy's efforts, I think it's appropriate to set the record
straight, since this is a common confusion. While Guy alone wrote CLtL (1
and 2), he didn't have any veto power. His role was to describe the
results of the committee work -- he was more like a reporter than an
author.
--
Barry Margolin
BBN Internet Services Corp.
······@near.net
From: Simon Brooke
Subject: In defence of jd (was: A Dylan implemented on Common Lisp)
Date:
Message-ID: <D583EE.6rM@rheged.dircon.co.uk>
In article <··········@sybase.com>, Lee Schumacher <········@sybase.com> wrote:
>In article <··········@cogsci.ed.ac.uk>, ····@aiai.ed.ac.uk (Jeff
>Dalton) writes:
(much excised)
>|> Note that Scott Fahlman was one of the designers of Common Lisp
>|> and had plenty of opportunities to eliminate any irritations that
>|> irritated him.
>|>
>|> -- jd
>
>I'm sorry, but you have no standing to criticize Fahlman here. First of
>all, CL was largely design by commitee, and no one had any absolute power
>over it. Secondly, if anyone did have that power it was Guy Steele, who
>wrote the manual, and not Scott. Thirdly, Scott has devoted years of his
>life to cmu cl, which is one of the most complete and robust lisps ever
>seen and is free to all. Have you made even 1% of that contribution
>to lisp world ? I don't think so.
Well, I do. Jeff was practically the lone advocate of the Common LISP
project on this of the pond, in the face of an initially quite hostile
european LisP community. He played a very important liaison role
between X3J13 and BSI IST/5/16, effectively acting as ambassador for
Common LISP; and consequently the widespread international acceptance
of the Common LisP standard is partly Jeff's doing. He's also put
quite a bit of work into EuLisp (and no doubt done a lot of other
important things which I don't know about).
It must be widely known by now that I *never* agree with Jeff about
*anything*, so you can take this as an unbiased account.
--
------- ·····@rheged.dircon.co.uk (Simon Brooke)
...but have you *seen* the size of the world wide spider?
From: Jeff Dalton
Subject: Re: In defence of jd (was: A Dylan implemented on Common Lisp)
Date:
Message-ID: <D5E3HL.21G@cogsci.ed.ac.uk>
In article <··········@rheged.dircon.co.uk> ·····@rheged.dircon.co.uk (Simon Brooke) writes:
>In article <··········@sybase.com>, Lee Schumacher <········@sybase.com> wrote:
>>In article <··········@cogsci.ed.ac.uk>, ····@aiai.ed.ac.uk (Jeff
>>Dalton) writes:
>
>(much excised)
>
>>|> Note that Scott Fahlman was one of the designers of Common Lisp
>>|> and had plenty of opportunities to eliminate any irritations that
>>|> irritated him.
>>
>>I'm sorry, but you have no standing to criticize Fahlman here. First of
>>all, CL was largely design by commitee, and no one had any absolute power
>>over it.
Sure, but some people had considerable influence. There are large
archives of e-mail, btw. It's possible to look and see what positions
various people took and what irritations they tried to eliminate.
Scott was reasonably happy with Common Lisp and defended it for a
long time. The CMU group in general was not known for complaining
about irritations.
>> Secondly, if anyone did have that power it was Guy Steele, who
>>wrote the manual, and not Scott. Thirdly, Scott has devoted years of his
>>life to cmu cl, which is one of the most complete and robust lisps ever
>>seen and is free to all.
But it's now unsupported.
>>Have you made even 1% of that contribution
>>to lisp world ? I don't think so.
No one needs "standing" in order to make a point.
It happens to be my view that Dylan has become a catalyst of sorts
for Lisp criticism and that it can be very damaging when some of the
people best able to defend Lisp seem to be attacking Lisp and Common Lisp
instead. That the CMU group has switched from Common Lisp to Dylan
is in itself very damaging. I'm not planning to suppress this view
just because some people will attack me for it.
I haven't seen the original of this article, evidently by Lee
Schumacher, so I don't know what else he may have said. If anything,
Lee Schumacher underestimates Scott Fahlman's contributions.
For instance, SPICE Lisp (the Lisp that with a new compiler and
other changes became CMU CL) provided much of the source code
used in a number of early CL implementations, whose existence
was one of the factors that gave CL some credibility. (I have,
FWIW, been an enthusiastic user of both SPICE Lisp and CMU CL.)
But this makes his criticisms of Common Lisp more damaging than
if they'd come from someone else. And these days, people often
say and think "Lisp" when what they're saying is actually true
only of Common Lisp or, indeed, only of certain CL implementations.
So this kind of criticism tends to damage Lisp as a whole, and
especially when it -- presumably unintentionally -- reinforces the
misinformation about CL that's posted from time to time, the damage
can be fairly great.
Now, Scott was one of the Common Lisp "Gang of 5". He was also in
X3J13. He was clearly one of the major figures in the development
of Common Lisp. And he was one of the chief defenders of Common
Lisp. Consider, for instance, his reaction to the Gabriel and Brooks
critique of Common Lisp (delivered at the 1984 ACM L&FP conference),
and his arguments against subsets (one of the ways people tried to
tame the size of Common Lisp).
He may well feel -- for good reasons -- that CL contains many
irritations. I'd have to agree, so some extent, since I composed a
list of CL "pitfalls" that was merged into the Comp.lang.lisp FAQ.
He may well feel -- again for good reasons -- that it's better to start
again without so much historical baggage. And again I'd have to
agree, to an extent, since I've been involved in some efforts to start
over (e.g. EuLisp).
But my attitude towards Common Lisp has been fairly constant. I
used to me more critical than Scott Fahlman, even though I've
spent much of my time defending CL. I have complained, for
instance, about the large size of implementations, which sometimes
seemed to require larger machines than the ones I had, while Scott
defended them. (CMU CL is, btw, an excellent, but very-large-footprint
implementation.) Now he seems to be more critical than I am,
and the difference between us seems to be greater.
-- jd
In article <··········@news.internex.net>,
····@rclsgi.eng.ohio-state.edu (Dave Yost) writes:
>> It would seem to me to be a very worthy university project to
>> build a portable Dylan implementation on top of Common Lisp.
>> Would someone please do it?
This may be common knowledge to others, and slightly off-the-mark from
the aim of this thread, but here's a snippet from one of Digitool's WWW
pages (http://www.digitool.com/MCL-best-secret.html):
> MCL (Macintosh Common Lisp), a best kept secret
>
> [stuff deleted]
>
> Some of the most exciting new software products are developed in MCL.
> These include Dylan, the new programming language, and SK8 ("HyperCard
> done right!").
Cheers,
-Dick
Dick Jackson ········@ibd.nrc.ca Institute for Biodiagnostics
Opinions are mine alone. National Research Council Canada, Winnipeg
"And I told him my dream was to live for all time
In some perfect refrain, like the man who wrote 'Danny Boy'."
- Joe Jackson, from the album _Night_Music_, 1994.
···@prl.ufl.edu (Kelly Murray) writes:
> If the CL->Dylan mapping isn't 100%, maybe we could
> push hard to get Dylan changed so it would be.
Aren't there features that are in Lisps that will *never* be in Dylan,
because of the runtime overhead? Isn't call/cc one such?
Dave Yost (····@rclsgi.eng.ohio-state.edu) wrote:
(you don't seem to have an email address that can be replied to)
: It would seem to me to be a very worthy university project to
: build a portable Dylan implementation on top of Common Lisp.
: Would someone please do it?
...
I've been thinking along the same lines, and would like to hear
from anyone who is also interested in seeing it happen.
...
---
My home page: ftp://ftp.netcom.com/pub/dd/ddyer/home.html
or try http://www.triple-i.com/~ddyer/home.html
--
---
My home page: ftp://ftp.netcom.com/pub/dd/ddyer/home.html
or try http://www.triple-i.com/~ddyer/home.html
In article <··········@news.internex.net>,
Dave Yost <····@rclsgi.eng.ohio-state.edu> wrote:
>It would seem to me to be a very worthy university project to
>build a portable Dylan implementation on top of Common Lisp.
>Would someone please do it?
Where did that From address come from? I'm ····@Yost.com
Dave