
Dart programming language design - ColinWright
http://www.johndcook.com/blog/2012/04/14/dart-programming-language-design/
======
gruseom
From Bracha's talk, it's clear that they're designing Dart not for themselves
but for what their imaginary average web programmer (who sounds like quite a
dull creature) will tolerate. That's why Dart is so Java-like, for example.
Isn't that a well-known path to mediocrity? Even Bracha doesn't seem to like
Dart very much - he just really hates Javascript. I wish they had instead
taken on the task of producing the greatest and most inspiring (to themselves)
web language they possibly could. Perhaps part of the problem, though, is that
they are language designers and implementors who don't actually write web
programs themselves.

Of course, Java was designed in such a way and became widespread if not
beloved. But then it too won what Bracha (in pooh-poohing Javascript's
success) calls a "language lottery", meaning it benefitted from an accident of
timing. Barring that happening for Dart, it seems unlikely that lots of smart
programmers will get very excited about it.

One interesting point in Bracha's talk: he mentions the Dart VM more as a
server-side platform - basically an alternative to Node.js - than as something
they would ship to the client in Chrome. The client-side story, at least for
now, is that Dart always compiles to JS. And he claims that they've already
got compiled Dart to be about as fast as handwritten JS, which is surprising.

------
lucian1900
I still don't get Dart. It looks like it has the worse bits of Java and
JavaScript, while only giving you minimal improvement in semantics.

Why bother with optional types (if you're enlightened enough to realise that
you can just throw them away, since they're not needed for optimisation) when
you could have richer compile-time contracts? Why bother with classes at all,
when you could just have prototypal inheritance + interfaces?

I don't quite get what the goal is.

------
luismgz
My first reaction to Dart was "jeez, yet another c-like, java[script] clone".
I hated it, I want a world without stupid braces and semicolons. It doesn't
seem to bring anything new to the table and it looks exactly like java, c#,
javascript, etc... and exactly for the same reasons (to be familiar for the
average programmer). Syntactically, it's dull and unexciting. However, on a
second thought, I changed my mind a bit. Like it or not, it has to be this way
to gain wide adoption and, indeed, anyone with experience in java or
javascript can get productive in no time with Dart. But what's really
interesting is the snaphot feature. Dart will load in milisecons in the
browser, making startup times irrelevant. It's also designed with performance
in mind, and it will have some features that will make it ideal for large code
basis and team work.

As for its boring syntax, this won't be a problem. Coffeescript demonstrated
that you can target a messy language and make it beatiful and fun. Dart
already has a "transpiler" for compiling it down to javascript. If Dart
becomes a good compilation target (and it looks so), people will start wrting
their own transpilers targeting Dart. The best of both worlds. As for the
concerns about the null chance of other browsers adopting Dart, this is a
battle they can't win. Dart will run everywhere, either on its own VM or
compiled to javascript. And it will lead to a situation where new applications
run on every browser, but "work best on Chrome". How long will the other
vendors keep on pushing a mediocre, substandard language such as javascript
when Dart is already making developers lives easier, and applications faster
and better?

------
sharmajai
_Type systems are a form of documentation, and they help enable programming
tool support, but their role in error detection is greatly overstated._

This is a blasphemy towards static typing. Whenever the size of a software
system stops being trivial, static typing is a must have to assume any kind of
robustness. I cannot think of refactoring thousands of lines of code written
in a dynamically typed language and sleep peacefully in the night. On the
other hand, I can rely on the linker/compiler errors to, at the very least,
flag any type misuse introduced due to my changes, in a statically typed one.

------
quink
> Application programmers, unless they’ve committed serious crimes, should not
> be forced to deal with [JavaScript etc.].

> We’re not out to take JavaScript away. We’re not that stupid. I personally
> if I could I would, but Google probably wouldn’t.

I know it's cool to hate on JavaScript these days. But it just doesn't deserve
it quite that much. And, wrong as that analogy may be, it smells like someone
coding mostly in C++ talking about why C sucks.

~~~
tomjen3
How much Javascript have you written?

This has dynamic closure. Everything else has lexical closure.

Vars can be declared inside a block but it has no effect, because they are
always scoped to the nearest function.

Variables must be declared with var, or they will still work but they will be
scoped to the global environment.

Equality isn't transitive.

NaN is not NaN.

The way to convert a number to a string? Append a string.

aString + aNumber = aString

aString - aNumber = NaN

etc.

~~~
ams6110
There are probably as many if not more idiosyncrasies with any programming
language.

~~~
quink
Bingo. And it doesn't need anything as heavy as Dart to provide some nicely
syntactical and automated sugar. CoffeeScript is quite enough and maps one-to-
one with the generated JavaScript. It would be nice to have Python-style
operator overloading in JavaScript, but I don't care that much, since it
probably helps make JavaScript faster, for varying definitions of faster.

