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

> * if your test suite has 100% coverage of arguments/return-value and field usage, you have type checked your program.

The most horrible argument in favor dynamic typing in my opinion. Test suits shouldn't be about checking if a return value is of expected type, that's ridiculous. It's implementing a type checker manually.

There are a lot of things statically typed languages can do to make types painless :

- (global) type inference (Crystal does that)

- co and contravariance, it is not limited to dynamically typed language

- optional parameters

- adhoc type declaration like in C# (ex {x:1,y:"a"} is a type).

- contracts

- pattern matching

- generics

- ect ... etc ...

I just dislike dynamically typed languages. Even interpreted languages should be statically typed IMHO. Again, there are multiple ways to make statically typed language painless when it comes to types.

> Test suits shouldn't be about checking if a return value is of expected type

Indeed and so they don't have to. When you have reasonable code coverage, it is really surprising to encounter type issues in production. And they are the easiest mistakes to fix. But the point is, runtime checks happen implicitly as you run the code. So no "implementing a type checker" needed ...

On the other hand my comment on when you get the equivalent of being fully type checked was incorrect. Even 100% code coverage will not guarantee it for some code.

I like both kind of languages, and use both. While you get some advantages in static languages, you do also pay a price in language semantics and effort. It is good to point that out, so we can continue making progress, like Crystal or latest C# (and latest F#!). There used to be a time when the mood was: Java is good for all, stop confusing us with your new languages.

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