From ...
Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed1.cidera.com!Cidera!skynet.be!skynet.be!ossa.telenet-ops.be!nmaster.kpnqwest.net!nreader2.kpnqwest.net.POSTED!not-for-mail
Newsgroups: comp.lang.lisp
Subject: Re: CMUCL18d on Alpha?
References: <3CBA8472.48774F5C@ilt.fhg.de> <3CBBE1E6.93F85F44@ilt.fhg.de> <3CBBF4AC.39CD4A4C@kfunigraz.ac.at> <3CBE88D1.6A17BCE1@ilt.fhg.de> <4npu0xrqo5.fsf@rtp.ericsson.se> <3CBFBFFA.AF340500@ilt.fhg.de> <87bscfeo6l.fsf@orion.bln.pmsf.de> <4r8lb658w.fsf@beta.franz.com>
Mail-Copies-To: never
From: Erik Naggum
Message-ID: <3228240751673464@naggum.net>
Organization: Naggum Software, Oslo, Norway
Lines: 67
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 19 Apr 2002 21:32:32 GMT
X-Complaints-To: newsmaster@KPNQwest.no
X-Trace: nreader2.kpnqwest.net 1019251952 193.71.199.50 (Fri, 19 Apr 2002 23:32:32 MET DST)
NNTP-Posting-Date: Fri, 19 Apr 2002 23:32:32 MET DST
Xref: archiver1.google.com comp.lang.lisp:32048
* "Siegfried Gonzi"
| I still do not buy the alleged debunking of a so called Lisp myth:
| "Common Lisp is slow". Every time where Common Lisp performs well, there
| are 100 other situations where Common Lisp performs not that good.
You have previously made the point very strongly that you do not wish to
become a competent programmer. It is therefore not surprising if you do
not yet understand that some programming languages and environments are
optimized for writing short programs that are fast and some programming
languages and environments are optimized for writing short programs that
are correct. To make a fast program correct takes effort that requires a
good programmer. To make a correct program fast also takes effort that
requries a good programmer. You are not, by your own admission, a good
programmer, nor do you wish to become one. That means that you what you
think or believe about programming languages affects and applies to short
programs that take no effort to write and which accept _all_ the premises
of the language developers. Such programs are rarely useful, but for
some reason, incompetent programmers who do not even know how to _think_
about programming always believe that short programs test the language
the most. What short programs show is what the language has been
optimized for in terms of expressivity, and what one language can do in a
short program is definitely not a good standard to apply to any other.
Example: When a C++ programmer has discovered that "foo" + "bar" yields
"foobar", he will be very disappointed that (concatenate 'string "foo'
"bar") is the Common Lisp equivalent, but that is because he has bought
into the C++ mindset and all the premises underlying its choices. When a
Common Lisp programmer discovers that a matrix represented with lists may
be transposed with (apply #'mapcar #'list ), he will be highly
disappointed by the effort it takes to both represent and transpose a
matrix in C++.
It takes both education and experience to realize how your understanding
of any programming language has been influenced by the mindset and the
tacit premises acquired by default from your first language, which is why
I so strongly recommend that people approach every programming language
as the first, without all the mental baggage from a previous language.
This is particularly important when one accepts without question the
short programs of one language and only seek to reimplement them in each
new language, instead of trying to discover short programs in each on
their own terms.
It is not Common Lisp that does not perform well, it is the programmer
who does not know how to make a Common Lisp program perform well, but
without skills, a Common Lisp program can perform abysmally, yet produce
correct results. Likewise, if a C++ program is buggy and crashes, it is
the programmer who does not know how to make a C++ program work
correctly, but without skills, a C++ program can crash very quickly.
| I personally do not have any problems with that performance situation (I
| would even say people in general do not care; how would you otherwise
| explain Python's success?); but people should be more honest or otherwise
| one should show the original poster how to improve his performance
| bottleneck with a factor of 10 or even 100.
Perhaps you should leave this issue to (those who would like to become)
real programmers? We have very little use for the kind of "alternative
programming" that is like "alternative medicine" where people of no clue
and little intelligence believe all sorts of things based on random
coincidences and a massive lack of understanding of anything medical.
///
--
In a fight against something, the fight has value, victory has none.
In a fight for something, the fight is a loss, victory merely relief.
Post with compassion: http://home.chello.no/~xyzzy/kitten.jpg