If a Lisp vendor does not allow distribution of the Lisp compiler with
runtimes, is there some other way to translate a special purpose programming
language to Lisp and execute the result? Could the result be made as fast as
C++ for handling large amounts of simple data?
I've been told not to continue considering Lisp, because of considerations
such as the above. I would like to have some good arguments available, just
in case I get a chance to argue in favor of Lisp again. The hardest point to
argue against is that the fastest Lisp, Allegro, does not allow distribution
of the compiler with runtimes, and the 2nd fastest Lisp, Xanalys, is several
times slower.
I'm omitting my name because one of my coworkers has a nasty habit of doing
global searches to see what each of us is posting about, and my name is
unique enough to be easy to search on. I don't have a blind box handy for
replies, so please post them. Thanks in advance.
·········@nosuchisp.com writes:
> If a Lisp vendor does not allow distribution of the Lisp compiler with
> runtimes, is there some other way to translate a special purpose programming
> language to Lisp and execute the result? Could the result be made as fast as
> C++ for handling large amounts of simple data?
>
I think that if you want native code compilation at some stage in the
process, then you need the compiler, so your choice is really either
to have the compiler or live with an interpreter. Of course the
interpreter may be faster than C++...
> I've been told not to continue considering Lisp, because of considerations
> such as the above. I would like to have some good arguments available, just
> in case I get a chance to argue in favor of Lisp again. The hardest point to
> argue against is that the fastest Lisp, Allegro, does not allow distribution
> of the compiler with runtimes, and the 2nd fastest Lisp, Xanalys, is several
> times slower.
>
There are other lisp systems which allow distributiion of the compiler
and can certainly be competitive in terms of performance. CMUCL is
often pretty good. As far as I'm aware none of the free systems
competes very well with the commercial ones in terms of overall
quality, support, completeness of implementation and number of
platforms supported, but this is only a problem if you need these
things. Significant commercial applications (yahoo store) have
been written using noncommercial lisps.
--tim
On 24 Oct 2000 10:27:59 +0100, Tim Bradshaw <···@tfeb.org> wrote:
>·········@nosuchisp.com writes:
>things. Significant commercial applications (yahoo store) have
>been written using noncommercial lisps.
Do you know what lisp was used for Yahoo store? O:-) Just curious...
//-----------------------------------------------
// Fernando Rodriguez Romero
//
// frr at mindless dot com
//------------------------------------------------
Fernando Rodr�guez <·······@must.die> writes:
> Do you know what lisp was used for Yahoo store? O:-) Just curious...
>
CLISP (at least this was true sometime in late 98, when Paul Graham
gave his LUGM talk on it)
--tim
In article <···············@tfeb.org>,
Tim Bradshaw <···@tfeb.org> wrote:
> Fernando Rodr�guez <·······@must.die> writes:
>
> > Do you know what lisp was used for Yahoo store? O:-) Just curious...
> >
>
> CLISP (at least this was true sometime in late 98, when Paul Graham
> gave his LUGM talk on it)
In my (limited) experience, CLISP is often fast enough. In the PC, well
optimized code often runs as fast compiled in CLISP as it does in Corman Lisp
(a machine-language compiler). Corman beats CLISP easily on sloppy code,
though...
Corman is also a very good option for Windows machines. It's not free, but
it's not very expensive either (at $200 it's just about $100 more than what i
want to spend now). Still, Roger Corman is very nice to allow you to use the
bare-bones character environment for free.
glauber
--
Glauber Ribeiro
··········@my-deja.com http://www.myvehiclehistoryreport.com
"Opinions stated are my own and not representative of Experian"
Sent via Deja.com http://www.deja.com/
Before you buy.
* glauber <··········@my-deja.com>
| In my (limited) experience, CLISP is often fast enough. In the PC, well
| optimized code often runs as fast compiled in CLISP as it does in Corman Lisp
| (a machine-language compiler). Corman beats CLISP easily on sloppy code,
| though...
CLISP is often good enough as long as you do not write any functions
of your own that implement any abstractions that require multiple
calls to user-land functions. CLISP's performance dichotomy between
its C-implemented compiled runtime functions and your byte-compiled
Lisp functions leads programmers to optimize at a low abstraction
level because they are penalized for their abstractions. This is
not a good thing for a Lisp environment, where we want to encourage
function calls and make abstractions as inexpensive as possible. We
don't want people _not_ to use Common Lisp because of performance
issues or to think that only built-ins are fast because they are
written in C. Approach CLISP as a good toy implementation of Common
Lisp, and move on to a real compiler if you ever plan to investigate
performance issues.
#:Erik
--
I agree with everything you say, but I would
attack to death your right to say it.
-- Tom Stoppard
>>>>> "en" == Erik Naggum <····@naggum.net> writes:
en> CLISP is often good enough as long as you do not write any
en> functions of your own that implement any abstractions that
en> require multiple calls to user-land functions.
en> Approach CLISP as a good toy implementation of Common Lisp, and
en> move on to a real compiler if you ever plan to investigate
en> performance issues.
I agree with your second statement, but don't see any justification
for the first, unless you implicitly assume that every programmer is
interested in performance on each problem. If I am not particularly
concerned about performance, I will not notice the slowdown from
user-defined functions, so I will not be discouraged from using
abstraction.
--
Eric Marsden <URL:http://www.laas.fr/~emarsden/>
* Eric Marsden <········@mail.dotcom.fr>
| I agree with your second statement, but don't see any justification
| for the first, unless you implicitly assume that every programmer is
| interested in performance on each problem. If I am not particularly
| concerned about performance, I will not notice the slowdown from
| user-defined functions, so I will not be discouraged from using
| abstraction.
This is a good point. I tend to stress that CLISP is not suitable
if your goal is performance, anyhow, so I should also argue that
it's good enough as long as you don't prioritize performance.
_However_, my experience is that even though you ignore performance
(as long as you get your answers within a reasonable amount of time),
a large number of programmers will want to know the "expensiveness"
of what they do and then soon discover that builtins in CLISP are
very fast (especially bignums) while their own code runs much, much
slower. Even if you ignore performance consciously, I don't think
you can completely ignore the effect of _observing_ that some things
are much faster than others even if you did not set out to find out
about this to begin with.
Hence my cautions. If you know about them and are aware of the
conditions under which CLISP is and is not good enough, I don't
think CLISP is a bad choice (as long as you use the ANSI mode with
the -a option, but that that's not the default is another gripe).
#:Erik
--
I agree with everything you say, but I would
attack to death your right to say it.
-- Tom Stoppard
In article <················@naggum.net>,
Erik Naggum <····@naggum.net> wrote:
[...]
> Hence my cautions. If you know about them and are aware of the
> conditions under which CLISP is and is not good enough, I don't
> think CLISP is a bad choice (as long as you use the ANSI mode with
> the -a option, but that that's not the default is another gripe).
Erik, i'm curious to know if you have a favorite among the free Unix Common
Lisp implementations.
glauber
--
Glauber Ribeiro
··········@my-deja.com http://www.myvehiclehistoryreport.com
"Opinions stated are my own and not representative of Experian"
Sent via Deja.com http://www.deja.com/
Before you buy.
* glauber <··········@my-deja.com>
| Erik, i'm curious to know if you have a favorite among the free Unix
| Common Lisp implementations.
When I looked around for Common Lisp environments back in late 1993
so I could program in a programming language instead of killing
myself with C++, I tried a number of languages, including Ada,
Smalltalk, Scheme and Common Lisp, all of which have reasonably good
free implementations. (MIT Scheme was excellent, but Scheme is one
of those languages that are OK only as long as you live in a dorm
room and are unaware that you will eventually want to buy a house.)
Common Lisp implementations included CLISP and CMUCL at the time and
CLISP was immature and nearly useless at the time, even worse than
KCL, which a friend got his hands on sometime in 1987. CMUCL has
been excellent all the time I have used it, but I was unimpressed
with the CLOS (PCL) performance and hence did not work a lot with
that part of CL until I got Allegro CL. I still have a complete
CMUCL system installed on my system and occasionally use it to
ensure that I know which parts of my code are portable to it, but I
no longer use it in any "production system" sense.
#:Erik
--
I agree with everything you say, but I would
attack to death your right to say it.
-- Tom Stoppard
In article <················@naggum.net>,
Erik Naggum <····@naggum.net> wrote:
> * glauber <··········@my-deja.com>
> | Erik, i'm curious to know if you have a favorite among the free Unix
> | Common Lisp implementations.
>
> When I looked around for Common Lisp environments back in late 1993
> so I could program in a programming language instead of killing
> myself with C++, I tried a number of languages, including Ada,
> Smalltalk, Scheme and Common Lisp, all of which have reasonably good
> free implementations. (MIT Scheme was excellent, but Scheme is one
> of those languages that are OK only as long as you live in a dorm
> room and are unaware that you will eventually want to buy a house.)
:-)
It's really nice, and it makes you reinvent the wheel each time, but hey,
it's so easy to reinvent the wheel in Scheme that many people don't care.
Some people apparently have a lot of free time.
> Common Lisp implementations included CLISP and CMUCL at the time and
> CLISP was immature and nearly useless at the time, even worse than
> KCL, which a friend got his hands on sometime in 1987. CMUCL has
> been excellent all the time I have used it, but I was unimpressed
> with the CLOS (PCL) performance and hence did not work a lot with
> that part of CL until I got Allegro CL. I still have a complete
> CMUCL system installed on my system and occasionally use it to
> ensure that I know which parts of my code are portable to it, but I
> no longer use it in any "production system" sense.
I downloaded CMUCL thinking maybe i could get it to compile for AIX and
Windows (the platforms i currently work in), but it looks like setting it up
is a daunting task.
CLISP has some pretty strange C source, but it compiled fine in AIX and had a
pre-made Windows binary. I'm glad for CLISP, because if it wasn't for it i
wouldn't have tried to learn Common Lisp (i'd probably be using some version
of Scheme instead). I think it's nice of Franz to let people have a limited
version of Allegro for free, but it's too limited for my needs and i'm just
not going to pay for the full system. So i guess i'll be using "CLISP -a" for
the time being until i have justification to buy a commercial system.
Incidentally, it seems that there's a lot more interest in developing free
Scheme systems than Lisp. I guess it's to be expected, since Scheme is
designed to be simple to implement.
glauber
--
Glauber Ribeiro
··········@my-deja.com http://www.myvehiclehistoryreport.com
"Opinions stated are my own and not representative of Experian"
Sent via Deja.com http://www.deja.com/
Before you buy.
On Thu, 26 Oct 2000 13:55:53 GMT, glauber <··········@my-deja.com> wrote:
>In article <················@naggum.net>,
> Erik Naggum <····@naggum.net> wrote:
>> * glauber <··········@my-deja.com>
>> | Erik, i'm curious to know if you have a favorite among the free Unix
>> | Common Lisp implementations.
>>
>> When I looked around for Common Lisp environments back in late 1993
>> so I could program in a programming language instead of killing
>> myself with C++, I tried a number of languages, including Ada,
>> Smalltalk, Scheme and Common Lisp, all of which have reasonably good
>> free implementations. (MIT Scheme was excellent, but Scheme is one
>> of those languages that are OK only as long as you live in a dorm
>> room and are unaware that you will eventually want to buy a house.)
>
>
>:-)
>
>It's really nice, and it makes you reinvent the wheel each time, but hey,
>it's so easy to reinvent the wheel in Scheme that many people don't care.
>Some people apparently have a lot of free time.
You're missing the point: Scheme was designed as a teaching and
investigation tool, not for "real world" programming. As a learning language
it has been far more successful that CL as a general purpose language. :-P
//-----------------------------------------------
// Fernando Rodriguez Romero
//
// frr at mindless dot com
//------------------------------------------------
In article <··································@4ax.com>, Fernando
Rodr?guez <·······@must.die> wrote:
> On Thu, 26 Oct 2000 13:55:53 GMT, glauber <··········@my-deja.com> wrote:
>
> >In article <················@naggum.net>,
> > Erik Naggum <····@naggum.net> wrote:
> >> * glauber <··········@my-deja.com>
> >> | Erik, i'm curious to know if you have a favorite among the free Unix
> >> | Common Lisp implementations.
> >>
> >> When I looked around for Common Lisp environments back in late 1993
> >> so I could program in a programming language instead of killing
> >> myself with C++, I tried a number of languages, including Ada,
> >> Smalltalk, Scheme and Common Lisp, all of which have reasonably good
> >> free implementations. (MIT Scheme was excellent, but Scheme is one
> >> of those languages that are OK only as long as you live in a dorm
> >> room and are unaware that you will eventually want to buy a house.)
> >
> >
> >:-)
> >
> >It's really nice, and it makes you reinvent the wheel each time, but hey,
> >it's so easy to reinvent the wheel in Scheme that many people don't care.
> >Some people apparently have a lot of free time.
>
> You're missing the point: Scheme was designed as a teaching and
> investigation tool, not for "real world" programming. As a learning language
> it has been far more successful that CL as a general purpose language. :-P
When is a general purpose language successful? How much
in software sales would that be for example?
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
On Thu, 26 Oct 2000 19:22:26 +0200, Rainer Joswig
<······@corporate-world.lisp.de> wrote:
>>
>> You're missing the point: Scheme was designed as a teaching and
>> investigation tool, not for "real world" programming. As a learning language
>> it has been far more successful that CL as a general purpose language. :-P
>
>When is a general purpose language successful? How much
>in software sales would that be for example?
Don't take me wrong, I like Cl and I hope that growing usage of scheme
in colleges will benefit CL: some of the students that were introduced to
scheme might turn to CL when looking for something more powerful.
//-----------------------------------------------
// Fernando Rodriguez Romero
//
// frr at mindless dot com
//------------------------------------------------
In article <··································@4ax.com>, Fernando
Rodr?guez <·······@must.die> wrote:
> On Thu, 26 Oct 2000 19:22:26 +0200, Rainer Joswig
> <······@corporate-world.lisp.de> wrote:
>
>
> >>
> >> You're missing the point: Scheme was designed as a teaching and
> >> investigation tool, not for "real world" programming. As a learning language
> >> it has been far more successful that CL as a general purpose language. :-P
> >
> >When is a general purpose language successful? How much
> >in software sales would that be for example?
>
> Don't take me wrong, I like Cl and I hope that growing usage of scheme
> in colleges will benefit CL:
Usage of Lisp at Schools/Colleges/Universities is **crucial** for
the success and survival of Lisp. This is the number one source for
contacts with Lisp technology (another being the
GNU/Linux/Free Software/Open Source movements).
> some of the students that were introduced to
> scheme
"Introduced to Scheme" doesn't mean they are doing something useful
(-> writing software that's being used by somebody) with it.
I have seen "academic exercises" ("write a routine that reverses a list" -
Common Lisp spoiled the party, since half of the exercises are
already standard in CL and many others got trivial).
So Scheme is often not taught as an introduction to "Scheme and
software development", but as an introduction to Computer Science
and as a kind of academic puzzle. CS students are often
not introduced to the idea that there is a customer for
the software, that he has a problem that has to be solved
and that he might have limited time and money.
> might turn to CL when looking for something more powerful.
Since often Scheme has not been used "useful", students later will
not look for Common Lisp, but for the obvious C++ and friends.
I think students take Common Lisp because they have to.
It is more of a tradtion question. Instructors often use Scheme
in basic courses and in their research projects Common Lisp
becomes an option. They can select the better students and
in multi-year, multi-university projects Common Lisp often is
(was?) a viable solution.
How could one make CL even more successful in Universities?
- all students should get access to the best Lisp environment around.
Many universities have site licenses for Lisp on their
Unix clusters. This should be extended to PCs/Macs/Linux/... .
- Enable application delivery in Lisp (it is technical possible,
but it needs to be painless -> costs? license? distribution options?
platforms? compiler distribution? downloading software?
application toolkits?), so students will learn that
writing APPLICATIONS in Lisp is a viable option.
- provide introductory material, so that students quickly can move on
from Scheme to CL. What are the differences to Scheme? The student
might have seen SICP, how does she apply this knowledge
to CL?
- follow research trends so that Lisp stays an option for research
projects
- somebody has to explain how to actually develop software with
Common Lisp, what the tools are and why they are the way they
are. Nice books were/are "LISP Style and Design" (Miller, Molly M.,
and Eric Benson, Digital Press, no longer available - sigh)
and "Lisp Lore: A Guide to Programming the Lisp Machine"
(Bromley/Lamson, still available I guess, but expensive).
Like somebody explained how one might develop software
using Smalltalk in a commercial environment (-> XP).
- make sure the Lisp software developed in Universities are
as accessible as possible for the public. Others might
want to use it or learn from it.
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
* Rainer Joswig <······@corporate-world.lisp.de>
| How could one make CL even more successful in Universities?
Many excellent points omitted, but I suspect one point was omitted
by accident:
- secure funding for all of the above.
#:Erik
--
Does anyone remember where I parked Air Force One?
-- George W. Bush
In article <················@naggum.net>,
Erik Naggum <····@naggum.net> wrote:
> * Rainer Joswig <······@corporate-world.lisp.de>
> | How could one make CL even more successful in Universities?
>
> Many excellent points omitted, but I suspect one point was omitted
> by accident:
Well, somehow. ;-)
> - secure funding for all of the above.
Quite a lot of Universities have site licenses for
commercial Lisp systems and those Lisp systems are
installed on the main computing clusters for general
usage. I guess Lisp companies want to see renewal
of the maintenance contracts? They might even
want to sell new major versions of their Lisp
systems? They might also want to sell support and licenses
to University-near research labs, spin-offs, start-ups?
How does a University justify spending money on Lisp?
Lisp has to be good for introductory courses (Computer Science,
AI, Music, Psychology, ...), for research projects, ...
What does the customer need to make successful usage out
of the Lisp system? As a Lisp vendor I might even make
sure the Lisp system's setup is done right on the computer
cluster and give them a package including out-of-the-box
documentation/tutorials that easily integrates into the
University's intranet.
Sent via Deja.com http://www.deja.com/
Before you buy.
Rainer Joswig <······@corporate-world.lisp.de> writes:
> Usage of Lisp at Schools/Colleges/Universities is **crucial** for
> the success and survival of Lisp. This is the number one source for
> contacts with Lisp technology (another being the
> GNU/Linux/Free Software/Open Source movements).
Well, whenever I mention Lisp, I get the same response, almost
word-for-word. "Lisp?! I had to learn that in college. Why would
you use that? It's slow and interpreted..." They might also toss in
that [Language X] is better because it is "object oriented".
--
vsync
http://quadium.net/ - last updated Sat Oct 7 18:53:10 PDT 2000
(cons (cons (car (cons 'c 'r)) (cdr (cons 'a 'o))) ; Orjner
(cons (cons (car (cons 'n 'c)) (cdr (cons nil 's))) nil))
vsync <·····@quadium.net> writes:
> Rainer Joswig <······@corporate-world.lisp.de> writes:
>
> > Usage of Lisp at Schools/Colleges/Universities is **crucial** for
> > the success and survival of Lisp. This is the number one source for
> > contacts with Lisp technology (another being the
> > GNU/Linux/Free Software/Open Source movements).
>
> Well, whenever I mention Lisp, I get the same response, almost
> word-for-word. "Lisp?! I had to learn that in college. Why would
> you use that? It's slow and interpreted..." They might also toss in
> that [Language X] is better because it is "object oriented".
There's a high probability that if you do some correlations, you
would find by coincidence that those who responded in that manner
are likely to have gone to a college which doesn't teach Lisp as
a programming language, but instead as an oddity - "Lisp is good with
recursions, so let's teach recursion in Lisp." - "Lisp is interactive,
so let's show this odd behavior in Lisp, and nevermind bothering with
the built-in compiler." It's this kind of teaching that breeds into
students the attitude that Lisp is not a language for real work, but
just an odd language for doing odd things inefficiently. (and yes,
Lisp is powerful enough that you can even do things as inefficiently
as you wish :-)
What is needed is for teachers to provide a vision for what Lisp
really is, and what it is good for, not just the ways in which it
is different than other languages.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
In article <····························@news.is-europe.net>,
Rainer Joswig <······@corporate-world.lisp.de> writes:
> How could one make CL even more successful in Universities?
You forgot the most important one: BAN "Intro to AI"!
Mike McDonald
·······@mikemac.com
In article <·····················@typhoon.aracnet.com>,
·······@mikemac.com wrote:
> In article <····························@news.is-europe.net>,
> Rainer Joswig <······@corporate-world.lisp.de> writes:
>
> > How could one make CL even more successful in Universities?
>
> You forgot the most important one: BAN "Intro to AI"!
>
> Mike McDonald
> ·······@mikemac.com
Why? Because they use Java for that nowadays?
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
In article <····························@news.is-europe.net>,
Rainer Joswig <······@corporate-world.lisp.de> writes:
> In article <·····················@typhoon.aracnet.com>,
> ·······@mikemac.com wrote:
>
>> In article <····························@news.is-europe.net>,
>> Rainer Joswig <······@corporate-world.lisp.de> writes:
>>
>> > How could one make CL even more successful in Universities?
>>
>> You forgot the most important one: BAN "Intro to AI"!
>>
>> Mike McDonald
>> ·······@mikemac.com
>
> Why? Because they use Java for that nowadays?
>
No, because it does the most harm to both CS students and Lisp, IMNSOHO. For
a lot of CS students, this is their only exposure to Lisp. The problems solved
in "Intro to AI" classes are so rinky dink as to turn the students off to both
AI and Lisp. If the class progresses really quickly, they might get to write a
Lisp program that plays tic-tac-toe by the end of the semester. In my
experience, they come away thinking Lisp is only good for wierd toy problems
and that AI is a joke.
Mike McDonald
·······@mikemac.com
In article <·····················@typhoon.aracnet.com>,
·······@mikemac.com wrote:
> In article <····························@news.is-europe.net>,
> Rainer Joswig <······@corporate-world.lisp.de> writes:
> > In article <·····················@typhoon.aracnet.com>,
> > ·······@mikemac.com wrote:
> >
> >> In article <····························@news.is-europe.net>,
> >> Rainer Joswig <······@corporate-world.lisp.de> writes:
> >>
> >> > How could one make CL even more successful in Universities?
> >>
> >> You forgot the most important one: BAN "Intro to AI"!
> >>
> >> Mike McDonald
> >> ·······@mikemac.com
> >
> > Why? Because they use Java for that nowadays?
> >
>
> No, because it does the most harm to both CS students and Lisp, IMNSOHO. For
> a lot of CS students, this is their only exposure to Lisp. The problems solved
> in "Intro to AI" classes are so rinky dink as to turn the students off to both
> AI and Lisp. If the class progresses really quickly, they might get to write a
> Lisp program that plays tic-tac-toe by the end of the semester. In my
> experience, they come away thinking Lisp is only good for wierd toy problems
> and that AI is a joke.
So let them use Java. ;-)
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
>>>>> "Rainer" == Rainer Joswig <······@corporate-world.lisp.de> writes:
Rainer> I think students take Common Lisp because they have to.
This is interesting. I wonder what a survey would show.
At my university (Ohio State), C++ is part of the requirement, and
Common Lisp is an option. Many students get through the entire
undergraduate program without ever writing a Common Lisp program.
"Programming in Common Lisp" is listed as 459.31 and a 459.xx is
required for graduation. Many people opt for the C, C++, or Java
versions of 459; some, primarily business students, opt for Cobol.
The 459s are focused on the languages themselves, not some other
problem domain where the language needs to be used for the
assignments.
Our 459.31 isn't highly popular. The first time I taught it two years
ago, by the second or third week of the term, roughly half of the
class was empty. Meanwhile, there were multiple sections of other
459s, with huge wait lists. The C, C++, and Java courses are taught
every quarter, while the Lisp course is taught only once per year.
The good news is that a fairly significant number of those who did
stick with it turned out really to like it and to want to continue
using it. That introduced another problem, in that there aren't other
courses where one can really use a lot of Lisp. The current
recommendation is that I point interested students in the direction of
the AI courses. In some sense, that contradicts most of what I had
been talking about all quarter: that Common Lisp really is a general
purpose language.
Last year, the enrollment in 459.31 was up, a significant number of
the students being there because their friends who had taken the
course the previous year recommended it. This time, even more
students -- both absolutely and relatively -- asked me about
continuing in the use of Lisp.
This year, I'm hoping that we'll fill the class completely. Students
are now talking about Lisp with each other and are using it on their
own. We have an open source club, a student group, with lots of
budding Lisp programmers. In fact, a series of three talks on Lisp is
being given this quarter to any students who will attend. The club is
buying pizza and soda for all comers, which is usually a pretty good
way to attract a significant following. I should add that this is all
the idea of the students in the club. Although I agreed to give the
third talk in the series, I didn't have any idea what was happening
until after the master plan was put together, with the speakers lined
up.
My company, Interhack, is also sponsoring a Lisp programming contest.
More correctly stated, it's a contest to create a version of decss.c
that will be understood by CMU CL but also convey something to the
human reader. In any case, we're offering $250, $100, and $50 cash
prizes, which also seems to be a good way to stir up some more
interest.
And of course, word being out that we're looking for clueful student
Lisp programmers doesn't seem to hurt. :-)
I'm guessing that Rainer's statement about students taking Lisp
because they're required is largely true, perhaps even generally true.
However, there are places -- at least one, but I would also guess
there are others -- where the opposite is true. They're taking C++
because they must and using Lisp when they want to do something
productive or fun.
I think getting a survey that shows what the different camps are at
universities and in what proportions they're to be found. (Actually
taking the survey would probably be difficult, though, because at
least in our case, if you ask the people you'd think that it would
make sense to ask, you'll get a view of the world that agrees with the
curriculum more than what largish-and-growing groups of students are
doing in their free time...)
--
Matt Curtin, Founder Interhack Corporation http://www.interhack.net/
"Building the Internet, Securely." research | development | consulting
In article <··············@animal.interhack.net>,
C Matthew Curtin <········@interhack.net> wrote:
>
> This is interesting. I wonder what a survey would show.
>
> At my university (Ohio State), C++ is part of the requirement, and
> Common Lisp is an option.
Well, my remark was in the direction that students often
don't have a choice. In introductory course they take what's
offered and necessary. If they later at university
(german CS students need 8+ years to finish university)
want to work in a larger context - say a research project
or taking some small problem from the research agenda of
their professor - they often need to take the tool they
are being given.
But, hey, it's good that there are different places.
Sent via Deja.com http://www.deja.com/
Before you buy.
Rainer Joswig <······@corporate-world.lisp.de> writes:
> How could one make CL even more successful in Universities?
>
> [good points deleted]
- Someone would have to write - or announce better than now - a Common
Lisp reference which is more up-to-date than CLtL, more complete than
the language reference in Graham's ACL, smaller than the CLtL brick,
cheaper than the ANSI spec, easier to read off-line than the
HyperSpec, and easier on beginners than the same.
Sorry, it does not count to rip out parts of CLtL (if possible) and
insert Appendix D of ACL.
- Then to try to compete with Perl for hackers; at least set up
something like CPAN and some widely published regexp utilities.
--
Hallvard
* Hallvard B Furuseth <············@usit.uio.no>
| - Then to try to compete with Perl for hackers; at least set up
| something like CPAN and some widely published regexp utilities.
Competing with Perl for "hackers"� is not a good thing. Regular
expressions is just the wrong tool for the job -- it is right in
Perl because Perl is very, very heavily optimized for them so few
other approaches make sense, including Common Lisp. If we even try
to mimic Perl on the regular expression front, we have a loser.
Perl is about doing something that saves the day. Common Lisp is
about doing something that saves the month or the year. It may take
just as long to write, but that's the perspective difference.
#:Erik
-------
� I wonder which meaning of "hacker" this is. It is _not_ the old,
honored meaning of excellent coders with a passion. It is probably
not the mass media meaning.
--
Does anyone remember where I parked Air Force One?
-- George W. Bush
Erik Naggum <····@naggum.net> writes:
> Competing with Perl for "hackers"� is not a good thing. Regular
> expressions is just the wrong tool for the job -- it is right in
> Perl because Perl is very, very heavily optimized for them so few
> other approaches make sense, including Common Lisp. If we even try
> to mimic Perl on the regular expression front, we have a loser.
But it's the regular expression stuff which recruits people to Perl.
Me, for example. Why not try to save them? Some stay at regexp level
and would maybe stay there even in Lisp, but there are quite a lot of
others who go on and start doing object oriented programming and whatnot
in Perl. They _could_ have been doing that in Lisp instead, and maybe
Lisp could even save some of the regexp fanatics.
Sure, persistent regexpers would increase the percentage of _poor_ Lisp
programs and programmers. Is that your objection?
> � I wonder which meaning of "hacker" this is. It is _not_ the old,
> honored meaning of excellent coders with a passion. It is probably
> not the mass media meaning.
Um. I'm not sure either. People who want to be "hackers" in the old
meaning and have some chance of becoming that, I suppose.
--
Hallvard
* Hallvard B Furuseth <············@usit.uio.no>
| But it's the regular expression stuff which recruits people to Perl.
Precisely. If another language tried to acquire similar regular
expression power, it would help recruit people to Perl, because that
language is the embodiment of the idea that regular expressions are
a good way to solve a huge number of problems. It isn't. They are
good for a _very_ small number of problems, such as searching a text
in a text editor or a file system, _interactively_.
| Me, for example. Why not try to save them?
Nah. I'm not into saving random people from themselves. If I were,
I'd have to go shoot the cigarettes out of people's mouths. That
would just land me in jail, and nobody would come save me. So there.
| They _could_ have been doing that in Lisp instead, and maybe Lisp
| could even save some of the regexp fanatics.
Nope. If you fall prey to the regular expression, you're damaged
goods as far as I'm concerned. There is redemption and the chance
of englightenment, of course, but people who extoll the virtues of
programming with regular expressions are about as interesting to
listen to as those who extoll the virtues of street prostitutes.
| Sure, persistent regexpers would increase the percentage of _poor_
| Lisp programs and programmers. Is that your objection?
No. I don't want people to think that regular expressions is
something programmers should put in source code at all. It is
simply the wrong approach to programming text applications. The
regular expression is an excellent tool when searching for something
_interactively_, so tools that accept regular expressions from the
user are the only ones worth using, but if you don't have that whole
interactive "if at first you don't succeed, cry, try again" feel to
using regular expressions, you're doing something very, very wrong,
because you never know when your regular expression sees a false
negative or a false positive. Such mistakes are populating the Perl
world to an alarming degree, but they go virtually unnoticed. If
you spend all the time it takes to actually _know_ that you get the
right results every time, you could have implemented a full-fledged
parser and object-oriented representation of whatever it was you
were trying to hack up with regular expressions in the first place.
#:Erik
--
Does anyone remember where I parked Air Force One?
-- George W. Bush
* Hallvard B Furuseth <············@usit.uio.no>
| But it's the regular expression stuff which recruits people to Perl.
* Erik Naggum <····@naggum.net>
| Precisely. If another language tried to acquire similar regular
| expression power, it would help recruit people to Perl,
I don't believe so.
| because that language is the embodiment of the idea that regular
| expressions are a good way to solve a huge number of problems.
So it does, but that's a problem its users _feel_.
| It isn't. They are
| good for a _very_ small number of problems, such as searching a text
| in a text editor or a file system, _interactively_.
Sure.
| I don't want people to think that regular expressions is
| something programmers should put in source code at all.
Small quick-and-dirty interactive programs are also code.
Anyway, I guess I'm damaged goods; I do like regular expressions
for some very simple stuff even in larger programs.
| if you don't have that whole
| interactive "if at first you don't succeed, cry, try again" feel to
| using regular expressions,
Of course I do. Even many "30-line regular expressions are fine" people
seem to share that. Their problem is that they haven't figured out that
this feeling doesn't belong to serious programs.
| you're doing something very, very wrong,
| because you never know when your regular expression sees a false
| negative or a false positive. Such mistakes are populating the Perl
| world to an alarming degree, but they go virtually unnoticed.
That's because the power and speed of Perl regular expressions are out
of proportion to the rest of the language. For example, stepping
through a string one character at a time in a string is slow - unless
you do it with regular expressions. Perl strings have fill pointers -
but only tied to regular expressions. Even for a plain substring search,
'$x =~ /$y/' is faster than index($x, $y).
None of this would be true for "Lisp with regular expressions".
| If
| you spend all the time it takes to actually _know_ that you get the
| right results every time, you could have implemented a full-fledged
| parser and object-oriented representation of whatever it was you
| were trying to hack up with regular expressions in the first place.
In Lisp, yes. I'd expect people to _notice_ that, even if regular
expressions is what got them started.
In Perl, not always. Assuming a non-rexep solution would be fast
enough to be interesting, it still takes a bit of coding to handle
even a very small syntax.
--
Hallvard
Hallvard B Furuseth <············@usit.uio.no> writes:
> * Erik Naggum <····@naggum.net>
> | I don't want people to think that regular expressions is
> | something programmers should put in source code at all.
>
> Small quick-and-dirty interactive programs are also code.
> Anyway, I guess I'm damaged goods; I do like regular expressions
> for some very simple stuff even in larger programs.
yes but imho regular expressions are a bad pathway. it's cheap at
first but in the end loses hard. regular expressions are a kludge to
try to reconstruct where you once were. instead, we should focus on
*not losing context in the first place*. this is what lisp excells at
and what C and perl and unix in general sucks for. the C progammer is
continually trying to figure out where they once were, the lisp
programmer just dumps a sexp with all the structure needed to pick up
right where they left off. thus while C and perl may look like
winners at first, the lose so hard to the context-lossage turns that
lisp often out does them with its hands tied behind its back.
--
J o h a n K u l l s t a m
[········@ne.mediaone.net]
Don't Fear the Penguin!
I wrote:
> Perl strings have fill pointers -
> but only tied to regular expressions.
Oops - I meant pointers into a string; just a special case of "stepping
through a string is faster with regular expressions". That's what comes
from posting at "31 o'clock" in the night...
--
Hallvard
Erik Naggum <····@naggum.net> writes:
> expression power, it would help recruit people to Perl, because
> that language is the embodiment of the idea that regular
> expressions are a good way to solve a huge number of problems. It
> isn't. They are good for a _very_ small number of problems, such
> as searching a text in a text editor or a file system,
> _interactively_.
I agree that regular expressions are bug a fraction of what's useful.
It would be wrong to think that Perl is popular, or useful because of
regular expressions. Lots of languages have them, including CL
(regex.lisp is pretty good, and ACL has them built-in).
Perl's success (and the reason I like programming in Perl) is that
Perl provided solutions to a huge number of problems. I'll cite some
of them, since this newsgroup seems to disregard Perl's merits.
o Extensive libraries.
I've seen almost nothing that didn't have a
Perl extension to it. Everything from reading and parsing sexp's
to Perl/Tk programs to configure sendmail. You name it, and Perl
has a very nice, simple way to do it with a uniform OO syntax, and
a reasonably efficient implementation.
o As high-level or low-level as you want to go.
Many Perl packages have their guts written in C, and are very
fast. Perl does a fine job calling C routines. But Perl remains
high-level, with heaps of useful built-in functions (like CL).
o A useful and powerful (though not always elegant) object system.
While its object system is completely ad hoc, it works great,
supports multiple inheritance, and has reasonable semantics. There
are things about it that might make most Common Lisp programmers
want to barf, such as using packages (namespaces) as classes, but
this just seems to make sense to me, just as Common Lisp makes
sense, even though they're a bit different. Anyway, in CL, when
most people define classes, they often place the methods in a
particular package anyway.
Of course, this makes (or seems to make) multiple dispatch
(multimethods) impossible, and Perl uses Class::method() semantics
throughout. But somehow it manages to do what you'd want it to do,
and I rarely feel that the libraries I use could do much better if
Perl had multimethods. Maybe the simplicity simplifies things for
the better, and that's nice, since Perl's syntax doesn't need to
get more complicated right now.
[An interesting aside to this is the Perl supports simple class
meta-objects in a very simple but useful way, and it's easy to
agregate class data uniformly, and have the behavior of class
methods depend on that data. It's not MOP, but it's useful.]
o Excellent platform independent support which includes almost all
useful standard libraries.
Not only is the langauge supported on many platforms, so are things
like DBI (database interface), CGI, networking, file management,
etc.
o Great at I/O.
Since many programs spend lots of time on I/O, it helps that Perl
is highly optimized in this area, both in simplifying code that
handles I/O and making it work fast.
o Many of the benefits of programming in Lisp.
Perl supports many fine things that you could only find in Lisp,
like eval(), function references (named or anonymous) that act very
much like lambda expressions, optional/keyword argument lists,
packages, OO, Lvalue semantics (for SETF-like usage), built-in data
structures like lists and hashtables, and most stuff that's not
coming to me right now, but that reminded me a lot of CL.
o Perl is FREE.
You get a lot more bang for the buck in Perl than in CL. I am
happier with the free stuff in Perl than the free stuff in Lisp.
In Perl, you get Corba, DBI, CGI, networking, X, Tk -- all for
free, and the APIs are nicely designed, in my opinion.
People who have been using Perl since before Perl V have seen the huge
changes, and felt them. Perl really does conform to what people want
and need -- very fast. It's responsive to needs of programmers at all
levels, which is probably why it's got the kitchen sink (which,
interestingly, is something people often say about CL).
A lot of what CL has in theory, Perl has in practice. A lot of that
is because people have put in the time, and because there's only one
Perl, and that one Perl interfaces with C for all the low-level stuff
(like talking to your serial port or your favorite database backend).
If you're a CL programmer, then Perl should be your 2nd best friend,
specifically because it complements CL so well where CL is deficient.
Of course, having the two inter-operate is a challenge, but I've
managed to do so with IPC without too much struggle.
dave
Espen Vestre <·····@*do-not-spam-me*.vestre.net> writes:
> David Bakhash <·····@alum.mit.edu> writes:
>
> > ACL has them built-in
>
> the ACL regexps are som limited that they are close to useless.
Perhaps a delayed response to your post, but if you use regexps for
typical things like making sure that an input matches a particular
format, or extracting out simple parts of an input, then ACL's regexps
are just as useful (at least to me) though very poorly implemented
syntacticly (i.e., coming from Perl regexps, writing them in ACL is
painful, and reading them back is much harder too). It would have
been nice if the regexp package came with a nice reader macro, like
#R/whatver here/ or #R"whatever here", or something that didn't
require so much backslashing. In the 2nd case above, for example, the
only character that would need escaping is #\" as far as I can tell.
I've been unfortunate enough to have to write programs which process
files in a particular, unnecessarily complicated and illogical format
that I appreciate regexps. They are a tool like anything else, and
when I need them, and when you've got them there to use, it's not
necessarily a bad thing.
dave
David Bakhash <·····@alum.mit.edu> writes:
> painful, and reading them back is much harder too). It would have
> been nice if the regexp package came with a nice reader macro, like
> #R/whatver here/ or #R"whatever here", or something that didn't
> require so much backslashing. In the 2nd case above, for example, the
> only character that would need escaping is #\" as far as I can tell.
I agree on that, but that wasn't my point. I consider them "close to
useless" because they don't support the * or + operations on anything
but 'single-character' regexps.
--
(espen)
Espen Vestre <·····@*do-not-spam-me*.vestre.net> writes:
> David Bakhash <·····@alum.mit.edu> writes:
>
> > painful, and reading them back is much harder too). It would have
> > been nice if the regexp package came with a nice reader macro, like
> > #R/whatver here/ or #R"whatever here", or something that didn't
> > require so much backslashing. In the 2nd case above, for example, the
> > only character that would need escaping is #\" as far as I can tell.
>
> I agree on that, but that wasn't my point. I consider them "close to
> useless" because they don't support the * or + operations on anything
> but 'single-character' regexps.
again, agreed. I think they did a horrible job on them too. But
efficiency-wise, I tested them against nregex.lisp (the free one), and
ACL's destroyed it (that is, on ACL, of course, and with a compiled
nregex).
dave
David Bakhash <·····@alum.mit.edu> writes:
> Perl's success (and the reason I like programming in Perl) is that
> Perl provided solutions to a huge number of problems. I'll cite some
> of them, since this newsgroup seems to disregard Perl's merits.
> (...)
> o Extensive libraries.
> o As high-level or low-level as you want to go.
> o A useful and powerful (though not always elegant) object system.
> o Many of the benefits of programming in Lisp.
Perl4 didn't have these, yet it grew into Perl5 which now does.
As for low-level: Individual Lisps implementations compete fine, though
some sort of standardization would be nice.
Still, I suspect that means the Perl to compare "success" with for now
is Perl4, and try to emulate the story of how that grew the community
which made Perl5 and CPAN.
> o Perl is FREE.
There are several free Lisps.
> o Excellent platform independent support which includes almost all
> useful standard libraries.
Yup.
That seems to leave Lisps like CLISP and GCL as the running contenders,
since they are fairly portable and can be compiled from scratch...
BTW, can another Lisp be used to bootstrap CMUCL?
> o Great at I/O.
I don't know how the various Lisps stand up here, but in any case the
speed of more advanced stuff in Perl5 counterbalances it in a lot of the
packages Perl is used for.
--
Hallvard
Hallvard B Furuseth <············@usit.uio.no> writes:
> BTW, can another Lisp be used to bootstrap CMUCL?
No, but in SBCL (see Sourceforge) there exists a descendant of CMUCL
that is intended to be bootstrapped by any sufficiently powerful ANSI
Common Lisp.
BUT, and that's a big but: Most people seem to forget that CMU CL,
like e.g. GCC -- but unlike stuff like Perl, Python, CLISP, GCL,
etc. -- has its own native code generator, so that bringing it up on
another platform is not a simple bootstrapping issue, but requires a
new compiler backend to be written for the processor in question.
Furthermore, since most Lisp implementations are interacting
intimately with the underlying OS in a couple of areas (like
e.g. memory management and signal-handling for modern generational
garbage-collection), even porting to a new OS is not all that trivial
(it's not excessively hard either, but it's definitely not done by
just recompiling with a few tweaks to Makefiles and includes).
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
Pierre R. Mai <····@acm.org> writes:
> Hallvard B Furuseth <············@usit.uio.no> writes:
>
>> BTW, can another Lisp be used to bootstrap CMUCL?
>
> No, but in SBCL (see Sourceforge) there exists a descendant of CMUCL
> that is intended to be bootstrapped by any sufficiently powerful ANSI
> Common Lisp.
Sounds good.
> BUT, and that's a big but: Most people seem to forget that CMU CL,
> like e.g. GCC -- but unlike stuff like Perl, Python, CLISP, GCL,
> etc. -- has its own native code generator, so that bringing it up on
> another platform is not a simple bootstrapping issue, but requires a
> new compiler backend to be written for the processor in question.
Well, yes. It was just a stray thought because I suspect it'll feel
more friendly to strangers who want to play with the implementation
(e.g. port it to another host) if it can be bootstrapped. Not that CMU
CL seems too friendly that way in any case.
> Furthermore, since most Lisp implementations are interacting
> intimately with the underlying OS in a couple of areas (like
> e.g. memory management and signal-handling for modern generational
> garbage-collection), even porting to a new OS is not all that trivial
> (it's not excessively hard either, but it's definitely not done by
> just recompiling with a few tweaks to Makefiles and includes).
So maybe the maintainers should try to make it more attractive to people
who might try to port it, if they haven't time themselves...
--
Hallvard
Hello!
In article <················@bombur.uio.no>,
Hallvard B Furuseth <············@usit.uio.no> wrote:
>Pierre R. Mai <····@acm.org> writes:
>> Hallvard B Furuseth <············@usit.uio.no> writes:
>>> BTW, can another Lisp be used to bootstrap CMUCL?
>> No, but in SBCL (see Sourceforge) there exists a descendant of CMUCL
>> that is intended to be bootstrapped by any sufficiently powerful ANSI
>> Common Lisp.
>Sounds good.
Sounds better as it is, at least till now.
I tried to bootstrap any of {SBCL,CMUCL} with any *other* free Lisp
(to work around the vicious circle of having to have binaries to
generate binaries for sbcl/cmucl, as I run OpenBSD and until a few
months ago, there were no downloadable binaries available) and found
nothing that worked:
- clisp:
is said to lack some capabilities
- ecls:
just didn't work
>> BUT, and that's a big but: Most people seem to forget that CMU CL,
>> like e.g. GCC -- but unlike stuff like Perl, Python, CLISP, GCL,
>> etc. -- has its own native code generator, so that bringing it up on
>> another platform is not a simple bootstrapping issue, but requires a
>> new compiler backend to be written for the processor in question.
Not necessarily. If you have another OS on the same processor arch,
porting should be easier -- but only if you can bootstrap without
already having binaries for your OS.
>Well, yes. It was just a stray thought because I suspect it'll feel
>more friendly to strangers who want to play with the implementation
>(e.g. port it to another host) if it can be bootstrapped. Not that CMU
>CL seems too friendly that way in any case.
No. And SBCL not, either.
>[...]
Kind regards,
Hannah.
······@schlund.de (Hannah Schroeter) writes:
> Sounds better as it is, at least till now.
>
> I tried to bootstrap any of {SBCL,CMUCL} with any *other* free Lisp
> (to work around the vicious circle of having to have binaries to
> generate binaries for sbcl/cmucl, as I run OpenBSD and until a few
> months ago, there were no downloadable binaries available) and found
> nothing that worked:
The underlying problem here is that most free Lisp's out there don't
fully support the necessary subset of ANSI CL for this to succeed.
I'd guess that using one of the commercial implementations like ACL
would meet with more success.
OTOH the best approach might be to cross-compile CMU CL from one of
the supported platforms, e.g. from a FreeBSD or Linux machine.
> >> BUT, and that's a big but: Most people seem to forget that CMU CL,
> >> like e.g. GCC -- but unlike stuff like Perl, Python, CLISP, GCL,
> >> etc. -- has its own native code generator, so that bringing it up on
> >> another platform is not a simple bootstrapping issue, but requires a
> >> new compiler backend to be written for the processor in question.
>
> Not necessarily. If you have another OS on the same processor arch,
> porting should be easier -- but only if you can bootstrap without
> already having binaries for your OS.
The situation w.r.t. GCC is actually quite similar, and anyone who has
tried to bring up GCC on a new OS or a new arch has experienced the
amount of work that often needs to be invested. The normal way to
bring up e.g. GCC for a new OS is to either cross-compile from a
working host, or to try to compile GCC with an existing C compiler, if
(and at times this was a big if) you can find a C compiler that is
sufficiently conforming and bug-free.
What I'm trying to say here is that nowadays it is easy to expect out
of the box compilability of software, since we now live in a world
where most such software is written in C and fairly usable C compilers
are as ubiquituous as the air we breathe. But it is equally easy to
forget that this is a quite recent turn of events (just 10 years ago
usable C compilers were actually a much rarer thing, and many more
people needed to wade through the intricacies of bootstrapping a C
compiler on a pristine platform), and that it is limited to software
that is written primarily in C: That's one of the reasons it's fairly
easy to port e.g. CLISP or GCL, whose kernels consist mostly of C, and
where only auxiliary layers are written in CL.
Until such a time that fully capable CL implementations are as
ubiquitous, bootstrapping issues are certain to remain...
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
Hello!
In article <··············@orion.bln.pmsf.de>,
Pierre R. Mai <····@acm.org> wrote:
>[...]
>The underlying problem here is that most free Lisp's out there don't
>fully support the necessary subset of ANSI CL for this to succeed.
>I'd guess that using one of the commercial implementations like ACL
>would meet with more success.
There are AFAIK no commercial implementations that run on OpenBSD
(not even with its Linux/FreeBSD emulation capabilities, as they are
still limited -- I *did* try the newest ACL trial edition [linux
binaries]).
>OTOH the best approach might be to cross-compile CMU CL from one of
>the supported platforms, e.g. from a FreeBSD or Linux machine.
Have one... cmucl doesn't run correctly on OpenBSD's Linux or
FreeBSD emulation setups. I posted about that some months ago!
>[...]
>> Not necessarily. If you have another OS on the same processor arch,
>> porting should be easier -- but only if you can bootstrap without
>> already having binaries for your OS.
>The situation w.r.t. GCC is actually quite similar, and anyone who has
>[...]
>What I'm trying to say here is that nowadays it is easy to expect out
>of the box compilability of software, since we now live in a world
>where most such software is written in C and fairly usable C compilers
>are as ubiquituous as the air we breathe. But it is equally easy to
>forget that this is a quite recent turn of events (just 10 years ago
>usable C compilers were actually a much rarer thing, and many more
>people needed to wade through the intricacies of bootstrapping a C
>compiler on a pristine platform), and that it is limited to software
>that is written primarily in C: That's one of the reasons it's fairly
>easy to port e.g. CLISP or GCL, whose kernels consist mostly of C, and
>where only auxiliary layers are written in CL.
>Until such a time that fully capable CL implementations are as
>ubiquitous, bootstrapping issues are certain to remain...
If we look beyond CL, we see things like
- ocaml:
ocaml has a bytecode engine with portable bytecode files, *and*
a good native compiler for many archs including i386.
Bootstrapping works roughly like this:
- compile the bytecode interpreter (C sources)
- use the included portable bytecode of a ocaml->bytecode compiler
to bootstrap the initial generation of the tools (i.e. mllex, mlyacc,
the ocaml->bytecode compiler, the ocaml parts of the libraries) to
bytecode
(This step is fast, as the compiler implementation is so fast that
even the runtime cost of bytecode interpretation isn't prohibitive)
- if supported on the arch: compile the ocaml->native compiler
(using the bootstrap bytecode image or the stage 1 result, result
still is bytecode)
- if requested, build the ocaml->bytecode and ocaml->native compiler
again, this time using the ocaml->native compiler, resulting in
compilers that have a bit longer startup time, but better performance
for large inputs.
- SML/NJ:
SML/NJ has its own native compilation system. It has NO bytecode
system.
To bootstrap, you download the system sources (written in C [small parts]
and SML [most of the system]). Additionally you download "image" files
for your processor architecture (they are NOT operating system specific!).
Then, you build the C parts of the runtime. The SML parts are loaded from
the binary image files.
Then you use that system to recompile itself.
Both approaches are quite easy for the situation of an already supported
processor architecture and a not-yet supported OS (for example:
supported is x86/Linux, wanted is x86/OpenBSD).
The ocaml approach even provides at least some start for non-supported
processor architectures: as long as you don't port the native compiler
(i.e. provide a backend for the arch), you at least have got a bytecode
system.
Kind regards,
Hannah.
Hallvard B Furuseth wrote:
> As for low-level: Individual Lisps implementations compete fine, though
> some sort of standardization would be nice.
Is it not true for Perl implementations, too?
Btw, I was amazed that ACL, delivering a high-level language, also lets
you put breakpoints anywhere in assembly code and inspect register
contents.
Robert
* Robert Monfera wrote:
> Hallvard B Furuseth wrote:
>> As for low-level: Individual Lisps implementations compete fine, though
>> some sort of standardization would be nice.
> Is it not true for Perl implementations, too?
There is only one...
--tim
Hallvard B Furuseth <············@usit.uio.no> writes:
> Erik Naggum <····@naggum.net> writes:
> > Competing with Perl for "hackers"� is not a good thing. Regular
> > expressions is just the wrong tool for the job -- it is right in
> > Perl because Perl is very, very heavily optimized for them so few
> > other approaches make sense, including Common Lisp. If we even try
> > to mimic Perl on the regular expression front, we have a loser.
>
> But it's the regular expression stuff which recruits people to Perl.
> Me, for example. Why not try to save them? Some stay at regexp level
> and would maybe stay there even in Lisp, but there are quite a lot of
> others who go on and start doing object oriented programming and whatnot
> in Perl. They _could_ have been doing that in Lisp instead, and maybe
> Lisp could even save some of the regexp fanatics.
>
> Sure, persistent regexpers would increase the percentage of _poor_ Lisp
> programs and programmers. Is that your objection?
Look at PCRE - Perl-like REs for CL
<ftp://ftp.cus.cam.ac.uk/pub/software/programs/pcre/>
Look at Henry Baker's document archive [hmm... I thought I had a URL
on this...]; he's got a RE-like parsing system intended to provide a
similar ability to fairly readily build simple parsers.
--
(concatenate 'string "cbbrowne" ·@hex.net") <http://www.ntlug.org/~cbbrowne/>
Rules of the Evil Overlord #106. "If my supreme command center comes
under attack, I will immediately flee to safety in my prepared escape
pod and direct the defenses from there. I will not wait until the
troops break into my inner sanctum to attempt this."
<http://www.eviloverlord.com/>
········@hex.net writes:
> Look at Henry Baker's document archive [hmm... I thought I had a URL
> on this...];
Unfortunately, Henry Baker's home page at
ftp://ftp.netcom.com/pub/hb/hbaker/home.html
disappeared a while ago.
A temporary and unofficial mirror is at
http://linux.rice.edu/~rahul/hbaker/home.html
> he's got a RE-like parsing system intended to provide a
> similar ability to fairly readily build simple parsers.
The paper is "Pragmatic Parsing in Common Lisp",
http://linux.rice.edu/~rahul/hbaker/Prag-Parse.html
(also available in Postscript), originally published in ACM Lisp
Pointers 4, 2 (Apr-Jun 1991), 3-15. The paper reviews the classic
META parsing technique which can be used to parse streams, strings,
and lists.
--
T. Kurt Bond, ···@tkb.mpl.com
T. Kurt Bond <···@tkb.mpl.com> wrote:
+---------------
| ········@hex.net writes:
| > he's got a RE-like parsing system intended to provide a
| > similar ability to fairly readily build simple parsers.
|
| The paper is "Pragmatic Parsing in Common Lisp",
| http://linux.rice.edu/~rahul/hbaker/Prag-Parse.html
| (also available in Postscript), originally published in ACM Lisp
| Pointers 4, 2 (Apr-Jun 1991), 3-15. The paper reviews the classic
| META parsing technique which can be used to parse streams, strings,
| and lists.
+---------------
And far more than that. The META class of parsers can be used to build
full top-down recursive-descent compiler-style parsers, very quickly and
easily. Somewhere back around 1971(?), I used the META2 compiler-compiler
on a DEC PDP-10 to build a toy BLISS compiler in a weekend. (Generated
*horribly* inefficient but correct code.) Great fun!
-Rob
-----
Rob Warnock, 31-2-510 ····@sgi.com
Network Engineering http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673
1600 Amphitheatre Pkwy. PP-ASEL-IA
Mountain View, CA 94043
···@tkb.mpl.com (T. Kurt Bond) writes:
>> Look at Henry Baker's document archive [hmm... I thought I had a URL
>> on this...];
>
> A temporary and unofficial mirror is at
> http://linux.rice.edu/~rahul/hbaker/home.html
<ftp://samaris.tunes.org/pub/food/papers/people/Henry.Baker/>
looks less temporary.
> The paper is "Pragmatic Parsing in Common Lisp", (...)
META is fine, but like I said previosly, it takes some coding even for
small syntaxes. Also the paper's version eats six macro characters,
though that could be avoided by using postfix operators instead.
Anyway, replace "regexp utilities" with "text parsing packages
(including regexp utilities)" if you like, that makes more sense.
It'd also be weasel wording since I think the regexp stuff would be
the initial attraction:-)
There was an article about regular expressions losing context I was
going to answer, but I can't find it. I'll just say that I don't see
how a regular expression can take away my context unless I let it.
--
Hallvard
Hallvard B Furuseth <············@usit.uio.no> writes:
> META is fine, but like I said previosly, it takes some coding even for
> small syntaxes. Also the paper's version eats six macro characters,
> though that could be avoided by using postfix operators instead.
If the macro characters are a problem there's a modified version that
uses a fully parenthesized syntax at
http://tkb.mpl.com/~tkb/software.html
--
T. Kurt Bond, ···@tkb.mpl.com
···@tkb.mpl.com (T. Kurt Bond) writes:
>Hallvard B Furuseth <············@usit.uio.no> writes:
>> META is fine, but like I said previosly, it takes some coding even for
>> small syntaxes. Also the paper's version eats six macro characters,
>> though that could be avoided by using postfix operators instead.
>
> If the macro characters are a problem there's a modified version that
> uses a fully parenthesized syntax at
>
> http://tkb.mpl.com/~tkb/software.html
Thanks.
--
Hallvard
Christopher Browne wrote:
> Look at PCRE - Perl-like REs for CL
> <ftp://ftp.cus.cam.ac.uk/pub/software/programs/pcre/>
In what sense "for CL"? PCRE is written in C and intended
for use with C programs. I just did "egrep -i lisp" on
the whole distribution and it came up blank. Am I missing
something?
--
Gareth McCaughan ················@pobox.com
sig under construc
Erik Naggum <····@naggum.net> writes:
> � I wonder which meaning of "hacker" this is. It is _not_ the old,
> honored meaning of excellent coders with a passion. It is probably
> not the mass media meaning.
it's probably the 'always adds ad-hack solutions' meaning ;-)
--
(espen)
* Fernando Rodr�guez -> glauber
| Scheme was designed as a teaching and investigation tool, not for
| "real world" programming.
The problem with tools that are only good for the teaching/learning
process is that they are actually teaching many very bad things
amidst all the good stuff. It is good to learn how to build your
own tools. It is bad to learn that you have to, meaning that you
are more likely to spend a lot of time building something that is
already out there rather than try to understand it and use it. It
is good to learn recursion instead of iteration because it expands
the way you think in ways those who don't grasp recursion cannot
fathom. It is bad _not_ to learn iteration and when it is a good
thing, when it is more readable and understandable than recursion,
and above all, when recursion would kill you performance-wise and
iteration would not. It's just like the irrational gotophobia that
some students of programming have (no real programmer _fears_ goto)
because they have never actually seen the hell and spaghetti code
that they have been saved from by structured programming.
| As a learning language it has been far more successful that CL as a
| general purpose language. :-P
Hmpf! But this probably _is_ true. Scheme succeeds because it is
easy to teach to bright people and fun to implement. Hence, we have
about a million implementations of Scheme, and only one of them is
good for anything more than teaching others how to implement Scheme.
#:Erik
--
I agree with everything you say, but I would
attack to death your right to say it.
-- Tom Stoppard
Centuries ago, Nostradamus foresaw a time when Erik Naggum would say:
>* Fernando Rodr�guez -> glauber
>| Scheme was designed as a teaching and investigation tool, not for
>| "real world" programming.
>
> The problem with tools that are only good for the teaching/learning
> process is that they are actually teaching many very bad things
> amidst all the good stuff. It is good to learn how to build your
> own tools. It is bad to learn that you have to, meaning that you
> are more likely to spend a lot of time building something that is
> already out there rather than try to understand it and use it. It
> is good to learn recursion instead of iteration because it expands
> the way you think in ways those who don't grasp recursion cannot
> fathom. It is bad _not_ to learn iteration and when it is a good
> thing, when it is more readable and understandable than recursion,
> and above all, when recursion would kill you performance-wise and
> iteration would not. It's just like the irrational gotophobia that
> some students of programming have (no real programmer _fears_ goto)
> because they have never actually seen the hell and spaghetti code
> that they have been saved from by structured programming.
I would submit that if Common Lisp was used instead of Scheme,
instead of the modules using:
(define (reverse lst)
(if (pair? lst)
(append (reverse (cdr lst)) (list (car lst)))
lst))
They would instead spend three weeks demonstrating recursion using:
(defun reverse (list)
(if (consp list)
(append (reverse (cdr list)) (list (car list)))
list))
Instead of spending a couple weeks ignoring the Scheme DO form, they
would spend a couple weeks ignoring DO and LOOP and all the other
iterative functions of CL.
Courses generally don't seem to present the more "advanced" structures
of Scheme, such as hash tables, macros, and records/structures. I
would question why you'd expect them to teach more about CL.
--
·····@freenet.carleton.ca - <http://www.hex.net/~cbbrowne/lsf.html>
History of Epistemology in One Lesson
"First Hume said "We can't really know anything", but nobody believed
him, including Hume. Then Popper said "Hume was right, but here's what
you can do instead...". Bartley then debugged Popper's code."
-- Mark Miller
* Christopher Browne
| Courses generally don't seem to present the more "advanced" structures
| of Scheme, such as hash tables, macros, and records/structures. I
| would question why you'd expect them to teach more about CL.
I made no comments to that effect. Why do you think I expect that?
I don't _compare_ the two languages -- I'm simply pointing out
serious flaws in Scheme and how it is taught and used. Since we
don't have any data on how CL would be taught if it were where
Scheme is, I fail to see how I could be thought to _expect_ any
improvements just by changing the language being taught.
#:Erik
--
Does anyone remember where I parked Air Force One?
-- George W. Bush
Erik Naggum <····@naggum.net> writes:
> * Christopher Browne
> | Courses generally don't seem to present the more "advanced" structures
> | of Scheme, such as hash tables, macros, and records/structures. I
> | would question why you'd expect them to teach more about CL.
First, while these may be the "advanced structures" of Scheme, they are hardly
advanced by today's standards. This, fundamentally, is the challenge that
faces Lisp today. When I graduated from college, now too many years ago to
remember, it was exactly as Christopher says here, I had special knowledge of
the advanced fabric of computation that would get me farther and faster than
anyone else--I knew how to use Lisp and Lisp gave me a leg up on the kinds of
computations that I'd need to be doing. While others (say, C programmers)
were going to need hash tables in their computations, they had to remember
details of their implementation. Not so with Lisp--I could just ask for a
hash table because I wanted its big-O computational properties for storage
and access and immediately move to the business of USING hash tables. Ditto,
it was a big deal thing to have "records/structures" to help me organize my
thoughts back then. Ideas like inheritance of methods and structure were new
and just knowing them was a leap ahead. No longer so.
Lisp provides considerable computational power, but without continual tracking
of what people today think are "advanced structures", we're hosed. This is
why I have made a big point to any Lisp vendor who would listen of saying that
you must not charge for "connective tissue" to other languages. An RMI
interface is essential right now, and nobody better charge for it. In the
meantime, it's a darned shame they're charging for CORBA. Maybe if there were
both it would be ok to charge for CORBA, but the problem is that right now
the modern functionality that people think in terms of is jpegs and gifs,
audio streams, http servers, html and xml data, fonts and font metrics, and so
on. These are programming tasks to the Lisp world, as hash tables were
programming tasks to the C world of my generation, but they are library
operations to Java and well should be to Lisp. If Lisp could access Java for
free, it could leverage all the good work that people have done in library
creation in Java and on top of all that good work could add a rational
language connective glue because Java truly sucks. However, for as much as
Java sucks for programming, as long as it keeps producing high quality
libraries, the amount of coding you have to do in that sucky language in order
to get work done is, relatively speaking, small in order not to do the
visionary things Lisp people want to do but in order to stay far enough ahead
of competition to make money. And so Java succeeds while Lisp fails, even
though Lisp has tons to teach Java.
Java people do not talk about record structures as advanced. They might
talk about macros as advanced if only the language had them, but only for a
short while I suspect. Those are glue issues and must never have the word
advanced in front of them because they are the fundamental building blocks of
thought. If teachers of languages don't teach people how to use the building
blocks and insist to people that this is basic stuff, there is no hope people
will ever get to the advanced stuff because they'll rest on their laurels
having achieved the faux superiority of understanding record structures.
Now, back to Erik's comment about the quote above...
> I made no comments to that effect. Why do you think I expect that?
> I don't _compare_ the two languages -- I'm simply pointing out
> serious flaws in Scheme and how it is taught and used. Since we
> don't have any data on how CL would be taught if it were where
> Scheme is, I fail to see how I could be thought to _expect_ any
> improvements just by changing the language being taught.
I'm not entirely sure I agree with Erik here. The way I'd say it is that
the languages are structured in a way that leads naturally to a certain
teaching. Scheme is ABOUT being spartan. It is about saying that the
langauge eschews libraries and in some ways barely tolerates, as an
orderly addition, syntactic abstraction. It is entirely about a teaching
order in which people learn to think in the language without abstraction
and then learn to think of the abstraction as an "add-on".
Lisp, taught properly, is about the more democratic (as Erik called it
earlier) and less orderly notion that macros are really in there from
the getgo, and even though one can go back and retroactively explain the
bootstrap order in terms of simpler and more complicated mechanisms, the
fact is that the intended way for people to THINK is to say that macros are
always there, and record structures are always there, and inheritance is
always there, and hash tables are always there. These are not library
structures. A conscious decision was made not to go the ANSI C way of saying
there is the language and there is a library but there might be other libraries
because that leads to deviation of thinking. A conscious decision was made to
say "it's just all there to start with and the whole language/library issue
is purely an issue of efficiency of implementation, subprimitive to the
language itself".
A teacher of Lisp can, and teachers routinely do, confuse CL with Lisp 1.5
and insist that people need to learn to program in terms of car/cdr/cons
and recursion, but those are not acceptable production solutions for commercial
quality CL programmers, and there had better be repair later. I prefer to
think that the problem is that people confuse "algorithms courses" (learning
how to build up useful abstractions from more primitive list and vector
abstractions) with "lisp courses" which should be about using, not
implementing, lisp. The whole POINT of modern lisp which distinguishes it
from early lisp is that it is a USER commodity, designed to hide from the
casual user the horror of implementing COUNT or SEARCH or POSITION or even
LOOP. Those things are not "cheating"--they are what you are intended to do.
And so courses that teach you that their use is wrong are not teaching LISP,
or at least certainly are not teaching CL, they are teaching algorithms and
doing CL the disservice of saying that just because it is computationally
powerful enough to implement low-level algorithms, that it itself is offered
by we the designers and/or implementors FOR that purpose (and often, it is
falsely suggested, either implicitly or explicitly, for no other).
What I do agree with Erik on is the second of his assertions--which is that
we don't have huge amounts of data about how people would teach CL if it had
books that were as popular as Structure and Interpretation of Computer
Programming (S&ICP). I have personally never liked S&ICP, and have never
recommended it to the up and coming reader in spite of its being packed with
very important insights, primarily because it promotes a horrendous programming
style. Historically, and it even seemed so at the time, I believe the reason
was that there was so much "Fortran-esque" indoctrination that people got that
S&ICP intended merely to offer "balance" to the world. However, in offering
balance it did not preach balance. Like the adversarial court system of the
US, it assumed that balance would naturally arise from two people saying the
opposite things--the Fortran people saying that iteration was a process of
stepping through something n times, the Scheme people saying that iteration
was a process of doing something once and then recursing into the problem
with one fewer times needing for it to be done. It amounts to the same. And
a BALANCED approach would teach RESPECT for both approaches. But S&ICP never
went back and did that, and most Scheme courses graduate either people who
have no idea what they learned and hate Lisp/Scheme for being so obtuse or else
zealots who think they have been taught that Fortran-esque iteration is a
confusion to be left aside as foolhardy. Neither of these is a useful outcome.
Like all things in life, good teaching should be monotonic, adding to what
one already knows and providing additional options, not evangelical, replacing
"bad thought" with so-called "good thought". Sometimes, the result of good
teaching will be that the learner will decide they can get away with collapsing
out two ways of thinking about something and using only one, but that should
be a personal choice of the learner, not a choice of the teacher. The teacher
should provide options.
CL is about options. Within it, it provides multiple ways to do
something. The Schemers often hate that. My impression is that they
see any form of redundancy as a weakness. (I think that's why they don't
like our two namespace system, too.) I see it as a strength, and
as a form of tolerance and enlightenment...
Kent M Pitman <······@world.std.com> writes:
> Like all things in life, good teaching should be monotonic, adding to what
> one already knows and providing additional options, not evangelical, replacing
> "bad thought" with so-called "good thought". Sometimes, the result of good
> teaching will be that the learner will decide they can get away with collapsing
> out two ways of thinking about something and using only one, but that should
> be a personal choice of the learner, not a choice of the teacher. The teacher
> should provide options.
While I agree with most of what what said in this article, I heartily
disagree with this paragraph. It is sometimes impossible to replace
"bad thought" with "good thought", because replacement involves removing
the old and adding the new. If the old "bad thought" is deeply ingrained
in the student's head by previous teaching, it is likely to be perceived
by the student to be "good thought", and thus there will be resistance
to the new "good thought". The teaching must indeed sometimes be
evangelical.
This is why I don't like the progression of one language to another
in lisp-like languages; when scheme or logo are taught in schools,
the tendency is to not realize that there is something more powerful
out there; either the student gets turned off to lisp and never looks
at CL, or else the student becomes enamored with the beauty of their
simple, elegant language (sort of a first-language syndrome) and takes
a very long time to learn CL and even then, it takes a lot of relearning
to delete some of the older habits of their (scheming) years. Note that
I don't say that either scheme or logo are bad languages; it is in fact
precisely because they are good within themselves for learning that
they become so insidious wrt the eventual learning of CL.
I _do_ agree that teaching can be monotonic iff there are no bad thoughts
to unlearn. To that end, we should be promoting the teaching of CL
in schools, as an alternative to scheme or logo. The vendors should of
course do their parts, and I think we do try. But the CL community must
also do its part:
I have seen outcries for many things that are or are not available in
the CL standard to be standardized (e.g. foreign interface, multiprocessing,
defsystem, etc), but I have never heard anyone crying out for a standard
teaching curriculum and/or interface in CL. Logo and scheme don't need
such a standard, because they already have mechanisms that are amenable
to learning. Scheme is purportedly simple and thus the learning of the
core of scheme is within the scope of a class or two in college. Logo
has turtles, and its defining forms and turtle commands are mnemonic.
But CL is larger than can be fit into one ot two introductory courses in
college, and even harder to teach in pre-college schools.
It would be nice to have a "recommended course of study" for CL, as part
of the standard. This would give teachers something to present to
students that would not blow them away and turn them off. It would
also allow teachers to start with CL directly, rather than starting
with something "simpler" but "different".
To standardize this, a meeting of minds of those teachers of CL who
have been successful in CL could take place, and the outlines drawn
up as to how to teach CL _and_ how not to teach CL.
[Personal note: I am sorry to say that I won't be able to continue this
conversation after today; though I am not sorry for the reason: I am
leaving early tomorrow for a cruise with my wife for two weeks; so if
I don't respond to any particular articles for a while, it's only
because I haven't read them...]
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
Duane Rettig <·····@franz.com> wrote:
> [Personal note: I am sorry to say that I won't be able to continue this
> conversation after today; though I am not sorry for the reason: I am
> leaving early tomorrow for a cruise with my wife for two weeks; so if
> I don't respond to any particular articles for a while, it's only
> because I haven't read them...]
Bon Voyage!
(and welcome back...)
--
Arne Knut Roev <······@online.no> Snail: N-6141 ROVDE, Norway
=
The Gates of Hell shall not prevail:
Darkness now; then Light!
http://www-aig.jpl.nasa.gov/public/home/gat/lisp-study.html
Found this link a while ago. Would really be interested
in comments on it (posted it earlier to the My Opinion Thread
but no one responded).
rgds
JR
Duane Rettig <·····@franz.com> writes:
> Kent M Pitman <······@world.std.com> writes:
>
> > ... good teaching should be monotonic ...
>
> While I agree with most of what what said in this article, I heartily
> disagree with this paragraph. It is sometimes impossible to replace
> "bad thought" with "good thought",
I actually have a personal computational model of the brain that says that
says that you don't ever end up getting to do this. That in fact what
learning does is only to cons a new block of something, and that the
only way something "goes away" is by gc, not by explicit dropping of
pointer. All the attempts at forced dropping pointers more likely just
create convoluted, unmotivated paths around something, losing the "good"
in what was there because the area has been marked "off limits" and may
in some cases create gc-protection for ideas that ought have been naturally
gc'd if left alone. Just a theory. But that's where the term monotonic
came from here.
> because replacement involves removing the old and adding the new.
> If the old "bad thought" is deeply ingrained in the student's head
> by previous teaching, it is likely to be perceived by the student to
> be "good thought", and thus there will be resistance to the new
> "good thought". The teaching must indeed sometimes be evangelical.
I'm not so sure. The reason is that the teacher cannot know the whole of
what is to be replaced. The teacher can only know the shape of some patterns
to be looked for, but not the entirety of the patterns in context. Indeed,
even if the second teacher was there for the first teaching, the second
teacher cannot know, since the teacher knows only what was projected, not
how it was received and incorporated. If person A says to me
"people with green noses are untrustworthy", I might not learn that as such;
I might learn it as "on-such-and-so date, people with green noses were
thought to be untrustworthy" or "there are people who distrust people with
green noses" or any of a variety of other things that you didn't say, perhaps
in order to keep the teaching consistent with some theory I already have
that green noses are irrelevant to trustworthiness. Now if teacher 2 comes
along and says "anything anyone has taught you about green noses is false"
then am I to believe or disbleive? Personally, I'd find that to be just as
bad data as the first thing, since the second teacher is saying something
that on the meta appears absurd. What I have been taught is as much a product
of me as of the first teacher, so when someone tells me that things that are
the product of me are false, I learn to discount them, too. Or else I don't,
and that is worse. Because now I believe it's false that "at a certain date,
people with green noses were untrustworthy" or it's false that "some people
distrust green noses" or ... Hence, I think an evangelical approach--one
that I'll define as being "negative assertions about something one imagines
has been taught before" is bad.
Rather, I think monotonicity is achieved by merely teaching someone something
new and teaching them how to recognize the set of processes and facts that
this, by its nature and not by some assertion of truth, aubsumes. Then they,
not me the teacher, can develop their own patterns for finding and updating
prior pointers to facts, and more importantly can update related concepts to
bypass the old wisdom. Hence, rather than a network that looks like:
xref1 xref2
\ /
explaind-by explained-by
\ /
\ /
fact1 <---- supersedes --- fact2
you end up with a network like:
xref1
/ \
explained explained
by by
| |
v v
fact1 fact2
A A
| |
explained explained
by by
\ /
xref2
If the fact2 gets independent confirmation of being a stronger item,
eventually fact1 will just not be able to compete of its own accord
but in the meantime, the original structure of the two theories will not
be perturbed, can be compared, etc. This is what I mean by monotonic, in
any case. In a sense, both involve the incremental addition of links, but
only the second is culturally consistent with monotonicity in the sense that
the resulting graph actively represents (and doesn't just imply) the
thing learned. Part of my problem with evangelical thought is that I think
it ends up with lots of fuzzy-logic "supersedes" links randomly attached
to things without regard to what the logical implication is of perturbing a
random isolated factoid in a large complex network, and I think this does
damage to people's understanding of the world.
> This is why I don't like the progression of one language to another
> in lisp-like languages; when scheme or logo are taught in schools,
> the tendency is to not realize that there is something more powerful
> out there; either the student gets turned off to lisp and never looks
> at CL, or else the student becomes enamored with the beauty of their
> simple, elegant language (sort of a first-language syndrome) and takes
> a very long time to learn CL and even then, it takes a lot of relearning
> to delete some of the older habits of their (scheming) years.
I see this as less a problem of progression of languages and more a
problem of belief that all languages use the same skills. I was
taught early on that in order to understand "Programming" one must
understand it from many different points of view and then select from
what works in a given case. I was given a list of kinds of languages
(which I think I've since augmented) and told to learn one of each, so
that I could see how patterns of thought vary among them. Learn a
straight-line language (e.g., assembly or fortran), a functional
language (e.g., scheme), a block-structured language (like Algol, Pascal,
C++, or Java), a line-noise language (one with small amounts
of text and heavyweight operators, like teco or apl), an AI language
(like amord or emycin or prolog), a domain-specialized language (like
visual basic or hypertalk or tex or postscript, somewhat coincidental
that most of the domains are "display domains" here in the examples,
but i mean languages where the operators are heavy on support of some
specific domain; i suppose CAD could be another), a text processing
language (like snobol or teco or perl), a markup language (like scribe
or html), an object-oriented language (like lisp or smalltalk, not the
latter day pretenders like C++ or Java which are overly static), a
bit-twiddly language (like C or assembly), and so on. From these,
collect a quiver of all the tools of thought you might want to apply
to a problem, and then regardless of which language you choose to
implement your solution, at least conceptualize the problem like you
were going to use a language appropriate to the task you had at hand.
Moving from language to language isn't a process of unlearning, it's a
process of allowing yourself not to be burdened by the constraints of
the previous--only to be enabled by the power of the previous when that
serves your need, and to understand the whole point of moving to the new
language was to be enabled by new virtues.
> Note that
> I don't say that either scheme or logo are bad languages; it is in fact
> precisely because they are good within themselves for learning that
> they become so insidious wrt the eventual learning of CL.
I think more because they implicitly preach an evangelical "this is right,
others are wrong" as part of their curriculum and because it's that mantra,
not the technical aspects, which you have to overcome. If they instead
taught "this is one way of thinking and other languages will teach you
other valued ways of thinking" you'd not have the problem switching.
Because they choose to be evangelical, you often find yourself fighting
fire with fire because there are random little meta tags in people's brains
saying "good"/"bad" that have to be combatted where they should not have to.
But that doesn't mean that's a good way to start.
In 6.035 (the MIT course on compiler design at the time I went to school
as an undergrad there), our mid-term had a question "gotos are (a) good
(b) bad". This is what I mean by evangelism, and it has no place in
teaching. Things are only good or bad in a context, and people should be
teaching contexts, not universal truths.
> I _do_ agree that teaching can be monotonic iff there are no bad thoughts
> to unlearn.
I'm torn on this. This is perhaps the eternal conundrum of how to design
teaching, only here we are talking about how to teach teaching. Do you build
in the pragmatics or do you teach ideals? Do I say "nuclear arms are bad"
or do I say "nuclear arms are necessary if someone else develops them first".
Do I say "evangelism is bad" or do I say "some amount of corrective evangelism
is needed to correct prior evangelical effects". I think the important point
is to focus on not abusing a superior position. Evangelism seems to me to have
as its goal achieving the ideological upper hand; I'm advocating merely
achieving a posture of "live and let live" as far as ideologies go. If the
student isn't capable of getting to the point of evaluating competing theories
for himself/herself, then lisp vs scheme is the least of their problems.
They at that point need a course in how to think, evaluate, judge competing
theories, whehter about programming or about politics or science or whatever.
What causes people to reject "creation science" and either accept (or at least
tentiavely tolerate, pending something better) "darwinism" had better be more
than someone having the upper hand in debate. It should be that one system
favors itself over the other in the face of side-by-side scientific scrutiny
by the learner, not just in emphasis by the teacher.
> To that end, we should be promoting the teaching of CL
> in schools, as an alternative to scheme or logo.
I don't have any moral opposition to Scheme or Logo being taught with Lisp.
I think the argument you want to make here is a shelf space argument.
Syntactically, the school is going to tolerate only so much programming, and
of that an even smaller amount of programming in a language that isn't in
every job offer everywhere. We want CL in that set. Whether anything else
is there depends on whether it fits. But I'd rather have Scheme or Logo
there than Pascal, given that Java will almost certainly teach someone
whatever they need.
[Phew. Now after all that we come to the part of your message that I actually
had meant to reply to. I'll try to be more brief as I plow ahead:]
> The vendors should of
> course do their parts, and I think we do try. But the CL community must
> also do its part:
>
> I have seen outcries for many things that are or are not available in
> the CL standard to be standardized (e.g. foreign interface, multiprocessing,
> defsystem, etc), but I have never heard anyone crying out for a standard
> teaching curriculum and/or interface in CL.
The notion of a "teaching subset" came up in the discussion of what
X3J13 should do. I can't remember if it was during the charter
discussion (because it didn't end up in the charter) or afterward. It
was finally pointed out by one of the teachers among us that no singularly
determined useful subset for teaching was possible, since each teacher would
have their own interests and focus and none agreed. He managed to convince
us of this. We also talked about things that would likely get subsetted
and convinced us that the things one would leave out for teaching were not
things that would make implementations materially smaller, so we decided
not to proceed toward a subset for the purpose of guiding implementors.
We didn't talk about a standardized teaching curriculum, but the
issues seem materially similar. If someone comes up with any
curriculum that works, why does it need to be standard? If there are
two that work, why vote on which is best? The market can sort this
out.
> It would be nice to have a "recommended course of study" for CL, as part
> of the standard.
Standards are too inflexible, too hard to add new ideas, fix bugs,
pursue new thoughts to keep focused on the market.
I suggest this is something the ALU could usefully do. An ALU-endorsed
curriculum or even a set of principles that, if a curriculum conformed to,
would allow endorsement...
Duane Rettig wrote:
> I _do_ agree that teaching can be monotonic iff there are no bad thoughts
> to unlearn. To that end, we should be promoting the teaching of CL
> in schools, as an alternative to scheme or logo.
A while ago -- when I was learning to teach physics -- I remember coming
accross some interesting work (for which I regret I have no reference
:()
This consisted of testing a `good' class taught by a `good' physics
teacher[1] in an American high-school before and after a 10 week course
about electricity. The results were that despite the best efforts of the
teacher that, on average, the pupils scored less well after the the 10
week test than before. The question is why? The teacher was not
incompetent and the kids were reasonably predisposed to learn.
Following further investigation it was found that the reasons for this
were quite subtle and to do with `bad thoughts'.
The mental models that the pupils had about electricity were based on
lifetime experiences and were -- in general -- wrong. However, based on
they models the pupils were able to reason about electricity so as to
answer some or most questions correctly.
It was then found that the teacher had to a greater or lesser extent
suceeded in removing some or most the `bad thoughts' so that after the
course the children had better models to work with.
However, using these models caused the pupils to get more of the
questions wrong.
This is because the new taught model was not like homegrown models. The
pupils found using this model difficult -- it was more abstract -- and
as this was not based on 10+ years of experience it was not completely
trusted. As a consequence of this is that you ended up with a hash of
trying to apply the either the new model, getting confused and then
applying the old model. And geting the question wrong.
So (within the context of this discussion) I would suggest that unless
you are teaching something totally alien (like venusian or something)[2]
you will *alway* have to try and replace some cruft.
Also, it is not sufficient to monotomically remove ideas because you
can't. People are not state machines. I can quite happily hold two
completely contradictory ideas in my head at the same time and unless
they bash into each other I will give this no thought at all.
To suceed you will need to convince people -- by showing them that the
new way of thinking works better or is more appropriate -- and to then
give them some chance to prove this to themselves. Unfortunately, this
is in general very hard. Then again, you can teach nothing to somebody
who is unwilling to learn and you do not need to teaching anything to
somebody who is[3].
Will
-- who gave up teaching as a `bad-job'.
[1] `good' inasmuchas the kids were an average-to-bright mix without any
overwhelming problems (no more than you would expect with a group of 20+
teenagers, anyway) and a `good' teacher: he was bright, commited, liked
and respected by the majority of his students and peers.
[2] and if you don't have any cruft to remove -- like when you learn
quantum mechanics -- it is even harder because you will still try to
apply some cruft that is kicking around in your head -- and this will
simply be *wrong*.
[3] As one cynic I met on my travels put it `don't worry -- there'll
alway be enough middle-class kids in a class to convince you that you're
doing a good job.'
Will wrote:
> who is unwilling to learn and you do not need to teaching anything to
***
[0x477453] Fatal Gerund Interupt: Core Dumped
*this should read*:
> who is unwilling to learn and you do not need to teach anything to
>
> Like all things in life, good teaching should be monotonic, adding to what
> one already knows and providing additional options, not evangelical, replacing
> "bad thought" with so-called "good thought". Sometimes, the result of good
> teaching will be that the learner will decide they can get away with collapsing
> out two ways of thinking about something and using only one, but that should
> be a personal choice of the learner, not a choice of the teacher. The teacher
> should provide options.
>
> CL is about options. Within it, it provides multiple ways to do
> something. The Schemers often hate that. My impression is that they
> see any form of redundancy as a weakness. (I think that's why they don't
> like our two namespace system, too.) I see it as a strength, and
> as a form of tolerance and enlightenment...
Its been about 20 years since I first heard about Lisp. It was at
university and I was talking to a CS major who was taking a course on
compiler and language design. He showed me an example of creating a
Lisp compiler in Lisp. It took about a page and half. I remember being
intrigued by the expressibility of the language, though it was in an
older dialect of Lisp with hardly any indentation. The language stayed
in the back of my mind and I went on to program in Assembler, Pascal, C,
C++ and various other sundry languages.
Then I saw a special edition from the ACM on Lisp. It described
applications it was used for, one of which I was working on at the
time. I decided to learn the language and see if what was said was
true. I started with Scheme, why?, because I had a Mac at home and I
could get my hands on MacScheme. Though no finished program or product
came out of the experience I was hooked on the language. I kept looking
for places to use Scheme on the job and it helped that I had supportive
bosses (who had actually programmed in Lisp). Though the bosses were
sympathetic to programming in Lisp the work still went forward in
C/C++. Most of my co-workers didn't want to learn a new language.
After trying to apply Scheme for a few years, with some successes I
found myself wondering why I was programming in other languages? Most
of the programs I was working on were dead and lifeless. What my
programs ware doing was hidden in so much verbiage that it took too long
to understand (let alone someone else's programs).
I thus decided that Lisp was the way to go and I went with Common Lisp.
I thought with what I had seen so far and the accumulated experience
that had gone into developing CL that it was the right language. I have
not been disappointed!!
Things that were so hard in other languages were easy in Lisp. The
whole development process is so smooth. I could start out programming a
problem in an ad hoc natural fashion and gradually fill in the details.
Traditional waterfall development techniques involve separation of
specification, analysis, design, coding, testing and delivery. With
Lisp I found I could specify, design, code, test all with one language.
No SDL, No high level design docs, no low-level design docs, no testing
docs. Just Lisp code, which when well written was very readable by
other people (even those who do not understand Lisp). This is where I
find that Lisp's main strength is, the idea of the list and its simple
syntax. Then using the language (like english) to write the problem and
its solution. Usually people rely on english to state the problem and
solution in english and then translate it into code. But it ends up
being ambiguous and error prone (not to mention an unnecessary step). A
programmer has to specify the problem and the solution precisely
eventually, so why not from the beginning of the process?
And then using the rich functionality of the language (which was
obviously well thought out when you use CL for awhile) you can get the
computer to automate the solution.
Would this problem->solution approach be a good teaching method? Leave
the discussions about recursion, iterations, conditionals, hash tables
till later. Focus on getting your ideas to work on the computer. I have
seen this in how my kids learn. It works best for them when they wish
to accomplish something and then they learn things they need on the way
to getting it done. They learn much more effectively when what they are
learning is pertinent. Focus on how Lisp does not get in the way but
can be an effective tool in accomplishing things. The teacher is there
to guide the way that has been travelled before. The student is there
to find the way.
Wade
* Wade Humeniuk <········@cadvision.com>
| Would this problem->solution approach be a good teaching method?
| Leave the discussions about recursion, iterations, conditionals,
| hash tables till later. Focus on getting your ideas to work on the
| computer. I have seen this in how my kids learn. It works best for
| them when they wish to accomplish something and then they learn
| things they need on the way to getting it done. They learn much
| more effectively when what they are learning is pertinent. Focus on
| how Lisp does not get in the way but can be an effective tool in
| accomplishing things. The teacher is there to guide the way that
| has been travelled before. The student is there to find the way.
This sounds very much like the Problem-Oriented Learning methodology
now popular in many medical schools. Due to the enormous mass of
knowledge to learn and sheer amounts of information to memorize
(more or less), many ways to motivate students have been tried.
Bringing attention to problems that a (good) teacher can pose in
such a way as to fit the students' expected level of understanding
and skills, means that there is a feeling of mastering problems all
the time. It is reported harder work than the older styles with
lectures and mainly reading several thousand pages of literature,
but that seems to be because students actually do the work, as
opposed to skipping the incredibl boring parts.
I keep thinking the level of attention to detail and the necessity
to learn a tremendous amount of "stuff" for modern programmers is
closer to very established professions like medicine and law than
some of the undereducated punks would dream of in a nightmare. Most
of the CS education I have come across, both my own and what I have
read about elsewhere, has been in uninspiring theory and too little
actually rewarding work, especially as the theories get more and
more advanced and the poor student has _no_ idea whence they all
came, simply because of lack of programming experience. No wonder
today's dot-com coders think they need no education. *Sigh*
#:Erik
--
Does anyone remember where I parked Air Force One?
-- George W. Bush
········@salesman.brownes.org (Christopher Browne) writes:
> I would submit that if Common Lisp was used instead of Scheme, ...
>
> Instead of spending a couple weeks ignoring the Scheme DO form, they
> would spend a couple weeks ignoring DO and LOOP and all the other
> iterative functions of CL.
>
> Courses generally don't seem to present the more "advanced" structures
> of Scheme, such as hash tables, macros, and records/structures. I
> would question why you'd expect them to teach more about CL.
I haven't done a survey, but I'm skeptical about the generalization
being offered here. At my institution, Scheme is used in the first
course in computer science
(http://www.cs.grinnell.edu/~stone/courses/scheme/), and we present the DO
form (http://www.cs.grinnell.edu/~stone/courses/scheme/iteration.xhtml),
records (http://www.cs.grinnell.edu/~stone/courses/scheme/records.xhtml),
and some other topics that might be considered advanced: multiple values
(http://www.cs.grinnell.edu/~stone/courses/scheme/multiple-valued-procedures.xhtml)
and quasiquotation
(http://www.cs.grinnell.edu/~stone/courses/scheme/metaprogramming.xhtml),
for instance. I have to admit that we save hash tables for our second
course (and leave out CASE-expressions, continuations, and EVAL -- but
those aren't really what programmers are most likely to need, are they?).
--
John David Stone - Lecturer in Computer Science and Philosophy
Manager of the Mathematics Local-Area Network
Grinnell College - Grinnell, Iowa 50112 - USA
·····@cs.grinnell.edu - http://www.cs.grinnell.edu/~stone/
Erik Naggum wrote:
>
> I keep thinking the level of attention to detail and the necessity
> to learn a tremendous amount of "stuff" for modern programmers is
> closer to very established professions like medicine and law than
> some of the undereducated punks would dream of in a nightmare.
Steve McConnell argues for a true profession of Software Engineering
including licensing that would require some years of practice.
You can read chapter one of his book, _After_the_Gold_Rush_, at this site:
http://www.construx.com/stevemcc/gr.htm
An overview of his proposal is at:
http://www.construx.com/SEPG2000.pdf
Thanks,
Jeff Sandys, P.E. (licensed Mechanical Engineer)
* Jeff Sandys <·······@asme.org>
| Steve McConnell argues for a true profession of Software Engineering
| including licensing that would require some years of practice.
| You can read chapter one of his book, _After_the_Gold_Rush_, at this site:
| http://www.construx.com/stevemcc/gr.htm
| An overview of his proposal is at:
| http://www.construx.com/SEPG2000.pdf
The reference may be useful to others, as I have already acquired
and read the book, which is quite good, despite being published by
the evil empire. This book led me to read Code Complete, which I
had previously scoffed at out of prejudice towards the publisher,
but it is still _not_ to his credit to have chosen that publisher.
#:Erik
--
Does anyone remember where I parked Air Force One?
-- George W. Bush
Erik Naggum wrote:
> * Jeff Sandys <·······@asme.org>
> | Steve McConnell argues for a true profession of Software Engineering
> | including licensing that would require some years of practice.
> | You can read chapter one of his book, _After_the_Gold_Rush_:
> | http://www.construx.com/stevemcc/gr.htm
> | An overview of his proposal is at:
> | http://www.construx.com/SEPG2000.pdf
>
> The reference may be useful to others, as I have already acquired
> and read the book, which is quite good, despite being published by
> the evil empire. This book led me to read Code Complete, which I
> had previously scoffed at out of prejudice towards the publisher,
> but it is still _not_ to his credit to have chosen that publisher.
I am surprised that you read _Code_Complete_ which is mostly about
C programming. You may also enjoy _Rapid_Development_. In this book
Steve demonstrates how projects fail with fictional accounts of
GigaSoft Corp. As Jack Webb said, "The stories are true, only the
names have been changed ..." _Software_Project_Survival_Guide_ is
the condensed version of _Rapid_Development_ without the stories, all
published by the evil empire. These books are not language specific,
but many of the arguments used for rapid development can also be
made for lisp.
* Jeff Sandys <·······@asme.org>
| I am surprised that you read _Code_Complete_ which is mostly about
| C programming.
C is still a very important programming language. As long as it is
left reasonably alone by the C++ freaks who want very much to
destroy it in the ISO process (i.e., inch it towards C++ and make it
more "modern" (read: useless)), it will probably remain a very
important programming language for a long time to come. It could
become one of those languages that are stable enough to actually
trust, and which means it will no longer be used by the hoi polloi
of programmers (read: young, lonely geeks) who will flock to any
novelty where it takes almost nothing to be best at _something_.
| You may also enjoy _Rapid_Development_.
Steve McConnell has a lot of good and important things to say, but I
have read so many books on soi-disant rapid development over the
years, the title put me off. I'll pick it up, after all. Yes, I
have read his survival guide, too. Cost me several days of USENET
time, but it was worth it. :)
#:Erik
--
Does anyone remember where I parked Air Force One?
-- George W. Bush
There was a depressing (to me) article this year in Embedded
Systems Journal ( tag - Friends don't let friends write assembly
language). It does imply 'C' hasn't made it everywhere yet
(maybe Lisp should take heart?).
> C is still a very important programming language. As long as it is
> left reasonably alone by the C++ freaks who want very much to
> destroy it in the ISO process (i.e., inch it towards C++ and make it
> more "modern" (read: useless)), it will probably remain a very
> important programming language for a long time to come.
You will probably not answer technical questions if I am the one to ask them
but in technical things you are really very reliable so here it is:
If you were to program in C for any reason: Would you stricktly follow the C
standard or would you add C++ elements when necessary; are there additions
of C++ to C which you regard as an enrichment of C?
For example: Does it make a sense to use the *language* of classes when I do
not believe in inheritance and virtual functions and try to avoid them?
And another question: Does not the very idea of templates prove that
something went wrong with C++?
J.B.
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
In article <············@goliath.newsfeeds.com>,
Janos Blazi <······@netsurf.de> wrote:
>> C is still a very important programming language. As long as it is
>> left reasonably alone by the C++ freaks who want very much to
>> destroy it in the ISO process
Too late, I think, although I haven't studied the results of the
latest standardization process.
>
>You will probably not answer technical questions if I am the one to ask them
>but in technical things you are really very reliable so here it is:
>
So I'll answer.
>If you were to program in C for any reason: Would you stricktly follow the C
>standard or would you add C++ elements when necessary; are there additions
>of C++ to C which you regard as an enrichment of C?
>
C is something of a universal assembly language. It's very low-level,
but (when written very carefully) very portable. C++ isn't. If I
write in C, it's for portability - and that's why I stick as closely
as possible to the 1990 standard.
>For example: Does it make a sense to use the *language* of classes when I do
>not believe in inheritance and virtual functions and try to avoid them?
>
That depends on what you're writing and why. If I were writing a
program that could use classes, then either I'd write it is straight
C for portability or I'd write it in another language. C is for
portability or OS code. (And what would you use classes for
without inheritance and virtual functions? Constructors and
destructors? That's about all I can think of.)
>And another question: Does not the very idea of templates prove that
>something went wrong with C++?
>
Why? I see it as an interesting form of polymorphism. It doesn't
really work all that well, but that's true of lots of things in C++.
Personally, I think C++ turned out very well, considering the design
constraints. Obviously a language designed with other constraints
could be much better for most purposes.
One thing C++ lends itself to is the creation of new sublanguages.
It doesn't do that nearly as well as Common Lisp, but it does it
better than other mainstream languages ((equal "mainstream language"
"language with some job ads in the paper") here). Templates are
part of that.
--
David H. Thornley | If you want my opinion, ask.
·····@thornley.net | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-
* "Janos Blazi" <······@netsurf.de>
| You will probably not answer technical questions if I am the one to
| ask them but in technical things you are really very reliable so
| here it is:
I don't react or respond to people, but to what they _do_. You have
certainly made an impression, but that impression may change. If you
do something that _isn't_ annoying, you wouldn't find anyone happier
with that than me, but I would be slightly more irritated than usual
if you didn't keep it up.
| If you were to program in C for any reason: Would you stricktly
| follow the C standard or would you add C++ elements when necessary;
| are there additions of C++ to C which you regard as an enrichment of
| C?
There is nothing useful in C++ that is not already in ISO C. C++ is
about hiding and obfuscation, both of which are ostensible qualities
of abstraction if you do not understand at all what is going on
around you. E.g., _defining_ the interface to the linker such that
you require name mangling is simply retarded. There are many cases
like that. If you do not want to walk the necessary distance, do
not walk the extra mile in some other direction just to show that
you aren't lazy. C++ has done more damage to programming language
design than any other in the history of computing. For one thing,
it showed the wrong people that you _could_ base something on C,
which is really bad, because you can't. C is not the language you
extend. C is the language you do _not_ extend. C is at the far end
of its optimization path. It may be envied for its success, but if
one does not understand that it was much, much prematurely optimized
qua language, there is no hope at all of ever finding any other path
(and I think the "progress" of programming languages in the past
decade has shown _that_ with a depressingly strong forcefulness).
In my opinion, C cannot at this time be improved without breaking it
in important ways (such as C++ in fact did). The ANSI/ISO process
was already a little overzealous with those "const" jokes. (And its
primary designer had to step in to stop them from adding "noalias".)
Neither do I consider the feeble "support" for classes in C++ an
improvement. There is a lot of really clever work in force-feeding
C with stuff it could never really handle, but cleverness and good
intentions do not make a metric for good results.
C++ is the worst kind of misfit: The niche it tries to fill (which
is enabling programmers to think at a much higher level while
forcing them to be concerned with the lowest level details) is a
contradiction in terms and should not be created even though such
contradictions _may_ exist in the software world. If I want what
C++ wanted to give the world, I'll use Java, instead, and write the
stuff that needs tight hardware coupling in pure C. I very seldom
want what C++ tried to give the world in the first place, but that
is another story.
Very few languages are better than C for their purposes. Very few
languages are worse than C++ for their purposes. This is absolutely
no accident. It is a necessarey consequence of optimization, of
very bright people who considered a very narrow problem and solved
it exceptionally well. It's like creating the perfect steam engine
-- you simply cannot use any of that brilliant work if you want an
internal combustion engine or an antigravity propulsion system, and
it is _fantastically_ stupid to think you could, but if you watch
people struggling with unknown problems and known solutions, they
will rather apply more force and energy on making the problems fit
their solutions than snap out of it and try the reverse for a second.
The worst that could "happen" to a very intelligent person is that
is not "allowed" to break out of the conditions set for him by his
precessors. If you cannot say "This is all wrong, let's zoom out
and try over", the best you can hope for is good engineering, but
good engineering should be coupled with good ideas, too, and the
time you discover whether you have a really good idea is when you
_don't_ have to be super clever just to do ordinary stuff, but for
people who love to be clever, who are patted on the back and in many
other ways rewarded for being clever, languages like C++ (and Perl)
will win followers. _Anyone_ can be really clever in C++. _Any_
idiot can sit down with its _enormous_ definition and find some
miniscule point that makes some fairly reaonable thing into a very
special case with far-reaching ramifications that will impress other
idiots. But it is anti-productive, the antithesis of good design,
and a promulgator of cleverness to do the ordinary that means nobody
has any time to be clever on the hard problems.
In C, there is an upper limit to how clever you can be, and that's a
fantastically important property of the language: It means people
tire of being the cleverest, so the cycle of useless rewards stops.
Until a really stupid person came along and invented C with Classes,
of course.
I still use C mainly because it's the Unix system language. It is
hard to interface to Unix without being really good at thinking C.
In like manner, Windows is married to C++, but at least Unix has
real qualities, too.
#:Erik
--
Does anyone remember where I parked Air Force One?
-- George W. Bush
Erik Naggum wrote:
> but for people who love to be clever, who are patted on the back and
> in many other ways rewarded for being clever, languages like C++
> (and Perl) will win followers. _Anyone_ can be really clever in C++.
> _Any_ idiot can sit down with its _enormous_ definition and find some
> miniscule point that makes some fairly reaonable thing into a very
> special case with far-reaching ramifications that will impress other
> idiots.
This is so very true. And crystallises some nebulous thoughts I was
having struggling with.
<ramble>
I have been considering a move, and with this came a period of self
examination. For my sins, I have spent time writing both c and c++ and
have shown some proficiency. For fun (and to polish up on some details)
I started to look at K&R, Stroustrup and the ANSI specs.
On the first evening, after a cocoa and couple of hours reading K&R and
stuff, I had a pleasing glow and as I fell asleep, was feeling fine
about things like the syntax for passing pointers to arrays of functions
and such.
On the second evening, after four hours of fevered activity it became
clear that I was a lousy c++ programmer. There were vast areas of cruft
that I had never used -- even after a couple of years of coding. After
an hour or so of being unable to sleep, I started the MP chapter of
Computer Architecture, and equilibrium was restored.
</ramble>
> But it is anti-productive, the antithesis of good design, and a
> promulgator of cleverness to do the ordinary that means nobody has
> any time to be clever on the hard problems.
Yes -- to use c++ requires the absorption of an enormous mishmash of
stuff, far more than are required for acquaintance with c or common lisp
-- and for people of ordinary intelligence, like myself, it would be far
better for us to struggle with problems than with the tools.
Finally, is there an implementations of c++ that could be said to be
truly ISO compliant?
Thanks for this,
will
In article <·················@pindar.com>,
William Deakin <········@pindar.com> wrote:
[...]
> Finally, is there an implementations of c++ that could be said to be
> truly ISO compliant?
GCC (i think).
--
Glauber Ribeiro
··········@my-deja.com http://www.myvehiclehistoryreport.com
"Opinions stated are my own and not representative of Experian"
Sent via Deja.com http://www.deja.com/
Before you buy.
In article <············@nnrp1.deja.com>, glauber
<··········@my-deja.com> wrote:
> In article <·················@pindar.com>,
> William Deakin <········@pindar.com> wrote:
> [...]
> > Finally, is there an implementations of c++ that could be said to be
> > truly ISO compliant?
>
> GCC (i think).
::sniggers::
Metrowerks CodeWarrior is about the closest that I know of. And
probably Comeau.
-- Bruce
glauber wrote:
> > Finally, is there an implementations of c++ that could be said to be
> > truly ISO compliant?
>
> GCC (i think).
Hmmm, I'm not sure about this...
;)will
"William Deakin" <········@pindar.com> wrote in message
······················@pindar.com...
> Finally, is there an implementations of c++ that could be said to be
> truly ISO compliant?
In reality, most C++ compiler makes (and sadly, their users) still have the
standard as a goal rather than as an achievement.
faa
Frank A. Adrian wrote:
> In reality, most C++ compiler makes (and sadly, their users) still have the
> standard as a goal rather than as an achievement.
:(sigh)
In article <················@naggum.net>,
Erik Naggum <····@naggum.net> wrote:
[...]
> Scheme succeeds because it is
> easy to teach to bright people and fun to implement. Hence, we have
> about a million implementations of Scheme, and only one of them is
> good for anything more than teaching others how to implement Scheme.
OK, i'll ask. Which one?
g.
--
Glauber Ribeiro
··········@my-deja.com http://www.myvehiclehistoryreport.com
"Opinions stated are my own and not representative of Experian"
Sent via Deja.com http://www.deja.com/
Before you buy.
* glauber <··········@my-deja.com>
| OK, i'll ask. Which one?
Please. I would have been a little happier if you had asked about
the million implementations and had recognized "only one of them" as
the obvious hyperbole.
#:Erik
--
Does anyone remember where I parked Air Force One?
-- George W. Bush
In article <················@naggum.net>,
Erik Naggum <····@naggum.net> wrote:
> * glauber <··········@my-deja.com>
> | OK, i'll ask. Which one?
>
> Please. I would have been a little happier if you had asked about
> the million implementations and had recognized "only one of them" as
> the obvious hyperbole.
I thought of that, but i was afraid you'd attach the full list.
--
Glauber Ribeiro
··········@my-deja.com http://www.myvehiclehistoryreport.com
"Opinions stated are my own and not representative of Experian"
Sent via Deja.com http://www.deja.com/
Before you buy.
> You're missing the point: Scheme was designed as a teaching and
> investigation tool, not for "real world" programming. As a learning
language
> it has been far more successful that CL as a general purpose language. :-P
As somebody pointed out to me in this very newsgroup a few months ago,
Scheme was not designed as a teaching tool, though I believed at that time
it was. But the paper by Gabriel and Steele says it was not so.
Anyway, the original intention has nothing to do with the usability of the
language today. As a teacher I am very suspicous when something ismade "with
teaching in mind", for this statement usually serves as an excuse for a poor
product.
As an example I do not use math programs that are designed for teaching. It
is not more difficult to use them than (a limited subset of) Maple V for
example and the advantages are clear.
J.B.
J.B.
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
glauber <··········@my-deja.com> writes:
> I downloaded CMUCL thinking maybe i could get it to compile for AIX and
> Windows (the platforms i currently work in), but it looks like setting it up
> is a daunting task.
Since Windows is not a supported OS, you'd have to write low-level
support for the OS (e.g. signal handling code), etc. first. With AIX
the situation is even worse, since CMUCL has neither support for AIX,
nor a compiler back-end for the POWER processor.
In any case you'd need access to a platform that has a working CMUCL
first, for the cross-compilation.
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
In article <··············@orion.bln.pmsf.de>,
"Pierre R. Mai" <····@acm.org> wrote:
> glauber <··········@my-deja.com> writes:
>
> > I downloaded CMUCL thinking maybe i could get it to compile for AIX and
> > Windows (the platforms i currently work in), but it looks like setting it up
> > is a daunting task.
>
> Since Windows is not a supported OS, you'd have to write low-level
> support for the OS (e.g. signal handling code), etc. first. With AIX
> the situation is even worse, since CMUCL has neither support for AIX,
> nor a compiler back-end for the POWER processor.
>
> In any case you'd need access to a platform that has a working CMUCL
> first, for the cross-compilation.
Thanks!
That's exactly what it looked like to me, and i decided to stay away for now.
g
--
Glauber Ribeiro
··········@my-deja.com http://www.myvehiclehistoryreport.com
"Opinions stated are my own and not representative of Experian"
Sent via Deja.com http://www.deja.com/
Before you buy.
glauber <··········@my-deja.com> writes:
> Incidentally, it seems that there's a lot more interest in developing free
> Scheme systems than Lisp. I guess it's to be expected, since Scheme is
> designed to be simple to implement.
[Reacting to the words I've quoted out of context here, without regard to
whether glauber meant them in the way they read.]
In what other industry is the presence of free implementations a mark of
success? Does the vacuum cleaner industry survive on the wealth of free
implementations for those who can't afford a commercial one?
When the number of implementations of Scheme is so plentiful, you'd hope
the number of USERS was proportionally even more plentiful, but I don't
see that as true. There is SOME serious work in Scheme, but most serious
users don't waste their time implementing scheme, they get right to the
business of using it and focusing on business, and for that they don't need
a plentiful array of free Schemes, they just need one or two committed to
their success.
I've frankly never understood why people think a multitude of free
implementations is a sign of health. It seems more to me a sign of
self-obsession.
Emacs has only a couple of free implementations and is perfectly healthy.
It would be an utter waste of everyone's time for there to be more, each
building incompatible libraries that do essentially the same sets of things,
rather than having just one or two that are moving forward on the shoulders
of others' contributions.
CL has more than enough free implementations, I think.
Moreover, it's an unspoken thesis of CL that simple to implement is not a
criterion. The idea is that everyone needs the same robust common core and
that it's not supposed to be simple to implement. That way, when you get it
you really have something. If implementing it takes only a day, then it
really hasn't saved you much programming. Java and CL agree on this point,
at least, even if Java has a better set of libraries for modern practical
work. And a paucity of free implementations of Java doesn't seem to be
hurting Java any...
In article <···············@world.std.com>,
Kent M Pitman <······@world.std.com> wrote:
> glauber <··········@my-deja.com> writes:
>
> > Incidentally, it seems that there's a lot more interest in
developing free
> > Scheme systems than Lisp. I guess it's to be expected, since Scheme
is
> > designed to be simple to implement.
>
> [Reacting to the words I've quoted out of context here, without
regard to
> whether glauber meant them in the way they read.]
>
> In what other industry is the presence of free implementations a mark
of
> success? Does the vacuum cleaner industry survive on the wealth of
free
> implementations for those who can't afford a commercial one?
>
> When the number of implementations of Scheme is so plentiful, you'd
hope
> the number of USERS was proportionally even more plentiful, but I
don't
> see that as true. There is SOME serious work in Scheme, but most
serious
> users don't waste their time implementing scheme, they get right to
the
> business of using it and focusing on business, and for that they
don't need
> a plentiful array of free Schemes, they just need one or two
committed to
> their success.
>
> I've frankly never understood why people think a multitude of free
> implementations is a sign of health. It seems more to me a sign of
> self-obsession.
It's not a sign of success, but it's one sign of interest and vitality.
Scheme is a young language, while Lisp is mature. Common Lisp has found
its niches and lives there, but unless it finds a way to interest new
programmers, it may not live longer than the current generation of
programmers and the applications they wrote. So, part of the reason why
there are so many Schemes out there is probably the enthusiasm
generated by novelty. In the days when C was young there were also a
bunch of free and cheap compilers available (that's how i learned C).
One way to interest new programmers is to make a good free
implementation available. Good examples are Perl, Python, TCL and Java!
The only 2 usable free implementations of Common Lisp i know of are
CLISP and CMUCL. CLISP is the only one that you can actually take and
compile yourself.
In contrast, look at Kawa, for example, which does seamless integration
of Scheme and Java. Think of the hype potential, or think that if you
are "forced" to program in Java, you can still use Kawa and do your
coding in Scheme. Think of the possibilities, you have the clean syntax
from Scheme and the powerful pre-written libraries from Java. Wow, now
i almost convinced myself to go learn Scheme.
Anyway, i'm not disagreeing with you and this is not meant to say that
C.L. is "better" or "worse" than Scheme, Perl, Python, Java or C.
glauber
--
Glauber Ribeiro
··········@my-deja.com http://www.myvehiclehistoryreport.com
"Opinions stated are my own and not representative of Experian"
Sent via Deja.com http://www.deja.com/
Before you buy.
glauber <··········@my-deja.com> writes:
> The only 2 usable free implementations of Common Lisp i know of are
> CLISP and CMUCL. CLISP is the only one that you can actually take and
> compile yourself.
Depends on whether you use that weird patented meaning of "free" that people
have forced onto many of us who don't like it. In the ordinary meaning of
free ("gratis"), you'll find excellent implementations from Harlequin/Xanalys
and from Franz. Also, Cormon Common Lisp, last I checked, had a very low
cost or free implementation. And certainly GNU CL (formerly KCL) is free
even in the bizarro sense. See the ALU web page to see if this is complete;
it might still not be. The ALU web page is a better source of authority.
On Fri, 27 Oct 2000 23:05:36 GMT, Kent M Pitman <······@world.std.com>
wrote:
> even in the bizarro sense. See the ALU web page to see if this is complete;
> it might still not be. The ALU web page is a better source of authority.
There are also Poplog Common Lisp, ECLSpain and SBCL.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
In article <···············@world.std.com>,
Kent M Pitman <······@world.std.com> wrote:
> glauber <··········@my-deja.com> writes:
>
> > The only 2 usable free implementations of Common Lisp i know of are
> > CLISP and CMUCL. CLISP is the only one that you can actually take and
> > compile yourself.
>
> Depends on whether you use that weird patented meaning of "free" that people
> have forced onto many of us who don't like it. In the ordinary meaning of
> free ("gratis"), you'll find excellent implementations from Harlequin/Xanalys
> and from Franz. Also, Cormon Common Lisp, last I checked, had a very low
> cost or free implementation. And certainly GNU CL (formerly KCL) is free
> even in the bizarro sense. See the ALU web page to see if this is complete;
> it might still not be. The ALU web page is a better source of authority.
>
Well, Corman is a great system, for Windows or Power Mac (though it has a
different name on the Mac).
Harlequin and Franz distribute trial versions of their systems, but they're
limited enough to make them useless for anything other than learning (nothing
wrong there, it's their right to to so).
I'm not sure about GCL; i thought it was just a system for translating Lisp
to C. I'll take another look when i have a minute.
glauber
--
Glauber Ribeiro
··········@my-deja.com http://www.myvehiclehistoryreport.com
"Opinions stated are my own and not representative of Experian"
Sent via Deja.com http://www.deja.com/
Before you buy.
In article <············@nnrp1.deja.com>, glauber
<··········@my-deja.com> wrote:
> Well, Corman is a great system, for Windows or Power Mac (though it has a
> different name on the Mac).
PowerLisp from Roger Corman is a different system from
"Corman Lisp" and outdated.
> I'm not sure about GCL; i thought it was just a system for translating Lisp
> to C. I'll take another look when i have a minute.
GCL is a "normal" Lisp system - it just happens to use
the C compiler to generate native code in an intermediate
step - but the user does not see this directly.
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
* "Rainer" == Rainer Joswig <······@corporate-world.lisp.de> writes:
Rainer> PowerLisp from Roger Corman is a different system from
Rainer> "Corman Lisp" and outdated.
Although some parts of CormanLisp (e.g. the extended LOOP) can be
backported to PowerLisp fairly easy.
--
Eugene
* glauber wrote:
> The only 2 usable free implementations of Common Lisp i know of are
> CLISP and CMUCL. CLISP is the only one that you can actually take and
> compile yourself.
However there is only *one* free implementation of perl. It seems to
be sufficient.
--tim
In article <············@nnrp1.deja.com>, glauber
<··········@my-deja.com> wrote:
> One way to interest new programmers is to make a good free
> implementation available. Good examples are Perl, Python, TCL and Java!
How many usable and used "free" implementations do they have?
They might not even have one commercial implementation.
Actually I think an Lisp system like Macintosh Common Lisp
LispWorks, Genera, you name it, is so productive, that
I don't mind to pay for it a reasonable price. If you
are working professionally this is well worth
the money. Especially if the support is right - which
usually is quite good with Lisp companies.
> The only 2 usable free implementations of Common Lisp i know of are
> CLISP and CMUCL. CLISP is the only one that you can actually take and
> compile yourself.
Common Lisp is a bit more complicated than Scheme. Especially
if you want a real implementation with facilities like
generational incremental GC, FFI, threads, callable from
the OS, native code compiler, OS interfce, GUI toolkit, IDE,
networking, application delivery, tree shaker, etc.
I really urge everyone to think twice whether he/she wants to
spend a few years of their life to write a new Lisp
implementation. Sure new Lisp implementations can be
worthwile and Lisp technology has not reached nirvana -
just make sure you have the resources to really do
something new. There is are many areas where existing
implementations can be improved. Both CLisp and CMUCL
are very interesting and useful implementations -
study those and help the maintainers. It is hard
enough to move CMUCL forward (port it to other
platforms, improve the CLOS implementation,
robust modern incremental GC, robust threading, ...).
It's for example not enough to just introduce
threads and then thinking that's it. Is the Lisp
thread-safe? Is CLOS thread-safe?
The real challenge is to focus on application development.
What are cool Lisp systems worth, if you can't demonstrate
their ability to write equally cool applications.
Finally you have to deal with users (Lisp devevelopers
writing applications) and then you have enough to do,
to make the Lisp implementation really robust, reliable
and equipped with the right feature set. This is
the reason why Lisp has commercial vendors. There
are customers who have mission critical applications
and they need a certain level of quality.
It can't be said often enough: working on the existing
free implementations is a good thing for everyone
interested in "free" software. Writing Lisp applications
and libraries is another area. Finally http://www.lisp.org/
is only good and up to date, when volunteers are maintaining
the site.
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
* Rainer Joswig wrote:
> I really urge everyone to think twice whether he/she wants to
> spend a few years of their life to write a new Lisp
> implementation. Sure new Lisp implementations can be
> worthwile and Lisp technology has not reached nirvana -
> just make sure you have the resources to really do
> something new. There is are many areas where existing
> implementations can be improved. Both CLisp and CMUCL
> are very interesting and useful implementations -
> study those and help the maintainers. It is hard
> enough to move CMUCL forward (port it to other
> platforms, improve the CLOS implementation,
> robust modern incremental GC, robust threading, ...).
> It's for example not enough to just introduce
> threads and then thinking that's it. Is the Lisp
> thread-safe? Is CLOS thread-safe?
I can't agree with this too much. As I said in another post in this
thread, perl does just fine with precisely *one* implementation. while
there are certainly several free C/C++ implementations, one (gcc) is
enormously dominant: I've never used another as far as I can recall.
There is just no correlation between multiplicity of (free)
implementations of a language and success of that language. In fact
if there is a correlation it's probably the reverse of what you might
expect: the more implementations the less successful!
I can't help suspecting that the people who feel that they need to
write a new implementation of a language before they can do anything
useful are actually trying to avoid the awful truth that they don't
have anything useful they want to do. Certainly reimplementing CL is
a good way of ensuring that you have plenty of stuff to do for a good
long while before you get anything useful done.
If people want to contribute to free (in whatever sense we have to use
that word this week) Lisp systems I think it would be much better for
them to spend their time improving one of the existing systems. There
are obvious huge lacunae in most of them. Taking CMUCL as an example:
* CLOS. The current PCL-based implementation has sufficiently low
performance that it discourages CLOS-based programming. An
integrated `native' CLOS is needed.
* Better GC.
* 64bitness (maybe very hard).
* Multithreading (already (partly) done on x86).
* Native multithreading so it can use multiprocessors (undoubtedly
involves GC, and is very hard).
The combination of the last four of these is pretty interesting I
think, and is perhaps the kind of thing that some research-type
institution could get funding to undertake: there must be PhDs in it!
Not only that, but it's a commercially interesting proposition. The
big Unix vendors are making really a lot of money out of large 64bit
shared-memory (or effectively shared-memory in the case of SGI's
ccNUMA machines and probably Sun's E10k followup which is also meant
to be a ccNUMA machine). Lisp is *good* at large systems with complex
sharing of large data objects: it should be a really good match for
these machines. And applications on these machines sell for *really*
high unit costs -- millions of pounds -- so a language implementation
which could make writing such applications less painful than it is in
C (it will always be painful) could really win. But the commercial
lisp vendors are too timid, poor or (perhaps) stupid to take advantage
of this opportunity: even though I think there are 64bit
implementations arriving, there doesn't seem to be any sign of
something that can do native multithreading.
I'm working for a client right now which is likely to move away from
Lisp because they're going to hit the 32bit limit in a year (perhaps
less), and because they can't use the processors they can buy without
essentially converting the machines into a very expensive COW (Cluster
Of Workstations). It's really a tragedy because the advice I must
give them is that they are *right* so to do, even though the
reimplementation effort may be appalling, they just have no
choice. Bizarrely enough, the Boehm GC[1] for C now has parallel
variants (I don't know how scalable they are), so it may be that
*C*[2] will be the first language which offers a garbage-collected,
64bit, native-multithreaded implementation for these large machines.
That's a tragedy as this is high ground that Lisp could gain, if only
Lisp people had the vision to take it instead of trying to beat a
massively established system like Java, or sell Lisp as a language for
the web or whatever it is they think it would be cool to do four
years too late this week.
Well, Enough ranting, I'm sure I'm wrong.
--tim
Footnotes:
[1] http://www.hpl.hp.com/personal/Hans_Boehm/gc/
[2] Interestingly Java is not a candidate as far as I can see: it's
(I think) specified mostly as a 32bit system, and Sun's
`enterprise java' or whatever they call it with it's vastly
improved GC is actually just offering a generational collector
which doesn't look pll to me so will rapidly throttle the system
on multiprocessors.
Tim Bradshaw <···@cley.com> writes:
[ excellent points omitted ]
> If people want to contribute to free (in whatever sense we have to use
> that word this week) Lisp systems I think it would be much better for
> them to spend their time improving one of the existing systems. There
> are obvious huge lacunae in most of them. Taking CMUCL as an example:
>
> * CLOS. The current PCL-based implementation has sufficiently low
> performance that it discourages CLOS-based programming. An
> integrated `native' CLOS is needed.
While the low performance of CMU CL's PCL-based CLOS is often mentioned,
I personally haven't felt _the performance_ of CMU CL's CLOS to have been
a problem: Both in the micro-benchmarks I've conducted, as well as in
real-world usage in non-trivial heavily CLOS-based simulation systems,
I've found CMU CL's CLOS performance to be within a factor of 1.2-1.5 of
the fastest commercial CLOS implementations. Indeed performance was
good enough so that overall application performance was still best in
CMU CL.
I think that the impression of CMU CL's "slow" CLOS stems more from
the fact that it seems slow compared to CMU CL's blindingly fast code
in other areas, rather than from the fact that it is so much slower
than other CLOS implementations.
Which brings me to the problem I have with CMU CL's PCL-based CLOS:
The lack of full integration with the base-system and especially with
the compiler. The resulting rough edges (some spurious warnings
during compilation, MOP-related issues, less optimization done by the
compiler, no-CLOS based code in the base-system, ...) cause the
programmer to get the impression that CLOS code is a second-class
citizen in CMU CL, which is quite harmful.
The good news is that there is progress being made on the CLOS front.
> * Better GC.
Indeed this is one of the areas where IMHO CMU CL has the most
noticeable deficits when compared to commercial implementations,
IMHO. Especially on x86 where the conservative GC sometimes reacts
badly with code produced by the compiler, so that serious amounts of
garbage can remain unreclaimed for longish durations.
[ other problems and interesting problem description elided ]
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
* Pierre R Mai wrote:
> I think that the impression of CMU CL's "slow" CLOS stems more from
> the fact that it seems slow compared to CMU CL's blindingly fast code
> in other areas, rather than from the fact that it is so much slower
> than other CLOS implementations.
I believe that CMUCL's CLOS is significantly slower in many cases than
Allegro's (and probably other commercial systems'). I did do some
reasonable amount of benchmarking to demonstrate this to my
satisfaction a while ago, but I'm afraid I can't find the results just
now. And of course, benchmarks tend to give the answer you want
unless you do them very carefully.
However, I think the slowness compared to other things is very
dangerous. Erik has made this point a number of times about CLISP,
and it's a good point. If the implementation penalises use of certain
features, then people won't use them. The counter-argument to this
(which cropped up a little while ago too) is that quite often
performance is not a huge issue. But this requires programmers to be
seriously rational about what they are doing, and also to be aware of
*when* it matters. People aren't generally very good at either of
these things!
> Which brings me to the problem I have with CMU CL's PCL-based CLOS:
> The lack of full integration with the base-system and especially with
> the compiler. The resulting rough edges (some spurious warnings
> during compilation, MOP-related issues, less optimization done by the
> compiler, no-CLOS based code in the base-system, ...) cause the
> programmer to get the impression that CLOS code is a second-class
> citizen in CMU CL, which is quite harmful.
I definitely agree with this.
Well, working for "one of those 64 bit vendors" - HP in my case - leads
me to ask:
HOW COULD I HELP ?
What would it need to make the 64 bit CLOS implementation to become
truth?
Who would do it? The LC (my favorite abbreviation for LISP Community ;-)
) ? Or a LISP vendor? Or the H/W vendor together with a LISP vendor (oh,
did I get all those upper case and lower case letters right, E...?) ?
Maybe it helps to look at this the other way:
How could the LC "sell" this idea to a 64 bit vendor (I know by
experience that it really has to do with big numbers prefixed with a
dollar sign) - WHAT IS THE BUSINESS CASE?
If we can put this business case together and can put it in context with
the E-services hype it will sell and it will get implemented.
I really would like to help - could we come up with a separate thread
and a productive discussion on this ?
Looking forward to get feedback!
Regards,
FRGO
Frank G�nninger, HP Consulting, Hewlett-Packard GmbH, Germany
P.S, Of course I am not only looking for 64 bit... I'd like to get the
other features as well. FRGO
Tim Bradshaw wrote:
>
> * Rainer Joswig wrote:
>
> > I really urge everyone to think twice whether he/she wants to
> > spend a few years of their life to write a new Lisp
> > implementation. Sure new Lisp implementations can be
> > worthwile and Lisp technology has not reached nirvana -
> > just make sure you have the resources to really do
> > something new. There is are many areas where existing
> > implementations can be improved. Both CLisp and CMUCL
> > are very interesting and useful implementations -
> > study those and help the maintainers. It is hard
> > enough to move CMUCL forward (port it to other
> > platforms, improve the CLOS implementation,
> > robust modern incremental GC, robust threading, ...).
> > It's for example not enough to just introduce
> > threads and then thinking that's it. Is the Lisp
> > thread-safe? Is CLOS thread-safe?
>
> I can't agree with this too much. As I said in another post in this
> thread, perl does just fine with precisely *one* implementation. while
> there are certainly several free C/C++ implementations, one (gcc) is
> enormously dominant: I've never used another as far as I can recall.
>
> There is just no correlation between multiplicity of (free)
> implementations of a language and success of that language. In fact
> if there is a correlation it's probably the reverse of what you might
> expect: the more implementations the less successful!
>
> I can't help suspecting that the people who feel that they need to
> write a new implementation of a language before they can do anything
> useful are actually trying to avoid the awful truth that they don't
> have anything useful they want to do. Certainly reimplementing CL is
> a good way of ensuring that you have plenty of stuff to do for a good
> long while before you get anything useful done.
>
> If people want to contribute to free (in whatever sense we have to use
> that word this week) Lisp systems I think it would be much better for
> them to spend their time improving one of the existing systems. There
> are obvious huge lacunae in most of them. Taking CMUCL as an example:
>
> * CLOS. The current PCL-based implementation has sufficiently low
> performance that it discourages CLOS-based programming. An
> integrated `native' CLOS is needed.
>
> * Better GC.
>
> * 64bitness (maybe very hard).
>
> * Multithreading (already (partly) done on x86).
>
> * Native multithreading so it can use multiprocessors (undoubtedly
> involves GC, and is very hard).
>
> The combination of the last four of these is pretty interesting I
> think, and is perhaps the kind of thing that some research-type
> institution could get funding to undertake: there must be PhDs in it!
>
> Not only that, but it's a commercially interesting proposition. The
> big Unix vendors are making really a lot of money out of large 64bit
> shared-memory (or effectively shared-memory in the case of SGI's
> ccNUMA machines and probably Sun's E10k followup which is also meant
> to be a ccNUMA machine). Lisp is *good* at large systems with complex
> sharing of large data objects: it should be a really good match for
> these machines. And applications on these machines sell for *really*
> high unit costs -- millions of pounds -- so a language implementation
> which could make writing such applications less painful than it is in
> C (it will always be painful) could really win. But the commercial
> lisp vendors are too timid, poor or (perhaps) stupid to take advantage
> of this opportunity: even though I think there are 64bit
> implementations arriving, there doesn't seem to be any sign of
> something that can do native multithreading.
>
> I'm working for a client right now which is likely to move away from
> Lisp because they're going to hit the 32bit limit in a year (perhaps
> less), and because they can't use the processors they can buy without
> essentially converting the machines into a very expensive COW (Cluster
> Of Workstations). It's really a tragedy because the advice I must
> give them is that they are *right* so to do, even though the
> reimplementation effort may be appalling, they just have no
> choice. Bizarrely enough, the Boehm GC[1] for C now has parallel
> variants (I don't know how scalable they are), so it may be that
> *C*[2] will be the first language which offers a garbage-collected,
> 64bit, native-multithreaded implementation for these large machines.
> That's a tragedy as this is high ground that Lisp could gain, if only
> Lisp people had the vision to take it instead of trying to beat a
> massively established system like Java, or sell Lisp as a language for
> the web or whatever it is they think it would be cool to do four
> years too late this week.
>
> Well, Enough ranting, I'm sure I'm wrong.
>
> --tim
>
> Footnotes:
> [1] http://www.hpl.hp.com/personal/Hans_Boehm/gc/
>
> [2] Interestingly Java is not a candidate as far as I can see: it's
> (I think) specified mostly as a 32bit system, and Sun's
> `enterprise java' or whatever they call it with it's vastly
> improved GC is actually just offering a generational collector
> which doesn't look pll to me so will rapidly throttle the system
> on multiprocessors.
We have two 64-bit versions of Allegro CL 6.0, one for HP-UX 11.00 and the
other for Compaq Tru64 4.0 and 5.0.
In the case of HP, we worked closely with them to do the port.
Kevin Layer
Franz Inc.
"Frank Goenninger" <················@hp.com> wrote in message
······················@hp.com...
> Well, working for "one of those 64 bit vendors" - HP in my case - leads
>
> me to ask:
>
>
>
> HOW COULD I HELP ?
>
>
>
> What would it need to make the 64 bit CLOS implementation to become
>
> truth?
>
> Who would do it? The LC (my favorite abbreviation for LISP Community ;-)
>
> ) ? Or a LISP vendor? Or the H/W vendor together with a LISP vendor (oh,
>
> did I get all those upper case and lower case letters right, E...?) ?
>
>
>
> Maybe it helps to look at this the other way:
>
>
>
> How could the LC "sell" this idea to a 64 bit vendor (I know by
>
> experience that it really has to do with big numbers prefixed with a
>
> dollar sign) - WHAT IS THE BUSINESS CASE?
>
>
>
> If we can put this business case together and can put it in context with
>
> the E-services hype it will sell and it will get implemented.
>
>
>
> I really would like to help - could we come up with a separate thread
>
> and a productive discussion on this ?
>
>
>
> Looking forward to get feedback!
>
>
>
> Regards,
>
> FRGO
>
>
>
> Frank G�nninger, HP Consulting, Hewlett-Packard GmbH, Germany
>
>
>
> P.S, Of course I am not only looking for 64 bit... I'd like to get the
>
> other features as well. FRGO
>
>
>
> Tim Bradshaw wrote:
> >
> > * Rainer Joswig wrote:
> >
> > > I really urge everyone to think twice whether he/she wants to
> > > spend a few years of their life to write a new Lisp
> > > implementation. Sure new Lisp implementations can be
> > > worthwile and Lisp technology has not reached nirvana -
> > > just make sure you have the resources to really do
> > > something new. There is are many areas where existing
> > > implementations can be improved. Both CLisp and CMUCL
> > > are very interesting and useful implementations -
> > > study those and help the maintainers. It is hard
> > > enough to move CMUCL forward (port it to other
> > > platforms, improve the CLOS implementation,
> > > robust modern incremental GC, robust threading, ...).
> > > It's for example not enough to just introduce
> > > threads and then thinking that's it. Is the Lisp
> > > thread-safe? Is CLOS thread-safe?
> >
> > I can't agree with this too much. As I said in another post in this
> > thread, perl does just fine with precisely *one* implementation. while
> > there are certainly several free C/C++ implementations, one (gcc) is
> > enormously dominant: I've never used another as far as I can recall.
> >
> > There is just no correlation between multiplicity of (free)
> > implementations of a language and success of that language. In fact
> > if there is a correlation it's probably the reverse of what you might
> > expect: the more implementations the less successful!
> >
> > I can't help suspecting that the people who feel that they need to
> > write a new implementation of a language before they can do anything
> > useful are actually trying to avoid the awful truth that they don't
> > have anything useful they want to do. Certainly reimplementing CL is
> > a good way of ensuring that you have plenty of stuff to do for a good
> > long while before you get anything useful done.
> >
> > If people want to contribute to free (in whatever sense we have to use
> > that word this week) Lisp systems I think it would be much better for
> > them to spend their time improving one of the existing systems. There
> > are obvious huge lacunae in most of them. Taking CMUCL as an example:
> >
> > * CLOS. The current PCL-based implementation has sufficiently low
> > performance that it discourages CLOS-based programming. An
> > integrated `native' CLOS is needed.
> >
> > * Better GC.
> >
> > * 64bitness (maybe very hard).
> >
> > * Multithreading (already (partly) done on x86).
> >
> > * Native multithreading so it can use multiprocessors (undoubtedly
> > involves GC, and is very hard).
> >
> > The combination of the last four of these is pretty interesting I
> > think, and is perhaps the kind of thing that some research-type
> > institution could get funding to undertake: there must be PhDs in it!
> >
> > Not only that, but it's a commercially interesting proposition. The
> > big Unix vendors are making really a lot of money out of large 64bit
> > shared-memory (or effectively shared-memory in the case of SGI's
> > ccNUMA machines and probably Sun's E10k followup which is also meant
> > to be a ccNUMA machine). Lisp is *good* at large systems with complex
> > sharing of large data objects: it should be a really good match for
> > these machines. And applications on these machines sell for *really*
> > high unit costs -- millions of pounds -- so a language implementation
> > which could make writing such applications less painful than it is in
> > C (it will always be painful) could really win. But the commercial
> > lisp vendors are too timid, poor or (perhaps) stupid to take advantage
> > of this opportunity: even though I think there are 64bit
> > implementations arriving, there doesn't seem to be any sign of
> > something that can do native multithreading.
> >
> > I'm working for a client right now which is likely to move away from
> > Lisp because they're going to hit the 32bit limit in a year (perhaps
> > less), and because they can't use the processors they can buy without
> > essentially converting the machines into a very expensive COW (Cluster
> > Of Workstations). It's really a tragedy because the advice I must
> > give them is that they are *right* so to do, even though the
> > reimplementation effort may be appalling, they just have no
> > choice. Bizarrely enough, the Boehm GC[1] for C now has parallel
> > variants (I don't know how scalable they are), so it may be that
> > *C*[2] will be the first language which offers a garbage-collected,
> > 64bit, native-multithreaded implementation for these large machines.
> > That's a tragedy as this is high ground that Lisp could gain, if only
> > Lisp people had the vision to take it instead of trying to beat a
> > massively established system like Java, or sell Lisp as a language for
> > the web or whatever it is they think it would be cool to do four
> > years too late this week.
> >
> > Well, Enough ranting, I'm sure I'm wrong.
> >
> > --tim
> >
> > Footnotes:
> > [1] http://www.hpl.hp.com/personal/Hans_Boehm/gc/
> >
> > [2] Interestingly Java is not a candidate as far as I can see: it's
> > (I think) specified mostly as a 32bit system, and Sun's
> > `enterprise java' or whatever they call it with it's vastly
> > improved GC is actually just offering a generational collector
> > which doesn't look pll to me so will rapidly throttle the system
> > on multiprocessors.
>
* Frank Goenninger wrote:
> Well, working for "one of those 64 bit vendors" - HP in my case - leads
> me to ask:
> HOW COULD I HELP ?
I believe that acl 6 has a 64bit version on HP -- you should probably
ask Franz about this. My comment on 64bityness was specifically meant
in terms of free implementations (later on in the article I got a bit
carried away and more general)
--tim
Frank Goenninger <················@hp.com> writes:
> Well, working for "one of those 64 bit vendors" - HP in my case - leads
>
> me to ask:
>
>
>
> HOW COULD I HELP ?
>
>
>
> What would it need to make the 64 bit CLOS implementation to become
>
> truth?
>
> Who would do it? The LC (my favorite abbreviation for LISP Community ;-)
>
> ) ? Or a LISP vendor? Or the H/W vendor together with a LISP vendor (oh,
>
> did I get all those upper case and lower case letters right, E...?)
?
Now at least one firm currently build a Lisp for a 64-bit system and
that's symbolic. I don't know if it was here where the reasons were
posted. But at least it seems to give a 64-bit Lisp.
Now it could be that symbolics would be happy to port their system
from ALPHA True Unix to HP-UX. I'm sure if HP really would ask, a lot
of Lisp experts would be happy to work on that project.
>
> How could the LC "sell" this idea to a 64 bit vendor (I know by
>
> experience that it really has to do with big numbers prefixed with a
>
> dollar sign) - WHAT IS THE BUSINESS CASE?
That is a good question. And I have not the slightest idea. The thing
that could work (read it's speculative) that it would be a very
productive programming environment. That would require of course that
it really would be more productive. A lot of Lisp lovers tend to take this as
granted. Just figures are missing.
>
>
>
> If we can put this business case together and can put it in context with
>
> the E-services hype it will sell and it will get implemented.
Put in a bit of the open-source hype too ;-) I can't say that I put HP
in that context;-)
Regards
Friedrich
--
for e-mail reply remove all after .com
In article <··············@q-software-solutions.com>,
·····@q-software-solutions.com.NO-spam wrote:
> Now it could be that symbolics would be happy to port their system
> from ALPHA True Unix to HP-UX. I'm sure if HP really would ask, a lot
> of Lisp experts would be happy to work on that project.
Who pays for it? WHo needs it? Who maintains it?
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
Rainer Joswig <······@corporate-world.lisp.de> writes:
> In article <··············@q-software-solutions.com>,
> ·····@q-software-solutions.com.NO-spam wrote:
>
> > Now it could be that symbolics would be happy to port their system
> > from ALPHA True Unix to HP-UX. I'm sure if HP really would ask, a lot
> > of Lisp experts would be happy to work on that project.
>
> Who pays for it?
Hopefully HP ;-)
WHo needs it?
Can't tell. And probably nobody.
Who maintains it?
No idea, but I would think some would enjoy working for it. And if the
got paid too ...;-)
The point is that good points were made. What would anyone gain from
it? I do not have any idea. But I could ask who has gained from Apache
in it's beginning? Who has gained from Linux (there were other free
Unices available to that time?).
The other mentioned thing is how could HP raise their profits on
it. Now I have no clue. If one looks into the last survey of the
german Unix magazine iX, HP-UX is not int the strongest position. I
can't tell if they would find themselves in a better position with
that Lisp, but I doubt it.
Regards
Friedrich
--
for e-mail reply remove all after .com
* Friedrich Dominicus wrote:
> Now at least one firm currently build a Lisp for a 64-bit system and
> that's symbolic. I don't know if it was here where the reasons were
> posted. But at least it seems to give a 64-bit Lisp.
No, the Genera port for alpha is really mostly an emulator of their HW
lisp-machines, and as such has a 32bit (or less, perhaps) address
space. Those machines were (I think!) word-addressed though so it's
probably more like 36bits worth of byte-addressed space. I think the
reason that they run on alpha is that it's a whole lot easier to make
a n+m bit emulator run on a 2n bit machine so long as m is less than
n.
--tim
On 28 Oct 2000 13:53:35 +0100, Tim Bradshaw <···@cley.com> wrote:
> I'm working for a client right now which is likely to move away from
> Lisp because they're going to hit the 32bit limit in a year (perhaps
ECL-Spain is an ECoLisp fork that, among other things, is moving toward
better ANSI compliance. One of its goals is to be ported to 64-bit
environments, but I have no idea of neither how much work is involved, nor
whether progress is being made. The project's site is:
http://www.arrakis.es/~worm/ecls.html
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
glauber <··········@my-deja.com> writes:
> It's not a sign of success, but it's one sign of interest and vitality.
> Scheme is a young language, while Lisp is mature. Common Lisp has found
> its niches and lives there, but unless it finds a way to interest new
> programmers, it may not live longer than the current generation of
> programmers and the applications they wrote. So, part of the reason why
> there are so many Schemes out there is probably the enthusiasm
> generated by novelty. In the days when C was young there were also a
> bunch of free and cheap compilers available (that's how i learned C).
>
Scheme is not that young. Actually, Scheme predates Common Lisp.
I think the reason every second Scheme programmer reimplements the
language is the same reason every Forth programmer does. The language
is by design very spartan and a lot of things you need to do real
applications is missing and has to be added, either by the
implementation or by the programmer. Given that you're forced in the
role of language implementor anyway, many people chose to start from
their own foundation.
--
Lieven Marchand <···@bewoner.dma.be>
Lambda calculus - Call us a mad club
Lieven Marchand <···@bewoner.dma.be> writes:
> Scheme is not that young. Actually, Scheme predates Common Lisp.
Yep. The first Scheme report was 1978, I believe. The earliest CL
draft was 1981. Steele was key in the creation of both. Scheme
contributed the "controversial" notion of lexical scoping to Common
Lisp.
> I think the reason every second Scheme programmer reimplements the
> language is the same reason every Forth programmer does. The language
> is by design very spartan and a lot of things you need to do real
> applications is missing and has to be added, either by the
> implementation or by the programmer. Given that you're forced in the
> role of language implementor anyway, many people chose to start from
> their own foundation.
I think it goes deeper than this. I think the people who teach it and the
examples they choose when they teach it lead people to believe that
reimplementing it is a "mitzva" ("good thing"). It takes a while for
students to understand that just because a thing is "possible" it's not
always a "good idea". (Not to draw too sharp a parallel between two
hopefully unrelated concepts, but I think this is the reason viruses
get written as well.)
Students come out of school with a tremendous amount of zeal and energy that
is often worn away in the first few years. Companies parasite on this by
working them hard and paying them little. But often before companies get to
them, they sit around making projects for themselves to prove themselves.
A thesis is one such thing. But we owe it to students to point them in the
direction of new things that need to be done, rather than have them repeat
things that are done deals.
When I was at MIT, it was often pointed out to me, sometimes implicitly and
as often explicitly, that one must strive never repeat what others have
already done. There was always the pressure for the new and different. You'd
see it in thesis topics especially. Someone could write a masters' thesis
at many colleges in "a compiler for Lisp" and get away with it, but even in
1980, that was "already done" and not an acceptable masters' thesis topic
unless you had a specific new theory of how that compiler should work. At the
same time, I distinctly remember noting (often with the MIT-induced disdain
for the outside that I hadn't yet learned to question) that "other colleges"
(say it with a sneer to get a proper sense of it all) allowed their students
to get away with that kind of stuff. At the time, it was always explained to
me as that they just didn't care to force their students to think or maybe
the students weren't up to it. (Over the years, I've come to think much more
highly of those "other schools", but it was something I had to learn
gradually.) However, as often happens, perhaps there was a core value here
that was good without being recognized for its proper nature. Maybe the issue
of whether people are capable or not of new ideas isn't relevant. But the
push to go through the exercise of looking for new ideas, regardless of whether
you find them, and of saying "if it's already been done, maybe there's a better
use of me to find something that's not" isn't such a bad plan and perhaps some
of those "other schools" should be doing more of what MIT was doing. Not to
prove that they are as smart as smarter than the "MIT way", which is an utter
red herring, but because it's simply a good idea to say "let's teach people
to stretch".
Now, there is an alternate point of view that says that the Japanese notion of
"kaizen" (tuning an already existing thing in an engineering way) is a
legitimate art in its own right, but I like to think that "kaizen" is done for
the purpose of achieving a business edge over someone who is already succeeding
without having done this. In the case of Scheme, the problem is not that
implementation A is beating the pants off of implementation B and that some
"engineering tuning" will squeeze an extra few dollars out of the marketplace,
so I don't see what many just-graduated Schemers are often found doing as
legitimate kaizen. Maybe that's just because I'm not seeing it from the right
point of view, but I mostly seeing as "smart people wasting themselves".
I'm told it used to be, long ago, that to be a mathemetician, one spent a lot
of one's life memorizing logarithms so that one would have them at hand when
one needed them. Whether or not it's true in detail, I'm sure it's
illustrative of the general point that now we have calculators and it's
purposeless for anyone who aspires to be a mathemetician to waste any time at
all memorizing what he could as easily punch into a calculator as long as he
understands the general shape of what he's doing enough to go in the right
directions. We always think we're so much smarter than previous generations,
but my assumption is that we frequently repeat their mistakes by not
recognizing that it's merely the look of the situation that changes. The
important issue isn't logarithms or not, but it's "what is new" vs "what is
routine". One's life will not have contributed much by merely contributing
routine. And when making a Scheme compiler becomes routine, it's time not
to do it and to move on to what Scheme itself is good for.
This is the reason that Java is succeeding in spite of its poorly constructed
and extremely painful language layer. Because it has moved on to libraries,
and is not obsessing forever with language design. Lisp is better at the
language level, but that's not enough. It matters to be better at all the
stuff that follows before you can compare something that's been left behind.
If Lisp can't commit to move on and focus on libraries at an aggressive level,
and teach its followers that this is where the investment of what youthful
energy we are graced with should go, the lack of foundation argument will
sink into insignificance with time.
On Sat, 28 Oct 2000 22:49:13 GMT, Kent M Pitman <······@world.std.com>
wrote:
> A thesis is one such thing. But we owe it to students to point them in the
> direction of new things that need to be done, rather than have them repeat
> things that are done deals.
Any suggestions concerning worthy Common Lisp projects, not necessarily for
students?
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
In article <····························@4ax.com>, Paolo Amoroso
<·······@mclink.it> wrote:
> On Sat, 28 Oct 2000 22:49:13 GMT, Kent M Pitman <······@world.std.com>
> wrote:
>
> > A thesis is one such thing. But we owe it to students to point them in the
> > direction of new things that need to be done, rather than have them repeat
> > things that are done deals.
>
> Any suggestions concerning worthy Common Lisp projects, not necessarily for
> students?
Not necessarily of "academic" interest:
- CMUCL support for multiple processors + GC.
- CMUCL port to MacOS X.
- (maybe portable) development environment based on (Free) CLIM
- redesign/reimplement CL from a small kernel
- See also the list of proposed CL-HTTP projects:
http://wilson.ai.mit.edu/cl-http/projects.html
(Hmm, we need to cleanup the list a bit.)
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
Rainer Joswig <······@corporate-world.lisp.de> writes:
> - CMUCL port to MacOS X.
Well, the port to MacOS X itself shouldn't be much work (given that
for the purposes of basic CMU CL it's just a BSD, and FreeBSD is
already supported well). The hard part is writing a compiler backend
for PowerPC. Although CMU CL supported the IBM RT/PC at some point in
the distant past, this is architecturally quite different from the
POWER architecture or the PowerPC, and anyway the backend has probably
decayed beyond hope in the meantime...
Other projects in the porting area (in increasing order of difficulty,
but probably also in increasing order of academic interest):
- Write a backend for CMU CL for the upcoming AMD Sledgehammer 64bit
architecture.
- Write a conservative backend for CMU CL for the ia64 architecture
(i.e. it is probably not possible to make decent use of the ia64
without rewriting the whole compiler framework, so this might be a
study in how far you can go in compiling to ia64 within a
traditional compiler framework),
- Rewrite compiler framework to fully support VLIW-style architectures
(ia64).
Of course the problem with all of the above is that all the
architectures are still emulation-only for mere mortals. But once the
student has finished his port to PowerPC, the ia64 should be available
in silicon ;)
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
On Tue, 31 Oct 2000 17:38:40 +0100, Rainer Joswig
<······@corporate-world.lisp.de> wrote:
>> Any suggestions concerning worthy Common Lisp projects, not necessarily for
>> students?
>
>Not necessarily of "academic" interest:
>
>- CMUCL support for multiple processors + GC.
>- CMUCL port to MacOS X.
And win32. O:-)
>- (maybe portable) development environment based on (Free) CLIM
>- redesign/reimplement CL from a small kernel
And an apache module? Yes, yes, I know, but sometimes you can't chose
the http server... :-(
//-----------------------------------------------
// Fernando Rodriguez Romero
//
// frr at mindless dot com
//------------------------------------------------
In article <··································@4ax.com>,
Fernando Rodr�guez <·······@must.die> wrote:
> >Not necessarily of "academic" interest:
> >
> >- CMUCL support for multiple processors + GC.
> >- CMUCL port to MacOS X.
>
> And win32. O:-)
Yeah, why not. Also add support for LispOS. ;-)
For Win32 the Windows OS (ME/2000/whatever) support would
have to developed. CMUCL currently runs more under Unix-like
operating systems.
For MacOS X (which is a Unix OS underneath) the native
code generation would have to be developed (which might
be a worthwile start to later include other processors, too)
and some OS support - since MacOS X has a lot of extensions
and it is not using X11 for its window system.
> >- redesign/reimplement CL from a small kernel
>
> And an apache module? Yes, yes, I know, but sometimes you can't chose
> the http server... :-(
Has anybody else something to add to the wishlist? :-)
Oh, I have another one: port SK8 to CMUCL.
See http://corporate-world.lisp.de/mcl/sk8.jpg for a
screenshort of some basic SK8ing in Macintosh Common Lisp.
It's kind of the mother of all interface builders.
Sent via Deja.com http://www.deja.com/
Before you buy.
······@corporate-world.lisp.de writes:
> Has anybody else something to add to the wishlist? :-)
Sure, but somewhat easier tasks:
- CL library for _writing_ PNG images, perhaps based on the
png-reader code in the Closure web browser.
- CL library for reading and writing TIFF
- same for JPEG
--
chr
In article <··············@siteloft.no>, ·····@eunet.no (Christian
Nyb?) wrote:
> ······@corporate-world.lisp.de writes:
>
> > Has anybody else something to add to the wishlist? :-)
>
> Sure, but somewhat easier tasks:
Sounds good.
> - CL library for _writing_ PNG images, perhaps based on the
> png-reader code in the Closure web browser.
> - CL library for reading and writing TIFF
I've seen those. Lispix does it for example:
http://www.nist.gov/lispix/
Obvius has code to interface an external TIFF library:
ftp://www-white.media.mit.edu/pub/obvius/
> - same for JPEG
JPEG is here: http://members.home.net/vogt/jpeg.lisp
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
Fernando Rodr�guez <·······@must.die> writes:
>
> And an apache module? Yes, yes, I know, but sometimes you can't chose
> the http server... :-(
>
fastcgi might be worth looking at. It should allow apache to talk to
a persistent application server like a CL image. Since we were
talking about protocol design, fastcgi is pretty braindead as far as I
can see, but it exists, and so long as your lisp can do fast I/O it's
probably pretty fast.
--tim
>fastcgi might be worth looking at. It should allow apache to talk to
>a persistent application server like a CL image. Since we were
>talking about protocol design, fastcgi is pretty braindead as far as I
>can see, but it exists, and so long as your lisp can do fast I/O it's
>probably pretty fast.
Another valid option is the mod_jserv half of the Apache JServ servlet
engine. The protocol is documented at
http://java.apache.org/jserv/protocol/AJPv11.html
This is just interesting because it's a module designed and documented to
talk over a socket to Something Else.
Regards,
Will Hartung
(············@havasint.com)
Tim Bradshaw <···@tfeb.org> writes:
| fastcgi might be worth looking at. It should allow apache to talk to
| a persistent application server like a CL image. Since we were
FWIW, a friend of mine implemented a fastcgi interface (and
possibly some sugar on top of it) for CMUCL. Unfortunately he (and
thus also the code, which I didn't remember to ask from him in
time) is going to be unavailable for a few months.
--
Hannu
"Fernando Rodr�guez" <·······@must.die> wrote in message
·······································@4ax.com...
> On Tue, 31 Oct 2000 17:38:40 +0100, Rainer Joswig
> <······@corporate-world.lisp.de> wrote:
> And an apache module? Yes, yes, I know, but sometimes you can't chose
> the http server... :-(
I've written an Apache mod_lisp but it's still in a very early stage.
Marc Battyani
In our last episode (Sat, 28 Oct 2000 22:49:13 GMT),
the artist formerly known as Kent M Pitman said:
>Lieven Marchand <···@bewoner.dma.be> writes:
>
>> Scheme is not that young. Actually, Scheme predates Common Lisp.
>
>Yep. The first Scheme report was 1978, I believe. The earliest CL
>draft was 1981. Steele was key in the creation of both. Scheme
>contributed the "controversial" notion of lexical scoping to Common
>Lisp.
Those that claim Scheme is "new" just have no sense of history :-).
>> I think the reason every second Scheme programmer reimplements the
>> language is the same reason every Forth programmer does. The language
>> is by design very spartan and a lot of things you need to do real
>> applications is missing and has to be added, either by the
>> implementation or by the programmer. Given that you're forced in the
>> role of language implementor anyway, many people chose to start from
>> their own foundation.
>I think it goes deeper than this. I think the people who teach it
>and the examples they choose when they teach it lead people to
>believe that reimplementing it is a "mitzva" ("good thing"). It
>takes a while for students to understand that just because a thing is
>"possible" it's not always a "good idea". (Not to draw too sharp a
>parallel between two hopefully unrelated concepts, but I think this
>is the reason viruses get written as well.)
>
>Students come out of school with a tremendous amount of zeal and
>energy that is often worn away in the first few years. Companies
>parasite on this by working them hard and paying them little. But
>often before companies get to them, they sit around making projects
>for themselves to prove themselves. A thesis is one such thing. But
>we owe it to students to point them in the direction of new things
>that need to be done, rather than have them repeat things that are
>done deals.
I tend to agree. There's another perspective; more anon...
>When I was at MIT, it was often pointed out to me, sometimes
>implicitly and as often explicitly, that one must strive never repeat
>what others have already done. There was always the pressure for the
>new and different. You'd see it in thesis topics especially.
>Someone could write a masters' thesis at many colleges in "a compiler
>for Lisp" and get away with it, but even in 1980, that was "already
>done" and not an acceptable masters' thesis topic unless you had a
>specific new theory of how that compiler should work. At the same
>time, I distinctly remember noting (often with the MIT-induced
>disdain for the outside that I hadn't yet learned to question) that
>"other colleges" (say it with a sneer to get a proper sense of it
>all) allowed their students to get away with that kind of stuff. At
>the time, it was always explained to me as that they just didn't care
>to force their students to think or maybe the students weren't up to
>it. (Over the years, I've come to think much more highly of those
>"other schools", but it was something I had to learn gradually.)
>However, as often happens, perhaps there was a core value here that
>was good without being recognized for its proper nature. Maybe the
>issue of whether people are capable or not of new ideas isn't
>relevant. But the push to go through the exercise of looking for new
>ideas, regardless of whether you find them, and of saying "if it's
>already been done, maybe there's a better use of me to find something
>that's not" isn't such a bad plan and perhaps some of those "other
>schools" should be doing more of what MIT was doing. Not to prove
>that they are as smart as smarter than the "MIT way", which is an
>utter red herring, but because it's simply a good idea to say "let's
>teach people to stretch".
I think I can characterize this a bit more briefly by suggesting that
the "MIT Way" is oriented towards the "Ph.D Way."
A Ph.D thesis is supposed to include some notion of the "novel;" it is
supposed to extend knowledge into outright New Things. To get a Ph.D,
it does not suffice to do a "good survey," and perhaps to "reimplement
the wheel," both of which may be quite acceptable at the Master's
level.
MIT is certainly in the business of "generating Ph.Ds," and thus puts
considerable emphasis on "doing novel stuff."
>This is the reason that Java is succeeding in spite of its poorly
>constructed and extremely painful language layer. Because it has
>moved on to libraries, and is not obsessing forever with language
>design. Lisp is better at the language level, but that's not enough.
>It matters to be better at all the stuff that follows before you can
>compare something that's been left behind. If Lisp can't commit to
>move on and focus on libraries at an aggressive level, and teach its
>followers that this is where the investment of what youthful energy
>we are graced with should go, the lack of foundation argument will
>sink into insignificance with time.
I'll suggest a "flip side" to this...
At some point it makes more sense to start from scratch when it gets
too difficult to bolt the "new, novel stuff" onto the "previously
implemented stuff."
I'll cite GCC as an example, even though there are several good
contradictions.
I think there probably should have been a reasonable alternative to
GCC by this time, LCC and TENDRA both having been plausible
candidates.
My reasoning is that GCC basically takes a code generation model from
around 15 years ago, tying the compiler components together too
closely (to my taste). There are changes that are reasonably easy to
make, and there have been developments in peephole optimization as
well as in flow analysis. But the architecture is sufficiently rigid
that it is fairly difficult to make more sweeping changes to improve
it.
And therein lies the point: Once enough "details" accrete together in
any system, it becomes more and more difficult to make further
changes. It should be easier to improve a less mature system, as
suggested by Alan Perlis' quote:
"Optimization hinders evolution." -- Alan Perlis
The big contradiction comes in that after a "hiatus" when GCC seemed
"unimprovable," the EGCS project has evidently revitalized it,
seemingly in that a significant body of people have grown sufficiently
intimate with the code base that they can in fact find further
improvements to make.
Another system that might be closer to home is GNU Emacs; its being so
tied strongly to Emacs Lisp makes it seemingly impossible to take
advantage of more "modern" innovations such as compiling to faster
machine language as well as making use of some form of multi-threading
to allow more things to go on at once. [e.g. - At present, if GNUS is
busy downloading messages, nothing else can take place.]
On the one hand, adding a new variation on "Calendar Mode" to Emacs is
no big deal. The more radical surgery required to evolve Emacs to
"multiplex" better is almost certainly hindered by the past
optimizations. It might very well be an utterly unrealistic hope.
--
(concatenate 'string "cbbrowne" ·@" "acm.org")
<http://www.hex.net/~cbbrowne/emacs.html>
We all live in a yellow subroutine, a yellow subroutine, a yellow
subroutine...
glauber wrote:
> In my (limited) experience, CLISP is often fast enough. In the PC,
> well optimized code often runs as fast compiled in CLISP as it does in
> Corman Lisp (a machine-language compiler). Corman beats CLISP easily
> on sloppy code though...
My limited experience with Corman Lisp tells that undeclared, general
code runs quite fast on it relative to other implementations (though
declarations don't make much difference). I would not call undeclared
code sloppy, and probably it's not what you have meant, so I'm wondering
about the meaning of "sloppyness" that favors one implementation over
the other. Any specifics?
Robert
On 24 Oct 2000 14:32:46 +0100, Tim Bradshaw <···@tfeb.org> wrote:
> CLISP (at least this was true sometime in late 98, when Paul Graham
> gave his LUGM talk on it)
Which subsystems of Yahoo! Store were developed with CLISP?
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
Paolo Amoroso wrote in message ...
>On 24 Oct 2000 14:32:46 +0100, Tim Bradshaw <···@tfeb.org> wrote:
>
>> CLISP (at least this was true sometime in late 98, when Paul Graham
>> gave his LUGM talk on it)
>
>Which subsystems of Yahoo! Store were developed with CLISP?
It is my understanding that there is an, essentially, batch process in CLISP
that is used to create the pages for the individual stores. CLISP isn't used
to actually "run" the site, but rather to generate a set of related static
pages.
Somewhere, perhaps PG's home page (not that I have the URL, mind you), is
his enumerations about "Web Success". In them he frowns on server generated
HTML pages, so this would fit in quite well philisophically.
It's also interesting because people have to be thinking "How the heck is
Yahoo! driving a web site with CLISP?!?!??".
Simple, it isn't!
While everyone discusses the how to write web servers in Lisp, here's an
application that simply punts on the entire issue.
Of course, not every web application can be met with a block of static
pages, but many can.
Regards,
Will Hartung
(············@havasint.com)
In our last episode (Tue, 24 Oct 2000 18:00:09 -0700),
the artist formerly known as Will Hartung said:
>Paolo Amoroso wrote in message ...
>>On 24 Oct 2000 14:32:46 +0100, Tim Bradshaw <···@tfeb.org> wrote:
>>
>>> CLISP (at least this was true sometime in late 98, when Paul Graham
>>> gave his LUGM talk on it)
>>
>>Which subsystems of Yahoo! Store were developed with CLISP?
>
>It is my understanding that there is an, essentially, batch process in CLISP
>that is used to create the pages for the individual stores. CLISP isn't used
>to actually "run" the site, but rather to generate a set of related static
>pages.
>
>Somewhere, perhaps PG's home page (not that I have the URL, mind you), is
>his enumerations about "Web Success". In them he frowns on server generated
>HTML pages, so this would fit in quite well philisophically.
<http://www.paulgraham.com/mistakes.html>
The thing that seems most relevant:
Dynamically generated HTML is bad, because search engines ignore it.
And he comments that slow loading of pages is bad, and static generation
certainly means that there's no "runtime" cost to a lot of this...
>It's also interesting because people have to be thinking "How the heck
>is Yahoo! driving a web site with CLISP?!?!??".
>
>Simple, it isn't!
>
>While everyone discusses the how to write web servers in Lisp, here's an
>application that simply punts on the entire issue.
If it gets too slow, they need only spawn a few more CLISP processes to
do batch work. It doesn't forcibly hurt the runtime behaviour. Which is
pretty cool.
It's not particularly visible in looking at some of the HTML that is
generated; they don't have any <meta name="generator" content="CLISP">
tags :-). The HTML is very vaguely reminiscent in style to what is
generated by the application in his book "Common Lisp"
>Of course, not every web application can be met with a block of static
>pages, but many can.
This is in effect the same idea as the decision between:
a) Resolving code at compile time, using macros, versus
b) Resolving behaviour at runtime via some sort of dispatching.
Work that is done at compile time need never be done at runtime,
obviously saving that bit of CPU then. It doesn't too much matter how
slow CLISP is if the code is run at "compile" time.
In a sense, this application represents the opposite to the way
people tend to promote Lisp; "Lisp as Dynamic Language."
And I fairly heartily agree.
a) Search Engines Are Your Friend.
b) Web Apps tend to make Really Stupid Use of dynamic evaluation.
When they use JavaScript to do things that would be just as nicely
represented by static links, That's Really Stupid.
--
········@acm.org - <http://www.hex.net/~cbbrowne/linux.html>
(THASSERT (PLANNER RG))
-- Example of HACKER statement.
On Wed, 25 Oct 2000 02:44:40 GMT, ········@knuth.brownes.org (Christopher
Browne) wrote:
>The thing that seems most relevant:
> Dynamically generated HTML is bad, because search engines ignore it.
As long as your link doesn't look like a cgi script, you may fool a
robot into following it and indexing it, but usually it's not a good idea (for
you and the search engine).
//-----------------------------------------------
// Fernando Rodriguez Romero
//
// frr at mindless dot com
//------------------------------------------------
Fernando Rodr�guez <·······@must.die> writes:
> As long as your link doesn't look like a cgi script, you may fool a
> robot into following it and indexing it, but usually it's not a good
> idea (for you and the search engine).
Why? As long as my site provides a finite number of resources, I
don't see how it's anyone else's business how the pages were
generated.
--
chr
On 25 Oct 2000 11:18:13 +0200, ·····@eunet.no (Christian Nyb�) wrote:
>Fernando Rodr�guez <·······@must.die> writes:
>
>> As long as your link doesn't look like a cgi script, you may fool a
>> robot into following it and indexing it, but usually it's not a good
>> idea (for you and the search engine).
>
>Why? As long as my site provides a finite number of resources, I
>don't see how it's anyone else's business how the pages were
>generated.
As long as your contents is limited its ok, but systematically
following cgi scripts could end up dumping huge databases into the index as
well putting too much load on your server.
//-----------------------------------------------
// Fernando Rodriguez Romero
//
// frr at mindless dot com
//------------------------------------------------
Christopher Browne <········@hex.net> wrote:
+---------------
| Will Hartung said:
| >Somewhere, perhaps PG's home page (not that I have the URL, mind you), is
| >his enumerations about "Web Success". In them he frowns on server generated
| >HTML pages, so this would fit in quite well philisophically.
|
| <http://www.paulgraham.com/mistakes.html>
| The thing that seems most relevant:
| Dynamically generated HTML is bad, because search engines ignore it.
+---------------
Also see Philip Greenspun's comments on this issue, and his solution:
<URL:http://www.arsdigita.com/books/panda/publicizing>
[...skip down 2/3 of the way...]
Hiding Your Content from Search Engines (By Mistake)
...
I built a question and answer forum...all the postings were
stored in a relational database. ... The URLs end up looking
like "http://photo.net/bboard/fetch-msg.tcl?msg_id=000037".
...
AltaVista comes along and says, "Look at that question mark.
Look at the strange .tcl extension. This looks like a CGI script
to me. I'm going to be nice and not follow this link even though
there is no robots.txt file to discourage me."
Then WebCrawler says the same thing.
Then Lycos.
I achieved oblivion.
Briefly, his solution was:
Write another AOLServer TCL program that presents all the messages
from URLs that look like static files, e.g., "/fetch-msg-000037.html"
and point the search engines to a huge page of links like that.
The text of the Q&A forum postings will get indexed out of these
pseudo-static files and yet I can retain the user pages with their
*.tcl URLs.
...
(see my discussion of why the AOLserver *.tcl URLs are so good in
the chapters on Web programming; see http://photo.net/wtr/thebook/
bboard-for-search-engines.txt for the source code).
[Greenspun uses Tcl where many of us would choose Lisp (or even Scheme).]
-Rob
-----
Rob Warnock, 31-2-510 ····@sgi.com
Network Engineering http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673
1600 Amphitheatre Pkwy. PP-ASEL-IA
Mountain View, CA 94043
In our last episode (25 Oct 2000 05:37:26 GMT),
the artist formerly known as Rob Warnock said:
>Christopher Browne <········@hex.net> wrote:
>+---------------
>| Will Hartung said:
>| >Somewhere, perhaps PG's home page (not that I have the URL, mind you), is
>| >his enumerations about "Web Success". In them he frowns on server generated
>| >HTML pages, so this would fit in quite well philisophically.
>|
>| <http://www.paulgraham.com/mistakes.html>
>| The thing that seems most relevant:
>| Dynamically generated HTML is bad, because search engines ignore it.
>+---------------
>Also see Philip Greenspun's comments on this issue, and his solution:
... elided up to ...
>Briefly, his solution was:
>
> Write another AOLServer TCL program that presents all the messages
> from URLs that look like static files, e.g., "/fetch-msg-000037.html"
> and point the search engines to a huge page of links like that.
> The text of the Q&A forum postings will get indexed out of these
> pseudo-static files and yet I can retain the user pages with their
> *.tcl URLs.
That's a good response to the issue.
It still leaves the performance issue, namely that if you can generate
the web page "at compile time," then it's easy to let a web cache like
Squid stream it out without imposing the dynamic load of querying
databases and generating HTML at run time.
I would think this particularly critical at the time that a search
engine starts spidering your site; as the spider hits, watch the load
average [assuming Unix here ;-)] head Rather High.
The point is that it's interesting to see the trade-off of doing
things at compile time versus doing them at run time. I'll bet there
are some entertaining macros in the Yahoo! Store...
--
(concatenate 'string "cbbrowne" ·@" "hex.net")
<http://www.ntlug.org/~cbbrowne/lsf.html>
"If Ada became the hot, in-language you would see a lot more bad code
in Ada."
-- Thaddeus L. Olczyk <······@interaccess.com>, comp.lang.C++
* ·········@nosuchisp.com
| If a Lisp vendor does not allow distribution of the Lisp compiler
| with runtimes, ...
Then the right approach is to ask that vendor what it would take to
get permission to do that. All vendors allow distribution of the
Lisp compiler with runtimes, but at different terms than without.
| I've been told not to continue considering Lisp, because of
| considerations such as the above.
Most likely, you will be told not to continue to consider Lisp after
this issue has been resolved, because it is so obviously bogus.
You can most probably do without the compiler. Provided that you
compile enough of the support system, the interpreter can be used to
process a higher-level language in such a way that more than 90% of
the processing time is still spent in compiled code. This means
designing your own application-level language, but that's part of
the fun with programming in a powerful language.
| The hardest point to argue against is that the fastest Lisp,
| Allegro, does not allow distribution of the compiler with runtimes,
This is fortunately just plain wrong. Just call them and ask.
| I'm omitting my name because one of my coworkers has a nasty habit
| of doing global searches to see what each of us is posting about,
| and my name is unique enough to be easy to search on.
Please accept my sympathies. Cow-orkers like that should be shot.
(Now, if anyone of mine does the same, he sure won't tell anyone. :)
#:Erik
--
I agree with everything you say, but I would
attack to death your right to say it.
-- Tom Stoppard
·········@nosuchisp.com writes:
>
> I'm omitting my name because one of my coworkers has a nasty habit of doing
> global searches to see what each of us is posting about, and my name is
> unique enough to be easy to search on. I don't have a blind box handy for
> replies, so please post them. Thanks in advance.
This is the most redicoulous stuff I ever have written. Why do you
care about a co-worker. It's your life and you're opinion. Times of
slavery should have gone forever, and if you don't stand up, then
resign. And search for a more open minded environment.
Why do you post this question here and do not ask the vendors
directly? I'm quite sure that one can find an agreement which suits
both sided.
And for the speed of C++ please have a look at:
http://www-aig.jpl.nasa.gov/public/home/gat/lisp-study.html
just really good C Programmers get it faster than C++ programs. So at
least in this study Lisp beats hand down.
And nowhere did you mention what kind of problem you're working on. So
how should anyone have an idea if Common Lisp would suit the
requirements?
Friedrich
--
for e-mail reply remove all after .com
In article <··································@4ax.com>,
·········@nosuchisp.com wrote:
> If a Lisp vendor does not allow distribution of the Lisp compiler with
> runtimes, is there some other way to translate a special purpose programming
> language to Lisp and execute the result? Could the result be made as fast as
> C++ for handling large amounts of simple data?
- one could use some of the CL->C compilers, compile
the Lisp code to C and link the compiled code into the running
Lisp system
- use a self-written (in Lisp) compiler (your language -> C) and
link the resulting code to your running Lisp (this is the way
a sound synthesis program written in Lisp works)
- maybe use CMU CL
> I've been told not to continue considering Lisp, because of considerations
> such as the above. I would like to have some good arguments available, just
> in case I get a chance to argue in favor of Lisp again. The hardest point to
> argue against is that the fastest Lisp, Allegro, does not allow distribution
> of the compiler with runtimes,
I think you can get a license from Franz for doing that - it may be
expensive, though.
> and the 2nd fastest Lisp, Xanalys, is several
> times slower.
Contact Xanalys with some simple benchmarks. In general I found LispWorks
to be quite fast - maybe you need to change the code a bit to make it perform
better (this is not unusual). Lisp compiler usually have different
ideas of how and when to optimize. CMU CL at full verbosity gives
a lot of ideas where code can be improved - its compiler tells
you what kind of optimization it does and which not (and why not). The
Lisp machine's compiler, for example, ignores almost all declarations -
but there are plenty special tools to speed up execution.
I guess, Xanalys would be happy to improve their compiler,
in case there is a real problem.
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/