Greenspun's Tenth Rule of Programming: "Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified bug-ridden slow implementation of half of Common Lisp." Now with more JavaScript.
I've tried really hard with eslisp to defy Greenspun's Tenth, and to do justice to the Lisp tradition. The macros in eslisp are actual macros with scope and proper hygiene. They can perform arbitrary computation, and can arbitrarily modify the AST. You can even access the macro table during compilation to completely gut the language from the inside if you want.
So I guess the goal is to be a purpose-designed, fairly well specified, only somewhat buggy, slower-but-not-debilitatingly-so implementation of 80% of Common Lisp. :)
So, does it include bit-arrays, custom hash tables, multimethods, method combinations, the condition-restarts signalling system, ability to place items on the stack instead of on the garbage collector, type declarations that enable speed optimizations, saving the running state to disk, and upgrading the instances of a class to a new class?
I don't want to be smug, but 80% is a bold claim. Again, I think Eslisp is useful and maybe i'll try to introduce it to my team (they're all JS/TS developers) to see if they get the GATEWAY DRUG to Lisp.
"By then, Netscape management had decided that a scripting language had to have a syntax similar to Java’s."
I wonder how their reasoning went. I find it generally confusing, if two different languages have similar syntax (why did Java have to look a bit like C?). I guess, I need a visual hint reminding me of the expected semantic.
Anyhow, even if the original JavaScript (perhaps "ScriptingScheme" or "WebScheme"?) would have more resembled Scheme, I doubt it would have used S-expr for long. Over the years I developed the needed parenthesis-blindness, but can't imagine most Web developers having that patience.
