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.
"[H]aving a clear trust demarcation between real programs and web-based scripts is not a design flaw."
Words to live by, except that I would expand that statement slightly to say having a clear trust demarcation between the _hosting system_ and the _application_ is not a design flaw.
To thee I raise a pint!
What you describe is exactly JIT w/o recompilation (i.e. deoptimization/optimization cycles). FYI, GC is optional to JIT. GC however is a true blessing for any multithreaded code where detecting liveness is pain in the butt.
Actually GC is a true blessing anytime.
Read-barrier GC may make sense for fluid user experience (i.e. no freezes due to STW [stop the world] GC) but it's a hit in the benchmarks since each load has to be verified.
Sophisticated techniques like Escape analysis (escape detection) to reduce the amount of object created would most likely not worth but w/ enough core it might be useful via tiered compilation.
Good luck to Dart - strongly typed languages are much easier to reason in terms in corrects and static analysis.
Why is it "sad" ? JIT just adds complexity for very little to no advantage. If you really need profiler data, that could be distributed in a different file alongside source to give the compiler optimization hints.
Or the browser runtime could collect that profiling data and then do a recompilation of the source.
Plus, distributing some sort of semi-opaque Bytecode only helps to obfuscate code for commercial purposes.
Strong typing and proper classes are actually a feature of any sane programming language. JS does not provide this. You never know what to really expect inside an object. You will have a hard time to make any assumptions on the correctnes of your code based on this lack of invariants.
So, almost anything that is conventional and reasonable will be better than JS.
The funny thing is that everybody thinks it will have to adhere to the Java-esque ideas of "needs VM", "everything will be a heap object", "we don't need synchronous destructors" and so on. I call this Intellectual Shallowness.
1) Go to: USPTO search
2) Query: in/Bak-Lars (where did they get that syntax?)
3) ???
"Method and apparatus for reducing memory usage by encoding two values in a single field"
"Mixed execution stack and exception handling"
"Method and apparatus for performing byte-code optimization during pauses"
"Method and apparatus for concurrent thread synchronization"
"Method and apparatus for implementing fast subclass and subtype checks"
etc...
Sigghhhh~
Who (but Google) is going to support this?
Does anyone fancy writing code for Chrome only, or are we expected to write systems twice (once in js, once in Dart)?
We're just getting rid of the last bone-headed round of browser lock-in (IE6 I'm looking at you).
Let's not start that again.
Still at least its better than Google's Salt idiocy (and how is Google Go doing?)
is that if you cant be arsed to learn the ones available you've got properly you can always write another one.
The real trick is to get involved in ECMA or ISO to make sure that someone else's language doesn't achieve nirvana before yours gets ignored.
We are continually reinventing the wheel using shit graphics programs running on the spare CPU cycles on our matter transporter while people argue over what colour wheels the matter transporter should have.
The thing with Google is that they have a bit of a lot of 'previous', when it comes to announcing "The Next Big Thing" only to abandon it again, a few months or years down the line. Not such a problem when "The Next Big Thing" is something fairly trivial like Wave, but when "The Next Big Thing" is something as fundamental as a replacement for JS, I'd be pretty surprised if there's much of a stampede of folks willing to invest the man-hours in learning it, before it's gained traction.
And it won't gain traction without a stampede of folks willing to invest the man-hours in learning it.
>The thing with Google is that they have a bit of a lot of 'previous', when it comes to announcing "The Next Big Thing" only to abandon it again, a few months or years down the line.
You could interchange Microsoft with Google in this statement (see Silverlight, WPF, and soon to be TIFKAM)
With JavaScript I reckon there are two concepts the programmer has to understand:
- The various Document Object Models.
- JavaScript syntax.
Plus the fact you can insert JavaScript (seemingly) anywhere on a web page.
I would like a bunch of getters and setters for DOM elements and Dart offers this.
With JavaScript I reckon there are two concepts the programmer has to understand:
- The various Document Object Models.
- JavaScript syntax.
And a few other things, one might hope, such as the HTML and CSS standards, Javascript[1] semantics, good UI/UX/UIM practices, etc.
I would like a bunch of getters and setters for DOM elements and Dart offers this.
As do a zillion ECMAScript frameworks and libraries. True, the vast majority of them are horrible code written by people who can't be bothered to understand the language (hello, JQuery), but there are a few decent ones, and it's hardly difficult to write your own, if you have actually learned the subjects listed above.
And why is it useful to free developers from having to learn about the DOM? Do we really need more software written by people who don't understand what they're doing?
[1] Actually ECMAScript, which is the name of the language. "Javascript" is the proprietary, non-standard ancestor of ECMAScript, or the name of one ECMAScript implementation. The camel-case "JavaScript" is a typographic error or barbarism.
Speed obviously isn't the selling point for this: twice as fast means about one generation of mobile phones and that in a small part of user experience. Offloading stuff to hardware via, say WebGL or CSS, brings a lot more. It's far from perfect but the slow and steady development and adoption of HTML 5 (including CSS and JS) is gradually moving things along.
After keeping up with Dart progress for the better part of it's lifespan, I can see why hard core developers would like the concepts it bringing to the table for web developement. However, aside from the performance gains, most of what dart would deliver can already be done with existing stuff. For example, for structured development GWT/GXT presents a much better option since all the knowledge, tools, middleware etc ... are already entrenched.For more basic needs, there are enough JS frameworks and planned language additions to fit most people needs.
So the question remains, is there enough developers from those 2 camps who will by into Dart?
I'm a Java and Android developer but I want to get into HTML 5 development because Mozilla OS for mobiles sounds really interesting. However JavaScript is chaotic compared to Java.
With Dart, the idea of writing a single program in an object-oriented language that is referenced by a web page, just sounds really appealing.
And the learning curve, with regards to the syntax seems straight forward.
I reckon there are a lot of Java and C++ programmers out there who feel the same.
P.S.
There's the likelihood that Dart will be supported by Android and suddenly 75%+ mobile devices around the world are compatible with it.
Dart's problem is that there really is no advantage to using it over Javascript and it's not supported by ANY current browsers. Google can't just force everyone else to support a new programming system, this should have all gone through a standards body. That way we could be seeing support in all major browsers.
As is, I'm not going to use it in any production projects. It's just a toy at this point unless it gets picked up by other browser vendors.
P.S. Python whitespace is it's biggest issue, but not it's only. I've seen it used for everything from web apps to full graphical client apps and I think it's biggest issue is that people use it for things it was never designed for. If you're doing a web app, a system designed for web apps is the way to go and for complex client apps python's performance is just too poor.
One of the things that make Javascript weird, especially for newbies, is that the DOM manipulation (getting and tweaking HTML and CSS information) and browser events appear inexorably tied in with the language semantics - they really aren't, but the only real gateway to the DOM is via Javascript (unless you are writing browser-specific add-on's).
To be a bit Pollyannaish, maybe the browser manufacturers could agree upon an interface implementation that just was about DOM access, manipulation and event notification; and leave the language semantics and constructs at the "plug-in" level, triggered by script tagging. If you want to implement PERL or PASCAL for the browser, go for it. Grammar, punctuation, white space handling, collections, variable naming, whatever, the browser should not worry about it.
When the browser comes across a type attribute in a script tag it hasn't encountered before, the browser can prompt the user to download or find an appropriate plug-in. Embedded scripts would have to play nice with HTML syntax and grammar, but external scripts can use whatever markup they want.
Security? Well, scripting languages can't do anything with the underlying system that the browser doesn't allow (i.e. no unlimited file system or device access), same as today. Browser manufacturers would have to do some work to make sure that the sandbox scripting engines would play in would be sufficiently isolated from the file system, heap, etc.) . This approach may be somewhat in line with the "browser is the OS" meme that Google pushes, but in any sophisticated website, the browser really is acting like a very limited OS. I don't have a problem with that as long as the limits are well defined, understood and complied with (no nasty ActiveX-like shenanigans please).
Mine's the one looking for his "Python for Web Pages" O'Reilly book...
Google have the power to make Dart an important web technology just by implementing it in Android.
The desktop computer is circling the drain. HTML 5 apps on mobile devices will become more important, especially with the release of Mozilla OS.
If Android integrates a Dart VM then I reckon Mozilla will have to offer it on their mobile OS.
Side effects are why we write code. If not for them, execution of a program would have no observable effect in the outside world. On the other hand, side effects don't tell you all there to know is about the internal state of an object. So debugging (or optimizing) based upon side effects alone is incomplete.
From the Dart documentation:
Here’s another example of code that behaves differently in JavaScript and Dart:
if (1) {
print('JavaScript prints this line because it thinks 1 is true.');
} else {
print('Dart in production mode prints this line.');
// However, in checked mode, if (1) throws an exception
// because 1 is not boolean.
}
Dart has got to be the only language going that thinks that 1 is not true. Every single time someone invents a new language, they always manage to fuck it up by doing something different and unexpected, resulting in years of errors and frustration by developers. The choice is arbitrary - make it do it the same way as everything else and people will understand it. Do it differently for no reason, and nobody will buy into your spangly new language.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
