fredag den 23. september 2011

Google Dart interview

UPDATE: This blog post has moved to

On the 10th of October Lars Bak and Gilad Bracha will reveal the new and exciting Dart programming language for the web. This will be revealed in the opening keynote at the GOTO Aarhus 2011 International Developer Conference. After this interview I might get a chance at interviewing them about this subject and publish it on the GOTO Today Blog. Here is my draft brutto list of questions to ask - please help me add other exciting questions.

How will you sweet-talk other browser vendors?
Have other browser vendors already accepted to implement a Dart VM in their browsers?

Tool support
When will Brightly (the IDE for Dart and other web development) be released?

Language paradigm
Structural programming language - Why did you choose this programming paradigm? Why not the functional programming paradigm with its side-effect free programming? Or what about actor based programming like Scala, Erlang (Erjang) both paradigms are inherently designed for concurrency?

Language details
Where can I learn about the language details?
When you designed the language syntax and semantics, were you at any point disagreeing on what a particularly language construct should mean and/or expressed?

The language is optionally typed. This seems to be the type system of choice for new programming languages. But what about performance? Isn't easier to create a high performance VM with a statically typed language?

VM details
What about garbage collection - algorithm, memory management (heap, generations,???)

Why keep it a secret for so long? To create a hype about it? Or to gain a technical lead? Or ...?

Unrelated to Dart
What is your biggest aversion, if any, in modern software development?
What do you typically do when you're stuck with a computer science problem?
"Do no evil" is, I believe, the motto of Google. Is it possible for a large company, like google, to fulfill this motto.

6 kommentarer:

Suheimi sagde ...

Why hiding the development, hiding technical detail, etc, creating unhealthy debate in the web? Marketing gimmick?

Simon Hem Pedersen sagde ...


Thanks I put that in the pool of questions. I think one of the possible answers to this question might be that google want to ensure a technology lead. But it might also be to get more hype about it. Reading this document reveals some more information about the motivations for the new language.

Osvaldo Doederlein sagde ...

I guess the initial, closed development is just a design option - have a first cut of the language authored by only one or a few designers, instead of suffering of design-by-committee faults... not to mention that existing committees / forums that would likely be involved, are the same ones that take care of EcmaScript today, so they would naturally try to either avoid a competing language or make it be an evolutionary update of EcmaScript. So the only way to break this barrier is by imposing a consummate fact - showing off their vision already (roughly) designed and implemented; maybe with some cool introduction benchmarks and demos that show performance or other advantages that EcmaScript can't ever hope to match. So, I guess the interesting question to make here is how much Google plans to open Dart; there is a spectrum of models, from "benevolent dictator" (keep doing all design but share code and allow external contributors who agree with Google's governance), to "full standards player" (contribute the debut release to W3C or some other group and from now make everything in the open).

Alexandre sagde ...

A few ideas of questions about DART:
Status of the VM that will be released:
- Performance comparison to the current JS engines?
- Supported architectures?
Details about the language targets:
- Browser only? Android apps?
- Alternative to Java for legal reasons?
And above all:
When can we play with it?!

Anonym sagde ...

How they'll face (or ignore) the problem that led them to want/need to create another language? Namely, the difficulty to change and adapt JS's language, runtime, semantics, environment, etc to one's need (sure enough, following the common approach for designing a programming language implies hardwiring tradeoffs in it, causing future versions of Lars and Gilad to want to create yet another language because of those unwanted hardwired design decisions). Any strategies here? (Meta[object] protocols? Stratified design approach? ...)

Simon Hem Pedersen sagde ...

From Google+ by Ulrik Skyt:

"Have you had any success sweet-talking the other browser vendors so far?"
"Will an efficient, full-featured backend appserver/VM be available that is independent of Google infrastructure (like AppEngine)"
"Is Dart (or when will Dart be) ready for production use?"
"How does Dart compare against J2EE on the server side?"