Hacker News new | past | comments | ask | show | jobs | submit login

> declaring the return type doesn't tell users anywhere near all they need to know in many cases.

It doesn't declare all they need to know, but it covers a good fraction of it. As a really nice bonus, it's machine checkable.

> And since you can't usefully discuss the return value without implicitly disclosing its type in the comments

I don't seem to have this problem. I have lots of comments that are like:

    // Copies [from] to [to].
    copyFile(File from, String to) { ... }
Note that the comment didn't redundantly point out that "from" is a File and "to" is a String.

> But I don't think I have personally ever actually run into a bug in a dynamically typed language that would have been avoided by a static type system.

I actually get to perform this experiment all the time. I work on Dart. Dart has fully dynamically-typed runtime semantics, but also an optional static type checker that the Dart Editor uses to give you static warnings.

Up until recently, I've mostly write my code in a plain text editor. I do write type annotations, but I get no static checking whatsoever. They're basically comments.

Now that I'm using the Editor more, I can open up codebases I've written that were blind to static type checking and see what kinds of warnings it finds. I get some false positives (i.e. the bug is in the type annotation, not the code), but I also find a disheartening number of legit bugs, and this is in code with good test coverage.

I like dynamically-typed languages, but it turns out the static typing people aren't crazy: it really does find bugs.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: