Google's JavaScript assassin: Web languages are harder than VMs The problem with programming languages is that everybody’s got an opinion - just ask Lars Bak, the Virtual Machine guru who is building Google’s planned (by Google at least) replacement for JavaScript. Bak has spent 15 years working on object-oriented VMs (virtual machines) at Google and Sun Microsystems and notched up 50 …
We've ended up in the slightly surreal situation whereby javascript has become some sort of web assembly language... there's a vanishingly small chance of anyone agreeing on upgrades to javascript or substantially different new platforms, so instead we're ending up with languages like Typescript and Clojurescript and Coffeescript which "compile" to javascript because most people actually have browsers which support it.
Seems daft, but at least you have a bare minimum of choice and can reasonably expect to be able to run your code on most browsers. A new VM, supported by Webkit, Chromium, Mozilla and Microsoft? I'm not going to hold my breath.
" there's a vanishingly small chance of anyone agreeing on upgrades to javascript"
Indeed, but it would be nice to have something supplant or rather compete with JS in the browser (so long as it looks and smells nothing like that VBScript abomination).
It would be nice to have the option of prototype and OO. But the chances of it happening wholesale and any-time soon are slim to none - more's the pity.
I for one fail to understand why so many developers out there are so mentally entrenched with JS that they decry any effort to introduce anything new.
I for one fail to understand why so many developers out there are so mentally entrenched with JS that they decry any effort to introduce anything new.
Stockholm Syndrome? ;-)
No... this is just corporate politics at work. Look at the brouhaha around Javascript 2/ECMA script 4.... same arguments about develepers but largely not by developers.
The cynical side in me also wants to point out that current web "standards" like javascript and CSS and the like have "less than brilliant" compliance across all platforms. Adding a new and complex standard like a new bytecode language? Even if the big browser manufacturers wanted to support such a thing, do you suppose they'd do a good job of it?
"The cynical side in me also wants to point out that current web "standards" like javascript and CSS and the like have "less than brilliant" compliance across all platforms. Adding a new and complex standard like a new bytecode language? Even if the big browser manufacturers wanted to support such a thing, do you suppose they'd do a good job of it?"
You know, I could not agree more with everything quoted above. But are they valid reasons not to pursue such a goal? I'm not so sure. Is JS the pinnacle of what client-side could be? Far from it!
Either way, I would still like to have the option of prototype and OO and think it's a goal worth setting.
> Another VM just sounds like JVM, Flash, Silverlight etc and will end up with the same problems.
There is a difference. If it also compiles to javascript, then you only write once and just load either dart or JS into the browser an request. The VM's mentioned above have platform limitations.
Google has enough of the browser market via chrome and (more importantly) android to make this work. This might make web apps (which are horrid enough on a pc) work faster so mobile devices can run them.
As long as it compiles properly to JS as well, google can afford to go it alone. If gmail runs faster under chrome than anything else, so be it, hotmail doesn't need to come along for the ride. You might eat more memory running a JS VM and a Dart VM, but memory is cheap.
The aim of dart/NaCl etc is to get web apps running at a decent speed to bypass MS' grip on the desktop.
Too many dickheads at companies like Google, Microsoft and Apple that's why.
Look at what happened with HTML5 video, nobody could agree on a standard. Google pushed their standard against Apple and Microsoft.
What should have happened is a central impartial organisation should have proposed it and everyone adopt it.
Google will push a standard which gives them some control or advantage over Microsoft and Apple. Microsoft and Apple will do the same.
A language-agnostic browser VM sounds like an excellent idea. The variety of languages targeting JVM, which was probably never supposed to be language-agnostic, suggests this would be very productive approach.
One would also hope that such a VM could take care of the security issues that are always lurking in the shadows when programs run in the browser.
LLVM isn't really a VM per se as set of portable low level instructions which can be translated into an equivalent set of native instructions. So a browser could download bitcode and compile, cache and execute the native or it could run the bitcode through a JIT compiler each time. It could also instrument the native code with any security checks it liked to keep the app in a sandbox and prevent it busting out.
Browsers *really* need something like LLVM. It's crazy that tools like Emscripten, GWT etc compile one language into a scripting language where performance is really awful. If code were compiled to bitcode it could run at near-native speeds and do so in a way which is browser and OS neutral.
Google promised something called PNaCl for ages which would implement LLVM in their browser. It's emerging from development but it's still too early to say if it's portable to other browsers, or even if they'd be inclined to support it. I doubt Microsoft or Apple would support it though Mozilla might.
Regardless of politics this is something that browsers really need.
Well, Java proves to be a bug-riddled ball of crap, worthy of M$. There is little hope it will ever be reasonably secure to run untrusted code. JS suffers from too many bad design decisions.
A memory-safe language is required, so they create one of their own. Sounds reasonable. I do think, there should be more attempts like this to fuel the fire of language darwinism.
Picture: A fire of burning language specifications.
"FAMILIAR
Dart is a class-based, object-oriented language..."
I dunno, in a language where strings and numbers are interchangeable to some extent (eg you can add them together), then it makes sense that if 0 resolves to false (as it does in C/C++), then so should "0".
Having said that, it's about time we had a decent, fully oo, client-side scripting language.
JavaScript is a dynamically-typed language.
"0" == false is a natural consequence of dynamic typing. To avoid it you have to add complexity by making booleans a special case or reduce flexibility and eliminate them entirely.
Dynamic typing is annoying, but with JavaScript being heavily built on associative arrays it makes the language very simple.
Point taken. It could be that Dart is running 130% faster but the target is twice that. Or it could be 30% faster but the target is 100%. We'll go back to the source to check this one.
PS: On busy days thousands of comments are posted; we never get the chance to read them all so problems like this can go unnoticed. If you hit the corrections button on the article, we'll be able to fix problems immediately :-)
C.
1. Netcraft hasn't even bothered mentioning them since 2003:
http://news.netcraft.com/archives/2003/08/30/php_growing_surprisingly_strongly_on_windows.html
2. According to w3techs "the" server-side scripting of the late 90s now powers just over 1% of dynamic sites:
http://w3techs.com/technologies/overview/programming_language/all
and
3. That's in steady decline:
http://w3techs.com/technologies/details/pl-coldfusion/all/all
"syntax-significant whitespace always gives me the heebees......"
Seconded. IMO its the one stupid design decision that stops python being a first class language. But unfortunately a language where accidentaly deleting a space or tab can change the whole flow of the code but remain syntatically correct has a major design flaw.
eg:
for i in xrange(1,10):
..func1()
..func2()
vs
for i in xrange(1,10):
..func1()
func2()
In a perfect world, *all* programming languages would decouple their source syntax from their semantic elements. How hard could it be to write a front-end that accepted curly braces instead of significant white-space and then fed the resulting parse tree to *exactly the same* compiler? Probably "very", in real life. How hard *should* it be? Probably "trivial", since the formal tools for this were developed 50 years ago, by language designers.
In fact, my new figure of merit for whether to take a new language seriously is "Does the default distribution come with multiple front ends to accomodate the various syntax prejudices of the programming community?". If not, I'm not interested. :)
I'm with you. In fact when I'm king, they'll be universal interpreters and universal compilers. If you're writing an interpreted programming language, it'll just be a wrapper and you'll hook it up to one of the universal interpreters using some standard protocol/api/whatever. The universal interpreter can hook into universal standard libraries SO THAT EVERY FUCKING LANGUAGE DOESN'T HAVE THE SAME CORE OBJECTS WITH SLIGHTY DIFFERENT METHOD NAMES/SYNTAXES.
The problem with that is that it would come at a severe performance cost, hence why it's not done. Designing a language is much, much more difficult than using one. I'm assuming you didn't take Programming Languages in College? Because if you had, you'd realize that your point is absurd in real life, even if it does sound nice on paper.
I agree with you, but this is less true with properly OO languages, where differences in syntax hide a much bigger underlying similarity in function. Look at Smalltalk - in one sense (class libraries) it is absolutely enormous but in another (syntax) it is minute - it doesn't case statements, if-then-else or loops.
The only thing wrong with Smalltalk bytecode is that it was not secure, and that was, if I recall, one of the underlying principles of Java bytecode design (not that it worked completely). A standard bytecode into which a bunch of different OO languages could be safely compiled would be a wonderful thing.
>Curly-braces!
Curly braces always give me the heebeejeebees.
I'm left handed, and a touch-typist from age 8. It was years before I relealized that one of the reasons I hate curly-brace languages is that those keys for which I use the Little Finger on my Right Hand, are actually the slowest and most difficult keys on the keyboard for me.
And, of course, as a long-time touch typist, I'm not appalled at the effort of typing
Begin End
.OR.
Balance equals Balance plus ItemCost
(astute readers will have noticed that I put a decimal point on either side of that uppercase OR...)
Ditto.
"side effects" is the term used by most language designers to refer to "evidence that your program is actually running". If a block of code has no side-effects, the optimiser is allowed to remove it. If two blocks have the same side effects, it is allowed to pick the cheapest one. Side effects are not equivalent to bugs unless your code is 100% bug.
I have to quibble with this.
Side-effects refer to effects a method or function has other than its return value. A common best practice is to eliminate all side effects b/c it makes the code a lot easier to test.
Of course, at some point your code has to have side effects - it has to draw on the screen, or send packets, or whatever the point of the program is. However, the core of the program can still operate "without side effects."
* Don't use a VM. Compile stuff directly into machine code. All of it..
* Allow for synchronous destructors and refcounted pointers.
* Free yourself from the retareded ideas of Mr Gosling and the other academics. These will only generate bloat and crappy user experience.
Basically, make it a memory-safe Delphi/TurboPascal variant. That will both compile extremely fast and the program will run very efficiently. No random freezing.
Replies?
A not-so-retarded academic designed Pascal, oh not-so-clever opinionated one.
Personally, in an environment as malware-hostile as the internet, I rather like VMs and rather dislike the idea of machine code being generated and blindly trusted to execute safely. But that's just me.
That's also the reason I rather like JS - the browsers do not trust it. Java on the other hand is handed over to a real VM which is trusted, with disastrous results. Raw speed is not always the most important thing and having a clear trust demarcation between real programs and web-based scripts is not a design flaw.
errm, we "need a VM", because bytecode has proven to be more secure than distributing source ??
Java ans JS just proved the opposite. And, engineers at Borland made lightning-fast Pascal Compilers. The idea came from an academic, though.
The truth is that the JVM (and probably also the current JS ebńgines) are extremely complex pieces of code. And they are laaarge. That creates a huge attack surface. Too big for Oracle to secure.
I bet you could create a very secure and fast compiler for a memory-safe Pascal variant in less than 30K lines of C++ code. As opposed to millions of loc for the JVM and JS engines. The generated code would be highly efficient without much optimization.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
