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 poorl

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/JavaScriptIsAssemblyLanguageForTheWebPart2MadnessOrJustInsanity.aspx 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.