Common Lisp, unlike Scheme, was always a language designed for professional programmers not students. Its big symbols contain values, functions, and property lists to improve performance - lumping all those together with a single pointer and offsets saves a few bytes of memory and reduces the garbage collector's workload. Like destructive list manipulation, it's not expressing some Computer Science theory; it's there because sharp knives are useful.

In terms of the importance attached to language aesthetics, ANSI Common Lisp is probably closer to PHP than Ruby, ML, or Python. That doesn't mean that it isn't used to write beautiful code, only that it leaves doing so solely to the programmer's discretion.

Brendan Eich made the statement (speaking of JS as the asm of the web): "Source as 'bytecode' also avoids the big stupid Java bytecode mistake: freezing a poorly designed lowered form of Java, then being unable to evolve the high-form source, i.e., the Java programming language for fear of breaking Java bytecode compatibility. This severely messed up the design of inner classes and then generics in Java -- and then Sun broke bytecode compat anyway!" [Source](http://www.hanselman.com/blog/JavaScriptIsAssemblyLanguageFo...)

We are at a point where JS is following the same path. Ideas like ECMAScript 4 were rejected because they would break compatibility and we are still working around the problems of JS. We need that clean break now rather than later. Such a clean break would be at it's best now rather than later. We could simply continue supporting the current JS compilers 'as is' for old code (or provide a JS to new language compiler) and replace the language with another which is designed correctly (we could perhaps break the DOM too).

While I would like to see a scheme r7rs used (except with support for OOP, built-in actors, and static typing), I suspect that M-expressions (more like dylan) would be necessary (though for the record, I've seen more nested parenthesis/braces in JS code than I've seen in a lot lisp code). Such a language could also be interpreted via JS (or compiled to JS) for old browsers (though I suspect telling people to upgrade or go without would promote suitable updating more akin to telling everyone to change to digital TV or go without).

We need a clean break and lisp is worthy of consideration rather than being cast to the side like last time.

> though for the record, I've seen more nested parenthesis/braces in JS code than I've seen in a lot lisp code

I saw a presentation once, where they compared the amount of parenthesis/braces in mainstream languages vs Lisp, with Lisp having less in most algorithms being compared.

For example,

    func_call(args) vs (func_call args)
    array_access[index] vs (array_access index)

The thing is, since in other languages parenthesis/braces tend to be scattered along the source file, it looks like less than Lisp based languages.