It looks a bit like the thing that happened with XML. In years 2000-2005 developers got really, really excited about XML, and started to use it for everything. Everything, including things that it was never meant for. And yes, the resulting technologies worked (kind of), but they caused more problems than they solved. SOAP/WSDL. XSLT. All that XML-to-SQL-query stuff.
What I've seen personally often involved overly complex SOAP/WSDL services for things that could be accomplished with a simple HTTP request. Look at query prams, return the correct HTTP code and you're done.
Another common pathology is problem over-solving. Instead of writing a library to solve some problem and providing a sensible API, people write the library, hide it, then write an XML "driver" that consumes a custom-designed language encoded via XML tags. The alternative in this case is simply providing the original API.
CIL is insanely simple (I've written a CIL->x86 compiler in a matter of hours) and has only had small, incremental changes since the very first version.
Are there really any examples of what you're talking about outside of the Office team?
Subtle chains of cause and effect were at play among people involved, going back years to Silicon Graphics (Netscape drew from UIUC and SGI, plus montulli from Kansas, and jwz). Also going back through the living history of programming languages. SICP and some of the Sussman & Steele "Lambda the ..." papers made a big impression on me years before, although I did not understand their full meaning then.
Remember, I was recruited to "do Scheme", which felt like bait and switch in light of the Java deal brewing by the time I joined Netscape. My interest in languages such as Self informed a subversive agenda re: the dumbed down mission to make "Java's kid brother", to have objects without classes. Likewise with first-class functions, which were inspired by Scheme but quite different in JS, especially JS 1.0.
Apart from the "look like Java" mandate, and "object-based" as a talking point, I had little direction. Only a couple of top people at Netscape and Sun really grokked the benefit of a dynamic language for tying together components, but they were top people (marca, Rick Schell [VP Eng Netscape], Bill Joy).
Rather than dumb luck, I think a more meaningful interpretation is that I was a piece of an evolving system, exploring one particular path in a damn hurry. That system contains people playing crucial parts. Academic, business, and personal philosophical and friendship agendas all transmitted an analogue of genes: ideas and concrete inventions from functional programming and Smalltalk-related languages.
You might think "it's still luck, it could have been Forth, or TCL". Not likely. There were not years or even months to spare. I had hacked language implementations for fun since I was an undergrad, and for SGI's packet sniffing tools earlier my career. I was a C/Unix fanboy, I knew the C grammar by heart. Independent of me, the "Make it look like Java" order was not just lucky, it was congruent as a consequent, even predictable, given the rise of C in the '80s and C++ in the '90s, and the direct influence of C++ on Java.
My point is simple: the likelihood of any other language syntax than C (C++ -> Java, but really: C) was low. The likelihood of something without "objects" was also low. Netscape recruited me in part because I could hack quickly, and in part because I had some language implementation chops (not enough, in hindsight). I was "that guy", not in any brag-worthy sense, just the only person who was in the position to do the deed, with (barely) enough skills to pull it off.
Many hackers could have done a better job with more time, or perhaps a better job had they been in my shoes. Who knows? But no one at Netscape could have, and the opportunity was there and then.
The path dependence part is spot on. Netscape's business plan for 1.0 was getting out in six months or someone else would kill Mosaic and take over. The entire platform push in 1.1 (plugins) and 2 (frames, JS) was about getting on first. We knew Microsoft was coming, because Netscape had rejected a low-ball offer from them in late '94.
He couldn't just have used scheme wholesale though, since a major part of JS is the integration with the DOM. He would have needed to create some custom object system anyway to support that. So it would have been a new language anyway, and due to the time constraints at the time, it would probably have had the same amount of bugs and mistakes that JS ended up with.
Still, some pretty sizable element of luck is there indeed.
If the common browser language had been brainfuck we would have had to use that.
That said, it is important to note why brainfuck (or any other blub) wasn't the common browser language (or CBL from here on in) - the CBL is the CBL because it was relatively easy for humans to write small snippets of code in it. Without that, the language would never become the CBL.
Unfortunately that statement also means that the odds were against the CBL being anything other than an imperative style language. That we got something so close to a functional language is really quite a bonus (even if I do end up having to modify strings and eval() because we aren't using s-exprs)
Note that VBScript were much more familiar to many developers, because VB was one of the most popular language at the time. But it fell by the wayside because it was not supported at ubiquitously as JS. (It was also a much worse language than JS, but that was not the reason it failed.)
Where I believe they are actually cross compiling cil into js.
> Shaver's right, assembly without a great macro processor is not good for programmers or safety. JS is. So the analogy needs some qualification or it becomes silly.
This way you can compare anything to anything else and then try to qualify.
Don't they teach this stuff any more?
Why not just say "JS is the common language of the web" without the horrible analogy.
The key aspect of the analogy is that you have compilers emit or JIT to JS, rather than writing if yourself, and then have languages/DSLs that users write to, rather than JS.
Yes. That's why JS is the target (and its ubiquity).
but if you were to design a browser language with this kind of usage in mind it seems you'd want something that was a lot easier to optimize than JS
JS isn't turning out to be too bad to optimize. Post-lower optimization already occurs in the browser. The part the compiler would do is optimization prior to emission to JS.
What other language runs in all browsers?
JS could be called something like In-Browser Java (and it is heading to be the same bloated failure) or something. But assembly.. ^_^
Reality distortion is very common think among Java fan-boys. Some of them, for example, believe that a VM implemented as user level C++ program which uses its own unrelated to CPU base data-types and several layers of abstractions to interact with an OS, will run faster and more efficient than other c++ program linked directly with core OS libraries.
Now JS fan-boys thinks that if there are things like V8 or such as artificial as popular things like Nodejs, everything must be written in JS. That reminds me the very same slogan from Java's best days.
To dear down-voters: Think for a moment what is v8 or Spidermonkey and count how many code you should pile up to get access to something as simple as data stored in a MySQL table (or any other data behind its own socket-based protocol). ^_^ (yes, reality-checks are always painful)
His entire premise is based on the idea that you can convert one language into another, and therefore the target language is equivalent to assembly. That's ludicrous. I believe Facebook converts PHP into C or C++, therefore C/C++ is the new assembly. What?
The guy should just stick to talking about techniques for using cleaner languages and converting them into JS. Instead, a bunch of link-bate BS was poorly conceived and thrown in.
This won't be fully true until everyone is on the same page with ECMAScript5.
ES3 has become the universally compatible "write once, run anywhere" bytecode VM that Java promised to be.
x86 assembly language is to an x86 processor as;
The x86 processor executes machine code (I think actually some of the "backwards compatibility" in an x86 processor is provided by a scripting-like-language implementation on the chip but that's invisible to the assembly language programmer so not part of this discussion).
So I think you'd have to say that:
x86 machine code is to an x86 processor
x86 assembly language is to x86 machine code as;
But getting back to the original analogy, I think it would be better stated as: