How about Rube Goldberg Virtual Machine of the web? I don't see what people are so happy about.
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.
Right now people are really excited about JavaScript and begin to use it for things that are less and less appropriate for it. Yes, you can compile languages into JS, just like you can use XML to generate an SQL query. But is it really a good idea?
The analogy fails because using XML is, often, a choice. You can't get around JavaScript if you want to make a decent web app. The platform dictates it.
The analogy works in the way that maybe sometimes you shouldn't do a web app but a native client. I don't agree with the conclusion but I think it's what he meant.
We found out about it and started to look for alternatives to XML eventually. Hopefully, if the world does come to believe that compiling to JS is an unnecessary layer of abstraction, we'll have enough force of change from browser vendors to actually implement a lower-level change. At least with XML, we were free to change whenever... in-browser technologies isn't going to change without a concerted effort from just about everyone involved in browsers.
I presume you are talking about CoffeeScript and not something like GWT. The thing about it is that it is not really a layer of abstraction. Just consider an alternative syntax for javascript. The javascript that it produces is really readable.
There is no single alternative to XML, and I don't want to say that all XML is bad. But it's very commonly misused, because someone, somewhere tried to solve the wrong problem and XML happened to be the "default" solution. So, really, the alternatives depend heavily on the context.
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.
JS is ubiquitous because it's the only runtime that MS has ever bundled with Windows that was more or less compatible with other non-MS implementations running on non-MS platforms. It also does not utilize obfuscated and constantly changing object code formats, which is MS's forte.
> It also does not utilize obfuscated and constantly changing object code formats, which is MS's forte.
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?
Well, they have a spec for it, but it's not very good. That said, despite PE's history, it's remained largely the same for what, 15 years? Small changes to support various things, which make parsing arbitrary PEs a pain, but it's not bad considering its age.
Forgive me for parroting the thoughts of those smarter than me, but there was an engaging debate on Lambda the Ultimate recently on how terrible JS is as an assembly language: http://lambda-the-ultimate.org/node/4308#comment-66084
Dumb luck, as in winning the lottery? Not really. What did Ben Kenobi say to Han Solo about luck?
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.
I doubt an s-expr language would have been palatable, but if Eich had taken a few years to really get the browser language right it would never have taken root like JS has.
I don't see the problem with s-expressions? It would be a nice symmetry - pointy brackets for markup, round ones for code.
Eich have stated that he intended to create something like scheme for the web. The Java-inspired syntax (and name) were chosen for marketing reasons, not technical reasons.
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.
Ok, thank you for that, I think I'll just curl up in a little ball under a blanket and shiver for a while!
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)
I think that developers would have learned to write CBL whatever the language. The hype of the web combined with the CBL being the only language available for client side programming practically guaranteed its success, whatever the shortcomings of the language itself.
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.)
> 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.
Because "JS is the common language of the web" doesn't capture what the analogy is saying.
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.
You can do that with almost any language. The analogy holds in that you can't get underneath JS in a browser 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 clearly was a language that was designed to be written directly.
The analogy holds in that you can't get underneath JS in a browser
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.
Knowing the ins and outs of the DOM API implementations can get a bit arcane but optimizing JS is mostly about work avoidance and making sure you know how to make the native-code-implemented methods work for you to avoid putting extra work on the JIT/interpreters. You have to maintain a knowledge-base to be strong at it, but it can be very rewarding to see how much more you can get out of your code with a little bit of thought and study. The analogy also holds in that JS is extremely flexible and denies you very little. You can design and code to most any paradigm you want although I suspect attempting to implement static typing would get a little silly where numbers are concerned.
There's a reason why Flash has mostly been relegated to video, audio, and games, and it's not because Flash integrates so seemlessly smooth with websites. Javascript is in the bones of the web, Flash is just a layer on top.
What powerful drugs they're using to produce such great distortion of reality? ^_^
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)
Pretty sure you're getting downvoted due to the insinuation that the legends of JavaScript aren't thinking clearly due to drug use. You could just address their points directly if you think they are misguided.
The most interesting insight is that because JS is higher level than Java bytecode, it avoids some of the lower-level compatibility issues, which actually makes WORA easier, even when considering JS a VM language.
Yeah, I just listened to the entire podcast on the subject, and this whole "JS as assembly" is just dumb. The guy seems utterly mixed up about what JS, assembly, and IL represent.
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.
What do you mean? I think you might be missing the point. ECMAScript 3 is almost universally supported to the letter and will continue to be for the forseeable future, just like modern x86 processors are backwards compatible with the ABI from decades ago, and hence is a rock-solid foundation for projects like GWT that compile to it.
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;
JavaScript is to ??
So in this case it would be wrong to say that "??" is the JavaScript interpreter, because assembly language is a representation of machine code - it's basically an set of labels attached to binary numbers right?
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:
JavaScript is to a JavaScript interpreter as;
x86 machine code is to an x86 processor
Then:
x86 assembly language is to x86 machine code as;
?? is to JavaScript
Now one could argue that CoffeeScript is the assembly language of JavaScript (I've not used it but it seems to be a roughly 1-to-1 mapping of one set of instructions to another, aliased for aesthetic purposes).
But getting back to the original analogy, I think it would be better stated as:
If you think of a web browser as a kind of computing platform for which we can write applications, then JavaScript is like the machine code that makes it run.
I think that makes sense - and it also makes sense to build higher level languages on top of JavaScript in that case, since increased computing power has always enabled us to get more done with fewer man-hours, why should this be any different?
You're really torturing the analogy there, aren't you?
Rather than take it literally, let's restate the analogy to better capture the intent: If you want your language to run on an x86 processor, you should compile it to x86 assembly and if you want your language to run in the browser, you should compile it to Javascript. Simply put.
There was a time when many "alternate" languages compiled to C instead of directly to assembly (e.g. early implementations of Eiffel). If this were still the trend today, then the analogy would better be stated as "Javascript is the C of the cloud".
(as an aside, I've been saying that "Javascript is cloud assembly" since late 2008...)
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.
Right now people are really excited about JavaScript and begin to use it for things that are less and less appropriate for it. Yes, you can compile languages into JS, just like you can use XML to generate an SQL query. But is it really a good idea?