On Sat, Jun 28, 2014 at 3:58 PM, Kevin Smith <zenpars...@gmail.com> wrote:
> Static checking will be limited anyway. If you want to go this way you >> should use typescript. >> >> > That's the point that I'm trying to make, shops will choose other > languages that provide more static information. We should be thinking > about expanding the user base and ensuring that JS is a viable option years > down the road. > JavaScript's enormous user base is the strongest possible evidence that static analysis provides no advantage to programming language viability. Static analysis may encourage some new users; overall complexity may discourage as many. (I recently started using a typed version of JS; I am not impressed.) Any survey of the top languages in actual use clear demonstrates that the runtime platform and app goals dominate language choice. Even within a platform it is clear static checks are way down the list of valued features. Rather than point towards type-checking, I think we should focus on the actual checks offered by the module design. It seems that these would come with a small cost quite unlike type-checking. > >> CommonJS falls a bit short on the import side because static analysis of >> require calls is brittle. A special language syntax would enable a robust >> static analysis of dependencies. >> > > If you don't have static exports, then how are you going to know if what > you import is valid? You can't, without executing the program. > If you don't execute the program, how do you know if the code you are checking is even called? Oh, you do plan to execute the program. Well there you go. (I just think it is so weird that JavaScript's huge advantage of rapid dynamic feedback for developers receives so little attention while so much is lavished on static technologies developed decades ago for a computing environment vastly inferior to our current world.) jjb
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
