| I agree with a lot of your thoughts. Here are some areas where I disagree > 1. "uninitialized var usage is error": unfortunately impossible without at least one of the following compromises: Automatically initialize variables (wastes CPU); False alarms (see Java); Built-in formal proof system; or, Require compilers to solve the halting problem. I don't think this is true. It should be pretty easy to detect if a variable is initialized or not. I can potentially see how a false alarm would arise, but I don't think that matters in practice. (All the situations I'm imagining involve writing bad code) > 10. Multi-file module: May lead to unmaintainable code Go does this already and it is fine. > 12. Build process difference: Theoretically could speed up compilation. I'm worried for social reasons. In module-based languages, we tend to fall into module hell: one symptom being the infamous 20-page stacktrace (see: Java, Clojure, etc.) The nature of C's #include incentivizes shallow dependency trees (a very good thing). I can see why this is a concern, but I think it is more a problem with JVM languages because of the type of programming Java encourages. > 14. Tooling: This shouldn't be part of the language, it should be separate. I thought this way too. Then I used Go and realized the huge benefit tooling integrated into the language provides. (Go has other problems, but tooling is not one of them). |
It's easy to trace the code-paths between a variable's declaration and its usage, as long as those don't involve procedure calls. Then that problem becomes "static-analysis complete".