3 ms·

Of course it has to be executed, but it's either something that you are going to execute yourself (as in pushing a button) or at least you are making an easy wa

by BoppreH 17y ago

Of course it has to be executed, but it's either something that you are going to execute yourself (as in pushing a button) or at least you are making an easy way to trigger this function. If you are testing such code you make sure to run it. I understand that strict typing works by guaranteeing some things won't go wrong, but I can't see many meaningful situations where it wouldn't generate a runtime error in a scripted language, or at least results that make the source of the error painfully obvious.

wvenable 17y ago
> If you are testing such code you make sure to run it. Ahh, but that's not the problem. It's easy to test the code your changing, it's a much harder problem to find and test all the code that depends on that code. Having the compiler spit out every instance everywhere that you need to fix due to a new type-mismatch makes this significantly easier. Some dynamic languages will happily convert values from one type to another even when that's not the desired result -- you might not get an error at all, just some bad data you might not find until much later.
- gte910h 17y ago
  >Some dynamic languages will happily convert values from one type to another even when that's not the desired result -- you might not get an error at all, just some bad data you might not find until much later. This happens with algol style static languages too (And is one of the reasons I find people arguing for Erlang instead of python more persuasive than those instead arguing C++ instead of ruby). You are confusing strong types with dynamic variables. Most of the algol languages have weak to medium type strength. For instance, python has much stronger types than C. However, it's variables are all dynamic references.
AndrewDucker 17y ago
I work with systems with hundreds of thousands of lines of code. We try to check everything, and we have decent unit test coverage, but there are bound to be places we don't hit instantly - and running the tests takes longer than compiling does.

by BoppreH 17y ago

wvenable 17y ago

> If you are testing such code you make sure to run it. Ahh, but that's not the problem. It's easy to test the code your changing, it's a much harder problem to find and test all the code that depends on that code. Having the compiler spit out every instance everywhere that you need to fix due to a new type-mismatch makes this significantly easier. Some dynamic languages will happily convert values from one type to another even when that's not the desired result -- you might not get an error at all, just some bad data you might not find until much later.

gte910h 17y ago
>Some dynamic languages will happily convert values from one type to another even when that's not the desired result -- you might not get an error at all, just some bad data you might not find until much later. This happens with algol style static languages too (And is one of the reasons I find people arguing for Erlang instead of python more persuasive than those instead arguing C++ instead of ruby). You are confusing strong types with dynamic variables. Most of the algol languages have weak to medium type strength. For instance, python has much stronger types than C. However, it's variables are all dynamic references.

AndrewDucker 17y ago

I work with systems with hundreds of thousands of lines of code. We try to check everything, and we have decent unit test coverage, but there are bound to be places we don't hit instantly - and running the tests takes longer than compiling does.