From ... Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!news.tele.dk!small.news.tele.dk!134.222.94.5!npeer.kpnqwest.net!nreader1.kpnqwest.net.POSTED!not-for-mail Newsgroups: comp.lang.lisp Subject: Re: Polymorphism in Common Lisp References: Mail-Copies-To: never From: Erik Naggum Message-ID: <3207123764972938@naggum.net> Organization: Naggum Software, Oslo, Norway Lines: 53 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 18 Aug 2001 11:42:46 GMT X-Complaints-To: newsmaster@Norway.EU.net X-Trace: nreader1.kpnqwest.net 998134966 193.90.205.216 (Sat, 18 Aug 2001 13:42:46 MET DST) NNTP-Posting-Date: Sat, 18 Aug 2001 13:42:46 MET DST Xref: archiver1.google.com comp.lang.lisp:14535 * Software Scavenger > What I want to do is make it as short and clear as possible to contradict > the claim that Haskell programs are shorter and clearer than Lisp > programs. Clearly, Haskell must have been used for something that Common Lisp can do better? Rather than let Haskell set the baseline, let Common Lisp set the baseline and try to show what long and verbose code Haskell needs to do the same thing. E.g., it, too, should do poorly for parsing XML. :) > But is that the best I could do? The Haskell version still seems > slightly shorter and clearer. Every language has been optimized for _some_ forms of expression. That you have found that Haskell is doing well in what it was clearly intended to do is hardly surprising -- there is absolutely no reason to think the Haskell people are idiots. The same goes for Perl. Of _course_ it wins hands down in the area of economy of expression for its intended tasks. The _real_ issue in these heavily optimized languages is whether there is a huge disparity of compactness for problems of similar complexity of abstraction and expression. This is where Common Lisp truly excels beyond _any_ other language. You may, and some do, complain that there is no super-compact expression of some particular problems, but what you completely miss is that the _penalty_ for thinking "outside of the box" or outside of the "intended" uses of the language is _also_ absent. Optimization of design has _huge_ costs in terms of what you can _not_ do efficiently. This factor is almost always ignored in language comparisons because people are happy to switch languages and so enjoy creating _new_ ones that they can optimize for some miniscule little featurette, until, of course, they run into the popularity problem and their languages grow so large that the time a human mind needs to learn to use it efficiently will have dwarfed any _real_ savings from economy of expression. But by all means, write qsort in Haskell and hello, world in C. I am not sure what you are going to _do_ what those two utilities, however. If you have a language that is good at demonstrating such things, maybe it has been optimized for demonstrations? At least one really huge software company has made the bulk of its earnings on its ability to demonstrate to other people that the real users what they could do. From the Latin word "imponere", base of the obsolete English "impone" and translated as "impress" in modern English, Nordic hackers have coined the terms "imponator" (a device that does nothing but impress bystanders, referred to as the "imponator effect") and "imponade" (that "goo" that fills you as you get impressed with something -- from "marmelade", often referred as "full of imponade", always ironic). I am not sure _exactly_ what about Haskell prompted me to tell you about those two Nordic hacker jargon terms, however. :) ///