2 ms·
Disagree wholeheartedly. One of the under-appreciated superpowers of gradually typed systems like TypeScript is the ability to ignore errors in parts of the co
by eins1234 4y ago
Disagree wholeheartedly.
One of the under-appreciated superpowers of gradually typed systems like TypeScript is the ability to ignore errors in parts of the codebase I don't care about right now, and focus on exercising the runtime behavior of the code paths I'm currently working on, because I can always have a working program that can be executed (and possibly crash at runtime) regardless of what the static analysis tells me is wrong with it.
Without this, large scale changes tend to become extremely painful all-or-nothing affairs that have to be applied codebase wide at every iteration, and I only find out the change doesn't work the way I expected at runtime after I've already done all the work applying it to everything across the board, and have to repeat the whole process over and over again.
- woojoo666 4y agoI'm fine with providing developers an option to disable checks, as they already had previously with the nochecks option. But why make it the default? If you chose to use typescript over javascript, then you clearly care about type correctness, so why stop caring when it comes to your dependencies? As far as I'm aware, there's no other typed language that let's you do that. I don't see Rust developers complaining that they can't use broken dependencies. If you really wanted to import a broken dependency, at least with typescript you can compile the dependency to plain javascript which will remove all types (and thus all type errors as well). But to disable type checks by default for a typed language seems a bit odd. And to be clear, this is still an "all-or-nothing" approach. When you disable checks, it's "nothing". Deno will still compile even if there are type errors in your own code. (At least that's what I'm assuming, I haven't tested the nochecks option yet. Please correct me if I'm wrong)