Subject: Re: CMUCL18d on Alpha? From: Erik Naggum <erik@naggum.net> Date: Fri, 19 Apr 2002 21:32:32 GMT Newsgroups: comp.lang.lisp Message-ID: <3228240751673464@naggum.net> * "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: http://home.chello.no/~xyzzy/kitten.jpg