Is there a guarantee that TS will remain a strict superset?
Looking at the syntax, it reminds me of Flash ActionScript, which started out as an ECMAScript implementation but became an incompatible superset that pretended to be JavaScript compatible but would whine endlessly about untyped var declarations...
Hopefully ActionScript and C++ will serve as warnings to TypeScript designers: if you're ever thinking about disrupting code compatibility with the original language in the name of added type safety, don't do it.
My understanding is that the TypeScript team intend to TypeScript to always remain a superset. If you watch the various videos with Anders talking about it then that comes across pretty clearly.
There are a few language corners that don't translate, such as:
var x = "".constructor(5);
// The property 'constructor' does not exist on value of type 'String'.
The exceptions make sense if you dig into how the type system works. AFAIK these can always be worked around with an explicit cast to any:
var x = (<any>"").constructor(5);
I've found TypeScript to be a huge win for maintainability, and can't imagine going back to raw JS for an app of any complexity. I'd love to have a chance to pair it with Node for something.
Regarding noImplicitAny, I find the choice of a compiler option rather than source code markup (like "user strict") rather odd. Granted there's no standard way to do that, but still...
why? compilers for other languages has compile time switches for various checks and/or optimizations, there it is assumed normal. Javascript's "use strict" is just a hack for lack such option.
This has some benefits, i.e. you take some codebase that must compile with noImplicitAny and want to add some features, you start with less strict typing (implicit any allowed), when finished you compile with different flag. Because ide (most people use) is recompiling the code all the time there is no reason to clutter this when prototyping.
If you don't like this workflow, just use the flag from step 1.
My understanding was that NoImplicitAny changes the rules of the language, so its use will make it harder to move code from projects that rely on it to projects that don't. Traditional compilers opt for a rich set of warnings and the ability to turn any warning into error. On closer inspection, it seems that code developed with NoImplicityAny should work 100% on projects without that, so my concern was unwarranted.
The best recent development in TypeScript IMHO is there's now a usable Sublime Text plugin that makes code completion and other goodness available outside Visual Studio. https://github.com/Railk/T3S
My team has been using TypeScript since 0.9 was released. From our perspective it's been a great win. It's greatly eased the refactoring of our JavaScript.
The thing that's been really nice is the ability to write a certain amount of ES6 style code (eg using arrow functions to lexically bind the this value) and having the TypeScript compiler transpile that into ES5 / ES3 JavaScript.
I really like it. I think the tooling is still a little rough but it's still in Alpha so that's fair enough I guess. It'll improve.
I think typescript is such a good idea. And generics is a great addition.
The only thing I dislike about TS is the way it handles dependencies. The require/declare/import/export methodology confuses me. And on top of that there is the //<reference /> tag, and all of it seems to be relying on files, rather than on constructs in the code. Relying on files, means that I have to maintain the order of which to import what, and this becomes even harder if some of the files contain code that is not just module/class definitions, but actual statements in global scope.
One of the major problems with JavaScript has always been that there are too many options. I feel like TS reduces some, but it still lets people choose between a module pattern (AMD, CommonJS), and the traditional everything-in-the-global-scope way of writing programs.
So you're left feeling confused because there is more than one way to write a program. Options are good and all, but in the front-end Javascript community, I think we could deal with fewer of them.
To solve your own problem: I would recommend using CommonJS with Browserify for everything, and only use reference tags for ambient declarations. (.d.ts files). Then you'll always use import and export
TypeScript doesn't handle dependencies. The <reference> tag is just for the compiler to know where to find the type definitions you are using in a file. For proper dependency handling you still need to use something like RequireJS.
I feel so productive in Typescript. I remember the feeling I got when I realized how powerful the type system in Haskell was, and how useful it was at catching mistakes. Every once in a while I read an article about Haskell and think I should get better at it, then I realize that Typescript is really the best of both worlds. It turns JavaScript into this awesome productive language that can scale to large projects.
I like Typescript too, but this is a little over the top. Typescript's typing is nowhere near as expressive as Haskell's is (nor was it ever intended to be). I think of it more as a nicer way of doing Closure Compiler-like annotations plus you get a built in transpiler for many of the handier es6 features.
edit: oh, and tooling, but I'm not normally on Windows for development so I haven't played much with the Visual Studio integration.
Typing isn't just about catching type errors, but about semantic feedback useful for tooling. Unless you are using Haskell, then its just about catching type errors.
That's really unfair to Haskell. What are things like Hoogle if not tools, uniquely[1] enabled by Haskell's type system? All the basic IDE-like frills exist too, if you really want them. And now, with the advent of deferred type errors and holes, Haskell's type system is getting even more interactive. The process is quickly moving from writing code and running it through a compiler to having an ongoing conversation with the typechecker as you build up your program.
More importantly, types can go well beyond catching errors or tooling. Types can actually make your code more expressive and they can push your design forwards.
For the first, the simplest example is with Haskell's typeclasses: you can't easily write something like Show or have something like Haskell's flexible numeric literals without types. This allows you to grow[1] Haskell in ways that are even difficult in Lisp! For a more practical standpoint, I've found certain libraries to be much harder to reproduce without typeclasses, most crucially QuickCheck.
The second idea is slightly more abstract. As somebody else put it, types are like gravity sources: we place them strategically in our design space, and the rest of the code falls towards them. More concretely, coming up with the types to represent some domain often really helps in writing the code for it. Sometimes, once you've got the general framework of the types, the actual programming just feels like systematically filling in the blanks. More generally, the effect is nowhere near that pronounced, but the types do help shape everything else. In a sense, types help you constrain the set of possible programs at the outset, giving you fewer options to consider as you go along.
Oh, and I guess there's the performance thing. This includes both low-level optimizations (C++ or even C-style stuff) and high-level ones (like rewrite rules). Optional type systems seem to give up on these as a matter of principle. I don't believe static types are strictly necessary for good performance, but empirically they seem to help. Most languages with really good compilers are statically typed.
I think the idea that types just exist to catch type errors is one of the most unfortunate common misunderstandings about type systems. It really scares people away before they can learn about all the other benefits a good type system confers.
[1]: Okay, not really uniquely, but it's close. I've seen Hoogle-like tools for OCaml but not for Java or C++, much less something like Python. I'm not sure how useful or general they could be for other languages.
I saw Growing a Language in person in 1999 (he redid the talk during Utah's yearly Organick lecture). As for your arguments about Haskell, I find this very useful; thanks for the reply. I am quite interested in type systems for tool purposes, and grocking whether even code completion is possible for Haskell is quite a chore. Hoogle is exactly the tool I'm competing with :)
After using TypeScript for awhile, I really can't think of a reason not to use it. I haven't read anyone else express a reason not to use it. If it ever turns out to be a problem, then I can just switch over to working on the JavaScript output and dump the TypeScript front with almost zero effort. I did some refactoring the other day and it became clear that TypeScript is a tool that makes life easier and there probably is no good reason not to use it.
23 comments
[ 3.1 ms ] story [ 64.3 ms ] thread[1] http://www.typescriptlang.org/
Is there a guarantee that TS will remain a strict superset?
Looking at the syntax, it reminds me of Flash ActionScript, which started out as an ECMAScript implementation but became an incompatible superset that pretended to be JavaScript compatible but would whine endlessly about untyped var declarations...
Hopefully ActionScript and C++ will serve as warnings to TypeScript designers: if you're ever thinking about disrupting code compatibility with the original language in the name of added type safety, don't do it.
[1]: https://github.com/clausreinke/typescript-tools
The thing that's been really nice is the ability to write a certain amount of ES6 style code (eg using arrow functions to lexically bind the this value) and having the TypeScript compiler transpile that into ES5 / ES3 JavaScript.
I really like it. I think the tooling is still a little rough but it's still in Alpha so that's fair enough I guess. It'll improve.
The only thing I dislike about TS is the way it handles dependencies. The require/declare/import/export methodology confuses me. And on top of that there is the //<reference /> tag, and all of it seems to be relying on files, rather than on constructs in the code. Relying on files, means that I have to maintain the order of which to import what, and this becomes even harder if some of the files contain code that is not just module/class definitions, but actual statements in global scope.
So you're left feeling confused because there is more than one way to write a program. Options are good and all, but in the front-end Javascript community, I think we could deal with fewer of them.
To solve your own problem: I would recommend using CommonJS with Browserify for everything, and only use reference tags for ambient declarations. (.d.ts files). Then you'll always use import and export
edit: oh, and tooling, but I'm not normally on Windows for development so I haven't played much with the Visual Studio integration.
More importantly, types can go well beyond catching errors or tooling. Types can actually make your code more expressive and they can push your design forwards.
For the first, the simplest example is with Haskell's typeclasses: you can't easily write something like Show or have something like Haskell's flexible numeric literals without types. This allows you to grow[1] Haskell in ways that are even difficult in Lisp! For a more practical standpoint, I've found certain libraries to be much harder to reproduce without typeclasses, most crucially QuickCheck.
The second idea is slightly more abstract. As somebody else put it, types are like gravity sources: we place them strategically in our design space, and the rest of the code falls towards them. More concretely, coming up with the types to represent some domain often really helps in writing the code for it. Sometimes, once you've got the general framework of the types, the actual programming just feels like systematically filling in the blanks. More generally, the effect is nowhere near that pronounced, but the types do help shape everything else. In a sense, types help you constrain the set of possible programs at the outset, giving you fewer options to consider as you go along.
Oh, and I guess there's the performance thing. This includes both low-level optimizations (C++ or even C-style stuff) and high-level ones (like rewrite rules). Optional type systems seem to give up on these as a matter of principle. I don't believe static types are strictly necessary for good performance, but empirically they seem to help. Most languages with really good compilers are statically typed.
I think the idea that types just exist to catch type errors is one of the most unfortunate common misunderstandings about type systems. It really scares people away before they can learn about all the other benefits a good type system confers.
[1]: Okay, not really uniquely, but it's close. I've seen Hoogle-like tools for OCaml but not for Java or C++, much less something like Python. I'm not sure how useful or general they could be for other languages.
[2]: Easily my favorite CS talk: http://www.youtube.com/watch?v=_ahvzDzKdB0