Hacker News Reader

Comment by lmkg | Hacker News Reader

So what do types and type annotations actually do in Dart? I may have missed something obvious, but it looks like all the code samples given in the article will all pass static verification. Can someone give me an example of a code error that Dart will catch statically at compile time? My biggest confusion about Dart's type system (or at least its static one) is that it simply doesn't seem to do very much, so I wonder why it exists at all.

View on HN

Type annotations are optional and for people who do use them, they provide at least 2 substantial benefits:

1. Better code documentation. Based on my experience with Python, reading someone else's code (or even my own code after a while) is harder than e.g. C or Java code because types do provide useful information. When reading Python function in isolation I often wander: is the argument to a function a list? a dictionary? a string? Knowing that makes a big difference when reading a code and when I don't know that it's hard to figure that out because you have to trace the whole control flow to that function. This is especially important in large projects where you can't keep all the code in your head and how to read small parts of it.

2. Tools can tell you about errors. Part of the Dart project are lint-like tools that check annotations and notify you about mistakes. If you e.g. annotate a function as taking integer but you pass string to it, a tool can tell you about such mistake. This is what statically typed compilers always do and, again, it's especially important on large projects where you're only responsible for part of the code. Dart doesn't force you to use type annotations but you can choose to use it in your project and get less bugs by using Dart code lint tool.

Hehe. I guess Dart users are troubled by it as well because the way it works is surprising based on our previous experiences. Basically you can run the program in checked mode so you do get more feedback from the usage of the types. But checked mode is meant for development as it isn't as optimized as in other languages. We need to recall that Dart gets translated into JavaScript and adding type checks and stuff to all the code required puts an extra burden on it that can be hard to justify.

All in all, you should run in checked mode for more feedback. The idea is that you get warnings when stuff is bad. When stuff is super bad you get runtime exception.

Dart is optimist and will give you warnings and let your code run until it cannot.

I certainly agree that the translated JavaScript shouldn't need to enforce types in any way, unless Dart provides some kind of "downcasting" mechanism to give something a type it doesn't already have. However, that only applies if the Dart compiler doesn't statically enforce the types when compiling the code to JavaScript.

For one example: Haskell's strong static types all go away when you compile; the generated code does not do any type enforcement or verification.

The biggest thing I hoped the article would talk about got shot down in the very first section, which just said "Dart is dynamically typed" and explicitly dismissed any need to justify that, other than by saying "Users of dynamically typed languages ... will understand why we chose this".

I honestly can't even begin to understand why people consider dynamic typing a feature; when I saw the headline I hoped to see an interesting justification, but instead I saw it taken as a given and then used to justify many other things. I agree that almost all of those things do follow naturally from the assumption of dynamic typing, but I'd still like to know the rationale for that assumption.

The only justification I've ever seen for dynamic typing amounted to "because I like duck typing". However, a static type system can trivially enforce duck typing.

Reply on news.ycombinator.com