It seems like post 0.9.1, the direction of TypeScript has changed. Now the primary goal is to improve compiler speed.
This is fine, however, the way this goal is being achieved is by sacrificing programmer happiness. Bugs such as these -
are not fixed for efficiency reasons. More and more type inference is being sacrificed (https://typescript.codeplex.com/discussions/471751
because to do otherwise would decrease the compiler's speed.
Isn't the first rule of speed optimization the one that the output of an optimized program must not differ from the output of the unoptimized one, given the same input? Is it not possible to achieve those performance improvements in other ways? Like for example,
introducing aggressive caching of compilation data?
I really like TypeScript, but I have serious doubts about the direction where its headed now. Really hoping its just some sort of a temporary pre-1.0 phase where you remove things you're not sure you'd like to support forever...
Feb 17, 2014 at 6:18 PM
Edited Feb 17, 2014 at 7:18 PM
In large part, the design changes in the language since 0.9.1 have focused on:
- Catching errors
- Not getting in the user's way
- Simplifying the type system so that errors are easier to reason about
There were some changes that did have an impact on compile speed mostly because we opted for a simpler, easier-to-understand design.
To your specific points:
The thread in
is around the visibility of types when using external modules. For separate compilation scenarios where you output a .d.ts file, you need to be able to name the types of symbols and functions. You can import
modules and use only the type information, and the result won't have any impact on the .js file (basically, we never write out a require statement if you only use the module for type information). The issue is really around the visibility of the type names
and if the compiler has enough available to express them.
The thread on
touches on the switch from using 'any' to something that would help catch more errors in code where the user doesn't explicitly annotate ambiguous inference situations. We had been just using 'any', which
meant the user wouldn't get any help. Making this change did help projects catch these ambiguous situations and fix them.
Neither of these really is about compiler speed, but rather about helping programmers catch bugs and annotate their programs as clearly as possible. We're trying to, and I like your phrase, "optimize for programmer happiness" by striking a balance
for a type system that easier to understand while still strong enough to catch issues.