>One disagreement I have is Lisp is definitely not designed for high performance. Any competent C programmer would find the suggestion laughable. A competent p

>One disagreement I have is Lisp is definitely not designed for high performance. Any competent C programmer would find the suggestion laughable. A competent programmer, C programmer or not, would realize that performance is far more a matter of how you write your programs than what language you write them in; as the saying goes, "You can write FORTRAN in any language." Now, the original LISP was not designed for high performance, to my knowledge. Later vendor-specific Lisps, like those found on the Lisp machines, were, because they had to be. Modern Lisps like Scheme and Common Lisp capitalize on the designs and technologies of those Lisps. For example, SBCL contains a very powerful high-level optimizing compiler that is capable of folding common code patterns down to efficient, often statically-typed machine code; that compiler dates back to the 'eighties when it was part of CMUCL. Anecdotally, I recently ported a C implementation of introsort to Common Lisp. After adding type declarations, SBCL produced code about that took about 50% longer to run than GCC's code. The generated machine code used scalar integers, immediate-element arrays, and no runtime generic function dispatch. The comparative slowness was a result of the fact that SBCL's assembly-level optimization (or what little it has) is much weaker than GCC's, not of the fact that the code was written in Lisp. >less syntax just means messier code Lisp doesn't really have less syntax than other languages; it has more regular syntax. Forms like LET still have their own syntaxes beyond the lexical syntax of lists. Now, seventeen levels of infix operator precedence, that makes code messy. >Parentheses everywhere doesn't make a language good. Just harder to read Parentheses don't make Lisp hard to read. Being unfamiliar with that style of code layout makes Lisp hard to read. Once you're accustomed to it, the parentheses become mostly background noise, much like C's semicolons or many languages' "$s." Indentation is far more important, again just like in C. Lisp has the advantage that properly laid-out code clearly visually reflects the evaluation hierarchy, which is more than can be said for a lot of infix code, especially when dealing with complex arithmetical expressions. >The "macro system" which refers to the ability to perform arbitrary functions on arbitrary data, is not unique to lisp. That is not at all what Lisp's macro system does, and while there are other languages which have similar macro systems to Lisp's, they're at least as niche. >And in general, usually obfuscates code and makes debugging harder. Macros, when used correctly, make code more clear, not less. In fact, I've seen this argument made about a lot of different features in a lot of different languages, and it seems to me that what it usually means is, "I don't really understand what that feature is designed for." It's like claiming operator overloading is bad because it lets you define "+" to do division, even though you can just as easily write a function named "add" that does division. >Everything that you can do with macro's and Lisps's homogeneous syntax is achievable with similar constructs in other languages I can write a Lisp macro named DEFINE-ENUM that essentially does the same as C's enum, but also establishes a mapping from enumeration values to names; then, I could do CL-USER> (define-enum color (red 7) (blue 23) (purple 30)) COLOR CL-USER> purple 30 CL-USER> (enum-name 'color 30) PURPLE How would you do that in C? It may be doable, but certainly not both general and easy. You're wading into the Turing tar-pit here. >Programming languages where data and functions are delineated by design have clearer structure and organization Lisp delineates functions from other data (on that note, you described Lisp as "untyped." Lisp is in fact strongly typed). It lets you treat code as data if you like, but again the structure and organization of a program is a matter of how you write it, not what language you use. It's true, though, that Lisp lets you use (sometimes radically) different organizational structures than languages like Algol and C, but again those structures are unclear mostly because they're unfamiliar, not because they're inherently convoluted. >Additionally they allow the compiler or interpreter to optimize by design Lisp gives the compiler more room to optimize than a language like C; the tradeoff is that you don't have a human optimizing the difference as a matter of course (e.g., choosing a concrete integer type). This can sometimes be a good thing, and sometimes it isn't. >In the rare case it's useful to have a function become a data argument, there are usually accommodations in the language to do so It's actually very often useful if you have a way of writing generic algorithms; this is why "functors" are common in C++ (especially with the advent of lambda expressions), but not so much in C.