johnjbarton at google.com
Sun Jun 29 09:25:12 PDT 2014
On Sat, Jun 28, 2014 at 3:58 PM, Kevin Smith <zenparsing at 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.
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
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
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
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.)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss