Eh. As far as I'm concerned, if the only difference is the syntax, what's the point? But I'm comfortable with the Erlang, K, Lisp, C, and Forth syntax, so "I grafted Ruby syntax on X" is pretty underwhelming.
I agree with you (and I've been researching Earley parsing and Pratt top-down operator precedence parsers lately), but: one thing at a time. While learning, it may be more helpful to experiment with AST transformations in Lisp and get immediate results, and wait on parsing until they get to the syntax design.
Also, too many toy interpreters/compilers mess around with syntax but have really conventional semantics. I suspect if people don't sink so much time into parsing etc. first, they may be more likely to focus on semantics instead.
If you learn compilers using Lisp / ML / etc., you can skip learning about parsing upfront and just use Lisp expressions. That's one of the reasons why the Lispers and MLers have so much cool compiler literature. If you're writing a compiler in C, you're stuck doing parsing and tree manipulation manually.
Nowadays, you could also use JSON, Python dicts, etc. for data literals. Either way - worry about syntax later.
In particular, I suggest _Essentials of Programming_ Languages (http://eopl3.com/, AKA "EoPL"). Also, check out the _first_ edition - there's a really cool final chapter about compiling via continuation passing style (CPS, e.g. http://matt.might.net/articles/cps-conversion/) that got cut in later editions.
More generally - learn Lisp and/or ML, and go through any book that has you writing simple interpreters. EoPL, SICP, Appel's _Modern Compiler Implementation in ML_, "The Art of the Interpreter" (http://library.readscheme.org/page1.html), etc.
I think most people would look at the top of page 7, go "eek!", and leave with the idea that compilers are insurmountable magic. That's all.
For me, being able to read that stuff came much later than learning about compilers. (I haven't read that specific paper yet. Sent it to my kindle, though.)
I could similarly recommend some papers on compiling via CPS, but the people Crenshaw is addressing would just find them intimidating - they're still getting to grips with the basic techniques and terminology.
The nanopass paper uses so many passes for pedagogy, not efficiency. Of course it's inefficient, that's not the point. They're still easier to teach in isolation.
I'd guess that most people who are completely new to compilers don't know how to read denotational semantics, either. Handing that paper to them would just reinforce the "compilers are perceived to be magical artifacts" view that Crenshaw is trying to dispel.
He intentionally avoid Greek letters, let alone denotational semantics. I don't doubt that it's a good paper, but the people Crenshaw is addressing probably wouldn't be able to read it (yet).
Yes. I've read them both, they're worth your time. The thing with most compiler texts is that they bog you down with a lot of stuff upfront about automata, parsing algorithms, etc., and by the time they get to the good stuff, it's hard to see how it all fits together. Crenshaw dives right in, and you quickly get a simple compiler running. You can look into all the alternative parsing algorithms, etc. later.
After those, I recommend Niklaus Wirth's _Compiler Construction_ (http://www.inf.ethz.ch/personal/wirth/books/CompilerConstruc...) and Andrew Appel's _Modern Compiler Implementation in ML_ for follow-up, in that order. Wirth's book is a quick read, about on par with Crenshaw's. Appel's is more in-depth.
Actually, I think you're right - Javascript was frozen very early and Unix had a while to develop, but the same forces (competing commercial implementations) locked in minor errors in Unix as well.
I'd say Unix got more of its warts fixed than JS did, but that's only a difference of degree.
Mainly: The whole "Worse is Better" thing works better when you don't get stuck maintaining reverse compatibility with your early releases.
It'll probably be slower than smartly written, natively compiled code, but not necessarily by enough to matter. It really depends on what you're trying to do, so the best way to know is to try it and measure.
Compiling to a human-readable format can be pretty straightforward. You can skip some steps entirely (e.g. register selection), and modern tools make it easy to ignore others (lexing & parsing) for quite a while. Don't think about it as "compiling", if you think that's a scary hard thing. Think of it as "reading in a couple kinds of simple structures and converting them to text". Like a templating engine.
Figure out what kind of operations you want to support, how to map them into small chunks of Javascript, and go for it. You can pass hand-written JSON, XML, sexps, dicts, etc. to the compiler in a REPL and worry about parsing and other stuff later.
I think a standardized bytecode for Javascript could make sense, but designing a VM for JS and then trying to port (say) Ruby or ML to it later would be awkward, and I don't think most web devs are aware of that.
Compiling to Javascript is a practical choice now. I'm not a fan of the language, but that avoids a lot of its pain points.
I also wonder why these discussions seem to assume we're going to stay with the web stack as-is forever, but that's neither here nor there.
Worse is Better doesn't quite fit here. WiB is about getting a "basically right" prototype out, and then improving it with real world feedback, rather than waiting forever to have a perfect 1.0.
With Javascript, unfortunately, it didn't work out so well - a bunch of early bugs (which could have been quickly fixed) were preserved when Microsoft made a bug-compatible clone for IE, and then became part of the ECMAScript standard in 1996. This derailed efforts to improve the language - there is a lot of work on sophisticated implementations now, but the spec itself is buggy.
People invoke "Worse is Better" as retroactive justification for all kinds of engineering blunders, but it's a bit more limited in scope. Here you go: http://www.jwz.org/doc/worse-is-better.html
I'm mostly thinking about how many of the problems highlighted in "Javscript: The Good Parts" have been fixed in Lua, while Javascript can't be fixed. Not a matter of design and taste, but outright bugs.