From: peaceman
Subject: re: Lisp is *SLOW*
Date: 
Message-ID: <33D9242C.5763@capital.net>
Reginald S. Perry wrote:

> 

> Sajid Ahmed the Peaceman <········@capital.net> writes:

> 

> 

> Well this is interesting. How in the world is a move iterative? How is

> iterative defined in your world?

> 

> If you want to convince me, you will have to:

> 

> 1) define iteration

> 

> 2) define recursion

> 

> 3) define your assembly pseudo-language subset. this subset has to be

>    rich enough to describe computations that can be done today on modern

>    machines.

> 

> 4) define the iterative operation in this language according to your

>    definition of iterative.

> 

> 5) define the recursive operation in this language according to your

>    definition of recursive.

> 

> 6) Show how the operations in 5) are equivalent to the operations in 4)

> 

> 7) show that for every operation one can describe in your language,

>    they all map in to some equivalent of 4)

> 

> Do this, and I will be convinced. I would advise you think carefully

> before you start.

> 

> -Reggie



	Look, I'm not going to get into a debate 

about whether assembly language is iterative or recursive. 



	The main point I had was about Lisp code, and the postgrad 

curriculum in comp sci. I can admit that I was wrong in the 

semantics of the language, but I'm not going to change my 

views on the way computer science is taught in the post graduate 

level. It's computer science, based on computer processors. 

It's not mathematics. It is a function on a computer,translated into 

lower level assembly language code run one instruction at a time, not a 

function in an abstract mathematical world. 
	
	You may think I have a problem with mathematics. I don't, 
as long as there is practical applications in the real physical 
world. The problem with these abstract mathematical functions,
translated into lisp, is that in most instances they don't have 
any practical use. It's mathematics just for the sake of mathematics. 
That is a complete waste of time. 


					Peaceman

From: Martin Rodgers
Subject: re: Lisp is *SLOW*
Date: 
Message-ID: <MPG.e445b8c116f9412989905@news.demon.co.uk>
My body fell on peaceman like a dead horse,
who then wheezed these wise words:

> 	Look, I'm not going to get into a debate 
> about whether assembly language is iterative or recursive. 

Phew. ;)

> 	The main point I had was about Lisp code, and the postgrad 
> curriculum in comp sci. I can admit that I was wrong in the 
> semantics of the language, but I'm not going to change my 
> views on the way computer science is taught in the post graduate 
> level. It's computer science, based on computer processors. 

Is this supposed to be a suprise to anyone?

> It's not mathematics. It is a function on a computer,translated into 
> lower level assembly language code run one instruction at a time, not a 
> function in an abstract mathematical world.

Do you know _anything_ about compiler theory? Try posting this kind of 
nonsense in comp.compilers, and see how far you get. Your claim that 
abstract mathematics is divorced from the hardware once again shows us 
how little you know.

Have you ever heard of Boolean Algebra? How about Lambda Calculus? 
This is at the heart of computing.
 	
> 	You may think I have a problem with mathematics. I don't, 
> as long as there is practical applications in the real physical 
> world. The problem with these abstract mathematical functions,
> translated into lisp, is that in most instances they don't have 
> any practical use. It's mathematics just for the sake of mathematics. 
> That is a complete waste of time. 

Ever heard of Alan Turing? You're dismissing the foundations of 
computing! You might as well claim that mathematics has no practical 
use in the real world. If you do, then we may assume that you've 
missed them all. Unless you're trying to convince us that such things 
don't exist?

BTW, it ain't even that abstract. We are, after all, talking about 
_computing_. Perhaps these machines aren't _quite_ so abstract at the 
transistor level, but we don't see the millions of transistors in a 
machine, and on such a scale as even a small computer, we have so many 
of these damn things that the result is indeed pretty abstract. Never 
mind the boolean alegbra that's used at the basic logic level.

May I recommend a book by Tom Duncan, called Advantures with Digital 
Electronics? I think it may explain things at a simple enough level 
for you to understand - very little mathematical. However, it's 
impossible to avoid it completely. Yes, the book includes some logic 
tables! Ouch. Still, this is a practical hands-on type of book, using 
breadboards and actual digital circuits using chips.

You sound like computers are way to complicated for you. They're full 
of abstractions, and in large quantities. You can only avoid them by 
being ignorant of them, as I'm sure most users are. If you wish to be 
a programmer, then you'll have to face at least some of these 
abstractions. If you wish to talk about languages and compilers for 
them, then you'll have to face some really tough abstractions.

Try reading a language spec if you're unconvinced. Even "simple" specs 
still include _some_ of the things that you're dismissing. They have 
to, otherwise the spec would be meaningless. More detailed specs will 
include more of the things that you say are unnecessary. They're not 
just for compiler writers, either. Programmers sometimes need to be a 
language lawyer. It helps to know the language that you program in.

If you feel that you don't need to know a programming language that 
well, then you're either not asking tough enough questions (e.g. how 
do I write code that other compilers for this language will compile 
correctly?), you're ignorant of the subjects of these questions (holes 
in the language specs, for instance), or you're just ignoring them.

I'll leave the more fundamental issues for now, but I will say that 
they've been around for some time. At least as long as modern 
computing. Just ask yourself how old Lambda Calculus is, and when the 
first digital computer was built.

You still have a lot to learn, Grasshoper. ;)
-- 
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
    "My body falls on you like a dead horse" -- Portait Chinois
            Please note: my email address is gubbish
From: Marco Antoniotti
Subject: re: Lisp is *SLOW*
Date: 
Message-ID: <scf67tv11n5.fsf@infiniti.PATH.Berkeley.EDU>
In article <·············@capital.net> peaceman <········@capital.net> writes:

   From: peaceman <········@capital.net>
   Newsgroups: comp.lang.lisp,comp.programming,comp.lang.c++
   Date: Fri, 25 Jul 1997 18:09:48 -0400
   Organization: Logical Net
   Lines: 99
   Mime-Version: 1.0
   Content-Type: text/plain; charset=us-ascii
   Content-Transfer-Encoding: 7bit
   X-Mailer: Mozilla 3.01 (Win95; I)
   Xref: agate comp.lang.lisp:29555 comp.programming:52980 comp.lang.c++:283727

	...

	   The main point I had was about Lisp code, and the postgrad 

   curriculum in comp sci. I can admit that I was wrong in the 

   semantics of the language, 

Progress!!!!


   but I'm not going to change my 

   views on the way computer science is taught in the post graduate 

   level. It's computer science, based on computer processors. 

   It's not mathematics. It is a function on a computer,translated into 

   lower level assembly language code run one instruction at a time, not a 

   function in an abstract mathematical world. 

Last time I checked the science of "Algorithm Analysis" was doing pretty
well.  Take an Analysis of Algorithm course and you will see that
there is a *lot* of work done to justify the costs of "translating a
math specification" into a working program.

	   You may think I have a problem with mathematics. I don't, 
   as long as there is practical applications in the real physical 
   world. The problem with these abstract mathematical functions,
   translated into lisp, is that in most instances they don't have 
   any practical use. It's mathematics just for the sake of mathematics. 
   That is a complete waste of time. 

Again, this has *nothing* to do with Lisp (or C or COBOL).  It has to
do with your limited knowledge of the algorithmic issues involed any
programming activity.

Cheers
-- 
Marco Antoniotti
==============================================================================
California Path Program - UC Berkeley
Richmond Field Station
tel. +1 - 510 - 231 9472
From: Emergent Technologies Inc.
Subject: Re: Lisp is *SLOW*
Date: 
Message-ID: <5rvorr$l9k$1@newsie2.cent.net>
 peaceman wrote in article <·············@capital.net>...
> The main point I had was about Lisp code, and the postgrad
>curriculum in comp sci. I can admit that I was wrong in the
>semantics of the language, but I'm not going to change my
>views on the way computer science is taught in the post graduate
>level. It's computer science, based on computer processors.
>It's not mathematics. It is a function on a computer,translated into
>lower level assembly language code run one instruction at a time, not a
>function in an abstract mathematical world.
>
> You may think I have a problem with mathematics. I don't,
>as long as there is practical applications in the real physical
>world. The problem with these abstract mathematical functions,
>translated into lisp, is that in most instances they don't have
>any practical use. It's mathematics just for the sake of mathematics.
>That is a complete waste of time.
>
> Peaceman

I guess they didn't teach it right.  I took a course at Harvard once
(yeah, I get what I deserve, eh?) and came away with the impression
that Lisp was a complete waste of time.  I changed my opinion
rather quickly when I learned it from *real* programmers. 
From: Bryant Brandon
Subject: Re: Lisp is *SLOW*
Date: 
Message-ID: <01360EAA52CE7B3F.F1A95DEF918D3FF4.F528E1F59B11896B@library-proxy.airnews.net>
In article <·············@capital.net>, ········@capital.net wrote:

>Emergent Technologies Inc. wrote:
>> 
>> I guess they didn't teach it right.  I took a course at Harvard once
>> (yeah, I get what I deserve, eh?) and came away with the impression
>> that Lisp was a complete waste of time.  I changed my opinion
>> rather quickly when I learned it from *real* programmers.
>
>        I am a real programmer, and I can tell you what it's like
>in the real world. There are very times, if any, that you ever write
>recursive code. For the three years that I've been working, I only 
>wrote two recursive functions. That's right, only two. One was for doing
>some parsing for some subdirectories, and the other was some dinky 
>descrambler program I wrote in a few minutes. 

   I'm a hobbyist, fluent in Fortran(77 & 90), Basic, C, Pascal, C++, 68k
asm, various scripting languages, and I'm learning Lisp(quickly).

>        I am willing to accept Lisp as a decent programming language,
>if it is based on nonrecursive code, i.e. most of the programming 
>in standard iterative code, with a rare occasion of some recursive code.
>What I've seen of Lisp is the exact opposite. 

   People have told you and shown you many times that Lisp compilers can
turn recursion into iteration.  So, bitching that "Lisp enforces recursion,
so it's slower than iteration" is pointless.

>        If you want to land yourself a good job, let me tell you...
>
>
>1.  Database programming
>        Big Big demand, anywhere and everywhere. Most companies have
>    some kind of database for their customers/clients. SQL and some
>    kind of specialty in a platform helps out a lot. If you want to 
>    get into this field, forget about COBOL. It's still out there,
>    but will soon be extinct. 

   Your point?

>2.  Applications programming
>        Most companies and people use ms windows, and visual c++ is the way
>  to go, though VB is sufficient if your not going to be doing any large 
>  projects with several other programmers. MSdos applications
>programming
>  is approaching, slowly but surely, the nil level.  

   What about mainframe programming?  If you're a "real programmer," then
you must be familiar with this field.  Also, what about embedded
programming.

>3. Network Programming
>        This is a very strong field. You really need to know the O.S. 
>   and platform aspect, more than the programming aspect. There are 
>   quite a few jobs out there for networking, and administrating 
>   networks.   

   Hmm, sounds like a Unix thing, mostly.  There isn't much market for VC++
unless WinNT is more popular that I've been led to beleive.

>4. Scientific programming 
>        C is the way to go. Fortran is still around, but will be gone
>   as soon as the scientists that only know fortran kick the bucket. 

   Are you familiar with Fortran90?  It has much better optimising for
vector manipulations than C because it was designed to be.  I'm a hobbyist,
not a scientist, I know Fortran.  Even my Fortran 77 compiler has better
optimization than my C compiler.  BTW, Fortran77 did not allow recursion. 
You should LOVE that language.
    
>5. Web/Java programming 
>        At the moment there is a demand for Java (and cgi scripting), 
>   but in my analysis, it won't last long. Why you ask? Let's take a 
>   look at the so called advantages of Java:
>    
>   Platform independence: That doesn't work. C, basic, fortran, and 
>      many other languages have been around for years, and there 
>      hasn't been any trend to make some kind of on the fly compiler, 
>      to run the source code on different platforms. If there really 
>      was a demand for platform independent programs, I'm sure 
>      we would have seen some kind of C machines, or Fortran machines, 
>      that correspond with the now JAVA machines. 

   Actually, since the virtual machines behave quite differently on the
different platforms, Java's portability is kinda shot.  BTW, several LISP
systems compile the functions on the fly instead of interpreting it.  So,
LISP is a highly portable language.

>   Static access to internet resources: HTTP corresponds to the ftp 
>      protocol of the past, with an easier interface and fancy pictures.
>      It's just a matter of time before a protocol is introduced that 
>      does the same with the telnet. When that happens, say goodbye to 
>      Java and cgi scripts.   

   CL-HTTP.  Go read about it.  It's quite interesting.

>        The question is, where does LISP fit into this picture? I'd
>really like to hear your response. 
>
>
>                                        Peaceman

B.B.
From: jason hummel
Subject: Re: Lisp is *SLOW*
Date: 
Message-ID: <33EB274D.62FE@ols.net.NO_SPAM>
Bryant Brandon wrote:
> 
> In article <·············@capital.net>, ········@capital.net wrote:
> 
> >Emergent Technologies Inc. wrote:
> >>

> >2.  Applications programming
> >        Most companies and people use ms windows, and visual c++ is the way
> >  to go, though VB is sufficient if your not going to be doing any large
> >  projects with several other programmers. MSdos applications
> >programming
> >  is approaching, slowly but surely, the nil level.
> 
>    What about mainframe programming?  If you're a "real programmer," then
> you must be familiar with this field.  Also, what about embedded
> programming.

 the point was APPLICATION Programming. yea, and you "real programmers"
 never use the gook you write, otherwise it would work as documented.
 
> >3. Network Programming
> >        This is a very strong field. You really need to know the O.S.
> >   and platform aspect, more than the programming aspect. There are
> >   quite a few jobs out there for networking, and administrating
> >   networks.
> 
>    Hmm, sounds like a Unix thing, mostly.  There isn't much market for VC++
> unless WinNT is more popular that I've been led to beleive.

 have absolutly no doubt, when MS dumped 150million into Apple, NT will
 take over as the new server OS. how? java, they are splitting it up.
 i guess SGI was too slow:) secondly, it's that myth of Apples/Macs
 are the best thing since sliced bread in the corporate ranks.
 on the other front, i don't think it's as much to do with java but
 more about ActiveX when MS showed the money. yup, unless the unix
 community gets off it's high horse about COM/DCOM, they're doomed.

-- 
Regards,
jason hummel	

---------------------------------------------------------
NOTICE TO BULK EMAILERS:  Pursuant to US Code, Title 47,
Chapter 5, Subchapter II,  227, any and all nonsolicited
commercial E-mail sent to this address is subject to a
download and archival fee in the amount of $500 US.
E-mailing denotes acceptance of these terms.

http://www.ols.net/~keycad1
··············@ols.net
---------------------------------------------------------
From: Emergent Technologies Inc.
Subject: Re: Lisp is *SLOW*
Date: 
Message-ID: <5slg1b$6sb$2@newsie2.cent.net>
 jason hummel wrote in article <·············@ols.net.NO_SPAM>...
>Bryant Brandon wrote:
>>
>> In article <·············@capital.net>, ········@capital.net wrote:
>>
>> >Emergent Technologies Inc. wrote:
>> >>

[Bunch of stuff omitted]

No I didn't.

~jrm
From: Martin Rodgers
Subject: Re: Lisp is *SLOW*
Date: 
Message-ID: <MPG.e54d74ab00cde9c989933@news.demon.co.uk>
Sajid Ahmed the Peaceman wheezed these wise words:

> 	I am willing to accept Lisp as a decent programming language,
> if it is based on nonrecursive code, i.e. most of the programming 
> in standard iterative code, with a rare occasion of some recursive code.
> What I've seen of Lisp is the exact opposite. 

I've told you before that you probably had a bad teacher. Try again, 
this time teaching yourself from a good book. There are a number of 
them listed in the Lisp FAQ. (Haven't I refered you to that already?)

You lost your argument weeks ago, but you haven't notice yet. Why not 
stop posting disinformation and instead _learn something_? At the very 
least, you should get a life and do something else. All you're doing 
is giving Lisp programmers a wonderful excuse to post pro-Lisp memes. 
While I think this may help kill a few myths, I've been watching this 
happen long enough to know that there will always be more people like 
yourself, in a few months, to try again.

Always you prove one of two things: 1) how clueless you are about 
programming in general, never mind Lisp, and 2) that you have an 
ulterior motive for slagging off a language that you don't use. If you 
don't use Lisp, why should you even care that other people use it? If 
Lisp is as you claim, then surely you would benefit from other people 
using it, as they would then be writing slow and expensive code? Your 
own arguments show that you are not to be trusted.

If you simply said, "I had a bad learning experience with Lisp, which 
is why I'll never touch it again, never look at it again, and never 
recommend it to anyone - because I'm assuming that they too will have 
painful experiences with it", then we could at least take pity on you 
and offer some support. However, you prove yourself to be someone of 
much lower principles, resorting to cheap OS flamebait when your 
"arguments" are slaughtered by a reference to the native code produced 
by a real compiler for a real machine.

Try "showing" us that the Earth is flat - you'll find it much easier.
-- 
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
        "There are no limits." -- ad copy for Hellraiser
            Please note: my email address is gubbish
From: Sajid Ahmed the Peaceman
Subject: Re: Lisp is *SLOW*
Date: 
Message-ID: <33ECAC08.63E6@capital.net>
Martin Rodgers wrote:
> 
> Sajid Ahmed the Peaceman wheezed these wise words:
> 
> >       I am willing to accept Lisp as a decent programming language,
> > if it is based on nonrecursive code, i.e. most of the programming
> > in standard iterative code, with a rare occasion of some recursive code.
> > What I've seen of Lisp is the exact opposite.
> 
> I've told you before that you probably had a bad teacher. Try again,
> this time teaching yourself from a good book. There are a number of
> them listed in the Lisp FAQ. (Haven't I refered you to that already?)
> 
> You lost your argument weeks ago, but you haven't notice yet. Why not
> stop posting disinformation and instead _learn something_? At the very
> least, you should get a life and do something else. 

	Yeah, sometimes I ask myself why I bother responding to 
you guys. You'll find out for yourself what real programming 
is like once you get a job in the real world. 


> ....
> Try "showing" us that the Earth is flat - you'll find it much easier.


	I'm more into showing whether or not the universe is flat.

						Peaceman
From: Martin Rodgers
Subject: Re: Lisp is *SLOW*
Date: 
Message-ID: <MPG.e56cc101bc04a39989950@news.demon.co.uk>
Sajid Ahmed the Peaceman wheezed these wise words:

> 	Yeah, sometimes I ask myself why I bother responding to 
> you guys. You'll find out for yourself what real programming 
> is like once you get a job in the real world.

Wanna bet? You're making some mighty big assumptions about what we all 
do for a living, and what constitutes the "real world". I'd bet that 
you know a lot about the _PC world_, esp the lowest common demoninator 
aspects of it. That, however, still leaves a lot of room for other 
things which we can safely call computing.

Meanwhile, see <URL:http://www.franz.com/frames/ha.list.html> for a 
some "real  world" apps written in Lisp. You might be suprised.

BTW, what do you gain by making these assertions? Even if you were 
right, do you think that you're doing anyone a favour?

> > Try "showing" us that the Earth is flat - you'll find it much easier.
> 
> 
> 	I'm more into showing whether or not the universe is flat.

Hmm. I'm tempted to ask...However, it would probably be off topic in 
all three of the newsgroups to which we're posting. Some other time 
and place, perhaps. sci.physics.relativity, perhaps.
-- 
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
        "There are no limits." -- ad copy for Hellraiser
            Please note: my email address is gubbish
From: Christopher Oliver
Subject: Re: Lisp is *SLOW*
Date: 
Message-ID: <5t5rp6$db0@guy-smiley.traverse.com>
Sajid Ahmed the Peaceman wheezed these (un?)wise words:
> 	Yeah, sometimes I ask myself why I bother responding to 
> you guys.

Funny, I imagine that thought has crossed the minds of more than a
few of your opposition.

> You'll find out for yourself what real programming 
> is like once you get a job in the real world.

Hmmm...   You mean the world where you face the daily hard slog to keep
your business afloat?  You mean the world where the market and legal
issues get in your face as much as technical ones?  Funny, but that IS
where I work.  I also use technology as suits the problems at hand;
this sometimes means Lisp, and sometimes recursion.

Do not insult your audience by presuming to tell them they do not work
in the real world simply because they do not share your views!

--
Christopher Oliver                     Traverse Communications
Systems Coordinator                    223 Grandview Pkwy, Suite 108
oliver -at- traverse -dot- com         Traverse City, Michigan, 49684
"Everyone takes the limits of his own vision for the limits of the world."
                                       - Schopenhauer
From: Christopher Oliver
Subject: Re: Lisp is *SLOW*
Date: 
Message-ID: <5sejdn$l3n@guy-smiley.traverse.com>
Sajid Ahmed the Peaceman (········@capital.net) wrote:
: 	I am a real programmer, and I can tell you what it's like
: in the real world. There are very times, if any, that you ever write
: recursive code.

Guess that makes me an imaginary (or at least complex) programmer.
I deal with recursion quite often in the design of algorithms and
structures.  Not all common coding is merely gluing together vendor
components; even if it were, somewhere along the line, all those
"unreal" problems have to be solved.  Don't vendors do real work?

:       If you want to land yourself a good job, let me tell you...

"Son, the future is... plastics."

Let me give you a further hint.  If I'm interviewing a programmer,
a firm grasp of recursion is the LEAST I'll expect of the candidate.
There are more than a few jobs outside the university where code
grinders need not apply.
 
:                                       Peaceman

Then how about showing a little more pacificism.  Folk who make
routine professional use of their comp. sci. backgrounds bridle a
touch when you suggest they don't work in the real world.

--
Christopher Oliver                     Traverse Communications
Systems Coordinator                    223 Grandview Pkwy, Suite 108
······@traverse.com                    Traverse City, Michigan, 49684
"You can even make Emacs look just like vi -- but why?"  - C. Musciano
From: Gareth McCaughan
Subject: Re: Lisp is *SLOW*
Date: 
Message-ID: <86bu387man.fsf@g.pet.cam.ac.uk>
"Sajid Ahmed the Peaceman" wrote:

> 	I am a real programmer, and I can tell you what it's like
> in the real world. There are very times, if any, that you ever write
> recursive code. For the three years that I've been working, I only 
> wrote two recursive functions. That's right, only two. One was for doing
> some parsing for some subdirectories, and the other was some dinky 
> descrambler program I wrote in a few minutes. 

I really do wish you'd stop putting forward your own limitations
as fundamental facts of life.

> 	I am willing to accept Lisp as a decent programming language,
> if it is based on nonrecursive code, i.e. most of the programming 
> in standard iterative code, with a rare occasion of some recursive code.

Why on earth should anyone care what you're willing to accept as
a decent programming language, when you have shown yourself utterly
incapable of understanding the issues involved?

You have made, over and over and over again, the assertion that
recursion is unnecessary, inefficient and hard to understand.
People have explained that

  - there are some problems for which recursion is the best way
    of expressing things;

  - in most cases where a human can do away with it, a compiler
    can too, so inefficiency isn't a reason not to use it;

  - for many people, recursion is just as easy to understand as
    iteration.

But *you* can't see how a compiler could do a decent job of
optimising recursive code, so you say it's necessarily inefficient;
and *you* have trouble understanding recursive code, so you say
it's hard to understand; and *you* have only ever written two
bits of recursive code, so you say it's unnecessary.

So why, exactly, should we take any notice of your pronouncements?

> 	If you want to land yourself a good job, let me tell you...

Ah, I see. Lisp is bad because there are more jobs in C++. Well,
there are even more jobs -- and better paying ones, too, by all
accounts -- writing COBOL. Clearly that's an even better language,
yes?

[snip big collection of obiter dicta about the world of programming]

> 	The question is, where does LISP fit into this picture? I'd
> really like to hear your response. 

Anywhere you want it to. Or, rather, anywhere someone who actually
has a clue how to use it wants it to.

-- 
Gareth McCaughan       Dept. of Pure Mathematics & Mathematical Statistics,
·····@dpmms.cam.ac.uk  Cambridge University, England.
From: Martin Rodgers
Subject: Re: Lisp is *SLOW*
Date: 
Message-ID: <MPG.e5553d33b8276f5989939@news.demon.co.uk>
Gareth McCaughan wheezed these wise words:

> You have made, over and over and over again, the assertion that
> recursion is unnecessary, inefficient and hard to understand.

Sajid Ahmed the Peaceman has demonstrated, over and over and over 
again, the limits of his education. The problem is that he assumes 
that a poorly taught language is the same as a poor language. He could 
have been taught C just as badly, but I guess he was just lucky.
 
Perhaps it's much easier to find bad teachers using Lisp than it is to 
find bad teachers using C? Perhaps it's just easier to teach Lisp 
poorly, or harder to teach the language well. I don't know, but at 
least I can make the distinction. I've been using C since the early 
80s, and I still consider myself a "beginner". While I started with 
K&R, which I consider a good C tutorial, I'm not so sure about any of 
the other C tutorials. I've read a number of Lisp tutorials, and some 
of them are very heavy tomes indeed and I wouldn't recommend them to 
beginners. It could be that Sajid Ahmed's teacher used one of these 
advanced books, which may be ideal for MIT students, but may be 
totally unsuitable for most programmers.

I think that we can give Sajid Ahmed the benefit of the doubt, and 
guess that he's not an MIT student. ;) We get the languages that we 
deserve, and it may be that Sajid Ahmed deserves C/C++.
-- 
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
        "There are no limits." -- ad copy for Hellraiser
            Please note: my email address is gubbish
From: Erik Naggum
Subject: Re: Lisp is *SLOW*
Date: 
Message-ID: <3080050640488221@naggum.no>
* Sajid Ahmed the Peaceman
| I am a real programmer, and I can tell you what it's like in the real
| world.

hmmm.  it is not very often that we find people who use arguments ad
hominem to support their own position.

why should we listen to you?  because what you say is wise, true, coherent,
informative, or entertaining?  no.  because you're a "real" programmer who
can tell people what the "real world" is like?  yeah, something like that.

how can we determine whether something is or is not "real" according to
your usage?  what is the test to falsify a claim to be "real"?  if you fall
through such a test, what are you?  a fraud, a fake, a wannabe, a failure?

if you are real but others here are not, are they then supernatural,
omniscient, omnipotent, and/or omnipresent compared to you?  surely, they
cannot be any _less_ than you are.

I have wanted to know what this "real world" thing is.  however, the more I
hear about it, the less interesting it gets.  this is in sharp contrast to
the observable world which gets more and more interesting, what with all
the fascinating research, development, creations, art, and other splendor.
the "real world" of you and other Microsoft victims is one where everything
that is great about the observable world is turned on its head.  there's
research, but they're doing everything over again.  there's development,
but it's about products with more useless "user functions", not any actual
_development_ -- they're just doing more of the same old shit.  there are
creations, but they are insignificant compared to the market share and the
sales figures.  there is probably art somewhere, but it's so hard to spot
that I don't even see it.  if there is splendor, it's on the cover of
magazines and in their ads.

inside this extremely _superficial_ "real world", we find programmers who
show brilliance and sustained intelligence in solving hard problems.  if we
dig below the surface, we find new releases of programming environments
with massive performance improvements, for both programmers and products,
and vast improvements in the ways we work.  if we look at the products that
aren't sold by the millions, we find entirely new things we can do that the
consuming public just wouldn't be able to understand for several years.  if
we are concerned with more than appearance, we find art in the intelligent
application of new technology to previously non-existing problems.  if we
are willing to learn and study, we still find splendor in the work of many
people in this field.  not many new ones, but the old ones still sparkle in
the darkness of our times.

many believe there is not much development left in computer science.
considering that people are more willing than ever before to do manual work
(they only need more immediate feedback from pushing the colored levers in
the lab rat interface, er, the graphical user interface) this may be true
at the consumer level, but this is not unlike physics.  "consumer physics"
(i.e., the kind of physics that consumers would understand and use) has
probably not seen much development for the past 50 years.  however, the
results of the continued "elite" research is ever more present in the
hardware and the technology we use today.

your "real world" is really a televised projection of the observable world.
whatever the TV tells you, "reports" to you, you believe, including the
ads.  what's real is not what you experience, but what you're told.  the
same is true of the computers the mass market uses: they don't really see
the computer _doing_ anything, only making user-friendly appearances on
their screen, the computerized TV.

who chooses what to display on the computerized TV?  who chooses what to
send on the TV?  according to research into what people will push levers to
get more of (the mass-market market research), people will push levers to
get more entertainment, more ways to keep from exposing themselves to new
ideas, change, or revolutions.  people seek the safety of the known and the
customary, and they find it in the TV.  society is "de-controversialized"
(starting with the desire for political correctness), and the approvable is
up for democratic vote.

the "real world" has been created by people who voted for whatever made
them feel safest, and they got to choose among the ads delivered through
their electronic pacifier -- the TV or the computerized TV, pick one.

the observable world becomes visible only when the strong glare from the
propaganda machine cum pacifier has subsided, which means you have to turn
it off, go out to see for yourself, enjoy the strange sensations that come
when you rediscover that you're a sensing being, not just a sink for
prepackaged propaganda and microwaved entertainment (satellite TV).

if you leave the glossy ads in the magazines behind, you will find that
people don't actually produce all that much with these things.  they work a
lot, and the scream a lot about it, but what comes out of the "real world"
is just electronically heated air.  and that's just what we see from this
bozo the peaceman, too.  "consumer ideas for consumer brains."

| The question is, where does LISP fit into this picture?  I'd really like
| to hear your response.

in this picture, Lisp is like the internal design of the ant hill busy with
bugs only significant because of their numbers, who don't know what they
are doing, why they are there, or where they are going, except by following
the trail of smell from others of their kind.  what makes an ant colony
thrive and survive is the structure of the ant hill, not the busy ants.
the construction of the ant hill and the reason it survives winters and
predators is hard to see by focusing on the busy ants, but film an ant hill
for months and view it at 100 times normal speed, you see it.  fortunately,
some people are able to think in larger time frames than 1/24th of a
second, and so don't need the aid of the TV to see the pictures worth
seeing.

#\Erik
-- 
404 Give me a URL I cannot refuse.
From: Sajid Ahmed the Peaceman
Subject: Re: Lisp is *SLOW*
Date: 
Message-ID: <33ECB6F7.560D@capital.net>
Erik Naggum wrote:
> 
> who chooses what to display on the computerized TV?  who chooses what to
> send on the TV?  according to research into what people will push levers to
> get more of (the mass-market market research), people will push levers to
> get more entertainment, more ways to keep from exposing themselves to new
> ideas, change, or revolutions.  people seek the safety of the known and the
> customary, and they find it in the TV.  society is "de-controversialized"
> (starting with the desire for political correctness), and the approvable is
> up for democratic vote.
> 

	It's true that there is some propaganda on TV and in the 
political system, but not to the extent that you make it out to be. 


> the "real world" has been created by people who voted for whatever made
> them feel safest, and they got to choose among the ads delivered through
> their electronic pacifier -- the TV or the computerized TV, pick one.
> 

	That is completelt untrue. The real world will always be the 
real world, regardless of what people think. 



> the observable world becomes visible only when the strong glare from the
> propaganda machine cum pacifier has subsided, which means you have to turn
> it off, go out to see for yourself, enjoy the strange sensations that come
> when you rediscover that you're a sensing being, not just a sink for
> prepackaged propaganda and microwaved entertainment (satellite TV).
> 
> if you leave the glossy ads in the magazines behind, you will find that
> people don't actually produce all that much with these things.  they work a
> lot, and the scream a lot about it, but what comes out of the "real world"
> is just electronically heated air.  

	If you want to live in your fantasy world, fine, but one 
day reality will catch up to you, and then you'll be in big trouble. 
You have to accept reality. There is no way to dodge it. Get out of 
your dream man. 

					Peaceman
From: Richard A. O'Keefe
Subject: Re: Lisp is *SLOW*
Date: 
Message-ID: <5smdis$dui$1@goanna.cs.rmit.edu.au>
Sajid Ahmed the Peaceman <········@capital.net> writes:
>	It's true that there is some propaganda on TV and in the 
>political system, but not to the extent that you make it out to be. 

Come off it!  The whole commercial television system exists solely
for the purpose of propaganda.  It's called "Advertising".  Advertising
not only sells consumable products, it sells a culture.  Any good
history of advertising will tell you about the political and cultural
ideas implicitly (but none-the-less powerfully) pushed by advertisments.
Just look at old 50s advertisements some time and see the sex role
stereotyping, class values, and other stuff in just about every advertisement.
Just becuase it's not labelled "party political broadcast" doesn't mean
it doesn't tend to encourage some ideas and discourage others.

I find most of the advertising on TV here deeply offensive, not so much
because of the products, but because of the sexual, "musical", political,
&c attitudes they ram down viewers' eyes without consent.  The "mute"
button on my remote control gets a lot of use.

For one concrete example of political propaganda, consider Pauline Hanson
and her One Nation party.  She's an Australian politician with ideas that
would make me very very frightened if I were Jewish or Asian.  Or at least,
_maybe_ she is.  I _think_ she's a raving racist loony, but I have to say
that her _ideas_ are NEVER given a fair hearing on TV.

And "I am, you are, we are Australian" or whatever the wretched jingle is,
if that isn't propaganda, I don't know what is.

So now we know that pieceman doesn't know anything about the electronic
press either.

-- 
Four policemen playing jazz on an up escalator in the railway station.
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.
From: Will Hartung
Subject: Re: Lisp is *SLOW*
Date: 
Message-ID: <vfr750EELwC1.HqD@netcom.com>
Sajid Ahmed the Peaceman <········@capital.net> writes:

...yada yada yada...

>	The question is, where does LISP fit into this picture? I'd
>really like to hear your response. 

Where does it fit?

Where it has ALWAYS fit!

Up on the ridge overlooking the Valley that seems to be the core of
your little world. Sitting in its lawn chair, drink in its hand, one of
those fruity ones with the umbrella. It thinks "What to do today? Where
can I go next? What can I make new today?".

It counts off on its fingers where it's been before. (Thankfully it
supports BIGNUMS). From OS kernels to applets, AI to scripting, it has
stripes on its arm a mile long. Been there, done that. Computing World
Traveler, Exlporer, and Pioneer.

It fits where it always has. A place for others to look to. For others
to wonder "How does it do that?". They try to emulate. Try to make do,
but always at some cost, always compromising. Never quite "making" it.
They specialize on some little nit, say "See I can do it too!", and
discovered that the target they were trying to hit has moved on again,
advanced once more, leaving it behind.

It has been said that those who do not learn Lisp are doomed to
reinvent it. There's also this bumper sticker - "I may be slow, but
I'm ahead of you!".

So, Lisp fits where it always has fit. Rather than being a peg looking
for a hole, it's a sponge capable of filling them all -- simultaneously.

It sits on its chair, takes of sip, and watches the fires in the city
below flare up, spread, and eventually die, and smiles as it sees
another moth, just like you, attracted to the lights of the pyres.

While others, sick of the smoke, try to climb the hill so they can get
a drink.

Welcome, pull up a chair. Come watch with me. Care for a Mai Tai?

Lisp smiles. Perfect fit.

"Specialization is for insects." - R. A. H.

-- 
Will Hartung - Rancho Santa Margarita. It's a dry heat. ······@netcom.com
1990 VFR750 - VFR=Very Red    "Ho, HaHa, Dodge, Parry, Spin, HA! THRUST!"
1993 Explorer - Cage? Hell, it's a prison.                    -D. Duck
From: Richard A. O'Keefe
Subject: Re: Lisp is *SLOW*
Date: 
Message-ID: <5sh90h$6g4$1@goanna.cs.rmit.edu.au>
Sajid Ahmed the Peaceman <········@capital.net> writes:
>	I am a real programmer...

>4. Scientific programming 
>	C is the way to go. Fortran is still around, but will be gone
>   as soon as the scientists that only know fortran kick the bucket. 

You should have seen me rolling around the room laughing!
Whatever pieceman knows, he _doesn't_ know Fortran.
If you want really high scientific computing performance, Fortran is
still the only game in town (well, Sisal is better, and NESL may be,
but C certainly isn't).  Modern Fortran has most of the good things
that C has, omits most if the mistakes, and has a ton of useful stuff
that C hasn't got.  Ok, f90 isn't the best for everything, but what
language is?  I don't see Fortran dying any time soon.  (I know more
than 100 languages and still see the usefulness of Fortran.)
	
>5. Web/Java programming 
>	At the moment there is a demand for Java (and cgi scripting), 
>   but in my analysis, it won't last long. Why you ask? Let's take a 
>   look at the so called advantages of Java:
>    
>   Platform independence: That doesn't work. C, basic, fortran, and 
>      many other languages have been around for years, and there 
>      hasn't been any trend to make some kind of on the fly compiler, 
>      to run the source code on different platforms.

There isn't even any _source_ compatibility for BASIC, so scratch BASIC.
Fortran programs _are_ source compatible; to move an F90 program from
one 32/64-bit IEEE platform to another (all Java can manage) you just
recompile.  If a program's going to run for hours, you don't particularly
mind a bit of up-front compiling.

>	If there really 
>      was a demand for platform independent programs, I'm sure 
>      we would have seen some kind of C machines, or Fortran machines, 
>      that correspond with the now JAVA machines. 

Well, we do actually have quite a lot of platform independent languages
already.  Telescript, Facile, Oberon, TCL, ...

>   Static access to internet resources: HTTP corresponds to the ftp 
>      protocol of the past, with an easier interface and fancy pictures.
>      It's just a matter of time before a protocol is introduced that 
>      does the same with the telnet.

>	The question is, where does LISP fit into this picture? I'd
>really like to hear your response. 

Why should we believe that?  You haven't _listened_ to anything else
that anyone has said.

I like the Xerox phrase:  "Power tools for exploratory programming."
But not just exploratory, of course.  People are programming huge
telecoms applications in a (somewhat simplified but still strictly
recursive) platform independent (yep, add Erlang to the list of platform
independent "mobile programming languages") descendant of Lisp.  What
it buys them is reduced costs.  (A factor of 6 fewer lines of code than
C.)  This is bet-your-BIG-business stuff.  I have two powerful statistics
packages installed here.  One of them is an extension of Lisp.  The other
_looks_ like C, but is implemented using Lisp technology.  Lisp was used
for the Dylan compiler (story I heard is that Apple pulled the plug on
Dylan to appease Sun) which works very well.

I could multiply examples, but you will doubtless contract your picture
to exclude them.
-- 
Four policemen playing jazz on an up escalator in the railway station.
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.
From: Martin Rodgers
Subject: Re: Lisp is *SLOW*
Date: 
Message-ID: <MPG.e565cc496749d48989942@news.demon.co.uk>
Richard A. O'Keefe wheezed these wise words:

> You should have seen me rolling around the room laughing!

People would be laughing even harder in comp.sys.super. Sajid Ahmed 
the Peaceman should really do his research (instead of making it up). 
The reality is very different for Fortran users than, say, the PC 
users that he'll be used to. Good grief, some of those people don't 
even take these small machines seriously! And who can blame them?

It's a big world, and it seems that Sajid Ahmed the Peaceman has yet 
to step outside his hometown, never mind see the big city. It's easy 
to dismiss a language that won't get much use in the corner of the 
world that you inhabit, however large that may be. The survival of 
Fortran has _nothing_ to do with what PC users want.
-- 
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
        "There are no limits." -- ad copy for Hellraiser
            Please note: my email address is gubbish
From: Dennis Weldy
Subject: Re: Lisp is *SLOW*
Date: 
Message-ID: <8MGIS5zp8GA.151@news2.ingr.com>
 It's like I've (and others) have saidrepeatedly when dealing with Nudds
and his claims of "real-world" programming. What that means depends a great
deal on what world you work in. ;-)

Dennis

Martin Rodgers wrote in article ...

>Richard A. O'Keefe wheezed these wise words:
>
>> You should have seen me rolling around the room laughing!
>
>People would be laughing even harder in comp.sys.super. Sajid Ahmed 
>the Peaceman should really do his research (instead of making it up). 
>The reality is very different for Fortran users than, say, the PC 
>users that he'll be used to. Good grief, some of those people don't 
>even take these small machines seriously! And who can blame them?
>
>It's a big world, and it seems that Sajid Ahmed the Peaceman has yet 
>to step outside his hometown, never mind see the big city. It's easy 
>to dismiss a language that won't get much use in the corner of the 
>world that you inhabit, however large that may be. The survival of 
>Fortran has _nothing_ to do with what PC users want.
>-- 
><URL:http://www.wildcard.demon.co.uk/> You can never browse enough
>        "There are no limits." -- ad copy for Hellraiser
>            Please note: my email address is gubbish
>.
> 
From: Martin Rodgers
Subject: Re: Lisp is *NOT* slow
Date: 
Message-ID: <MPG.e5abb18ecbc401898999a@news.demon.co.uk>
Dennis Weldy wheezed these wise words:

>  It's like I've (and others) have saidrepeatedly when dealing with Nudds
> and his claims of "real-world" programming. What that means depends a great
> deal on what world you work in. ;-)

Hence the phrase Your Mileage May Vary. ;)

It's unfortunate that Peaceman is so unaware of the capabilties of the 
GNUC & MS C/C++ compilers. It helps to recognise when you're out of 
your depth. The risk is that you may find yourself teaching your 
grandmother to such eggs.

While Peaceman will have no chance of proving his claims, he is doing 
an excellent job of spreading false memes. The fact that we can 
counter all his arguments may mean nothing to anyone who suffered from 
an equally poor education as his. If he's complaining about something, 
he's either succeeded in making his point, or he's yet to make it.

Note that he admits the failure of his CS teacher, and yet still 
considers himself to be an authority on the subject of recursion and 
compilers. Also note that he offers no proof at all for any of his 
claims, but simply repeats his lies over and over.

He'd make a great taxi driver. ;)
-- 
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
        "There are no limits." -- ad copy for Hellraiser
            Please note: my email address is gubbish
From: Dennis Weldy
Subject: Re: Lisp is *NOT* slow
Date: 
Message-ID: <Z3U6BQ2p8GA.151@news2.ingr.com>
 

Martin Rodgers wrote in article ...

>Dennis Weldy wheezed these wise words:
>
>>  It's like I've (and others) have saidrepeatedly when dealing with
Nudds
>> and his claims of "real-world" programming. What that means depends a
great
>> deal on what world you work in. ;-)
>
>Hence the phrase Your Mileage May Vary. ;)
>
>It's unfortunate that Peaceman is so unaware of the capabilties of the 
>GNUC & MS C/C++ compilers. It helps to recognise when you're out of 
>your depth. The risk is that you may find yourself teaching your 
>grandmother to such eggs.

Personally, I was unaware that MS c/C++ compilers would handle the tail
recursion. (Im assuming microsoft, and because I wasnt able ti read all
msgs in this thread, I figure that it was shown that they would, otherwise
y'wuldn'tve said it). 

I really think that what Michael Abrash says in his book "Zen of code
optimization" really fit, in that y'shouldn't try to look at the code to
see where the bottlenecks are, rather you should measure, measure, measure.
Trying to optimize by turning a recursive function into iteration (which
depending on the aglorithm may make the code that much more difficult to
read and maintain) when it's not a performance problem is well...not a good
use of your time. 

>
>While Peaceman will have no chance of proving his claims, he is doing 
>an excellent job of spreading false memes. The fact that we can 
>counter all his arguments may mean nothing to anyone who suffered from 
>an equally poor education as his. If he's complaining about something, 
>he's either succeeded in making his point, or he's yet to make it.
>
>Note that he admits the failure of his CS teacher, and yet still 
>considers himself to be an authority on the subject of recursion and 
>compilers. Also note that he offers no proof at all for any of his 
>claims, but simply repeats his lies over and over.
>
>He'd make a great taxi driver. ;)

Maybe. I'll admit that he is much more pleasant to deal with than Nudds. No
lisp-pusher-religionist crap. ;-)

Dennis
>-- 
><URL:http://www.wildcard.demon.co.uk/> You can never browse enough
>        "There are no limits." -- ad copy for Hellraiser
>            Please note: my email address is gubbish
>.
> 
From: Martin Rodgers
Subject: Re: Lisp is *NOT* slow
Date: 
Message-ID: <MPG.e5b9d65d5f21d669899a9@news.demon.co.uk>
Dennis Weldy wheezed these wise words:

> Personally, I was unaware that MS c/C++ compilers would handle the tail
> recursion. (Im assuming microsoft, and because I wasnt able ti read all
> msgs in this thread, I figure that it was shown that they would, otherwise
> y'wuldn'tve said it). 

Yes, if you invokle the right incantation, then VC++ 4.0 will perform 
TRO. Here's that incantation "cl fac.c /O1" for the factorial code. 
The "/O1" option is short for "minimize space". "/O2" also works.

TRO in C can be tested/demonstrated with the following code:

int *p = NULL;

void r(int i)
{
    if (p == NULL)
        p = &i;
    printf("%d %p\n", i, &i);

    if (p != &i)
        exit(0);

    r(i + 1);
}

void main(void)
{
    r(1);
}
 
> I really think that what Michael Abrash says in his book "Zen of code
> optimization" really fit, in that y'shouldn't try to look at the code to
> see where the bottlenecks are, rather you should measure, measure, measure.

I've read the same advise in a number of othe places, too. You can 
sometimes be suprised by where the time is really spent.

> Trying to optimize by turning a recursive function into iteration (which
> depending on the aglorithm may make the code that much more difficult to
> read and maintain) when it's not a performance problem is well...not a good
> use of your time. 

Good knowledge of aglorithms is always the place to start, IMHO. Of 
course, if you learn about aglorithm from a CS book, then the author's 
preferences may influence you. This is probably why I have a number of 
these books, by a variety of authors.

Computer science is just as fallible as any other science. The people 
involved are only human, after all. However, that's no reason to 
reject CS. Considering the part that it plays in making these darn 
machines do _anything_ at all, never mind something interesting or 
useful...but you have to learn some of it in order to appreciate that.

> >He'd make a great taxi driver. ;)
> 
> Maybe. I'll admit that he is much more pleasant to deal with than Nudds. No
> lisp-pusher-religionist crap. ;-)

There are extremes, and there are _extremes_. ;) You can even find 
hardware people slagging off software, so I guess the choice of 
programming language is pretty trivial. Even machine code may be too 
"high level"! Not that my current machine is free from hardware bugs. 

One of these hardware bugs prevented Linux FT installing, a few years 
ago. Ok, ok. So that's just another software problem...

Perfection is great when you can afford it. That's why so many of us 
write software, and perhaps why some of it gets shipped before it's 
ready - and a few corners may have been cut just to get that far.
Maybe that happens at the hardware level, too. It might explain that 
HD controller bug that Linux FT used to object to.

There could be an entire fleet of taxis looking for drivers.
-- 
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
        "There are no limits." -- ad copy for Hellraiser
            Please note: my email address is gubbish
From: Dennis Weldy
Subject: Re: Lisp is *NOT* slow
Date: 
Message-ID: <z4dECh$p8GA.175@news2.ingr.com>
 

Martin Rodgers wrote in article ...
<snip>
>
>Good knowledge of aglorithms is always the place to start, IMHO. Of 
>course, if you learn about aglorithm from a CS book, then the author's 
>preferences may influence you. This is probably why I have a number of 
>these books, by a variety of authors.
>
>Computer science is just as fallible as any other science. The people 
>involved are only human, after all. However, that's no reason to 
>reject CS. Considering the part that it plays in making these darn 
>machines do _anything_ at all, never mind something interesting or 
>useful...but you have to learn some of it in order to appreciate that.
>
Agreed. And even the "theoretical" results of math/cs research has a strong
impact on what wwe do today. After all, one can see clearly the concept of
Turing machines in the most modern CPUs. Without Godel/Turing/Church, (or
equivalent discovery that certain problems are noncomputable)we might still
be trying to solve problems that are unsolvable. ;-) 

Dennis.
From: William Clodius
Subject: Re: Lisp is *SLOW*
Date: 
Message-ID: <33EF6BE4.794B@lanl.gov>
Richard A. O'Keefe wrote:
> <snip>
> If you want really high scientific computing performance, Fortran is
> still the only game in town (well, Sisal is better, and NESL may be,
> but C certainly isn't). <snip>

Unfortunately Lawrence Livermore no longer supports Sisal. Although the
web pages (http://www.llnl.gov/sisal/), binaries, and source codes are
still available, the Sisal team was dissolved about a year ago. (See a
recent thread in comp.lang.functional). Unless someone else supports it,
Sisal's long term future is bleak.

-- 

William B. Clodius		Phone: (505)-665-9370
Los Alamos Nat. Lab., NIS-2     FAX: (505)-667-3815
PO Box 1663, MS-C323    	Group office: (505)-667-5776
Los Alamos, NM 87545            Email: ········@lanl.gov
From: Sajid Ahmed the Peaceman
Subject: Re: Lisp is *SLOW*
Date: 
Message-ID: <33ECA6FA.7E9@capital.net>
Marco Antoniotti wrote:
> As per your declaration of "being a real programmer", I (and I assume
> many other "fake programmers" over here) would like to see a very
> simple admission of ignorance from you.  We read Plato and his
> description of Socrates: "knowing not to know" is usually a good
> starting point.
> 
> Cheers
> --
> Marco Antoniotti
> 

	If you look at my previous posts (someone said that they were
archiving them) you will see several places where I admitted I didn't
know something, usually followed by people calling me an idiot, 
stupid , etc. I have already said that I can accept Lisp as a 
decent programming language, if the recursion is done away with. 

	I will also admit that I was wrong on one of my posts 
about turning recursion into iteration, ( I gave the example 
of infinitely recursive functions, like sine cos, etc. having
no iterative counterparts). I realized that about ten minutes 
after stepping out of the office. 

	Now, will any of you guys admit that you were wrong? 
I thought so.

				Peaceman
From: Martin Rodgers
Subject: Re: Lisp is *SLOW*
Date: 
Message-ID: <MPG.e56c972939c5c8398994d@news.demon.co.uk>
Sajid Ahmed the Peaceman wheezed these wise words:

> 	Now, will any of you guys admit that you were wrong? 

You need to do a lot more than merely claim that you're right. Can you 
back it up with any evidence? Apparently not, otherwise you would have 
done so already.

Prove that nobody can use Lisp to do real work. Now, tehre's a 
challenge. If you merely asserted that nobody you know uses Lisp, then 
there'd be no problem. It wouldn't even suprise me, after looking at 
your Dejanews author profile:

131 unique articles posted. 
     Number of articles posted to individual newsgroups (slightly 
skewed by cross-postings): 
          35 comp.periphs 
          25 comp.lang.lisp 
          10 comp.programming 
          9 comp.os.msdos.programmer 
          6 comp.sys.ibm.pc.hardware 
          5 alt.comp.hardware 
          4 alt.comp 
          4 comp.hardware 
          2 alt.comp.hardware.homebuilt 
          2 alt.os.windows95 
          2 comp.ai.philosophy 
          2 comp.ibm.pc.hardware 
          2 comp.sys.ibm.pc.hardware.misc 
          1 adass.iraf.programming 
          1 alt.cd-rom 
          1 alt.crackers 
          1 alt.test 
          1 comp.benchmarks 
          1 comp.ibm.pc 
          1 comp.os.ms-windows.misc 
          1 comp.os.ms-windows.nt 
          1 comp.os.ms-windows.setup.win95 
          1 comp.periphs.scsi 
          1 comp.sys.ibm.pc.hardware.chips 
          1 comp.sys.ibm.pc.hardware.comm 
          1 comp.sys.ibm.pc.hardware.systems 
          1 comp.sys.ibm.pc.misc 
          1 comp.sys.mac.programmer.help 
          1 comp.sys.palmtops 
          1 comp.virus 
          1 microsoft.public.win95 
          1 ott.forsale.computing 
          1 sci.electronics.design 
          1 tw.bbs.comp.hardware.cpu

It seems that you have a lot to say about PC issues, but that's not 
being disputed here. Instead, it's your assertions about Lisp. Try 
asking Dejanews for profiles of the people disagreeing with you, and 
aee what it tells you about us.

Name the Lisps that you've used. Are any of them commercial systems,
like LispWorks and Allegro CL? Here's LispWorks:

<URL:http://www.harlequin.co.uk/products/ads/lispworks/lispworks.html>

There's a free version of ACL for you to play with:
<URL:http://www.franz.com/frames/dload.main.html>

Show us some code that runs with ACL/PC (I'm sure you can find a 
machine that can run it) that demonstrates the problems that you 
describe. Can you do that?
-- 
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
        "There are no limits." -- ad copy for Hellraiser
            Please note: my email address is gubbish
From: Sajid Ahmed the Peaceman
Subject: Re: Lisp is *SLOW*
Date: 
Message-ID: <33F1D656.E92@capital.net>
Martin Rodgers wrote:
> 
> Sajid Ahmed the Peaceman wheezed these wise words:
> 
> >       Now, will any of you guys admit that you were wrong?
> 
> You need to do a lot more than merely claim that you're right. Can you
> back it up with any evidence? Apparently not, otherwise you would have
> done so already.

	I have already provided ample evidence for all the points 
that I have stated. 

> 
> Prove that nobody can use Lisp to do real work. Now, tehre's a
> challenge. 

	It would be a challenge all right. You can use lisp to 
do work. The question is whether or not it's as easy and 
efficient as other languages. If you don't use any iterative 
code in your lisp program, it's not. 

>If you merely asserted that nobody you know uses Lisp, then
> there'd be no problem. 

	I do assert that nobody I know uses Lisp, or would want 
to use lisp. 





>It wouldn't even suprise me, after looking at
> your Dejanews author profile:
> ...

	I'm glad to see your looking stuff up about me. When you get 
a chance, take a look at my homepage.

http://www.capital.net/com/peaceman	 

> 
> It seems that you have a lot to say about PC issues, but that's not
> being disputed here. Instead, it's your assertions about Lisp. Try
> asking Dejanews for profiles of the people disagreeing with you, and
> aee what it tells you about us.
> 
> Name the Lisps that you've used. Are any of them commercial systems,
> like LispWorks and Allegro CL? Here's LispWorks:
> ...

	I've used a few Lisps in the past, and I'm not about to 
use anymore, thank you. 



					Peaceman
From: Mukesh Prasad
Subject: Re: Lisp is *SLOW*
Date: 
Message-ID: <33F1E8C3.7C6F@polaroid.com>
Sajid Ahmed the Peaceman wrote:
[snip]
>         I'm glad to see your looking stuff up about me. When you get
> a chance, take a look at my homepage.
> 
> http://www.capital.net/com/peaceman
> 

I was wondering what the point of all this was.
Could this be it?  Given that Lisp is now well
known to attract attention on newsgroups...
From: Christopher B. Browne
Subject: Re: Lisp is *SLOW*
Date: 
Message-ID: <slrn5v4hn4.k82.cbbrowne@knuth.brownes.org>
On Wed, 13 Aug 1997 11:44:22 -0400, Sajid Ahmed the Peaceman
<········@capital.net> posted:
>Martin Rodgers wrote:
>> 
>> Sajid Ahmed the Peaceman wheezed these wise words:
>> 
>> >       Now, will any of you guys admit that you were wrong?
>> 
>> You need to do a lot more than merely claim that you're right. Can you
>> back it up with any evidence? Apparently not, otherwise you would have
>> done so already.
>
>	I have already provided ample evidence for all the points 
>that I have stated. 

I haven't seen a single line of code.

I haven't seen any specific run times.

It should be quite simple to present some algorithms whose implementations
are slower in LISP than they are in C++, along with the corresponding
run times.

*THAT* would be ample evidence.

>> Name the Lisps that you've used. Are any of them commercial systems,
>> like LispWorks and Allegro CL? Here's LispWorks:
>> ...
>
>	I've used a few Lisps in the past, and I'm not about to 
>use anymore, thank you. 

*WHICH* implementations, pray tell?

If it was Xlisp, then we can probably all agree that it's not terribly
efficient.  Xlisp was created as a simple PC implementation of LISP.
Drawing any wide conclusions out of running things in Xlisp is entirely
foolish.
-- 
Christopher B. Browne, ········@hex.net, ············@sdt.com
PGP Fingerprint: 10 5A 20 3C 39 5A D3 12  D9 54 26 22 FF 1F E9 16
URL: <http://www.hex.net/~cbbrowne/>
Q: What does the CE in Windows CE stand for?  A: Caveat Emptor...
From: Martin Rodgers
Subject: Re: Lisp is *NOT* slow
Date: 
Message-ID: <MPG.e5ccb62d57370a59899b7@news.demon.co.uk>
Sajid Ahmed the Peaceman wheezed these wise words:

> 	I have already provided ample evidence for all the points 
> that I have stated. 

Evidence? Where? You posted some poor C code that TRO impossible. 
That's not evidence for anything other than the fact that compilers 
can be fooled into not performing an optimisation.

Can you refute the correctly written C code and the resulting code 
produced by GNU C? You've not succeeded so far.
 
> > Prove that nobody can use Lisp to do real work. Now, tehre's a
> > challenge. 
> 
> 	It would be a challenge all right. You can use lisp to 
> do work. The question is whether or not it's as easy and 
> efficient as other languages. If you don't use any iterative 
> code in your lisp program, it's not. 

So you claim. Where's your evidence of this? You admit that your 
education failed to teach you Lisp. The C source code you've posted 
suggests that it also failed to teach you _C_, but perhaps it was just 
a deliberately contrived example, designed to prevent TRO.
 
> 	I do assert that nobody I know uses Lisp, or would want 
> to use lisp. 

Which tells us nothing about Lisp.

> 	I'm glad to see your looking stuff up about me. When you get 
> a chance, take a look at my homepage.
> 
> http://www.capital.net/com/peaceman

I've seen it, some time ago. As I've said. Perhaps you've not been 
reading my posts to closely? I won't question your expertise at 
solving PC problems, but this is rather different from the issues of 
selling PC hardware and software, fixing the problems of products that 
fail, etc. We're talking about programming and compiler theory, two 
areas which you admit that your education failed to teach you.

Let me ask you this question: how many compilers have you written? How 
many books about compilers have you read? If your formal education 
failed, then you could have still taught yourself. However, it appears 
that you have not done this.

BTW, what do you gain by attacking Lisp? If you were right, then it 
could be no possible threat to you! Why then do you go to so much 
trouble (producing such weak arguments, but never mind) to slag off 
something that couldn't ever hurt you? Did your CS teacher leave you 
bitter and twisted, with a need to seek retribution on the language 
that you feel was "responsible" for your educational scars?

> > Name the Lisps that you've used. Are any of them commercial systems,
> > like LispWorks and Allegro CL? Here's LispWorks:
> > ...
> 
> 	I've used a few Lisps in the past, and I'm not about to 
> use anymore, thank you. 

Then shut up and go away. I don't like to be offensive, but you've 
made your point. So why continue to post your anti-Lisp propaganda?
The phrase "put up or shut up" seems very appropriate, somehow.

You could at least explain why you're doing this. What will you 
personally gain by this attack? What kind of threat does Lisp pose 
that it motivates you to argue against it? Is it truely Lisp that 
bothers you, or just the idea that people out there may be using it?

Anyway, back to recursion. Try compiling the following code with VC++ 
4.0 or later (you do have a copy of VC++, don't you?) using "cl $*.c 
/O1" to invoke the compiler.

#include <stdio.h>

int *p = NULL;

void r(int i)
{
	if (p == NULL)
		p = &i;
	printf("%d %p\n", i, &i);

	if (p != &i)
		exit(0);

	r(i + 1);
}

void main(void)
{
//	rfact(300, 400);
	r(1);
}

You should get an output like the following:

1 0012FF80
2 0012FF80
3 0012FF80
4 0012FF80
5 0012FF80
6 0012FF80
7 0012FF80
8 0012FF80
9 0012FF80
10 0012FF80
11 0012FF80
12 0012FF80
13 0012FF80
14 0012FF80
15 0012FF80
16 0012FF80
17 0012FF80
18 0012FF80
19 0012FF80
20 0012FF80
21 0012FF80
22 0012FF80
23 0012FF80
....

And so on, ad infinitum (that's Latin, BTW). Note that the stack space 
is constant. You can check this for yourself. Please do so.

If you can't cope with this, or choose not to, then we can justifiably 
call you a troller and dismiss everything you have to say in your 
trolls. We've certainly be refuting your claims.

Hmm. I wonder what other C/C++ programmers think of this? Perhaps some 
of you could also try the above code and report the result. Remember 
to use optmisation. It could be that only VC++ and GNU C support TRO, 
but these compilers are available to enough programmers for a few of 
you to test Peaceman's claims vs our claims wrt recursion.

Peaceman, your claims belong more in comp.compilers than in 
comp.lang.lisp, comp.programming, comp.lang.c++. I might find the 
result even more entertaining than this current thread, which I'm 
archiving so that when I need a laugh, I can re-read it.
-- 
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
        "There are no limits." -- ad copy for Hellraiser
            Please note: my email address is gubbish
From: Michael Schuerig
Subject: Re: Lisp is *NOT* slow
Date: 
Message-ID: <19970814124816227558@rhrz-isdn3-p18.rhrz.uni-bonn.de>
Martin Rodgers
<···@this_email_address_intentionally_left_crap_wildcard.demon.co.uk>
wrote:

> #include <stdio.h>
> 
> int *p = NULL;
> 
> void r(int i)
> {
>   if (p == NULL)
>       p = &i;
>   printf("%d %p\n", i, &i);
> 
>   if (p != &i)
>       exit(0);
> 
>   r(i + 1);
> }
> 
> void main(void)
> {
> //    rfact(300, 400);
>   r(1);
> }

Metrowerks CodeWarrior Pro 1 does not optimize the tail recursion.

Michael

--
Michael Schuerig            Happiness is good health and a bad memory.
·············@uni-bonn.de                             -Ingrid Bergman
http://www.uni-bonn.de/~uzs90z/
From: Martin Rodgers
Subject: Re: Lisp is *NOT* slow
Date: 
Message-ID: <MPG.e5e71d863f2b2109899be@news.demon.co.uk>
Michael Schuerig wheezed these wise words:

> Metrowerks CodeWarrior Pro 1 does not optimize the tail recursion.

Too bad. Are you sure that you just didn't it the right options? Even 
GNU C will fail to perform TRO if you don't give it the right 
incantation. Still, a few years ago I didn't know of _any_ C compilers 
that could do this. It's possible that CodeWarrior will also be able 
to do it, once Metrowerks decide that it's worth doing.

If Peaceman doesn't convince them that it can't be done, that is. 
Since he appears to know far less about compiler theory than 
Metrowerks, I won't worry about it. As I've said, I'd love to see him 
try this troll in comp.compilers.
-- 
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
        "There are no limits." -- ad copy for Hellraiser
            Please note: my email address is gubbish
From: Sajid Ahmed the Peaceman
Subject: Re: Lisp is *NOT* slow
Date: 
Message-ID: <33F4FEBD.227F@capital.net>
Martin Rodgers wrote:
> 
> Sajid Ahmed the Peaceman wheezed these wise words:
> 
> >       I have already provided ample evidence for all the points
> > that I have stated.
> 
> Evidence? Where? You posted some poor C code that TRO impossible.
> That's not evidence for anything other than the fact that compilers
> can be fooled into not performing an optimisation.
> 

	Let's got throught the summary of this thread: 

	I made a post that LISP programs were slow, and that 
Lisp programmers were deceived because of their abstract 
mathematical worlds, i.e. thinking computer functions returning 
instantaneously. I got about 10 responses, mostly flames, some 
legitimate saying that Lisp supports iteration. I then said
I could accept Lisp as a decent language if it indeed was
an iterative language, and I apologized for calling all Lisp 
programmers as deceived. I then got more flames and name calling.
I then gave the example of the Qsort algorithm taking several 
lines in Lisp, and just a few in C. Someone posted a 15 line Qsort 
lisp program. I then pointed out that the program that was posted
was not "good" lisp code because of the use of local (automatic) 
variables. I fixed up the code to get rid of the local variables, 
and got a program with 80+ lines. I then got more flames about the 
style that I used, and someone changed my code and put several 
statements on each line, and brought it down to about 24 lines.
Then there were several comments from people in the Lisp group 
about some implementations of C using shell sort instead of the 
standard Qsort, with more flames thrown at me throughout.  
I then pointed out that the reason the Lisp code is slow is becuase
of the overhead of recursion, i.e. a stack.  You guys then said
that recursion doesn't need a stack because of tail recursion,
and tail recursion optimization, with more flames added. I then gave 
an example of tail recursion that needed a stack, because of the 
numerous posts about tail recursion, even though my argument was
about all recursion in general. I got more flames and name calling 
as expected. Now the thread has moved on to pointers and references 
in Lisp. 

         Flame me and call me as many names as you want. It doesn't 
do anything. 

> 
> Anyway, back to recursion. Try compiling the following code with VC++
> 4.0 or later (you do have a copy of VC++, don't you?) using "cl $*.c
> /O1" to invoke the compiler.
> 
> #include <stdio.h>
> 
> int *p = NULL;
> 
> void r(int i)
> {
>         if (p == NULL)
>                 p = &i;
>         printf("%d %p\n", i, &i);
> 
>         if (p != &i)
>                 exit(0);
> 
>         r(i + 1);
> }
> 
> void main(void)
> {
> //      rfact(300, 400);
>         r(1);
> }
> 
> You should get an output like the following:
> 
> 1 0012FF80
> 2 0012FF80
> 3 0012FF80
> 4 0012FF80
> 5 0012FF80
> 6 0012FF80
> 7 0012FF80
> 8 0012FF80
> 9 0012FF80
> 10 0012FF80
> 11 0012FF80
> 12 0012FF80
> 13 0012FF80
> 14 0012FF80
> 15 0012FF80
> 16 0012FF80
> 17 0012FF80
> 18 0012FF80
> 19 0012FF80
> 20 0012FF80
> 21 0012FF80
> 22 0012FF80
> 23 0012FF80
> ....
> 
> And so on, ad infinitum (that's Latin, BTW). Note that the stack space
> is constant. You can check this for yourself. Please do so.
> 

	Thats a good observation you've made with the visual C++ 
compiler and it's optimization techniques. Some people claim this 
as a bug, others as a feature.  

					Peaceman
From: Martin Rodgers
Subject: Re: Lisp is *NOT* slow
Date: 
Message-ID: <MPG.e5fc8e15d804fa59899cb@news.demon.co.uk>
Sajid Ahmed the Peaceman wheezed these wise words:

>          Flame me and call me as many names as you want. It doesn't 
> do anything. 

Pointing out technical flaws in your argument isn't flaming. Any 
flaming you get is for your insistance on assuming that you can talk 
about a subject while being completely ignorant of it. You even admit 
your ignorance, i.e. your failed education.

Your recursion code was _not_ tail recursion, and therefore could not 
be eliminated by the compiler. Corrected versions of your function 
were posted by others - did you read them? Can you see the difference?

Can you give me a reason for not thinking of your posts as trolls?
You repeated refused to offer any evidence wrt to Lisp, and your C 
code is either flawed or deliberately contrived to prevent TRO.

Why should anyone _not_ call you a troller? Why should anyone not 
dismiss all your claims as nothing but a troll? If you have an agenda 
other than trashing Lisp, then please state it.
-- 
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
        "There are no limits." -- ad copy for Hellraiser
            Please note: my email address is gubbish
From: Marco Antoniotti
Subject: Re: Lisp is *NOT* slow
Date: 
Message-ID: <scfafii56dv.fsf@ferrari.PATH.Berkeley.EDU>
I offer my sincerest apologies to everyone (including the Peaceman) up
here.  I just cannot resist. :)

In article <·············@capital.net> Sajid Ahmed the Peaceman <········@capital.net> writes:

   From: Sajid Ahmed the Peaceman <········@capital.net>
   Newsgroups: comp.lang.lisp,comp.programming,comp.lang.c++
   Date: Fri, 15 Aug 1997 21:13:33 -0400
   Organization: Logical Net
   Reply-To: ········@capital.net
   Lines: 109
   Mime-Version: 1.0
   Content-Type: text/plain; charset=us-ascii
   Content-Transfer-Encoding: 7bit
   X-Mailer: Mozilla 3.01 (WinNT; I)
   Xref: agate comp.lang.lisp:29992 comp.programming:54285 comp.lang.c++:287749

	   Let's got throught the summary of this thread: 

	   I made a post that LISP programs were slow, and that 
   Lisp programmers were deceived because of their abstract 
   mathematical worlds, i.e. thinking computer functions returning 
   instantaneously. I got about 10 responses, mostly flames, some 
   legitimate saying that Lisp supports iteration. I then said
   I could accept Lisp as a decent language if it indeed was
   an iterative language, and I apologized for calling all Lisp 
   programmers as deceived.

Thank you.  But you forget to mention that your unwarranted comments
about recursion came about at this point.

   I then got more flames and name calling.
   I then gave the example of the Qsort algorithm taking several 
   lines in Lisp, and just a few in C. Someone posted a 15 line Qsort 
   lisp program. I then pointed out that the program that was posted
   was not "good" lisp code because of the use of local (automatic) 
   variables. I fixed up the code to get rid of the local variables, 
   and got a program with 80+ lines. I then got more flames about the 
   style that I used, and someone changed my code and put several 
   statements on each line, and brought it down to about 24 lines.

Your Qsort program in LISP was pure junk.  I do not remember your
Qsort in C, but I am afraid to think about it, having seen your 'factorial'.

   Then there were several comments from people in the Lisp group 
   about some implementations of C using shell sort instead of the 
   standard Qsort, with more flames thrown at me throughout.

This was an interesting discussion in which you showed you did not
have a clue why using shell sort instead of quicksort was an issue at
all.

   I then pointed out that the reason the Lisp code is slow is becuase
   of the overhead of recursion, i.e. a stack.  You guys then said
   that recursion doesn't need a stack because of tail recursion,
   and tail recursion optimization, with more flames added.

"we guys" said that there are TWO kinds of recursion (a fact which you
choose to ignore) and that tail-recursion can be eliminated by the compiler.

   I then gave 
   an example of tail recursion that needed a stack, because of the 
   numerous posts about tail recursion, even though my argument was
   about all recursion in general.

You gave first an incredibly obfuscated C version of the factorial
function which was NOT tail-recursive (showing that you just did not
get it).  BTW.  I am still waiting for the iterative traversal of
binary trees.  Then you posted an obfuscated version which was tail
recursive and people showed you that a good compiler can eliminate the
stack allocation.

   I got more flames and name calling 
   as expected. Now the thread has moved on to pointers and references 
   in Lisp. 

I have missed this part.  I just recall your useless cluttering of C
code with pointers.

	    Flame me and call me as many names as you want. It doesn't 
   do anything. 

I got that.  But I get a perverted pleasure from pointing out balooney
:)

Cheers

-- 
Marco Antoniotti
==============================================================================
California Path Program - UC Berkeley
Richmond Field Station
tel. +1 - 510 - 231 9472
From: Gareth McCaughan
Subject: Re: Lisp is *NOT* slow
Date: 
Message-ID: <86u3gdgfnr.fsf@g.pet.cam.ac.uk>
"Sajid Ahmed the Peaceman" wrote:

> 	Let's got throught the summary of this thread: 

OK, let's.

> 	I made a post that LISP programs were slow, and that 
> Lisp programmers were deceived because of their abstract 
> mathematical worlds, i.e. thinking computer functions returning 
> instantaneously. I got about 10 responses, mostly flames, some 
> legitimate saying that Lisp supports iteration. I then said
> I could accept Lisp as a decent language if it indeed was
> an iterative language,

which, from later comments, seems to mean "if it indeed made
writing recursive code gratuitously difficult", since you're
still objecting to Lisp on the grounds that some people write
recursive code in it

>                        and I apologized for calling all Lisp 
> programmers as deceived

while still suggesting that everyone who ever writes recursive
code is deceived or stupid or something

>                        . I then got more flames and name calling.
> I then gave the example of the Qsort algorithm taking several 
> lines in Lisp, and just a few in C. Someone posted a 15 line Qsort 
> lisp program. I then pointed out that the program that was posted
> was not "good" lisp code because of the use of local (automatic) 
> variables

although why local variables are supposed to be bad Lisp style,
I cannot imagine

>          . I fixed up the code to get rid of the local variables, 
> and got a program with 80+ lines

by inserting vast quantities of whitespace and incidentally making
the code much worse

>                                 . I then got more flames about the 
> style that I used, and someone changed my code and put several 
> statements on each line,

or (to put it differently) refrained from splitting each statement
over many, many lines, and undid some of your gratuitous insertion
of whitespace,

>                          and brought it down to about 24 lines.
> Then there were several comments from people in the Lisp group 
> about some implementations of C using shell sort instead of the 
> standard Qsort, with more flames thrown at me throughout.  
> I then pointed out

falsely

>                    that the reason the Lisp code is slow

(which it isn't, so far as anyone can tell from the evidence you've
posted)

>                                                          is becuase
> of the overhead of recursion, i.e. a stack.  You guys then said
> that

tail

>      recursion doesn't need a stack because of tail recursion,
> and tail recursion optimization, with more flames added. I then gave 
> an example of

something that looks a bit like

>               tail recursion

but actually isn't

>                              that needed a stack, because of the 
> numerous posts about tail recursion, even though my argument was
> about all recursion in general

and persisted in making assertions about all recursion which are
false because some recursion is tail recursion

>                               . I got more flames and name calling 
> as expected. Now the thread has moved on to pointers and references 
> in Lisp. 


Then, later,

> 	Thats a good observation you've made with the visual C++ 
> compiler and it's optimization techniques. Some people claim this 
> as a bug, others as a feature.  

Perhaps you could explain some respect in which it is wrong for
a C compiler to perform the optimisation in question in the case
in question?

-- 
Gareth McCaughan       Dept. of Pure Mathematics & Mathematical Statistics,
·····@dpmms.cam.ac.uk  Cambridge University, England.
From: Dennis Weldy
Subject: Re: Lisp is *SLOW*
Date: 
Message-ID: <NJjgS5zp8GA.151@news2.ingr.com>
 Hmm...ok, then you must not consider C, C++, Pascal, or any of the
algol-derived languages decent?
After all, they too support recursion. 
Guess you don't consider assembly decent either, cause it allows one to do
stuff recursively also.

My point is, that if you don;t want to use recursion in Lisp, y'dont have
to. No one forces you to do so in C. 
;-) It's been pointed out here that Lisp has several nice iterative
constructs. 

So, given that, what's the problem?

Dennis


Sajid Ahmed the Peaceman wrote in article <············@capital.net>...

>Marco Antoniotti wrote:
>> As per your declaration of "being a real programmer", I (and I assume
>> many other "fake programmers" over here) would like to see a very
>> simple admission of ignorance from you.  We read Plato and his
>> description of Socrates: "knowing not to know" is usually a good
>> starting point.
>> 
>> Cheers
>> --
>> Marco Antoniotti
>> 
>
> If you look at my previous posts (someone said that they were
>archiving them) you will see several places where I admitted I didn't
>know something, usually followed by people calling me an idiot, 
>stupid , etc. I have already said that I can accept Lisp as a 
>decent programming language, if the recursion is done away with. 
>
> I will also admit that I was wrong on one of my posts 
>about turning recursion into iteration, ( I gave the example 
>of infinitely recursive functions, like sine cos, etc. having
>no iterative counterparts). I realized that about ten minutes 
>after stepping out of the office. 
>
> Now, will any of you guys admit that you were wrong? 
>I thought so.
>
> Peaceman
>.
> 
From: Marco Antoniotti
Subject: Re: Lisp is *SLOW*
Date: 
Message-ID: <scf67tam260.fsf@infiniti.PATH.Berkeley.EDU>
In article <············@capital.net> Sajid Ahmed the Peaceman <········@capital.net> writes:

   From: Sajid Ahmed the Peaceman <········@capital.net>
   Newsgroups: comp.lang.lisp,comp.programming,comp.lang.c++
   Date: Sat, 09 Aug 1997 13:20:58 -0400
   Organization: Logical Net
   Reply-To: ········@capital.net
   Mime-Version: 1.0
   Content-Type: text/plain; charset=us-ascii
   Content-Transfer-Encoding: 7bit
   X-Mailer: Mozilla 3.01 (WinNT; I)
   Xref: agate comp.lang.lisp:29784 comp.programming:53749 comp.lang.c++:286382

   Marco Antoniotti wrote:
   > As per your declaration of "being a real programmer", I (and I assume
   > many other "fake programmers" over here) would like to see a very
   > simple admission of ignorance from you.  We read Plato and his
   > description of Socrates: "knowing not to know" is usually a good
   > starting point.
   > 

	   If you look at my previous posts (someone said that they were
   archiving them) you will see several places where I admitted I didn't
   know something, usually followed by people calling me an idiot, 
   stupid , etc. I have already said that I can accept Lisp as a 
   decent programming language, if the recursion is done away with. 

I was not making any point about Lisp "per se".  My remarks were on
the "general computing" track.

	   I will also admit that I was wrong on one of my posts 
   about turning recursion into iteration, ( I gave the example 
   of infinitely recursive functions, like sine cos, etc. having
   no iterative counterparts). I realized that about ten minutes 
   after stepping out of the office. 

But you still have not provided the iterative translation of the C
recursive code I posted a couple of weeks ago.

	   Now, will any of you guys admit that you were wrong? 
   I thought so.

Wrong about what?  Let's agree on the topics we are discussing and we
can start distributing torts and medals.



-- 
Marco Antoniotti
==============================================================================
California Path Program - UC Berkeley
Richmond Field Station
tel. +1 - 510 - 231 9472
From: Sajid Ahmed the Peaceman
Subject: Re: Lisp is *SLOW*
Date: 
Message-ID: <33F1FC78.2538@capital.net>
Marco Antoniotti wrote:
> 
> But you still have not provided the iterative translation of the C
> recursive code I posted a couple of weeks ago.
> 


	Post it again.  I'll provide you the iterative translation.

					Peaceman
From: Marco Antoniotti
Subject: Re: Lisp is *SLOW*
Date: 
Message-ID: <scfen7xyapf.fsf@infiniti.PATH.Berkeley.EDU>
In article <·············@capital.net> Sajid Ahmed the Peaceman <········@capital.net> writes:

   From: Sajid Ahmed the Peaceman <········@capital.net>
   Newsgroups: comp.lang.lisp,comp.programming,comp.lang.c++
   Date: Wed, 13 Aug 1997 14:27:04 -0400
   Organization: Logical Net
   Reply-To: ········@capital.net
   Lines: 10

   Marco Antoniotti wrote:
   > 
   > But you still have not provided the iterative translation of the C
   > recursive code I posted a couple of weeks ago.
   > 


	   Post it again.  I'll provide you the iterative translation.

Voila`!  Remember.  No stack or funny 'parent field allowed'. :)

Forget about 'insert'.  Just provide the translations for
'preorder_traversal' and 'inorder_traversal'.

------------------------------------------------------------------------------

#include <stdio.h>
#include <assert.h>
#include <stdlib.h>

typedef struct _tree_node
{
   int key;
   struct _tree_node *left;
   struct _tree_node *right;
} tree_node;

void
insert (tree_node *tree, int value)
{
  assert (tree);
  
  if (value == tree->key)
    return;
  else if (value < tree->key)
    {
      if (tree->left == 0)
	{
	  tree->left = (tree_node*) malloc (sizeof (tree_node));
	  tree->left->key = value; /* Sorry.  No check on malloc return. */
	}
      else
	insert (tree->left, value);
    }
  else
    {
      if (tree->right == 0)
	{
	  tree->right = (tree_node*) malloc (sizeof (tree_node));
	  tree->right->key = value; /* Sorry.  No check on malloc return. */
	}
      else
	insert (tree->right, value);
    }
}


void
preorder_traversal (tree_node *tree)
{
  if (tree == 0)
    return;
  else
    {
      printf ("%d ", tree->key);
      preorder_traversal (tree->left);
      preorder_traversal (tree->right);
    }
}


void
inorder_traversal (tree_node *tree)
{
  if (tree == 0)
    return;
  else
    {
      inorder_traversal (tree->left);
      printf ("%d ", tree->key);
      inorder_traversal (tree->right);
    }
}

void
main()
{
  tree_node *root = (tree_node*) malloc (sizeof (tree_node));
  __const__ int tree_size = 20;
  int count;

  /* Sorry.  No system error checking.. */

  srand(getpid());

  root->key = rand() % 100;

  for (count = 0; count < tree_size; count++)
    insert(root, rand() % 100);

  puts("Preorder traversal\n");
  preorder_traversal(root);
  putchar('\n');

  puts("\nInorder traversal\n");
  inorder_traversal(root);
  putchar('\n');
}

------------------------------------------------------------------------------
-- 
Marco Antoniotti
==============================================================================
California Path Program - UC Berkeley
Richmond Field Station
tel. +1 - 510 - 231 9472
From: Marco Antoniotti
Subject: Re: Lisp is *SLOW*
Date: 
Message-ID: <scfd8nhy94u.fsf@infiniti.PATH.Berkeley.EDU>
Apologies to the C programmers out there.  Being a Lisp programmer I
assumed (wrongly) that 'malloc' returns a 'zeroed' structure, which
might not be the case.  Hence I introduced what purify calls an
'uninitialized memory bug' in the function 'insert'.

Cheers

-- 
Marco Antoniotti
==============================================================================
California Path Program - UC Berkeley
Richmond Field Station
tel. +1 - 510 - 231 9472
From: David Thornley
Subject: Re: Lisp is *SLOW*
Date: 
Message-ID: <5sv2vq$ej7$1@darla.visi.com>
In article <···············@infiniti.PATH.Berkeley.EDU>,
Marco Antoniotti <·······@infiniti.PATH.Berkeley.EDU> wrote:
>
>Apologies to the C programmers out there.  Being a Lisp programmer I
>assumed (wrongly) that 'malloc' returns a 'zeroed' structure, which
>might not be the case.  Hence I introduced what purify calls an
>'uninitialized memory bug' in the function 'insert'.
>
Well, you could use calloc(), which promises all-bits-zero, except if
you intend to use the field as a floating-point or pointer value,
since only integers have a guaranteed value (zero) for all-bits-zero.
Don't forget to change the arguments, since malloc(n * sizeof (int))
is the same as calloc(n, sizeof(int)).  Remember also that it is
unwise to cast the value returned by malloc or calloc, since a void *
will be automatically converted to any other pointer type, and if
you do cast it you make it harder to tell if you've left out the
#include <stdlib.h>, which can cause subtle bugs.  You did, of
course, leave out checking for malloc failure, which in lisp terms
is (safety 0), but is forgiveable for an example.  Don't forget to
keep some sort of idea of who's got what, so that you free all
memory after you're through with it and not before.

The preceding paragraph was brought to you by the "real world".
Have fun!

Reality is for folks who can't handle Lisp.

David Thornley
From: Dennis Weldy
Subject: Re: Lisp is *SLOW*
Date: 
Message-ID: <j4#k#WNp8GA.75@news2.ingr.com>
 

Sajid Ahmed the Peaceman wrote in article <·············@capital.net>...
 >5. Web/Java programming 
> At the moment there is a demand for Java (and cgi scripting), 
>   but in my analysis, it won't last long. Why you ask? Let's take a 
>   look at the so called advantages of Java:
>    
>   Platform independence: That doesn't work. C, basic, fortran, and 
>      many other languages have been around for years, and there 
>      hasn't been any trend to make some kind of on the fly compiler, 
>      to run the source code on different platforms. If there really 
>      was a demand for platform independent programs, I'm sure 
>      we would have seen some kind of C machines, or Fortran machines, 
>      that correspond with the now JAVA machines. 

Do remember the pascal P-machine of years gone by. Yes, that was a
forerunner (conceptual) of virtual machine-compile-on-the-fly platform
independence. Of course, it was so much slower than native code....and the
capabilities of different platforms were...quite different. 

What do things look like today? Well. I'd imagine that you'd be
hard-pressed to find a plain-old-text-terminal hooked up to the net
anymore. I'd even go so far as to say that nearly all (ok, most) have
comparable graphics facilities. Furthger, increases in the processing power
of the machines don't make it that much of a penalty anymore to run the
interpeted code. Or even "compiling on the fly". 

Im so glad that Dennis Ritchie, Ken Thompson didn't use the same if:
If there really was a demand for a small multiprocessor-multiuser OS, Im
sure someone else would've written it by now. So lets forget about this
Unix stuff.
If there really was a demand for a small language that could be used for
systems programming, we would've seen it already. So lets forget this C
stuff. 

Or how about:
If there were a need for a client-server-type graphics protocol, it wuldve
been developed already. So lets shut down the X project....

If I remember my history rightly, Java started out as a language which
would be used for set-top boxes. Rather than use existing embedded-systems
tools, hey decided to create a virtual machine. That way, the controlling
code would be independent, just the VM would be reimplemented on different
platforms. Then along came the Internet. :-) "Hey, we could use this stuff
in Browsers and on the web!"

C can be platform independent (at the source level). Same with fortran. Of
course, for different platforms you have to recompile the program, or
provide executables for ALL platforms on which you wish your program to
execute. Lots of disk space, and lots of time. Oh yeah, you also have to be
alle to verify the proggie works on all the platforms.. ;-)

With Java, you just have the bytecode. The bytecode can either be
interpreted OR just-in-time compiled. 
On the user's machine across the net. Realistically, I'd say that [personal
opinion] that Java would not be where it is today, were it not for the Web.
Had Java not entered the picture, most likely you wouldve seen someone
coming up with a "platform independent p-code C machine, or fortran, or
<insert favorite language here>" 

>
>   Static access to internet resources: HTTP corresponds to the ftp 
>      protocol of the past, with an easier interface and fancy pictures.
>      It's just a matter of time before a protocol is introduced that 
>      does the same with the telnet. When that happens, say goodbye to 
>      Java and cgi scripts.   
We have  protocol that lets you have an easier interface and fancy pictures
on remote machines. it's called X. Of course, would you want strangers on
the net being able to execute any program on your server? Would you want
any site to have access to your local machine? For me, its NO on both
counts. 
>  
>
> 
> The question is, where does LISP fit into this picture? I'd
>really like to hear your response. 

Lisp fits int the above, by being yet another programming language. Use it
(or dont) as you see fit).

Dennis
>
>
> Peaceman
>.
> 
From: Sajid Ahmed the Peaceman
Subject: Re: Lisp is *SLOW*
Date: 
Message-ID: <33ECB881.762E@capital.net>
Dennis Weldy wrote:
> 
> 
> 
> Sajid Ahmed the Peaceman wrote in article <·············@capital.net>...
>  >5. Web/Java programming
> > At the moment there is a demand for Java (and cgi scripting),
> >   but in my analysis, it won't last long. Why you ask? Let's take a
> >   look at the so called advantages of Java:
> >
> >   Platform independence: That doesn't work. C, basic, fortran, and
> >      many other languages have been around for years, and there
> >      hasn't been any trend to make some kind of on the fly compiler,
> >      to run the source code on different platforms. If there really
> >      was a demand for platform independent programs, I'm sure
> >      we would have seen some kind of C machines, or Fortran machines,
> >      that correspond with the now JAVA machines.
> 
> Do remember the pascal P-machine of years gone by. Yes, that was a
> forerunner (conceptual) of virtual machine-compile-on-the-fly platform
> independence. Of course, it was so much slower than native code....and the
> capabilities of different platforms were...quite different.
> 
> What do things look like today? Well. I'd imagine that you'd be
> hard-pressed to find a plain-old-text-terminal hooked up to the net
> anymore. I'd even go so far as to say that nearly all (ok, most) have
> comparable graphics facilities. Furthger, increases in the processing power
> of the machines don't make it that much of a penalty anymore to run the
> interpeted code. Or even "compiling on the fly".
> 
> Im so glad that Dennis Ritchie, Ken Thompson didn't use the same if:
> If there really was a demand for a small multiprocessor-multiuser OS, Im
> sure someone else would've written it by now. So lets forget about this
> Unix stuff.
> If there really was a demand for a small language that could be used for
> systems programming, we would've seen it already. So lets forget this C
> stuff.
> 
> Or how about:
> If there were a need for a client-server-type graphics protocol, it wuldve
> been developed already. So lets shut down the X project....
> 
> If I remember my history rightly, Java started out as a language which
> would be used for set-top boxes. Rather than use existing embedded-systems
> tools, hey decided to create a virtual machine. That way, the controlling
> code would be independent, just the VM would be reimplemented on different
> platforms. Then along came the Internet. :-) "Hey, we could use this stuff
> in Browsers and on the web!"
> 
> C can be platform independent (at the source level). Same with fortran. Of
> course, for different platforms you have to recompile the program, or
> provide executables for ALL platforms on which you wish your program to
> execute. Lots of disk space, and lots of time. Oh yeah, you also have to be
> alle to verify the proggie works on all the platforms.. ;-)
> 
> With Java, you just have the bytecode. The bytecode can either be
> interpreted OR just-in-time compiled.
> On the user's machine across the net. Realistically, I'd say that [personal
> opinion] that Java would not be where it is today, were it not for the Web.
> Had Java not entered the picture, most likely you wouldve seen someone
> coming up with a "platform independent p-code C machine, or fortran, or
> <insert favorite language here>"
> 
> >


	I think JAVA is a great language, I just don't think it will catch
on in the computer world. I could be wrong, but that is my analysis of
things. 


> >   Static access to internet resources: HTTP corresponds to the ftp
> >      protocol of the past, with an easier interface and fancy pictures.
> >      It's just a matter of time before a protocol is introduced that
> >      does the same with the telnet. When that happens, say goodbye to
> >      Java and cgi scripts.
> We have  protocol that lets you have an easier interface and fancy pictures
> on remote machines. it's called X. Of course, would you want strangers on
> the net being able to execute any program on your server? Would you want
> any site to have access to your local machine? For me, its NO on both
> counts.
> >

    CGI scripts are out there and running right this moment. They run 
on the servers machine, and the output is sent back to the client 
as a web page. 



					Peaceman
From: Christopher Oliver
Subject: Re: Lisp is *SLOW*
Date: 
Message-ID: <5sj44f$bni@guy-smiley.traverse.com>
Subject: Re: Lisp is *SLOW*
Newsgroups: comp.lang.lisp,comp.programming,comp.lang.c++
Followup-To: comp.lang.lisp,comp.programming,comp.lang.c++
References: <············@cdn-news.telecom.com.au> <·············@capital.net> <·············@capital.net> <············@nic.wat.hookup.net> <·············@capital.net> <·································@news.lavielle.com> <·············@capital.net> <············@nic.wat.hookup.net> <·············@capital.net>
Organization: The magic land of misplaced socks
Distribution: 

Sajid Ahmed the Peaceman (········@capital.net) wrote:
: 	Let's take a look at the following example of tail recursion, 

... which is NOT and example of tail recursion.  Not only are you doing
further computation with the returned value of the procedure, but you're
also passing in an automatic variable.

Following are two somewhat long winded examples with code, but please
bear with me.

Since I'm more confortable with C:

: int factorial(int *number) {
:    int x;
:    if (*number == 1) return 1; 
:    x = *number-1;
:    return *number * factorial(&x);
: } 

This is not tail recursive.  Instead you should have written:

static int fact-aux(int n, int p) {
  return n <= 1 ? p : fact-aux(n-1, p * n);
}

int fact(int n) {
  return fact-aux(n, 1);
}

Results for 'gcc -O3 -S -fomit-frame-pointer':

        .file   "fact.c"
        .version        "01.01"
gcc2_compiled.:
.text
        .align 4
.globl fact
        .type    fact,@function
fact:
        movl 4(%esp),%edx         ; We fetch our initial argument here.
        movl $1,%eax              ; We fetch our iteration counter here.
.L11:
        cmpl $1,%edx              ; Are we done?
        jle .L10                  ; If so, return our value.
        imull %edx,%eax           ; Otherwise, compute next running product.
        decl %edx                 ; Decrement iteration counter.
        jmp .L11                  ; Loop (NOT CALL SUBROUTINE!)
        .align 4
.L10:
        ret
.Lfe1:
        .size    fact,.Lfe1-fact
        .ident  "GCC: (GNU) 2.7.2.1"

I see no explicit recursion here nor any stack use within the iteration.
Where's the beef?


With that out of the way, let's examine the compilation with Attardi's
EcoLisp to C of the following tail recursive factorial in Lisp:

(defun fact (n)
  (labels ((fact-aux (n p)
		     (if (<= n 1)
			 p
		       (fact-aux (- n 1) (* n p)))))
    (fact-aux n 1)))

The meat of the compilation:

/*      function definition for FACT                                  */
static L1(int narg, object V1)
{
  VT3 VLEX3 CLSR3
    TTL:
    RETURN(LC2(2, (V1), MAKE_FIXNUM(1)) /*  FACT-AUX        */ );
}
/*      local function FACT-AUX                                       */
static LC2(int narg, object V1, object V2)
{
  VT4 VLEX4 CLSR4
    TTL:
  if (!(number_compare((V1), MAKE_FIXNUM(1)) <= 0))
    {
      goto L2;
    }
  VALUES(0) = (V2);
  RETURN(1);
L2:
  {
    object V3;
    V3 = number_minus((V1), MAKE_FIXNUM(1));
    V2 = number_times((V1), (V2));
    V1 = (V3);
  }
  goto TTL;
}

While there is consing going on here, I see loops built with goto, but
no explicit recursion despite its presence in the original Lisp.  There
doesn't seem to be any repeated allocation of automatic variables either.
Hmmm...  Curious!

: 	There you have it, tail recurion that needs a stack.

You're not looking too good, son.  Would you like to play some more?

--
Christopher Oliver                     Traverse Communications
Systems Coordinator                    223 Grandview Pkwy, Suite 108
oliver -at- traverse -dot- com         Traverse City, Michigan, 49684
   Some mornings it just doesn't seem worth it to gnaw through the
   leather straps.      -- Emo Phillips
From: ? the platypus {aka David Formosa}
Subject: Re: Lisp is *SLOW*
Date: 
Message-ID: <871225993.841966@cabal>
In <·············@capital.net> Sajid Ahmed the Peaceman <········@capital.net> writes:

[...]

>2.  Applications programming
>	Most companies and people use ms windows, and visual c++ is the way
>  to go,

If I was doing Applications programing in a windows envoiroment I would
make use of delphi.  In fact a current projet I am wroking on has
a delphi frount end and a back end writton in Lisp.

[...]

>3. Network Programming
>	This is a very strong field. You really need to know the O.S. 
>   and platform aspect, more than the programming aspect.

For some odd reson the IMAP protcol kicks out very lispy resoponces.
In fact as Network Programming is mostly buliding parsers for protocols
and Lisp is very good for doing this Lisp is a very good languege for
some types of network programming.

[...]

>4. Scientific programming 
>	C is the way to go.

For what reson?  Most Scince programing is Floating point number crunching
for wich Lisp has very good libries.

[...]

>5. Web/Java programming 
>	At the moment there is a demand for Java (and cgi scripting), 
>   but in my analysis, it won't last long.

This will be amusing

>   Why you ask? Let's take a look at the so called advantages of Java:
>    
>   Platform independence: [...] there 
>      hasn't been any trend to make some kind of on the fly compiler, 
>      to run the source code on different platforms.

There has been massive demand for such a product.  Why do you think that
C and Unix gained the strean in the first place?  Simply becuse there 
where C compliers for every know hardwhere advalable.  But still with
C you have to do alot of hacking to get it to be totly portable.

[...]

>   Static access to internet resources: HTTP corresponds to the ftp 
>      protocol of the past, with an easier interface and fancy pictures.

I would say that HTTP is closer to gopha then ftp.

>      It's just a matter of time before a protocol is introduced that 
>      does the same with the telnet.  When that happens, say goodbye to 
>      Java and cgi scripts. 

Quoi?  telnet is older then ftp and works on a totaly diffrent consept.
FTP and telnet live happerly togetther a new telnet like protocol will 
not case the end of the web.  

--
Please excuse my spelling as I suffer from agraphia see the url in my header. 
Never trust a country with more peaple then sheep. Buy easter bilbies.
Save the ABC Is $0.08 per day too much to pay?   ex-net.scum and proud
I'm sorry but I just don't consider 'because its yucky' a convincing argument
From: William Clodius
Subject: Re: Lisp is *SLOW*
Date: 
Message-ID: <33EF3135.2781@lanl.gov>
Sajid Ahmed the Peaceman wrote:
> <snip>
> 4. Scientific programming
>         C is the way to go. Fortran is still around, but will be gone
>    as soon as the scientists that only know fortran kick the bucket.
> <snip>

From Perlis's "Epigrams on Programming", Sigplan 17 #9, Sept 1982, also
available at

http://www.cs.cmu.edu/~spot/programming-epigrams.html

"42. You can measure a programmer's perspective by noting his attitude
on the continuing vitality of FORTRAN."

-- 

William B. Clodius		Phone: (505)-665-9370
Los Alamos Nat. Lab., NIS-2     FAX: (505)-667-3815
PO Box 1663, MS-C323    	Group office: (505)-667-5776
Los Alamos, NM 87545            Email: ········@lanl.gov
From: Emergent Technologies Inc.
Subject: Lisp is slow:  proof!
Date: 
Message-ID: <5sr41u$k8$1@newsie2.cent.net>
Ok, the subject line is a little misleading.
I'd just like to draw attention to ``The Supercomputer Toolkit:
A General Framework for Special-Purpose Computing'' by
Harold Abelson, Andrew Berlin, Jacob Katzenelson, William
McAllister, Guillermo Rozas, Gerald Sussman, and Jack Wisdom.

They describe joint work done around 1991 between the MIT
Project for Mathematics and Computation and Hewlett-Packard's
Information Architecture Group on the design and construction of
a Supercomputer Toolkit.

This toolkit was used to compute the long-term motion of the
Solar System, improving upon previous integrations by two orders
of magnitude.  The report on the analysis was published in Science,
which devoted an editorial to the significance of this achievement.

The toolkit achieves scalar floating point performance equal to eight
times a Cray 1S programmed in Cray Fortran.  The approach of
partial evaluation allowed the development of a library of symbolic
manipulation components to support automatic construction of
simulation codes.  As an example, the Solar system simulation code
issues a floating-point operation on 98% of the instructions.

What is the toolkit language (and I'm sure you see this coming)
?

Lisp.

And not micro-optimized Lisp, but highly abstract code.  Here is an
example.

(define add-vectors (vector-elementwise +))

.(define (vector-elementwise f)
  .  (lambda (vectors)
.    (generate-vector
.     (vector-length (car vectors))
.     (lambda (i)
.        (apply f (map (lambda (v) (vector-ref v i))
.                            vectors))))))
.
.(define (generate-vector size proc)
.  (let ((ans (make-vector size)))
.   (define (loop i)
.      (if (= i size)
.          ans
.          (begin (vector-set! ans i (proc i))
.                    (loop (+ i 1)))))
.   (loop 0)))

This code is drawn from the paper and is the type of code used in
programming the toolkit.

Constructs such as APPLY cannot be expressed in C (variable
arity).  

This code also uses recursion to describe an iterative
process.
 
Sajid Ahmed the Peaceman wrote in article <·············@capital.net>...
>
>4. Scientific programming
> C is the way to go. Fortran is still around, but will be gone
>   as soon as the scientists that only know fortran kick the bucket.
>
> The question is, where does LISP fit into this picture? I'd
>really like to hear your response.

It looks to me that it occupies the high ground.

~jrm
From: Martin Rodgers
Subject: Lisp is *NOT* slow:  proof!
Date: 
Message-ID: <MPG.e5b7a1d1491435f9899a4@news.demon.co.uk>
Emergent Technologies Inc. wheezed these wise words:

> Ok, the subject line is a little misleading.

So I changed it to something closer to the truth. ;)

> I'd just like to draw attention to ``The Supercomputer Toolkit:
> A General Framework for Special-Purpose Computing'' by
> Harold Abelson, Andrew Berlin, Jacob Katzenelson, William
> McAllister, Guillermo Rozas, Gerald Sussman, and Jack Wisdom.

Is this paper on the web and do you have a URL for it? I'd very much 
like to read it.

Thanks.
-- 
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
        "There are no limits." -- ad copy for Hellraiser
            Please note: my email address is gubbish
From: Emergent Technologies Inc.
Subject: Re: Lisp is *NOT* slow:  proof!
Date: 
Message-ID: <5st2vk$3l2$1@newsie2.cent.net>
Unfortunately, I don't think this paper is on the web.
Here is the reference:

International Journal of High Speed Electronics, Vol. 3, Nos. 3 & 4 (1992)
337-361

I would put it on the web myself except that it is copyright by
World Scientific Publishing Company.
 Martin Rodgers wrote in article ...
>Emergent Technologies Inc. wheezed these wise words:
>
>> Ok, the subject line is a little misleading.
>
>So I changed it to something closer to the truth. ;)
>
>> I'd just like to draw attention to ``The Supercomputer Toolkit:
>> A General Framework for Special-Purpose Computing'' by
>> Harold Abelson, Andrew Berlin, Jacob Katzenelson, William
>> McAllister, Guillermo Rozas, Gerald Sussman, and Jack Wisdom.
>
>Is this paper on the web and do you have a URL for it? I'd very much
>like to read it.
>
>Thanks.
>--
><URL:http://www.wildcard.demon.co.uk/> You can never browse enough
>        "There are no limits." -- ad copy for Hellraiser
>            Please note: my email address is gubbish
> 
From: Fred Gilham
Subject: Re: Lisp is *NOT* slow:  proof!
Date: 
Message-ID: <u7en7wgxko.fsf@japonica.csl.sri.com>
>> I'd just like to draw attention to ``The Supercomputer Toolkit:
>> A General Framework for Special-Purpose Computing'' by
>> Harold Abelson, Andrew Berlin, Jacob Katzenelson, William
>> McAllister, Guillermo Rozas, Gerald Sussman, and Jack Wisdom.
>
>Is this paper on the web and do you have a URL for it? I'd very much
>like to read it.


It's on the net---ftp to publications.ai.mit.edu and go to
ai-publications/1000-1499.  It's AIM-1329.ps.

-- 
-Fred Gilham    ······@csl.sri.com
``The road to tyranny is paved with human rights....Once the state
sets out to guarantee a right, it will destroy every obstacle that
stands in the way of liberating the oppressed.''  --Thomas Fleming
From: Martin Rodgers
Subject: Re: Lisp is *NOT* slow:  proof!
Date: 
Message-ID: <MPG.e64ffba6e9f12499899dc@news.demon.co.uk>
Fred Gilham wheezed these wise words:

> It's on the net---ftp to publications.ai.mit.edu and go to
> ai-publications/1000-1499.  It's AIM-1329.ps.


I'll fetch it ASAP.

Many thanks.
-- 
          "As you read this: Am I dead yet?" - Rudy Rucker
              Please note: my email address is gubbish
From: Dave
Subject: Re: Lisp is slow:  proof!
Date: 
Message-ID: <33fc8b0e.13377038@nntp.a001.sprintmail.com>
On Tue, 12 Aug 1997 21:55:40 -0400, "Emergent Technologies Inc."
<········@eval-apply.com> wrote:

>Ok, the subject line is a little misleading.
Just like a sly LISP supporter! I'm suspicious already!!

>They describe joint work done around 1991 between the MIT
>Project for Mathematics and Computation and Hewlett-Packard's
>Information Architecture Group on the design and construction of
>a Supercomputer Toolkit.
>
>This toolkit was used to compute the long-term motion of the
>Solar System, improving upon previous integrations by two orders
>of magnitude.
The key word here is "long-term motion". Try a real-time app and see
where your LISP get's you!

>What is the toolkit language (and I'm sure you see this coming)
>Lisp.
>
>And not micro-optimized Lisp, but highly abstract code.  Here is an
>example.
>
>(define add-vectors (vector-elementwise +))
>
>.(define (vector-elementwise f)
>  .  (lambda (vectors)
>.    (generate-vector
>.     (vector-length (car vectors))
>.     (lambda (i)
>.        (apply f (map (lambda (v) (vector-ref v i))
>.                            vectors))))))
>This code is drawn from the paper and is the type of code used in
>programming the toolkit.
>
>This code also uses recursion to describe an iterative
>process.
Which only a sly LISPy type would be absolutely sure to dream up!
Just to get even, I'm gonna write an iterative version of a recursive
function, so there!<g>

The rest of us only use recursion when we want to - but LISPy's are
just *wild* about it! 

Good stuff! I don't think anyone familiar with AI or LISP is arguing
that LISP has no future - it is a premier AI language and allows
abstractions that are unique and valuable. 

But it's still slow! Of course, Tiger's aren't Cheetah's either - and
way slower; still a very neat animal.

Regards,
Dave
From: Ian Wild
Subject: Re: Lisp is slow:  proof!
Date: 
Message-ID: <33F99F6C.1E57@cfmu.eurocontrol.be>
Dave wrote:
> 
> Just to get even, I'm gonna write an iterative version of a recursive
> function, so there!<g>
>

Can it be Ackermann's function, please.  I've /always/ wanted
to see the iterative version of Ackermann's function.

ian
From: Dave
Subject: Re: Lisp is slow:  proof!
Date: 
Message-ID: <33fa884c.2034476@nntp.a001.sprintmail.com>
On Tue, 19 Aug 1997 15:28:12 +0100, Ian Wild <···@cfmu.eurocontrol.be>
wrote:

>Dave wrote:
>> 
>> Just to get even, I'm gonna write an iterative version of a recursive
>> function, so there!<g>
>>
>
>Can it be Ackermann's function, please.  I've /always/ wanted
>to see the iterative version of Ackermann's function.
>
>ian

Sorry Ian,

Never met the [A(1,j) = j+1 for j >= 1] dude. 'Sides, he looks dull.
Plan is to try an iterative version of an iteratively deepening alpha
beta search of a chess game tree.

Chess is fun, Ackerman's function is not, IMHO.

Regards,
Dave
From: Jason Trenouth
Subject: Re: Lisp is slow:  proof!
Date: 
Message-ID: <33fd63bb.2102594812@newshost>
On Tue, 19 Aug 1997 12:15:56 GMT, ·····@sprintmail.com (Dave) wrote:

> On Tue, 12 Aug 1997 21:55:40 -0400, "Emergent Technologies Inc."
> <········@eval-apply.com> wrote:
> 
> >Ok, the subject line is a little misleading.
> Just like a sly LISP supporter! I'm suspicious already!!
> 
> >They describe joint work done around 1991 between the MIT
> >Project for Mathematics and Computation and Hewlett-Packard's
> >Information Architecture Group on the design and construction of
> >a Supercomputer Toolkit.
> >
> >This toolkit was used to compute the long-term motion of the
> >Solar System, improving upon previous integrations by two orders
> >of magnitude.
> The key word here is "long-term motion". Try a real-time app and see
> where your LISP get's you!

Video switching systems and spacecraft perhaps?

e.g. http://www.harlequin.com/news/press/archive/pr-att.html

__Jason