Subject: Re: CMUCL18d on Alpha?
From: Erik Naggum <>
Date: Fri, 19 Apr 2002 21:32:32 GMT
Newsgroups: comp.lang.lisp
Message-ID: <>

* "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 <matrix>), 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: