From: ·····@vus002.telecom.com.au (Satan - The Evil 1)
Newsgroups: comp.lang.lisp,comp.programming,comp.lang.c++
Date: 9 Jul 1997 02:17:59 GMT
Organization: Telstra
Lines: 57
X-Newsreader: TIN [version 1.2 PL2]
Xref: agate comp.lang.lisp:29128 comp.programming:52032 comp.lang.c++:280612
...
I would say that C++ has such a bad repution amongst Lisp
programmers because it takes several years to become
a very good and efficient C++ programmer whilst you can
quickly become an efficient Lisp programmer. The massive
number of *bad* C++ programmers certainly doesn't help
its reputation.
If one tenth of the managers out there would see this point (and the
immense potential for savings in the software development cycle),
Common Lisp would become the standard tool for development in a very
brief time.
Cheers
--
Marco Antoniotti
==============================================================================
California Path Program - UCB
Richmond Field Station
tel. +1 - 510 - 231 9472
I really should know better than to post on this topic, but I couldn't
resist.
In article <···············@infiniti.PATH.Berkeley.EDU>,
Marco Antoniotti <·······@infiniti.PATH.Berkeley.EDU> wrote:
> From: ·····@vus002.telecom.com.au (Satan - The Evil 1)
> Date: 9 Jul 1997 02:17:59 GMT
>
> I would say that C++ has such a bad repution amongst Lisp
> programmers because it takes several years to become
> a very good and efficient C++ programmer whilst you can
> quickly become an efficient Lisp programmer. The massive
> number of *bad* C++ programmers certainly doesn't help
> its reputation.
>
>If one tenth of the managers out there would see this point (and the
>immense potential for savings in the software development cycle),
>Common Lisp would become the standard tool for development in a very
>brief time.
It's been my experience as a professional Lisp programmer (and former
S/W support person at Symbolics) that a large percentage of the Common
Lisp programmers I've worked with never learn how to use their language
correctly either. In this sense the Lisp community is little different
than the C++ community. However, many of these same CL programmers
couldn't care less about machine efficiency, and that IS different from
the C++ world.
In the C++ community, generality, flexibility, and correctness are
sacrificed on the altar of machine efficiency. The language design
encourages this attitude; C++ programmers are forced to deal with
low-level issues like the mechanics of iteration in order to get
anything done at all, and the language offers little help with
abstractions and higher level design issues. This strikes me as penny
wise and pound foolish.
Neither language is easy to learn, although I think one can learn to do
interesting things sooner in CL. Both languages are huge, and I don't
think the textbooks for either are terribly good (the exceptions on the
CL side being Paul Graham's and Peter Norvig's outstanding books). Most
of the C++ books I've seen failed to provide any motivation for the
existence of the various features of the language. The fact that many
C++ features are ad hoc kludges (e.g. templates) intended to work around
holes in the original design doesn't help this. (CL isn't much better
in this respect; many of its defects stem from backwards compatibility
with dialects going back to Lisp 1.5. But at least the object system is
well thought out.)
To get back to the point of this thread (and the original subject line),
IMHO the average C++ programmer will probably write code that runs
faster than his Common Lisp counterpart, but the CL programmer will be
done sooner, and will likely have fewer obscure bugs to fix. Neither
will write code you'd want to show off to an expert (remember, we're
talking average programmers here). And both will take about the same
time -- a couple of years at least -- to come up to a reasonable level
of competence.
A bad C++ programmer will tend to write code that leaks memory and
crashes a lot. A bad Lisp programmer will tend to write code that is
slow and conses a lot. Given these choices, I'd rather have a program
that is slow and GCs too much than one that runs fast but crashes for
obscure reasons.
-- Chuck
--
Chuck Fry -- Jack of all trades, master of none
······@chucko.com (text only please), ········@home.com (MIME enabled)
This space for rent... NOT.
Chuck Fry (······@best.com) wrote:
: I really should know better than to post on this topic, but I couldn't
: resist.
[...]
: In the C++ community, generality, flexibility, and correctness are
: sacrificed on the altar of machine efficiency. The language design
Much of the satisfaction in writing C/C++ comes from the
ability to write efficient code. But I wonder, are people
with an intrisic love of efficiency and machine specifics
attracted to C/C++ or do they come to love these through
the use of C/C++? I suppose this is like the question;
"Does power corrupt or does power attract those who are
already corrupt or easily corruptable?"
Maybe a different type of programmer is attracted to Lisp
than is attracted to C++. In which case, there will always
be conflict between the two as each beleives they are
fundamentally correct in their choice of language and simply
cannot see the other's point of view. Try going to
comp.lang.asm.x86 and telling them that their code is
not flexible or general and they will say "who cares!".
[...]
: existence of the various features of the language. The fact that many
: C++ features are ad hoc kludges (e.g. templates) intended to work around
I hope you don't have anything against templates. They have to
be one of the best features of C++. What do you think?
[...]
OK, so what would make the ideal language? How about Lisp
or Clos with embedded C++? Just like C/C++ can have
embedded assembler via the _asm directive (after all,
C programmers are just frustrated assembler programmers) :)
Actually, maybe this would just start another never ending
flame war between those who believe Lisp should be embedded
in C++ and those who believe C++ should be embedded in Lisp.
Cheers,
- PCM
In article <············@cdn-news.telecom.com.au>,
Satan - The Evil 1 <·····@vus002.telecom.com.au> wrote:
>Maybe a different type of programmer is attracted to Lisp
>than is attracted to C++. In which case, there will always
>be conflict between the two as each beleives they are
>fundamentally correct in their choice of language and simply
>cannot see the other's point of view. Try going to
>comp.lang.asm.x86 and telling them that their code is
>not flexible or general and they will say "who cares!".
I can only speak for myself. As a lapsed assembly language hacker, I
get plenty of fine-grained control out of Common Lisp. I will
grudgingly use C if absolutely necessary, but I really do not like C++.
Regarding trolling in comp.lang.* newsgroups by insulting the readers'
choice of languages, it happens all the time in comp.lang.lisp, and I'm
sick to death of it. This thread started out as yet another example.
>[...]
>: existence of the various features of the language. The fact that many
>: C++ features are ad hoc kludges (e.g. templates) intended to work around
>
>I hope you don't have anything against templates. They have to
>be one of the best features of C++. What do you think?
I think templates are a special-purpose kludge to work around the fact
that too much type information must be known at compile time before code
can be generated. Common Lisp doesn't have this particular restriction.
E.g. you don't have to declare the element type of an array, list, or
structure before you use it, and you can mix and match element types at
run time. In some implementations you can declare element types of
arrays and structures, if the application warrants it.
The Common Lisp feature corresponding to templates is the macro
facility, which is far more general and powerful than C++ templates, and
which I consider one of the primary advantages of Common Lisp over other
languages.
>OK, so what would make the ideal language? How about Lisp
>or Clos with embedded C++? Just like C/C++ can have
>embedded assembler via the _asm directive (after all,
>C programmers are just frustrated assembler programmers) :)
>Actually, maybe this would just start another never ending
>flame war between those who believe Lisp should be embedded
>in C++ and those who believe C++ should be embedded in Lisp.
I don't believe in half-breeds. Neither language is ideal for my
purposes, but I find when trying to solve problems, Common Lisp gets in
my way a lot less than C++.
And frankly, I don't see what C++ has to offer that some existing Common
Lisp implementation is not already delivering. As it is now, most good
CL implementations offer both high-level abstraction capability and
intimate control over the code generated by the compiler. Some even
allow in-line assembly coding.
I will admit that C++ objects and methods tend to have less overhead
than their CLOS counterparts, but the intended purposes of the two
object systems are rather different. CLOS is really an object system
prototyping system; much of the overhead is there to support customized
object semantics on a common base. Something resembling C++ classes
could be written straightforwardly in Common Lisp, if anyone needs to
use that paradigm.
And here's a tip if you're looking for better CLOS performance for a
critical subsystem. Write your class definitions as DEFSTRUCTs.
Granted, this restricts you to single inheritance, but the object
overhead is much lower than DEFCLASS, and you can still use CLOS's
multiple dispatching.
--- Chuck
--
Chuck Fry -- Jack of all trades, master of none
······@chucko.com (text only please), ········@home.com (MIME enabled)
This space for rent... NOT.
With a mighty <············@cdn-news.telecom.com.au>,
·····@vus002.telecom.com.au uttered these wise words...
> Actually, maybe this would just start another never ending
> flame war between those who believe Lisp should be embedded
> in C++ and those who believe C++ should be embedded in Lisp.
Have you heard of Intentional Programming? ;)
<URL:http://www.research.microsoft.com/research/ip/ifipwg/ifipwg.htm>
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Please note: my email address is gubbish
Will write Lisp code for food
With a mighty <············@shell5.ba.best.com>,
······@best.com uttered these wise words...
> It's been my experience as a professional Lisp programmer (and former
> S/W support person at Symbolics) that a large percentage of the Common
> Lisp programmers I've worked with never learn how to use their language
> correctly either. In this sense the Lisp community is little different
> than the C++ community. However, many of these same CL programmers
> couldn't care less about machine efficiency, and that IS different from
> the C++ world.
This is what I was refering to when I said:
> I know that there are things I won't hesitate to do in Lisp that I'd never
> have dreamed of doing in C or C++. One language opens up my imagination by
> making hard things easy, while the other makes simple things hard work.
C/C++ encourages a programmer to think of the machine first, and the
task that the code should perform _second_. Perhaps even third.
> In the C++ community, generality, flexibility, and correctness are
> sacrificed on the altar of machine efficiency. The language design
> encourages this attitude; C++ programmers are forced to deal with
> low-level issues like the mechanics of iteration in order to get
> anything done at all, and the language offers little help with
> abstractions and higher level design issues. This strikes me as penny
> wise and pound foolish.
Alas, I can only agree with you on this. Doublethink? If the language
limits the programmer's vocabulary, expect their ideas to be equally
restricted. If the language helps expand the programmer's vocabulary,
expect anything.
> To get back to the point of this thread (and the original subject line),
> IMHO the average C++ programmer will probably write code that runs
> faster than his Common Lisp counterpart, but the CL programmer will be
> done sooner, and will likely have fewer obscure bugs to fix. Neither
> will write code you'd want to show off to an expert (remember, we're
> talking average programmers here). And both will take about the same
> time -- a couple of years at least -- to come up to a reasonable level
> of competence.
"What does the market reward (reduced time to market),
and what does the market not penalize (buggy software).
If you want to change behavior, you've got to change
the rewards -- otherwise, talk is cheap."
-- David Chase
> A bad C++ programmer will tend to write code that leaks memory and
> crashes a lot. A bad Lisp programmer will tend to write code that is
> slow and conses a lot. Given these choices, I'd rather have a program
> that is slow and GCs too much than one that runs fast but crashes for
> obscure reasons.
Same here. I just wish I was better at convincing other people! Talk
is cheap, and completely useless when _some people_ (those who ask for
C++ instead of Lisp code) prefer not to listen. Perhaps the answer is
to walk...
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Please note: my email address is gubbish
Will write Lisp code for food