More Info On Google's Alternative To JavaScript 247
I'm Not There (1956) writes "Last week the news came in that Google is supposed to unveil 'Dart,' a new programming language for browser-based apps. Now an internal email from late last year describes this project as the 'high risk/high reward' path [of Google's browser development strategy]. Apps in this new language will run in a VM on browsers that support it, and can be translated to JS for other browsers. 'Performance, developer usability, and ability to be tooled' are the main characteristics of the language."
The email notes that Google will be working on ECMAScript Harmony in the near term, but they describe the project as ultimately doomed by "fundamental problems" with ECMAScript. It's interesting that Google took part in abandoning ECMAScript 4, which would have been almost fully backward compatible with current implementations while solving most of the "fundamental problems" Google claims require a brand new language to fix.
Lua would be better (Score:5, Interesting)
Lua [lua.org] is very Javascript-like already except it's very small, simple, clean, and fast. Much faster; LuaJIT [luajit.org] is incredible.
And when JS suddenly seems viable (Score:5, Interesting)
It's interesting that this should come about when Javascript seems (to me) to be undergoing quite a surge.
The community has carved out a set of practices that makes Javascript pretty satisfying to work in -- Crockford's efforts, the require/export conventions etc.
Callback oriented programming habits learned in the browser with jQuery (etc.) have shown that Javascript lends itself quite well to that style of programming. Underscore has promoted a functional style.
Node.js seems to be more popular than forebears such as Twisted, presumably because of all those JS-in-the-browser programmers who can apply their callback habits to Node.
CoffeeScript is there for people who want a more expressive syntax. ... and just as people are coming around to the idea that JS isn't that bad after all, Google says "nah, it's irredeemable"
Makes sense (Score:5, Interesting)
Javascript is something of an accidental success. As with many languages before it, its users valiantly cope with its flaws and do their best to dress up the squalor they live in, but it's not funny for Google anymore. They have to develop, maintain, and test one of the largest JavaScript codebases in the world, and the it's-the-90's-and-I'm-high-on-cocaine-at-4am-and-it's-due-tomorrow scripting language design philosophy is not helping them. In fact the story of the last few years has been the quiet proving out of the "extra keystrokes for correctness" paradigm, from simple assertions (including "type assertions" aka good old fashioned strong typing) to unit tests to highly complex integration tests of harrowing complexity.
If I understand correctly, Google already writes much of their JavaScript in an intermediate language that adds certain features. They have long needed a compile step anyway for compression/"obfuscation" and I suspect it was a natural outgrowth of that. This appears to be another step in the evolution of that development pipeline.
There are many interesting developments brewing in the browser these days. I wish the browser guys luck, because I think have just a little longer to get their act together before the world gradually changes out from under them, and a purpose-designed, clever, far more powerful platform, such as Android or iOS, might actually start to change the web browser's position in the computing ecosystem. A modern scripting language is only part of the price of admission to staying relevant as a platform.
Re:Editorial Piece Angries Up My Blood (Score:4, Interesting)
The problem with the toolbox analogy is that your screwdriver never has to interact with your hammer. Software code on the other hand is notoriously bad at working with code from other languages, sure there's language bindings and and various ways of making them somewhat talk to each other but the cost of mixing languages is huge. It's more like building bits and pieces of the system to work on optical signals and the rest on electrical signals, not like pounding one nail and screwing one screw into a board.
It's very rarely you need a programming language to do just one thing, maybe they go into specialty or research projects but anything commonly used has to be a swiss army knife. Most of the time you want to ask "Can I add another tool to this knife?" not design an entirely new dedicated knife for that purpose. There's a place to mix products for a "best of breed" solution, but languages are not it. Your narrow choice of language is likely to fail as the project expands and it really needs other sets of functionality.
If you want to see a prime example of that, look at VBA projects that have run out of hand. Quite probably it wasn't such a bad choice for the original task, just tack on this little bit to Excel and it works. Then it grows and grows and all those limitations get very limiting and you're forced to rewrite everything. That's what happens with other narrow languages too, if you go beyond that scope it's very good at things falls apart. Not to mention all the indirect effects like the available employee pool and the complex skills required to take over.
That is why there's a very significant drop-off in languages. I'm not saying you should try making a square peg fit a round hole, but very often the languages you, the team and the company knows and is familiar with beats trying to get everyone up to speed on a new language. But that goes for everything, should you work within the system to improve it or outside the system to overthrow it. I guess it all depends on how broken the old system is but people have a tendency to idealize the system on the drawing board.
Sick of "Google is Evil" claims (Score:5, Interesting)
Google is not evil points:
* Google massively supports open-source software
* Google pushes for open standards rather than lock-in
* Google has fought for the defense of fair use
* Google has fought for net-neutrality
* Google provides free services
* Google is wiling to take a loss on products to provide these free services
* Google allows you to easily export your data from their services, and even fully delete your online data/profiles
* Google is the cloud services provider that doesn't claim to own your data
* Google is running a test in Kansas of gigabit internet for the whole town and another test of free city-wide wifi.
* Google is the only search company to fight censorship in China
* Google is the only search company that refused to hand over user data to the Bush Administration
* Google fought Brazil as well to protect user data
* Google developed an open-source phone platform and has been encouraging handset manufacturers to open up and let consumers flash custom roms
Google is evil points:
* The Google Map street view team recorded data on open wifi networks. If people didn't want anyone to know you have a wireless network, you can turn off broadcasting the SSID.
* Google eventually caved/compromised on one portion of net-neutrality. They have a joint proposal with Verizon that would ensure the internet itself is protected by net neutrality, but wireless phone providers would be allowed to provide unique content and services. Is this really all that evil of a compromise?
* Google hasn't released the source code of Honeycomb because they don't want the market diluted with phones with a bad phone stack, but has promised to release the source code of Ice Cream Sandwich when it comes out in October/November. Man, that really is evil!
Seriously, the assumption that Google must be evil just because they are a big corporation is a flawed, simplistic view. I'd rather judge them on their actions. And according to their actions, they are the only major IT company out there I would trust given that my alternatives are Microsoft, Amazon, Facebook, Apple, AOL, Yahoo, etc.