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.

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?

No, we don't

[BenJeremy]

There are far too many choices now. Most of them only differ in minor semantics, but it is enough that it makes porting already well-designed code a pain. It also muddles education and opens opportunities for countless security holes through exploits.

What we need is a "golden ideal" language - which may not be possible, but if we could whittle it down to three or four special purpose languages, optimized for specific uses, and a solid general-purpose language, we'd have an ecosystem worth contributing to and using.

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.

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.

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: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: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.

language chest-thumping

[Anonymous Coward]

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#.

So that'd be about five lines in awk, right?