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?

[jythie]

The quest for a 'perfect' language generally just results in people taking perfectly good languages and complicating them to the point they start handling their intended function worse and worse.

Yes, developers SHOULD have to choose. When you are dealing with drastically different contexts and environments there are going to be trade offs. We could potentially make languages look the same through similar syntax, but they are not going to be the same language and should not be.

As for why the browser only supporting one language, well, because it is simpler. Operating systems only support one language too, machine code. Everything else is translated into that language in order to run.

Re:Why?

[drinkypoo]

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

The obvious answer is to make the browser better at running complex applications. There is obviously a need for a browser which can run complex applications.

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?

[Chelloveck]

Genuine question, here, since I've never done any web dev. Why not write libraries in an existing language that spit out HTML/Javascript/PHP/whatever? Why do we need a new language to do this?

On the server side it's already pretty easy to use whatever language you want. There's the CGI protocol that gives a well defined interface between the server and any arbitrary program running as its own process. Most servers also have a way to run code in written various languages directly without the overhead of spawning a new process to do it.

On the browser side you have Javascript and... Well, that's about it really, unless you want to rely on browser plugins. Some browsers on some platforms can handle other scripting languages, but they tend to be vendor-specific like VBScript. If you load a browser plugin you can do anything you want, but it's not going to be all that portable. And, as we've seen with Flash and Java, they can open up new and interesting security holes.

Javascript itself is kind of a mess. It's inconsistent and has a lot of pitfalls that can trip up the unwary. I don't think we need more languages necessarily, but we could certainly use one good language. Of course, you'll never get developers to agree on what that good language is, and by the time it makes its way through the standards committee it's going to look an awful lot like Javascript. The big problem with defining a new language is that it needs to be in all the browsers before it's useful to developers. Developers won't adopt a language that's not widely deployed in browsers, and browser vendors won't bother to implement a language unless there is a critical mass of developers for it. So at this point we're pretty much stuck with Javascript.

Microsoft actually had a good idea at one time, which was to define an interface between the browser and an arbitrary external scripting language. You could (and probably still can) write Perl or Python code and execute it within Internet Explorer just like Javascript or VBScript. Of course that required the user to install the particular language you wanted, and calling out to an arbitrary external language opened up a ton of security holes. It wasn't very useful for web-based scripting. It was pretty good if you wanted an easy way to add a GUI to a local script, though. I used it to write a few quick-and-dirty prototype apps in Perl with an HTML GUI about 10 years ago. In fact it was good enough that I had a hell of a time convincing our sales guys that it was not a finished product they could sell.

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:Why?

[QilessQi]

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 userpost antethis
newspeak proglang doubleplus ridiculous namewise: specdocs unmention mathop "++"
replace fullwise with plusfull syntax:

      it = ++good

oldthinkers unbellyfeel newspeak.

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.

useless buzzword for marketing only

[sageres]

"Web programming language is a buzzword that I heard before since 1994-1995 over and over and over and over and over again. Here is one joke about one of the "Web programming languages" from that era:

--Knock knock!
--Who is there?
--... (wait one minute before replying... And then:) Java!

But for some reason, every declared "web programming language" seem to not having universal adoption.
Question is: Why, and why are they talking about it again and again?

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:No, we don't

[SirGeek]

I thought that was what Java was "supposed" to be. Write Once, Run anywhere ?

Oh yeah.. That's right... 99% of programmers ONLY write for their target... Use libraries designed for their preferred target and can't even bother to test the damned thing...

And I've been programming around 33 years (As a professional for about 25) so just a "little" familiar with what happens because of "I have this Tool (hammer) so every problem must be solved with it (everything = nail).

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.

Coming full circle

[H3lldr0p]

So how about that? A programming language that'll download and store a program for later use just in case the network connection isn't stable or available. Sounds good to me. Having more than one way to get a program is a great thing to do.

Seems to me that if I can't rely on my network I'd want some sort of storage media that'll let me back up or reinstall the base program. It should also be light and easy to transport with plenty of additional storage space, just in case of anything.

Seriously, the older I get the more I find out that everything old is new again.

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.

No problem

[PPH]

Some of our best CS minds are already working on it.

Desktop-Spoiled Users (Re:Why?)

[Tablizer]

This happens because the desktop UI has "spoiled" users and application requesters. We as developers cannot say "it can't be done" because it can be done and they've seen web applications or demos that do make their browser act like a desktop GUI.

However, the web standards are poorly fitted for desktop-style GUI's such that we have to "force it" with tricks and micromanaging low-level details with kludges, including dealing with browser-version-specific differences.

But forcing it results in a web application that is expensive to build and especially difficult to maintain. The result is that the requester balks at the initial cost, and then balks again when maintenance is an even bigger expensive headache. Thus, the requester is double pissed.

I believe it's time to rethink how web-served UI's are done. A new "GUI markup language" perhaps should be invented that does most of the common desktop-like GUI idioms declaratively (as markup) to reduce the need for direct GUI coding in JavaScript or whatnot.

Java applets and Flash gave of a taste of GUI-centric engines. But applets have awkward API's and don't integrate well with existing HTML browsers. Flash provided decent GUI's and API's, but Flash is proprietary, limiting its reach, and also suffers from the HTML integration problem.

A key lesson from Java and Flash is that a new GUI markup standard is probably going to have to be a super-set of HTML so that the HTML content and the GUI content don't have to run on different engines or panels. Hopefully it will also have an open-source version.

Re:Or maybe...

[BasilBrush]

I didn't make any such blanket assertion. I pointed out that Swift in particular doesn't have the brain dead design defects of C, from which Objective-C also suffers. It's a language specifically crafted to do what Objective-C did previously without all the C crap. Crap that causes many or most bugs in C language programs.

That does nothing to say that BASIC is better or worse than any other language.

And bounds checking and preventing stray pointers is certainly not "safety features de jour". No more than keeping rats and cockroaches out of restaurants is "health standards de jour".

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?

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.