3 ms·

On the positive side, these kind of errors tend to blow up immediately when the code is executed. Assuming that you have a semi-decent test suite, it won't make

On the positive side, these kind of errors tend to blow up immediately when the code is executed. Assuming that you have a semi-decent test suite, it won't make it to production. The language type system won't save your butt but your unit tests will. There is a deeper discussion here; if you are writing good automatic tests anyway, which I hope you are, then of how much value is a rigorious type system? :)

deleted 10y ago
[deleted]
greydius 10y ago
I agree that a comprehensive test suite is valuable, but I don't think it's safe to assume that errors like this will always be caught, no matter how good your tests are. It's not reasonable to write a test for every possible situation that could ever occur. In fact, it's a giant waste of time. > of how much value is a rigorous type system? It saves a lot of time on those tests you won't have to write and maintain just to ensure that you're getting your types correct. Strong static types are also good documentation. Some type systems (e.g. Haskell) can even explicitly indicate whether a procedure is pure or has effects. Static types also enable dispatch that can be resolved at compile-time, resulting in more efficient execution. And the list goes on. Of course, advocates of languages without static types have heard and dismissed all these arguments before. I guess it's really just a matter of taste.
- mvindahl 10y ago
  I've heard both sides of the static types vs dynamic types argument a lot of times. I don't think there will ever be any kind of universal agreement but I find the discussion to be interesting. For the record, I personally think a language like Typescript hit a sweet spot. Not a lot of mandatory ceremony but you have the choice to add types where it matters, e.g. at interface level. Also the duck typing saves you from inventing class names for all kind of almost-primitive types.
dllthomas 10y ago
> if you are writing good automatic tests anyway, which I hope you are "Don't write tests. Generate them."

deleted 10y ago

[deleted]

greydius 10y ago

I agree that a comprehensive test suite is valuable, but I don't think it's safe to assume that errors like this will always be caught, no matter how good your tests are. It's not reasonable to write a test for every possible situation that could ever occur. In fact, it's a giant waste of time. > of how much value is a rigorous type system? It saves a lot of time on those tests you won't have to write and maintain just to ensure that you're getting your types correct. Strong static types are also good documentation. Some type systems (e.g. Haskell) can even explicitly indicate whether a procedure is pure or has effects. Static types also enable dispatch that can be resolved at compile-time, resulting in more efficient execution. And the list goes on. Of course, advocates of languages without static types have heard and dismissed all these arguments before. I guess it's really just a matter of taste.

mvindahl 10y ago
I've heard both sides of the static types vs dynamic types argument a lot of times. I don't think there will ever be any kind of universal agreement but I find the discussion to be interesting. For the record, I personally think a language like Typescript hit a sweet spot. Not a lot of mandatory ceremony but you have the choice to add types where it matters, e.g. at interface level. Also the duck typing saves you from inventing class names for all kind of almost-primitive types.

dllthomas 10y ago

> if you are writing good automatic tests anyway, which I hope you are "Don't write tests. Generate them."