3 ms·
The problem is that, from a pragmatic perspective, you have to balance the benefits of a safer language and the cost of "explaining" to it that what you're doin
by astrobe_ 13y ago
The problem is that, from a pragmatic perspective, you have to balance the benefits of a safer language and the cost of "explaining" to it that what you're doing is safe. If you want to make it accept a particular construct as "safe", you have to feed it with a lot more information, whereas in a more permissive language you can just be imperative and tell it "I know it's ok, just do it". The tooling approach is, it seems, more attractive because it adds a bit of safety at a moderate cost.
- codygman 13y agoI guess I'm different in that I prefer to have a substantial amount of safety with "safe" code. If it's something that doesn't require that safety, it seems that something truly dynamic like lisp or racket is best. For intstance, languages with weak static typing seem to lead to "stringly typed" solutions.
- chongli 13y agoThe tooling approach is, it seems, more attractive because it adds a bit of safety at a moderate cost. There's one cost you've ignored: feedback time. A type-checker can be run on the fly with tools such as flymake. Debugging tools and tests are (orders of magnitude) slower to run and thus dramatically slow down the feedback cycle between bug detection and bug fix. This is especially prevalent when doing major refactoring work and the code is a long way from working again.