3 ms·

> Your compiler giving you a type check error is saying that the program is meaningless. What is the advantage of running a program that is known to be wrong?

> Your compiler giving you a type check error is saying that the program is meaningless. What is the advantage of running a program that is known to be wrong? Well one bit is you might not be looking at the meaningless part. Sometimes when doing large refactorings or updates never getting to run, try, or look at anything is discouraging. It's a great feeling when it compiles and everything works (or near enough), but spending two days cycling between compiling and fixing compilation errors is not as enjoyable as e.g. seeing the unit test report's green bar tick up. Maybe compilers should provide more enjoyable feedback, not just better error messages (though I fully support that movement).

_se 4y ago
Large refactoring and updates are exactly where strong type systems are the most useful. Make change, fail build, fix build, be happy. Unit tests are still there to turn green when you're done. I can't think of many worse experiences than my past self trying to refactor Python 2 code. Compared to _any_ type system it's just not even close.
- masklinn 4y ago
  Have you considered reading what I actually wrote rather than just hook onto a pair of words and ignore everything else?
Karellen 4y ago
I'm not sure I get what you mean by "you might not be looking at the meaningless part"? What's the difference between seeing a bunch of test failures and fixing them one by one until the test suite is all green, and seeing a bunch of compiler errors and fixing them one by one until the compiler runs clean?
- lazide 4y ago
  If there is a pretty graph or not? (Not joking) Speaking of which, that WOULD be a cool IDE feature. I always liked the feeling of my junit bar going all green after a big change.
- nlitened 4y ago
  > I'm not sure I get what you mean by "you might not be looking at the meaningless part"? For example, you might not be pushing buttons that trigger the meaningless part, but the other parts of the system might still be functional. > What's the difference between seeing a bunch of test failures and fixing them one by one until the test suite is all green, and seeing a bunch of compiler errors and fixing them one by one until the compiler runs clean? The difference is in one of the cases a highly qualified professional has freedom to decide _when_ to do the fixes.
duped 4y ago
I get the sentiment, but ime this speaks more to architecture and code organization than the merits of static typing. It's always possible to skip type checking by designing the software to be modular enough that unreachable code isn't included in the local build. Like updating data structures should never result in days of work before you can run simple tests. Create a new build artifact that only pulls in the new data structures and the software modules you're working on (and their tests). If you need to pull in the universe to run any unit tests, they aren't unit tests.
74ls00 4y ago
I agree. Sometimes I'm prototyping something or feeling my way down one possible implementation -- it's a lot more efficient to go deep in one area of the codebase and come back to fix up everywhere else later once I'm sure this is the right trajectory. In my day job, I use Flow.js which gives me this and I'm a little hesitant to give that up, given there's no many static type checkers that work this way.

_se 4y ago

Large refactoring and updates are exactly where strong type systems are the most useful. Make change, fail build, fix build, be happy. Unit tests are still there to turn green when you're done. I can't think of many worse experiences than my past self trying to refactor Python 2 code. Compared to _any_ type system it's just not even close.

masklinn 4y ago
Have you considered reading what I actually wrote rather than just hook onto a pair of words and ignore everything else?

Karellen 4y ago

I'm not sure I get what you mean by "you might not be looking at the meaningless part"? What's the difference between seeing a bunch of test failures and fixing them one by one until the test suite is all green, and seeing a bunch of compiler errors and fixing them one by one until the compiler runs clean?

lazide 4y ago
If there is a pretty graph or not? (Not joking) Speaking of which, that WOULD be a cool IDE feature. I always liked the feeling of my junit bar going all green after a big change.
nlitened 4y ago
> I'm not sure I get what you mean by "you might not be looking at the meaningless part"? For example, you might not be pushing buttons that trigger the meaningless part, but the other parts of the system might still be functional. > What's the difference between seeing a bunch of test failures and fixing them one by one until the test suite is all green, and seeing a bunch of compiler errors and fixing them one by one until the compiler runs clean? The difference is in one of the cases a highly qualified professional has freedom to decide _when_ to do the fixes.

duped 4y ago

I get the sentiment, but ime this speaks more to architecture and code organization than the merits of static typing. It's always possible to skip type checking by designing the software to be modular enough that unreachable code isn't included in the local build. Like updating data structures should never result in days of work before you can run simple tests. Create a new build artifact that only pulls in the new data structures and the software modules you're working on (and their tests). If you need to pull in the universe to run any unit tests, they aren't unit tests.

74ls00 4y ago

I agree. Sometimes I'm prototyping something or feeling my way down one possible implementation -- it's a lot more efficient to go deep in one area of the codebase and come back to fix up everywhere else later once I'm sure this is the right trajectory. In my day job, I use Flow.js which gives me this and I'm a little hesitant to give that up, given there's no many static type checkers that work this way.