Dart programming language design

Gilad Bracha’s presentation on Dart is interesting even if, like me, you do not intend to learn Dart. He has some good one-liners, especially digs at JavaScript, and some interesting ideas about programming language design. (JavaScript comes up frequently in presentation because of its popularity and because Dart compiles to JavaScript.)

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.

There are millions of people writing JavaScript who do not understand JavaScript’s type model at all.

Some of the programming language ideas in the talk:

  • optional type systems
  • separating compile time type-checking from execution
  • delegating type inference to tools rather than the language
  • mirror-based reflection
  • which programmer mistakes should cause compiler errors and which should cause warnings

Gilad Bracha argues that type systems are important, but not for the reason most people give. Type systems are a form of documentation, and they help enable programming tool support, but their role in error detection is greatly overstated. Anders Hejlsberg, designer of C#, made a similar statement at the same conference.

See also Gilad Bracha’s comments during this panel discussion.

Related post: Dynamic typing and anti-lock brakes

8 thoughts on “Dart programming language design

  1. “Anders Hejlsberg, designer of C#, made a similar statement at the same conference.”

    Do you remember what he said? and is it available online anywhere? I’d like to see it, because this is a point that most people who like statically typed languages are by no means prepared to concede.

  2. Dan, I’m pretty sure I remember Anders Hejlsberg commenting that at first the biggest benefit of type systems was error detection, but that this has changed over time and now the biggest benefit is how types interact with tooling. I don’t have an exact quote, and I may not be remembering this correctly, but that’s what I believe he said.

  3. Dart’s optional type checking is quite ingenious. If I understood the presentation correctly, any type conflicts in bits of code that aren’t actually executed will generate warnings rather than errors, and do not prevent the program from compiling and running. Makes perfect sense for incremental and experimental changes; I wish I had such a system when trying to modify code with big interconnected type hierarchies!

    The claim that static typing does not prevent errors seems rhetorically overstated, however. Mere compiler type checking indeed doesn’t help if a programmer introduces semantic errors while blindly modifying code just to shut up the compiler. But Bracha himself agrees that (correctly) declaring types helps with documentation and tooling, and the ultimate effect of those is once again to prevent errors.

    So the argument is really about whether type declarations should be required or merely recommended, with nobody advocating getting rid of them altogether. In a sense, everyone’s in favor of static typing — just not static typing that’s enforced too rigidly and too early.

  4. Chris: Some people benefit more from static typing than others. Programmers experienced in statically typed languages learn how to use the type system to their advantage. They write their code in a way that increases the probability that a logic error will result in a type error.

    On the other hand, static typing can create a false sense of security. Said another way, dynamic languages can create a sense of insecurity that encourages people to write more unit tests and runtime error checking. It’s a form of risk homeostasis.

    I do think statically typed programs are likely to have fewer bugs, but not by as wide a margin as static type zealots imagine.

    Perhaps the best way to write fewer bugs is to write less code. If a language lets you write much less code to get your work done, that language may reduce your bug count.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>