Dart programming language design | Hacker News Reader

Dart programming language design

johndcook.com

26 pointsColinWright10 comments

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.

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.

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?

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.

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

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.

NaN !== NaN is not a JavaScript thing so much as a floating point thing. === is transitive as far as I know, and you should have a pre-commit hook that prevents anyone from ever using ==.

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

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.

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

You can always call intVar.toString() if it pleases.

Reply on news.ycombinator.com