This project is read-only.

TypeScript's current direction not optimized for programmer happiness.

Topics: General
Feb 17, 2014 at 1:36 PM
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 ( 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:
  1. Catching errors
  2. Not getting in the user's way
  3. Typing more patterns in JavaScript (while still doing #2)
  4. 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.