I would strongly prefer to work in an environment that detected the error and gave me the power to trace through the app to resolve it while still letting the damn program run in the mostly-working state. The mental cost to review hundreds of lines of code to work out the implications of every change before you can see any results is a problem - it breaks the creative flow, it prevents experimentation.
The mental cost to review hundreds of lines of code to work out the implications of every change before you can see any results is a problem - it breaks the creative flow, it prevents experimentation.
Type errors don't require such a mental cost. Once you learn how to actually read the error messages it becomes almost brain-dead simple. Compile, jump to the error message (hopefully your editor can help here), fix, recompile.
it breaks the creative flow, it prevents experimentation.
I disagree. What prevents experimentation is the fear of the unknown regression. Strong types give you the reassurance you need to boldly refactor without worrying that you'll miss something.
Aren't the errors generated by nonconforming types a way to trace through the app? That's the point of a strong type system: code that by definition won't work isn't allowed to run.
