Google Engineer: We Need More Web Programming Languages

itwbennett (1594911) writes Web applications may one day surpass desktop applications in function and usability — if developers have more programming languages to choose from, according to a Google engineer. 'The Web is always available, except when it is not,' said Gilad Bracha, software engineer at Google and one of the authors of Google Dart, speaking to an audience of programmers Wednesday at the QCon developer conference in New York. 'It isn't always available in a way that you can always rely on it. You may have a network that is slow or flaky or someone may want to charge you.' Therefore any Web programming language, and its associated ecosystem, must have some way of storing a program for offline use, Bracha said. The Web programming language of the future must also make it easier for the programmer to build and test applications.

Comments

Why?

[Anonymous Coward]

any Web programming language, and its associated ecosystem, must have some way of storing a program for offline use

So what's the point of this being a "Web" language? Why not just keep downloading apps like we always have?

Re:Why?

[putaro]

Those do exist, for example Google Web Toolkit (GWT) which spits out Javascript and HTML from Java code that you write and manages the communications between the Javascript in the web page and the Java code running on the server. There are difficulties, though, because Javascript and HTML are really kind of sucky for running GUIs and it takes tweaking to get everything looking good in every browser.

Personally, I think that running complex applications inside the browser is just plain stupid but it keeps on getting pushed at us.

Re:Why?

[jythie]

Because developing new languages and ecosystems is fun, sexy, and gets you attention. Working in old fuddy languages with rich existing support requires reading books and bowing to other people who have already figured problems out. Bad for the ego.

Re: Why?

[jd2112]

The API of the current version is quite large, but the next release will be smaller. By version 2.0 they expect to have it down to a few pages.

Re:Why?

[Chris Mattern]

Note that Gilad Bracha is working on Newspeak, which will probably be as close to an ideal web language as one could hope for - once it's finished - and not only in the matter of containment.

It's doubleplusgood!

Re:No, we don't

[mwvdlee]

There are far too many choices now.

JavaScript and VBScript.
I agree there is atleast one choice too many.

Translation

[NotDrWho]

Translation: Google is about to introduce yet another web language into this Tower of Babel

Re:Translation

[NatasRevol]

It should be called the Tower of Babbage.

Re:No, we don't

[MatthiasF]

A Google engineer that designed a web language no one wants to use much less need, gives a talk about how the web needs more languages.

Part of me wants to think the guy is just nuts but this is starting to seem like a trend from Google.

They try to create a many options/products as possible to weaken established standards and then take them over with half-assed efforts that never work out.

The good thing about standards...

[menkhaura]

The good thing about standards is that there are so many to choose from.

Re:What is needed...

[jones_supa]

Yeah, I agree. The first thing to do would be to reinvent the web browser. I guess HTML would still suit for displaying static content, but all the interactive stuff is like rockets duct-taped on a stone-age sleigh.

Oblig. xkcd

[Anonymous Coward]

http://xkcd.com/927/

We don't need more languages, we need bytecode.

[goruka]

Web browsers should at this point be able to parse some sort of bytecode that can be translated to native. This way anyone can use whatever programming language he or she pleases. Google did a great work with PNaCL, but I don't think that will ever gain traction from the other vendors.

Mozilla's ASM.JS is much better idea and much closer to a real-life usage scenario, but Google itself is not doing enough to promote it and their support is half assed (even though It would definitely benefit them).

Re:We don't need more languages, we need bytecode.

[Qwertie]

I really don't agree with asm.js as the solution, although I do advocate a VM-based solution. asm.js is an assembly language inside Javascript:

function strlen(ptr) { // get length of C string
. ptr = ptr|0;
. var curr = 0;
. curr = ptr;
. while (MEM8[curr]|0 != 0) {
. . curr = (curr + 1)|0;
. }
. return (curr - ptr)|0;
}

Code written in asm.js is isolated from normal Javascript code and cannot access garbage-collected data (including all normal Javascript objects). I'm not sure it's even possible to access the DOM from asm.js. So, the advantages of asm.js are:

1. - Non-asm.js Javascript engines can run the code.
2. - "Human readability" (but not that much; asm.js is generally much harder to follow than normal code.)

A main reason to use asm.js is that you need high performance, but running in a non-asm.js engine kills your performance. Granted, performance isn't the only reason to use it.

But with most web browsers auto-updating themselves, there's no need to restrict ourselves to only JS in the long run. Whatever is standardized, all browsers will support. As for human readability, that's definitely an advantage (for those that want it), but [binary] bytecode VMs can be decompiled to code that closely resembles the original source code, as tools like Reflector and ILSpy have proven for the CLR.

The disadvantages compared to a proper VM are several:

• - Poor data types: no 64-bit integer, no vectorized types, no built-in strings.
• - No garbage collection.
• - No rich standard library like JS/Java/CLR
• - Ergo, poor cross-language interoperability (interop is C-like, rather than CLR-like)
• - Slower startup: the asm.js compiler requires a lexing and parsing step.
• - Extra code analysis is required for optimization. The code is not already stored in a form such as SSA that is designed to be optimized.
• - Code size will be larger than a well-designed bytecode, unless obfuscated by shortening variable and function names and removing whitespace.
• - No multithreading or parallelization.
• - Poor support for dynamic languages (ironically).
• - No non-standard control flow, such as coroutines or fibers or even 'goto' (some [non-goto] primitives in other languages do not translate to JS and goto may be the best translation).

If you add enough features to asm.js to make it into a truly great VM, it will no longer be compatible with Javascript, so the main reason for the Javascript parsing step disappears.

So as it is now, I feel that asm.js is kind of lame. However, it would make sense if there were a road map for turning asm.js into a powerful VM. This roadmap might look like this:

1. 1. Assembly language with very limited capabilities (today).
2. 2. Add garbage collector, 64-bit ints, DOM access, etc., with an emulation library for non-asm.js engines.
3. 3. Carefully define a standard library designed for multi-language interoperability but also high performance (don't just mimic standard Javascript).
4. 3. Define a bytecode form to reduce code size and startup time.
5. 4. Add the remaining features that are impossible to support in Javascript. Programs that still want JS compatibility can be careful not to use such features.
6. 5. Change the name: it's not JS anymore.

Re:Or maybe...

[BasilBrush]

I'm a old fogey. And I welcome new programming languages. Because the existing ones suck so much.

When do you suggest we should have stopped? With COBOL as the major language? or C? With PHP as the major web language? With PERL is the major scripting language?

Bring forth every language anyone wishes to invent, and let the good ones rise to the top.

Software quality is a different issue. And most of it is in unrelated to language. But on the language side, new languages can help. Take Swift vs Objective-C. Many or most fatal bugs and security vulnerabilities with C languages revolve around stray pointers, exceeding bounds, and omitting breaks in case statements or braces around if blocks. These are simply not possible in the new language. And thus software quality will be improved.

Re:No, we don't

[PRMan]

Yep, and even if you use the correct tool for the job people rewrite it anyway. I used XSLT to turn XML into a different XML. It was 20 lines and worked great. I came back later and somebody had replaced it with 2500 lines of C#.

Containment by default

[tepples]

Except once it's offline it's no longer contained...

How? Pretty much every major platform other than Windows desktop, OS X, and GNU/Linux has some sort of containment measure by default. This includes Windows Phone, Windows RT and Windows 8's WinRT subsystem, Android, iOS, and modern game consoles.

Re:No, we don't

[dgatwood]

A Google engineer that designed a web language no one wants to use much less need, gives a talk about how the web needs more languages.

Part of me wants to think the guy is just nuts but this is starting to seem like a trend from Google.

They try to create a many options/products as possible to weaken established standards and then take them over with half-assed efforts that never work out.

Even ignoring whether you trust Google to stand behind anything they throw out there, we really don't need more languages for web programming. JavaScript might have a few things that make it quirky, but it isn't a particularly difficult language to learn, and there's no compelling reason to use anything else.

The part of web app development that sucks isn't the language. It's the API. The HTML/XML DOM is a horrible way to design a UI, and browsers implement lots of things in different and inconsistent ways. For example, I once built a website that uses the HTML editing API, and found myself repeatedly adding piles of browser-specific workarounds. The worst was Internet Explorer, and it was such a nightmare that I basically gave up trying to make it fully work. But both Firefox and WebKit had serious bugs, most of which have still not been fixed (though a few of them have at least been fixed in Google's fork).

And that's the tip of the iceberg. While doing design work for an EPUB book, I found such fascinating bugs as:

• Safari/WebKit uses incorrect font metrics for web fonts, resulting in positioning being off by a couple of pixels (fixed in Google's Chrome Canary fork)
• Firefox/Gecko has a fascinating bug (989686) in which relatively positioned elements move around nondeterministically between reloads.

Almost every time I try to do anything significant with any browser (or with eBook readers based on browser engines), I end up filing five or six bugs against the browser, and although nearly all of them do get confirmed, within a small margin of error, none of them ever get fixed. All the while, these browsers keep getting new features, most of which are not fully implemented, most of which are just as fragile and buggy as the previous features that I filed bugs about, and we're trying to build apps on top of that mess. It's like developing for an early beta of an operating system, only the OS never gets out of beta.

That's what's wrong with writing apps on the web. The d**n browsers suck. They all range from horrible to utterly catastrophic. And that's me putting a positive spin on things. So before Google wastes a lot more time creating new languages that don't fix any real problem, thus adding yet another major browser feature that will only halfway work just like all the others, they and other web browser manufacturers need to take the time to fix the steaming dung heaps that they call browsers so that every single &^$@#(&^@ web programming project doesn't require me to spend 75% of my time working around browser bugs.