From: ············@wildcard.demon.co.uk (Martin Rodgers)
... Now
try to convince the hord of C++ programmers and the people that they
work for that Lisp can do some of the same things, and pay for itself.
Nah! I've done a lot of missionary work for Lisp over the years, but in
the future my missionary work will be on behalf of Dylan. Dylan has
avoided a few of Lisp's mistakes, and it starts out with fewer people who
think that they know what it is like and think they hate it.
Well, never mind that. What about the reviews that slag off Lisp or
Smalltalk for their "high cost"? Like the price, and the runtime
overhead? I know the reviewers are being unrealistic, using "Hello,
World" type examples, but they get away with it.
Well, my group at Carnegie Mellon has done as much as anyone to make a
professional quality Lisp affordable (free, in fact) and to improve Lisp
performance on typical Unix machines. Unfortunately, we never had quite
enough resources to get our system running on all the machines that
mattered and to clean up a few weak spots like our relatively primitve GC.
And now it's too late. On to the next challenge!
Most people base their expectations of Lisp on XLISP...
Maybe among the tiny-machine people you hang out with. Xlisp is not very
influential or well known around here.
Maybe you know C++ programmers who have different expectations?
I hope there are some, but I never hear from them.
Very few of the C++ programmers I know really like C++. Many are fervently
hoping something better will come along that they can actually use. So
Dylan has a shot with these folks. Lisp could have a shot too if we fixed
a bunch of problems and somehow got people to take a second look, but I
don't see that happening.
-- Scott
===========================================================================
Scott E. Fahlman Internet: ····@cs.cmu.edu
Principal Research Scientist Phone: 412 268-2575
School of Computer Science Fax: 412 681-5739
Carnegie Mellon University Latitude: 40:26:46 N
5000 Forbes Avenue Longitude: 79:56:55 W
Pittsburgh, PA 15213
===========================================================================
On 2 Aug 1994 04:56:56 GMT, ···@sef-pmax.slisp.cs.cmu.edu said:
> Well, my group at Carnegie Mellon has done as much as anyone to make
> a professional quality Lisp affordable (free, in fact) and to
> improve Lisp performance on typical Unix machines. Unfortunately,
> we never had quite enough resources to get our system running on all
> the machines that mattered and to clean up a few weak spots like our
> relatively primitve GC. And now it's too late. On to the next
> challenge!
This brings me to one point: what is Gwydion going to use as the
architecture-specific back end? I beg you to consider at least
allowing the gcc back end as an option; even if it offers lower
performance, it will give you dozens of architectures for free. Then,
once people on platform X have Gwydion up and running and are floored
by its beauty, they can work on squeezing every last cycle out of it.
I've been dying to try Python, but since there was never a solid port
to the i386, my Linux box never saw it.
I'm also worried about Gwydion's portability between Unixes. Even in
porting something as small as Mindy to Linux I had to tweak a few old
BSD constants to POSIX versions and change sigvec to sigaction.
Little things like aren't even worth mentioning, but in a product the
size of Gwydion they could add up to quite a royal pain.
I'm quite enthusiastic about Gwydion. Both my roommates want to
transfer to CMU for their grad studies so they can help get it out the
door ASAP :-)
-- Robert
········@mindspring.com (Robert Sanders) writes:
> This brings me to one point: what is Gwydion going to use as the
> architecture-specific back end? I beg you to consider at least
> allowing the gcc back end as an option; even if it offers lower
> performance, it will give you dozens of architectures for free. Then,
> once people on platform X have Gwydion up and running and are floored
> by its beauty, they can work on squeezing every last cycle out of it.
I'd agree with this. I'd go further and say that there should be an
option to output C as the assembler language. Really grotty, twisted,
unreadable C, but something that you can feed into a compiler and
forget about.
Most C compilers should be getting pretty robust to machine-generated C
by now, with all the CFront output that's been thrown at them in the
last five years.
Thousands of us are *still* compiling C++ that way.
-- Bruce
In article <··········@hoult.actrix.gen.nz> ·····@hoult.actrix.gen.nz (Bruce Hoult) writes:
Newsgroups: comp.lang.lisp,comp.lang.dylan
From: ·····@hoult.actrix.gen.nz (Bruce Hoult)
Date: Wed, 3 Aug 1994 17:55:02 +1200 (NZST)
References: <·····················@hrothgar.mindspring.com>
Lines: 20
Xref: thecourier.cims.nyu.edu comp.lang.lisp:3523 comp.lang.dylan:1695
········@mindspring.com (Robert Sanders) writes:
> This brings me to one point: what is Gwydion going to use as the
> architecture-specific back end? I beg you to consider at least
> allowing the gcc back end as an option; even if it offers lower
> performance, it will give you dozens of architectures for free. Then,
> once people on platform X have Gwydion up and running and are floored
> by its beauty, they can work on squeezing every last cycle out of it.
I'd agree with this.
This would certainly be a desired choice. Moreover the value added to
gcc (i.e. garbage collection facilities in the runtime) could benefit
the ProgLang community as a whole, giving them a mature back-end with
all the necessary bells and whistles.
Of course there is the "slight problem" of the FSF boycott of Apple :)
I'd go further and say that there should be an
option to output C as the assembler language. Really grotty, twisted,
unreadable C, but something that you can feed into a compiler and
forget about.
If this is what you want, you already have it. KCL/Ibuki/AKCL and GCL
do exactly that.
The problem is of course performance.
Most C compilers should be getting pretty robust to machine-generated C
by now, with all the CFront output that's been thrown at them in the
last five years.
Thousands of us are *still* compiling C++ that way.
You should compile Common Lisp, it is a much nicer way of life :-)
Happy Lisping
--
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
In article <··········@cantaloupe.srv.cs.cmu.edu>
···@sef-pmax.slisp.cs.cmu.edu writes:
> Nah! I've done a lot of missionary work for Lisp over the years, but in
> the future my missionary work will be on behalf of Dylan. Dylan has
> avoided a few of Lisp's mistakes, and it starts out with fewer people who
> think that they know what it is like and think they hate it.
A wise choice. I wouldn't bother trying to educate C programmers, anyway.
I certainly wouldn't feel a need to if I could avoid them, or compete
with them by using some other language. Maybe that'll be Dylan, but if
Smalltalk can't do it, then I doubt Lisp can.
Besides, C programmers hate Lisp's syntax even more than Smalltalk's. :-)
> Well, my group at Carnegie Mellon has done as much as anyone to make a
> professional quality Lisp affordable (free, in fact) and to improve Lisp
> performance on typical Unix machines. Unfortunately, we never had quite
> enough resources to get our system running on all the machines that
> mattered and to clean up a few weak spots like our relatively primitve GC.
> And now it's too late. On to the next challenge!
Yeah, like getting CMU CL to run for MS Windows, and then get it reviewed
in a mainstream development mag (MSJ, WinTech etc?). I bet most programmers
will never know about CMU CL, or be able to run it. I'm not criticising
CMU CL. I'm just saying that it won't help improve Lisp's reputation with
C programmers, and certainly not with the ones I know of.
> Most people base their expectations of Lisp on XLISP...
>
> Maybe among the tiny-machine people you hang out with. Xlisp is not very
> influential or well known around here.
These "tiny machines" are very popular and easy to find. I didn't say
XLISP was well known or influential at CMU. However, it is at most other
places, esp for those who use DOS and MS Windows. That might not sound
significant to you, but I'm not talking about a Unix community.
> Maybe you know C++ programmers who have different expectations?
> I hope there are some, but I never hear from them.
>
> Very few of the C++ programmers I know really like C++. Many are fervently
> hoping something better will come along that they can actually use. So
> Dylan has a shot with these folks. Lisp could have a shot too if we fixed
> a bunch of problems and somehow got people to take a second look, but I
> don't see that happening.
Obviously they've avoided the brainwashing that many C++ programmers
get from Microsoft. :-) Good luck to them. All the C++ programmers I
know use C++ inspite of what they think of it. Most of them use it simply
coz that's what Microsoft offers them. A few of them have tried using
alternatives, like Smalltalk or Actor, but they've been disappointed.
One of them has developed his own C-like language.
I agree that Dylan has a chance, but to compete with VC++ and VB, it'll
need to be damn good. Describing it as using ideas from Smalltalk and
Lisp might not work as well with some programmers as with others.
--
Future generations are relying on us
It's a world we've made - Incubus
We're living on a knife edge, looking for the ground -- Hawkwind
In article <············@wildcard.demon.co.uk> ············@wildcard.demon.co.uk (Martin Rodgers) writes:
>
> Very few of the C++ programmers I know really like C++. Many are fervently
> hoping something better will come along that they can actually use.
Obviously they've avoided the brainwashing that many C++ programmers
get from Microsoft. :-) Good luck to them. All the C++ programmers I
know use C++ inspite of what they think of it.
To make an analogy to video-cassette recorders: I know several people
who consider Betamax technology to be superior to VHS technology, but
most of them own a VHS anyway, and many have given up on their Betamax
entirely. Building a better mousetrap does not guarantee that the
world will beat a path to your door. If your goal is to make a better
language and provide people with an implementation, that's one thing;
if your goal is to get a significant fraction of the world to switch
over to your new language, that's another.
To put it in a more positive way, since we're all friends here: if you
come out with a wonderful new language and yet lots of people persist
in using the old one, that doen't prove that there's anything
technically wrong with your new language.
In article <················@butterball.odi.com>
···@odi.com "Dan Weinreb" writes:
> To put it in a more positive way, since we're all friends here: if you
> come out with a wonderful new language and yet lots of people persist
> in using the old one, that doen't prove that there's anything
> technically wrong with your new language.
Agreed. I'd be happy to use nothing but Lisp, but the demand is
for C++. In fact, it seems to be for VC++.
--
Future generations are relying on us
It's a world we've made - Incubus
We're living on a knife edge, looking for the ground -- Hawkwind