From: Mike McDonald
Subject: Lisp vs C++ flame wars (was Re: Writing a small Lisp)
Date:
Message-ID: <Cqo61D.5rB@jabba.ess.harris.com>
In article <·················@netcom.com>, ·······@netcom.com (james brister) writes:
|> In article <··········@jabba.ess.harris.com> ···@trantor.harris-atd.com (Mike McDonald) writes:
|>
|> [ talking about the C++ designers ]
|>
|> > I think they made big mistakes in the constraints they imposed
|> > upon themselves. Things like making speed the primary
|> > consideration (and hence all the reliance on compile time cruft)
|> > and compatibility with existing utilities (namely the linker which
|> > lead to all the name mangling mess). Then lots of little things
|> > like objects not know what type they are at run time, class info
|> > not existing at run time, ...
|>
|> What a load of crap. The primary consideration was bit-level
|> compatabilty with C. The idea was to add as much OO to C as possibly,
|> but impose no penalty if a programmer chose not to use the OO features.
|> And they succeeded.
Precisely one of those self imposed constraints that I consider a mistake. I
can think of no good reason why an object has to have the same bit representation
as a struct. They're different things that should be used for different purposes.
Trying to make them bit equivilant doesn't make sense to me.
|> Someday you people will get a clue that C++ was not designed to be
|> answer to the world's OO needs. If you don't like the compile time
Agreed, it wasn't designed to be the world's answer to OO programming. But then
why are all of the C++ bigots advocating just that?
|> contraints or inheritance restrictions (better than Smalltalk though,
|> from what I hear) or any other failings that many of you (with
|> self-important ideas on what a language should be) will whine about,
|> then don't use it. Go use eiffel or Modula-3 or LISP where the
|> abstraction gets better, but the run-time penalties get bigger.
|>
|> This all sounds like a lot of sour grapes to me. C++ and LISP weren't
My sour grapes have more to do with the advocates of C++ than the language
its self. And yes, I have sour grapes about the lisp bigots around here who claim
lisp is God's one true language. I believe that both languages have serious
sorthcomings in them.
|> meant to compete in the same programming arena--I'd no sooner choose
|> C++ to write a symbolic math package than I'd use LISP to write a
|> network transport package.
And I wouldn't use C++ for the network transport layers either. (And yes, I
have implemented TCP/IP on a shared memory multiprocessor. I chose C.) C yes, C++
no way. For me, the inconsistancies, constraints and kludgy syntax of C++ are not
worth the effort for most applications. I'd much rather use a cleaner language
like C an implement my own objects then put up with C++.
|> Perhaps you won't get a clue. Too bad.
|>
|> James (LISP *AND* C++ programmer and proud of it)
|> --
|> James Brister ·······@vix.com
|> decwrl!vixie!brister
Mike McDonald Advanced Technology Dept.
Harris Corp.
Email: ···@trantor.harris-atd.com M.S. 16-1912
Voice: (407) 727-5060 P.O. Box 37
Fax: (407) 729-3363 Melbourne, Florida 32902
In article <··········@jabba.ess.harris.com>, ···@trantor.harris-atd.com (Mike
McDonald) writes:
|> [stuff deleted]
|> In article <·················@netcom.com>, ·······@netcom.com (james brister) writes:
|> |> This all sounds like a lot of sour grapes to me. C++ and LISP weren't
|> |> meant to compete in the same programming arena--I'd no sooner choose
|> |> C++ to write a symbolic math package than I'd use LISP to write a
|> |> network transport package.
|>
|> And I wouldn't use C++ for the network transport layers either. (And yes, I
|> have implemented TCP/IP on a shared memory multiprocessor. I chose C.) C yes,
|> C++ no way. For me, the inconsistancies, constraints and kludgy syntax of C++
|> are not worth the effort for most applications. I'd much rather use a cleaner
|> language like C an implement my own objects then put up with C++.
Seconded, all (including the parts deleted).
And, you must not neglect the runtime hit imposed by using C++.
People tend to argue that C++ can be as fast as C, because it is a superset of C.
Of course it is as fast as C as long as you don't use any C++ features apart
from "sugar" like //-comments and inlined functions etc. But then you can stick
with C in the first place.
What I dream of (The Real Thing (tm)) is a language that is as simple and
universal as Scheme, has a more human-friendly syntax, and can be compiled
to either extremely safe or extremely fast code from the same sources, only
depending on compiler options. Yesss...
Of course, C++ fails all of these points.
-- Axel (SCHEME *AND* C programmer and proud of it)
-------------------------------------------------------------------------------
I lost my mind. Please mail me ·······@rzdspc2.informatik.uni-hamburg.de
if you should find it somewhere. * Axel Wienberg
From: Maxxwell M. Cassidy
Subject: Re: Lisp vs C++ flame wars (was Re: Writing a small Lisp)
Date:
Message-ID: <2siqbk$6fo@naples.gain.com>
Dear Lispers:
I find it amazing to see this argument play out.
Since when did programmers' concerns have any
bearing on choice of language? Who cares what
programmers think?
It is the technical designers of software packages
that decide what language to implement a
functional specification in. We usually are more
concerned with other things than what programmers
think. We will hire programmers that agree with
us if necessary.
We want the code to be able to be read and revised
by easily acquire personnel, and that means we
stick to popular languages. We want to be able to
take advantage of OO techniques without having to
have "gurus", who are a pain in the butt to
manage, and whose work is unintelligible to our
other staff. We would rather have sub-optimal
code than code that cannot be modified or
repurposed by a student intern.
We like to have the coding environment to have
debuggers, code generators, translators, class
libraries, database interfaces, serial
communications tie-ins, have cheap and widely
available compilers or interpreters, anyway, you
get the picture.
So that's why folks choose C++ a lot. It's also
why we're doing our next project in with a Scheme
extension language. It's why I have my database
code written in SQL, and not some "better"
language.
It seems to me that if you are not senior enough
to influence the choice of language, then you have
no right to be concerned about it at all. If you
are writing code for a living, you're not senior
enough to see the big picture. After all, coders
are disposible. They turn over about every 2
years anyway. The code they write, though, is
more or less permanent, and the people who follow
must be able to work with it. That's why
programming managers make the rules they do. Good
ones want the code to still be useful after they
fire the programmer who wrote it. Code written in
Forth will be useless as soon as you let the
programmer go, because it will take you longer to
hire someone who can understand it than to
redevelop in a more popular language.
C++ is an important language not because of what
it can do (which is precious little), but because
of what C programmers can do with it (which is
quite a lot -- look at the installed base).
As for you purists, go get a job teaching -- it's
the only way anyone will listen to you. Real
programmers program in whatever language they are
told to, or they get another job. I would happily
fire a purist and hire someone who cares more
about getting the work out.
If you look at the teams of programmers in your
area that could be hired without forking over
relocation costs, you'd think that FORTRAN, COBOL,
and C were the only languages in the world. It's
no wonder that folks program in those languages.
They can find the talent. They can find the
compilers for their systems. They can actually
get the work done, which this newsgroup has
clearly forgotten. I guess it's all the academics
here. Never were a practical lot.
C++, Lisp, SQL, etc., are not "great" languages
that can be praised or blamed on some abstract
system of merits. They are tools. Find the
tool-set that is economically efficient for the
job at hand; use it. That's all there is.
Maxx Cassidy.
--
- Taos Mountain Man * /\____ * -
- No Rose w/o Thorns * _/ \______ * -
- No Profit w/o Work _____/ \ -
- No Love w/o Trust ____/ \___-
Maxx Cassidy writes:
[...]
C++ is an important language not because of what
it can do (which is precious little), but because
of what C programmers can do with it (which is
quite a lot -- look at the installed base).
[...]
C++ is an important language because in their fear of missing out on
all the increased productivity promised by more recent advances in
computer science and software management, both coders and software
architects alike have been suckered into thinking that knowing C or
having a lot of code already written in C is somehow an an advantage
in learning and using C++.
thant (C++ programmer since cfront 1.2)
From: Henry G. Baker
Subject: Re: Lisp vs C++ flame wars (was Re: Writing a small Lisp)
Date:
Message-ID: <hbakerCqr1BA.8xD@netcom.com>
In article <··········@naples.gain.com> ····@Gain.COM (Maxxwell M. Cassidy) writes:
> Dear Lispers:
>
> I find it amazing to see this argument play out.
> Since when did programmers' concerns have any
> bearing on choice of language? Who cares what
> programmers think?
Machines seem to care a lot. They are much happier without
grumpy programmers feeding them s**t.
> It is the technical designers of software packages
> that decide what language to implement a
> functional specification in. We usually are more
> concerned with other things than what programmers
> think. We will hire programmers that agree with
> us if necessary.
This is the Mongolian hordes theory of SW development. Of course you
need to be more concerned with other things, because you need 10X as
many programmers. You now need a 'team', you now need to have lots of
meetings, you need huge investments in 'infrastructure' because more
people implies more management.
> We want the code to be able to be read and revised
> by easily acquire personnel, and that means we
> stick to popular languages. We want to be able to
> take advantage of OO techniques without having to
> have "gurus", who are a pain in the butt to
> manage, and whose work is unintelligible to our
> other staff. We would rather have sub-optimal
> code than code that cannot be modified or
> repurposed by a student intern.
By all means hire C programmers, then. I mean 'C' as in C-average or
worse. Some of these people can't think for themselves, and more than
likely had people on comp.lang.c do all of their homework for them.
(Or even worse, they didn't; one hopes that those on comp.lang.c would
provide at least B-level code.)
> We like to have the coding environment to have
> debuggers, code generators, translators, class
> libraries, database interfaces, serial
> communications tie-ins, have cheap and widely
> available compilers or interpreters, anyway, you
> get the picture.
You'll need all the debuggers you can get your hands on, and
god help you. If you really think that this stuff actually fits
together as advertised, I have a bridge I'd like to sell you.
> So that's why folks choose C++ a lot. It's also
> why we're doing our next project in with a Scheme
> extension language. It's why I have my database
> code written in SQL, and not some "better"
> language.
I can't imagine why you would use Scheme as an extension language.
Most Scheme people think, and you've already indicated your distaste
for thinkers.
> It seems to me that if you are not senior enough
> to influence the choice of language, then you have
> no right to be concerned about it at all. If you
> are writing code for a living, you're not senior
> enough to see the big picture. After all, coders
> are disposible. They turn over about every 2
> years anyway. The code they write, though, is
> more or less permanent, and the people who follow
> must be able to work with it. That's why
> programming managers make the rules they do. Good
> ones want the code to still be useful after they
> fire the programmer who wrote it. Code written in
> Forth will be useless as soon as you let the
> programmer go, because it will take you longer to
> hire someone who can understand it than to
> redevelop in a more popular language.
This is a pleasant myth, but a myth nonetheless. I'm aware of a large
project whose Lisp->C++ phase will probably take the better part of
the next century.
> C++ is an important language not because of what
> it can do (which is precious little), but because
> of what C programmers can do with it (which is
> quite a lot -- look at the installed base).
Don't confuse installed base of compilers with installed base of
interesting applications. There are a lot of Cobol programmers
writing Cobol programs, but most of these programs do the same thing
-- print/display data in various formats. With a decent 4GL, you can
eliminate the need for 80% of these programs. Likewise, most of the
people using C++ would be better off with a similar sort of super
application. C++ is not the language to be doing data display of this
sort, no matter how large your library is. You need a more
interpretive language.
The number of computer programs v. the number of times they are run is
probably another case of Zipf's law. A large fraction of programs are
run only once, which is why most of them would be better off
interpreted. (And probably are -- e.g., shell commands.) We should
therefore write everything in 'csh'. QED
There are also lots more trees around than there are NASA rockets, and
lots more arborists than rocket scientists. I would suggest that the
next time you need to put a satellite in orbit, you should start by
climbing a tree. You'll be gaining altitude, but I don't think that
the solution will scale ;-) very well.
> As for you purists, go get a job teaching -- it's
> the only way anyone will listen to you. Real
> programmers program in whatever language they are
> told to, or they get another job. I would happily
> fire a purist and hire someone who cares more
> about getting the work out.
Why do you associate 'purist' with lack of productivity? Are
you confusing productivity with lines of code? Most purists I
know are pragmatically lazy, and use purity to finesse work. Since
the result is usually a good deal more comprehensible, everyone wins,
except the manager whose salary is based on warm bodies instead of
working applications.
> If you look at the teams of programmers in your
> area that could be hired without forking over
> relocation costs, you'd think that FORTRAN, COBOL,
> and C were the only languages in the world. It's
> no wonder that folks program in those languages.
> They can find the talent. They can find the
> compilers for their systems. They can actually
> get the work done, which this newsgroup has
> clearly forgotten. I guess it's all the academics
> here. Never were a practical lot.
>
> C++, Lisp, SQL, etc., are not "great" languages
> that can be praised or blamed on some abstract
> system of merits. They are tools. Find the
> tool-set that is economically efficient for the
> job at hand; use it. That's all there is.
Ah!! The 'all programming languages are the same/equivalent'
argument. Well, in a world with a 55 mph speed limit all cars are
equivalent. However, if you have a F1 driver, you just might be able
to go a lot faster if you give him the right car, as opposed to 'any'
car.
[I appreciated the sarcasm of the original poster, though.]
From: Mike McDonald
Subject: Re: Lisp vs C++ flame wars (was Re: Writing a small Lisp)
Date:
Message-ID: <Cqs0L4.5Br@jabba.ess.harris.com>
In article <··········@naples.gain.com>, ····@Gain.COM (Maxxwell M. Cassidy) writes:
|>
|> Dear Lispers:
|> It seems to me that if you are not senior enough
|> to influence the choice of language, then you have
|> no right to be concerned about it at all. If you
|> are writing code for a living, you're not senior
|> enough to see the big picture. After all, coders
|> are disposible. They turn over about every 2
|> years anyway. The code they write, though, is
|> more or less permanent, and the people who follow
|> must be able to work with it. That's why
|> programming managers make the rules they do. Good
|> ones want the code to still be useful after they
|> fire the programmer who wrote it. Code written in
|> Forth will be useless as soon as you let the
|> programmer go, because it will take you longer to
|> hire someone who can understand it than to
|> redevelop in a more popular language.
With such an enlightened attitude, I have no doubt that you have a complete
turnover every two years!
Mike McDonald Advanced Technology Dept.
Harris Corp.
Email: ···@trantor.harris-atd.com M.S. 16-1912
Voice: (407) 727-5060 P.O. Box 37
Fax: (407) 729-3363 Melbourne, Florida 32902
From: Martin Rodgers
Subject: Re: Lisp vs C++ flame wars (was Re: Writing a small Lisp)
Date:
Message-ID: <770658295snz@wildcard.demon.co.uk>
In article <··········@jabba.ess.harris.com>
···@trantor.harris-atd.com "Mike McDonald" writes:
> |> fire the programmer who wrote it. Code written in
> |> Forth will be useless as soon as you let the
> |> programmer go, because it will take you longer to
> |> hire someone who can understand it than to
> |> redevelop in a more popular language.
>
> With such an enlightened attitude, I have no doubt that you have a complete
> turnover every two years!
Yeah, well. I _think I agree with you. :-) I'd argue that code in any
language can be written in a clear manner that another programmer can
understand. I have no trouble going back to Forth/Lisp/C++ code I've
written a few years ago and not looked at since. I can also look at
Forth and Lisp code written by other programmers and have little
trouble reading it other than following the odd difference in the way
programmers format their code. Those that are consistant are easy IME,
while those whose code plays tricks on the reader will never be very
readable IMHO.
There are few issues I keep in mind when coding, and they tend to be
portability, maintainability, and reliability. The code has to work
on a number of machines, with only those assumptions about the machine
tha are necessary, and those assumptions are as isolated as possible.
I have to be able to read the code and understand, and not just while
writing it. Lastly, it has to work. I place this last, as code that
works but which can't be maintained with be of little use to me, never
mind another programmer, if it can't be read and understood.
IME this is true of all programming languages. It's also true of the
one human language I'm familiar with, but I don't assume that English
is the only language in which is this true. I can generalise and see
that it's a basic feature of human interaction. In the same way, I
can generalise and see that my coding habits and a basic feature of
human/computer interaction.
The fact that the later is easier to "document" is misleading people
into thinking it's simple! Well, IME it's far from simple.
--
Martin Rodgers, WKBBG, London UK AKA "Cyber Surfer"
Assuming that Clipper will need to be global to be effective, write
to ················@cpsr.org and tell them you oppose Clipper. Now.
This is a shareware .signature -- please pass it on!
From: Maxxwell M. Cassidy
Subject: Re: Lisp vs C++ flame wars (was Re: Writing a small Lisp)
Date:
Message-ID: <2so1dg$d25@naples.gain.com>
In article <··········@jabba.ess.harris.com> ···@trantor.harris-atd.com (Mike McDonald) writes:
>In article <··········@naples.gain.com>, ····@Gain.COM (Maxxwell M. Cassidy) writes:
>|>
>|> Dear Lispers:
>
> With such an enlightened attitude, I have no doubt that you have a complete
>turnover every two years!
>
> Mike McDonald Advanced Technology Dept.
> Harris Corp.
Actually, I said nothing about my shop. 2 years
is the industry *average* turnover rate for
programmers. Managers will manage for better
rates, but the average manager gets average
results on that. So code still has to be
readable, which means it has to be in a standard
language, like Lisp or C. (Of course I refer to
*professional* programmers, not ones who do it as
*art*, for which there are no metrics.)
--
- Taos Mountain Man * /\____ * -
- No Rose w/o Thorns * _/ \______ * -
- No Profit w/o Work _____/ \ -
- No Love w/o Trust ____/ \___-
From: Konstantinos Roussos
Subject: Re: Lisp vs C++ flame wars (was Re: Writing a small Lisp)
Date:
Message-ID: <KNR.94Jun3202128@vegas.doorknob>
Hi!
Hmm....
The essential argument here is that:
Programmers are disposable stenographers. Unfortuantely what the
stenographers write has to be read by the next batch of disposable
stenographers. Therefore it is essential that all the stenographers
conform to a standard form of stenography, not because it is 'the
best' but because it is the standard. As a result we all have
substandard tools, substandard code, inappropriate use of human
resources to make 'pathetic but _industry_standard_tools' work right
because of the 'disposable stenographer' syndrome.
Hmm ... something smells fishy there.
cheers,
kostadis
<happily churning code in C++ >
--
-Kernighan n' Ritchie -
From: Barry Margolin
Subject: Re: Lisp vs C++ flame wars (was Re: Writing a small Lisp)
Date:
Message-ID: <2t7kj7INNk2e@early-bird.think.com>
In article <··········@naples.gain.com> ····@Gain.COM (Maxxwell M. Cassidy) writes:
>I find it amazing to see this argument play out.
>Since when did programmers' concerns have any
>bearing on choice of language? Who cares what
>programmers think?
Some companies actually like to hire people who enjoy their work. The
employees last longer that way.
>It is the technical designers of software packages
>that decide what language to implement a
>functional specification in. We usually are more
>concerned with other things than what programmers
>think. We will hire programmers that agree with
>us if necessary.
The above distinction between "technical designers" and "hired programmers"
is not realistic. In all the places I've worked, they are the same people.
You seem to think of programmers as being like construction workers or word
processors, performing a relatively straightforward task. Programming is
an iterative, creative process, and it generally doesn't make sense to
separate the design and implementation tasks so much that you can use
separate teams for them.
>We want the code to be able to be read and revised
>by easily acquire personnel, and that means we
>stick to popular languages. We want to be able to
>take advantage of OO techniques without having to
>have "gurus", who are a pain in the butt to
>manage, and whose work is unintelligible to our
>other staff. We would rather have sub-optimal
>code than code that cannot be modified or
>repurposed by a student intern.
Do you really think that you don't need "gurus" to take advantage of the OO
techniques of C++? The OO techniques were shoe-horned into C's limited
syntax, resulting in an even bigger mess, and figuring out how to do
reasonable OO programming with this requires a guru.
--
Barry Margolin
System Manager, Thinking Machines Corp.
······@think.com {uunet,harvard}!think!barmar
In article <··········@rzsun02.rrz.uni-hamburg.de> ·······@rzdspc16.informatik.uni-hamburg.de (Axel Wienberg) writes:
>In article <··········@jabba.ess.harris.com>, ···@trantor.harris-atd.com (Mike
>McDonald) writes:
>|> [stuff deleted]
>
>And, you must not neglect the runtime hit imposed by using C++.
>People tend to argue that C++ can be as fast as C, because it is
> a superset of C.
C++ *can* be as fast as C, but not because it's a superset of C
(which a lot of C programmers have argued against).
>Of course it is as fast as C as long as you don't use any C++ features apart
>from "sugar" like //-comments and inlined functions etc. But then
>you can stick with C in the first place.
D
It's obvious comp.lang.c++ isn't one of your regular newsgroups.
The *ONLY* feature of C++ that MIGHT cause C++ code to run slower than
equivalent C code is the virtual dispatch (late binding) mechanism.
Standard (nonvirtual) member functions in C++ execute just as fast as
a C function to which a pointer to a structure is passed. There is
absolutely no performance hit. A virtual function must be explicitly
declared as such -- nonvirtual is the default -- which makes it likely
that most functions are "straight" with no performance loss.
It has been often argued in comp.lang.c++ that the virtual function
dispatch mechanism is more efficient in terms of execution time than
what the typical programmer is likely to implement to get similar
functinality in C. I don't know personally, but the 'gurus' of that
newsgroup vehemently claim that, with most compilers, a switch
statement to determine the type of object, then branching to call the
appropriate function, is considerably slower than the built-in
virtual function dispatch provided by those compilers. The bottom
line, then, is that properly programmed C++ module can be faster
than equivalently implemented C module. (Flame bait??)
>
Incidentally, in CLOS we don't have that choice; i.e., early vs
late binding. That makes C++'s class system 'better' in that
respect. :-)
--
-- Pete Grant | Andrulis Research Corp is
Andrulis Research Corporation | on a contract with the US
·····@pentagon-gw.army.mil | Army AI Center, The Pentagon
(703) 271-7980 |
In article <·····················@pentagon-gw.army.mil> ·····@pentagon-gw.army.mil (Pete Grant) writes:
Newsgroups: comp.lang.lisp,comp.lang.scheme
Path: info-server.bbn.com!news2.near.net!MathWorks.Com!news.kei.com!eff!news.umbc.edu!haven.umd.edu!cs.umd.edu!prometheus!media!hqda-ai!grant
From: ·····@pentagon-gw.army.mil (Pete Grant)
Summary: C++ *NOT* slower than C (in runtime)
Organization: U.S. Army Artificial Intelligence Center, The Pentagon
References: <·················@netcom.com> <··········@jabba.ess.harris.com> <··········@rzsun02.rrz.uni-hamburg.de>
Date: Fri, 3 Jun 1994 22:54:31 GMT
Lines: 45
Xref: info-server.bbn.com comp.lang.lisp:12850 comp.lang.scheme:9128
In article <··········@rzsun02.rrz.uni-hamburg.de> ·······@rzdspc16.informatik.uni-hamburg.de (Axel Wienberg) writes:
>In article <··········@jabba.ess.harris.com>, ···@trantor.harris-atd.com (Mike
...
It's obvious comp.lang.c++ isn't one of your regular newsgroups.
The *ONLY* feature of C++ that MIGHT cause C++ code to run slower than
equivalent C code is the virtual dispatch (late binding) mechanism.
Standard (nonvirtual) member functions in C++ execute just as fast as
a C function to which a pointer to a structure is passed. There is
absolutely no performance hit. A virtual function must be explicitly
declared as such -- nonvirtual is the default -- which makes it likely
that most functions are "straight" with no performance loss.
This is just what they want you to believe. ········@shell.com has some
small C and C++ benchmarks that show a 30 - 40% performance loss in C++
when not using virtual functions. For example, if you define a complex
class in the way all the books do. I don't know why the loss happens, but
my guess is that the class slots are held in the stack so that pointer math
works right and not in registers that straight C can use. Of course, you
could always resort to straight C when you had to.
It has been often argued in comp.lang.c++ that the virtual function
dispatch mechanism is more efficient in terms of execution time than
what the typical programmer is likely to implement to get similar
functinality in C. I don't know personally, but the 'gurus' of that
I presume your a talking about single inheritance here. Multiple
inheritance in C++ has additional time and space overhead.
newsgroup vehemently claim that, with most compilers, a switch
statement to determine the type of object, then branching to call the
appropriate function, is considerably slower than the built-in
virtual function dispatch provided by those compilers. The bottom
This is generally true in Lisp too.
line, then, is that properly programmed C++ module can be faster
than equivalently implemented C module. (Flame bait??)
>
Incidentally, in CLOS we don't have that choice; i.e., early vs
late binding. That makes C++'s class system 'better' in that
respect. :-)
--
Ken Anderson
Internet: ·········@bbn.com
BBN STC Work Phone: 617-873-3160
10 Moulton St. Home Phone: 617-643-0157
Mail Stop 6/4c FAX: 617-873-3776
Cambridge MA 02138
USA
From: james brister
Subject: Re: Lisp vs C++ flame wars (was Re: Writing a small Lisp)
Date:
Message-ID: <bristerCr3on8.CsF@netcom.com>
Ken Anderson (········@wheaton.bbn.com) wrote:
: In article <·····················@pentagon-gw.army.mil> ·····@pentagon-gw.army.mil (Pete Grant) writes:
: It's obvious comp.lang.c++ isn't one of your regular newsgroups.
: The *ONLY* feature of C++ that MIGHT cause C++ code to run slower than
: equivalent C code is the virtual dispatch (late binding) mechanism.
: Standard (nonvirtual) member functions in C++ execute just as fast as
: a C function to which a pointer to a structure is passed. There is
: absolutely no performance hit. A virtual function must be explicitly
: declared as such -- nonvirtual is the default -- which makes it likely
: that most functions are "straight" with no performance loss.
: This is just what they want you to believe. ········@shell.com has some
: small C and C++ benchmarks that show a 30 - 40% performance loss in C++
: when not using virtual functions. For example, if you define a complex
: class in the way all the books do. I don't know why the loss happens, but
: my guess is that the class slots are held in the stack so that pointer math
: works right and not in registers that straight C can use. Of course, you
: could always resort to straight C when you had to.
And what they want you to believe is true, *when* the C++ programmer
knows what he's doing. For example passing in objects by value instead
of a const reference will cause one possibly two function calls to be
generated for every parameter pushed on the stack (copy constructor and
destructor) and the entire object will be copied onto the stack instead of
a pointer.
Writing slow C++ code is easy, but then so is writing slow LISP or
(insert favorite language here) code. Writing fast C++ code is easier
(IMHO) than writing fast LISP code mainly because the guts of the
langauge are not so hidden from the user. Very little of the LISP
instruction I have received has stressed what goes on when using
various aspects of the language--reading the XLISP source was a major
source of enlightenment.
James
--
James Brister ·······@vix.com
decwrl!vixie!brister
In article <·················@netcom.com> ·······@netcom.com (james brister) writes:
>Very little of the LISP
>instruction I have received has stressed what goes on when using
>various aspects of the language--reading the XLISP source was a major
>source of enlightenment.
XLisp is a very simple-minded Lisp interpreter. It should not be used to judge
the efficiency of a CommonLisp program compiled by the CMU CL Python compiler,
for example!
···············@ccm.jf.intel.com
(503) 696-9309
Intel / ProShare
Patrick D. Logan (···············@ccm.jf.intel.com) wrote:
: XLisp is a very simple-minded Lisp interpreter. It should not be used to
: judge
: the efficiency of a CommonLisp program compiled by the CMU CL Python
: compiler,
: for example!
Actually what I meant was that until I read the XLISP source I had no idea
what went on behind the scenes of a LISP system (e.g. what actually went into
the making of a closure). Until that point I fell into the trap mentioned by
Alan Kay (?) "LISP programmers know the value of everything, but the cost of
nothing". C and C++ programming pretty much require a more intimate knowledge
of the bit-level details.
James
--
James Brister ·······@vix.com
decwrl!vixie!brister
In article <·················@netcom.com> ·······@netcom.com (james brister) writes:
...
Patrick D. Logan (···············@ccm.jf.intel.com) wrote:
: XLisp is a very simple-minded Lisp interpreter. It should not be used to
: judge
: the efficiency of a CommonLisp program compiled by the CMU CL Python
: compiler,
: for example!
Actually what I meant was that until I read the XLISP source I had no idea
what went on behind the scenes of a LISP system (e.g. what actually went into
the making of a closure). Until that point I fell into the trap mentioned by
Alan Kay (?) "LISP programmers know the value of everything, but the cost of
nothing". C and C++ programming pretty much require a more intimate knowledge
Actually, i've been thinking about how people learn slow Lisp. Gabriel
says he's seen good programmers write some pretty slow Lisp. His model is
that you have a constant cost assumption where every operations has unit
cost. I guess this goes along with Alan Kay's quote. I think there are
other common performance related bugs that happen as you learn Lisp.
The subsetting bug -- to reduce the number of functions to learn you
tend to use overly general (slower) functions like EQUAL rather than EQ.
The expressiveness bug -- (mapcar #'some-feature some-data) is very
expressive, and efficient. While (reduce #'+ (mapcar #'some-computation
(mapcar #'some-feature some-data))) is expressive, but can be very slow.
The easy-to-use bug -- "Lets make everything keyword arguments so we don't
have to remember where they go". "Lets make all the functions take the
same keywords so we don't have to remember the arguments."
The really general bug -- "We made that really general, too bad its in our
inner loop."
The really smart compiler bug -- assuming something is as fast as you know
it could be.
Perhaps you can suggest others.
I wish i could remember how i learned Lisp. In my case, i learned Lisp
after learning Fortran and C, and i sure new how to make Fortran fast, and
probably C too. But Lisp has a seductive quality. You are typing to Lisp
and getting instant feedback. I started reading AI books and coding
examples i only dreamed about in Fortran. Eventually, i started building
bigger and bigger systems, and performance became important and i started
to learn how to deal with it.
Good books, like Peter Norvig's Common Lisp book will get people aware of
perfomance issues earlier. For example, he not only provides Scheme and
Prolog interpreters as "Structure and Interprations" does, but compilers
too.
BTW, i think computer science follows a performance learning curve
something like this too. First there is an early experimental phase that
brings up a cool idea, followed by recognizing how to make this cool idea
fast, followed by wide spread use of the idea. Examples
Planner -> Conniver -> Prolog
Actors -> Futures -> lambda as goto -> Clever scheme compilers
Frame languages -> Smalltalk -> Object Oriented Languages
CLOS MOP -> Compile time MOP
k
--
Ken Anderson
Internet: ·········@bbn.com
BBN STC Work Phone: 617-873-3160
10 Moulton St. Home Phone: 617-643-0157
Mail Stop 6/4c FAX: 617-873-3776
Cambridge MA 02138
USA
In article <·····················@wheaton.bbn.com> ········@wheaton.bbn.com (Ken Anderson) writes:
>Good books, like Peter Norvig's Common Lisp book will get people aware of
>perfomance issues earlier. For example, he not only provides Scheme and
>Prolog interpreters as "Structure and Interprations" does, but compilers
>too.
I haven't read Peter Norvig's book, but I have read some others which
attempted to 'make people aware of performance issues', and I
completely cringed at the advice that was given. Many bogus
suggestions based on obsolete technology, like using nreverse instead
of reverse, are often given. Suggestions like replacing 'format' with
separate 'print' statements ignore the fact that simply setting up the
stream may completely swamp out the costs of transmitting stuff to the
stream.
The single most important thing to do in any large program is to write
it in such a way that _you_ can understand it. Forget about efficiency
until you can understand it first. Then find out where it is slow. Once
you know, you have several choices:
1. You may be able to improve performance without doing violence to the
clarity of the program. In fact, you may actually improve the clarity of
the program and the efficiency at the same time. Unfortunately, this
doesn't happen very often.
2. You now have a problem. Whatever efficiency hacks you put it are
likely to be Lisp implementation or platform specific. You're thus
going to make a mess of the code if you aren't careful. In many
cases, the problem could be fixed by a smarter compiler, but yours is
dumb. What Lisp desparately needs is some mechanism to get behind the
implementation and guide the compiler, _without screwing up the
semantics_. Unfortunately, we currently have only _macros_, which
_can_ be used with good effect, but must be used very carefully. (But
at least we have macros; we're not dead in the water like some other
languages!) Macros can be used to do the equivalent of 'partial
evaluation' and some other relatively sophisticated optimizations that
your compiler couldn't or wouldn't do. (Or wasn't allowed to do based
on the many quirks in Lisp.)
3. Sometimes the inefficiency is localized to one or a small number
of routines. You may be able to hack it/them and reach acceptable
efficiency. If so, _leave the original routines in the source code_.
You need them for several reasons. First, you need to know what the
optimized routines were trying to do. Second, when your program
doesn't work, you need to prove to yourself that the problem isn't in
the optimized versions, so you need to be able to revert to the
unoptimized version. Third, when you port to a new architecture, you
should re-evaluate the optimizations, because they may not be
necessary, or they may be inappropriate in the new context. Fourth,
your cleverness may not result in any speedup, so you should then
revert to the 'unoptimized', but cleaner/clearer version (it always
amazes me that people are unwilling to abandon a clever idea even
after they have convinced themselves that it didn't work out, although
sometimes it is the fault of management who is unwilling to admit that
several months of effort didn't produce any improvement). You can
always leave a comment to the effect that 'we tried X, and it didn't
work out', so the next guy won't make the same mistake (although you
can bet he will try).
4. Consider memoization/caching. In many cases memoization can be
relatively transparent to the rest of the code, and can offer some
algorithms _much_ more performance than trying to hack the code
locally. For example, many of the Gabriel Benchmarks can be speeded
up dramatically through judicious use of memoization. See Lisp
Pointers V,3 (Jul/Sep 1992).
Etc., etc. Your mileage may vary.
In article <·····················@wheaton.bbn.com> ········@wheaton.bbn.com (Ken Anderson) writes:
Good books, like Peter Norvig's Common Lisp book will get people aware of
perfomance issues earlier. For example, he not only provides Scheme and
Prolog interpreters as "Structure and Interprations" does, but compilers
too.
By "Structure and Interprations" I assume you mean "Structure and
Interpretation of Computer Programs" (or SICP). SICP develops a
Scheme compiler in Chapter 5. The target architecture is a bit odd
though; for example it includes looking up a variable in an
environment as a primitive operation.
John McClain
In article <·················@netcom.com> ·······@netcom.com (james brister) writes:
Until that point I fell into the trap mentioned by
Alan Kay (?) "LISP programmers know the value of everything, but the cost of
nothing".
This quote is actually due to Alan Perlis, a professor at Yale who has since
passed away. He is also famous for `To much syntactic sugar causes cancer of
the semicolon'.
Jeff (home page ftp://ftp.cs.toronto.edu/pub/qobi/qobi.html)
--
Jeff (home page ftp://ftp.cs.toronto.edu/pub/qobi/qobi.html)
The Scheme->C compiler compiles the SCM "pi" code into something
that runs 1/3 as fast as the equivalent C. For the advantages,
this is quite pleasant.
--
Lance Norskog
·······@netcom.com
Artisputtingtogether. Art s th ow n aw y.
From: Shriram Krishnamurthi
Subject: Re: Lisp vs C++ flame wars (was Re: Writing a small Lisp)
Date:
Message-ID: <shriram.771135108@cs.rice.edu>
·······@netcom.com (james brister) writes:
> Writing fast C++ code is easier (IMHO) than writing fast LISP code
> [...] Very little of the LISP instruction I have received has
> stressed what goes on when using various aspects of the language
Then blame the instruction you received, not the language itself.
There are, for instance, numerous books and papers on implementing
functional languages in general and aspects of Scheme or LISP in
particular.
From: james brister
Subject: Re: Lisp vs C++ flame wars (was Re: Writing a small Lisp)
Date:
Message-ID: <bristerCr5MCw.C67@netcom.com>
Shriram Krishnamurthi (·······@asia.cs.rice.edu) wrote:
: ·······@netcom.com (james brister) writes:
: > Writing fast C++ code is easier (IMHO) than writing fast LISP code
: > [...] Very little of the LISP instruction I have received has
: > stressed what goes on when using various aspects of the language
: Then blame the instruction you received, not the language itself.
: There are, for instance, numerous books and papers on implementing
: functional languages in general and aspects of Scheme or LISP in
: particular.
You're missing the point. I did not blame the language. Of course the
instruction is lacking, but then LISP is a high-level abstract language
and teaching the innards is really low on the list of topics of any
curriculum I've seen--so low to be non-existant in most cases.
James
--
James Brister ·······@vix.com
decwrl!vixie!brister
From: Tom Lord
Subject: small, quick programs in scheme
Date:
Message-ID: <50603@toad.com>
It's really a shame. There are now umpteen different free schemes,
each of which solves a different subset of the problems that one would
ideally like to see solved in a scheme system.
I don't think there are any reasons in principle why a scheme can't be
practical for, say, the /bin/ls challenge. I just don't think very
much effort has been made in that direction.
I speculate that this situation is holding the language back in a big
way.
Device drivers are another matter. R^nRS scheme lacks appropriate
types for that task and has no declaration facilities to help the code
generator. A property of scheme noted in the rabbit thesis is that it
doesn't need to have traditional lisp types. RnRS screwed up by
making that statement false (both overtly by making scheme types
essential, and covertly by making pairs an essential part of how
functions can take arbitrary numbers of arguments).
-t
From: Kirk Rader
Subject: Re: Lisp vs C++ flame wars (was Re: Writing a small Lisp)
Date:
Message-ID: <Cr538C.5Dq@triple-i.com>
In article <·····················@wheaton.bbn.com> ········@wheaton.bbn.com (Ken Anderson) writes:
>In article <·····················@pentagon-gw.army.mil> ·····@pentagon-gw.army.mil (Pete Grant) writes:
>
> Newsgroups: comp.lang.lisp,comp.lang.scheme
> Path: info-server.bbn.com!news2.near.net!MathWorks.Com!news.kei.com!eff!news.umbc.edu!haven.umd.edu!cs.umd.edu!prometheus!media!hqda-ai!grant
> From: ·····@pentagon-gw.army.mil (Pete Grant)
> Summary: C++ *NOT* slower than C (in runtime)
> Organization: U.S. Army Artificial Intelligence Center, The Pentagon
> References: <·················@netcom.com> <··········@jabba.ess.harris.com> <··········@rzsun02.rrz.uni-hamburg.de>
> Date: Fri, 3 Jun 1994 22:54:31 GMT
> Lines: 45
> Xref: info-server.bbn.com comp.lang.lisp:12850 comp.lang.scheme:9128
>
> In article <··········@rzsun02.rrz.uni-hamburg.de> ·······@rzdspc16.informatik.uni-hamburg.de (Axel Wienberg) writes:
> >In article <··········@jabba.ess.harris.com>, ···@trantor.harris-atd.com (Mike
>
> ...
>
> It's obvious comp.lang.c++ isn't one of your regular newsgroups.
> The *ONLY* feature of C++ that MIGHT cause C++ code to run slower than
> equivalent C code is the virtual dispatch (late binding) mechanism.
> Standard (nonvirtual) member functions in C++ execute just as fast as
> a C function to which a pointer to a structure is passed. There is
> absolutely no performance hit. A virtual function must be explicitly
> declared as such -- nonvirtual is the default -- which makes it likely
> that most functions are "straight" with no performance loss.
>
>This is just what they want you to believe. ········@shell.com has some
>small C and C++ benchmarks that show a 30 - 40% performance loss in C++
>when not using virtual functions. For example, if you define a complex
>class in the way all the books do. I don't know why the loss happens, but
>my guess is that the class slots are held in the stack so that pointer math
>works right and not in registers that straight C can use. Of course, you
>could always resort to straight C when you had to.
This seems to me to be more a problem with "the books" than with the
language. Bad programming is bad programming - no matter what the
language. "The books" tend to use overly sophisticated techniques to
implement features that could be more easily and efficiently achieved
using much simpler idioms for any given example; generally this is
rationalized as being "for pedagogical purposes" but leaves the
impression that these rube-goldberg-esque approaches are the only ones
C++ supports, which is untrue. Anyone foolish enough to try and
actually use complex numbers as they are usually implemented in "the
books" deserves what he or she gets. :-)
[...]
>--
>Ken Anderson
>Internet: ·········@bbn.com
>BBN STC Work Phone: 617-873-3160
>10 Moulton St. Home Phone: 617-643-0157
>Mail Stop 6/4c FAX: 617-873-3776
>Cambridge MA 02138
>USA
------------------------------------------------------------
Kirk Rader ····@triple-i.com
From: james brister
Subject: Re: Lisp vs C++ flame wars (was Re: Writing a small Lisp)
Date:
Message-ID: <bristerCqoFy7.LGC@netcom.com>
Mike McDonald (···@trantor.harris-atd.com) wrote:
: In article <·················@netcom.com>, ·······@netcom.com (james brister) writes:
: |> What a load of crap. The primary consideration was bit-level
: |> compatabilty with C. The idea was to add as much OO to C as possibly,
: |> but impose no penalty if a programmer chose not to use the OO features.
: |> And they succeeded.
: Precisely one of those self imposed constraints that I consider a mistake. I
: can think of no good reason why an object has to have the same bit representation
: as a struct. They're different things that should be used for different purposes.
: Trying to make them bit equivilant doesn't make sense to me.
When you don't want/need polymorphism then the only difference between a
classic struct and an object is the tight binding between the data and the
functions that operate on it. Compile time checking eliminates the need for
embeded information that would be otherwise be required. Making them
bit-equivalent in this case allows sharing between C and C++ and given the
propensity of C and the close association between C and UNIX, this choice
makes perfect sense to me.
: Agreed, it wasn't designed to be the world's answer to OO programming.
: But then
: why are all of the C++ bigots advocating just that?
Beats me. I think C++ is better than a lot of people give it credit for, but
it certainly isn't the final answer (no language is).
: My sour grapes have more to do with the advocates of C++ than the language
: its self. And yes, I have sour grapes about the lisp bigots around here who claim
: lisp is God's one true language. I believe that both languages have serious
: sorthcomings in them.
Couldn't agree more. C++/LISP/(fill in name language here) bigots are usually
talking out of their collective butts--a lot like religious bigots (although
not quite as dogmatic--but close).
: And I wouldn't use C++ for the network transport layers either. (And yes, I
: have implemented TCP/IP on a shared memory multiprocessor. I chose C.) C yes, : C++
: no way. For me, the inconsistancies, constraints and kludgy syntax of C++ are : not
: worth the effort for most applications. I'd much rather use a cleaner language
: like C an implement my own objects then put up with C++.
I would if only for the better type-checking and encapsulation C++ gives you.
For that alone I consider C++ better than C.
James
--
James Brister ·······@vix.com
decwrl!vixie!brister
Lisp and C++ each have advantages and disadvantages. The programmer
should be able to choose where he or she wants to make the development
time/runtime tradeoff. The best solution, then, is to make both work
together as equal partners. Our paper "Sweet Harmony: The Talk/C++
Connection", to appear in LFP '94, describes the automatic,
transparent, and complete binding between Lisp and C++ that we have
implemented for Ilog Talk, a new commercial EuLisp and ISO Lisp-based
implementation. If you want a copy of the paper or more information
about the product, you can write to ····@ilog.com or ············@ilog.fr.
-- Harley Davis
Ilog Talk developer
--
------------------------------------------------------------------------------
nom: Harley Davis ILOG S.A.
net: ·····@ilog.fr 2 Avenue Galli�ni, BP 85
tel: +33 1 46 63 66 66 94253 Gentilly Cedex, France