3 ms·

Is it just me, or does anyone else feel that gradual/optional typing isn't good enough? I've been trying out Typescript in a couple of nontrivial projects, and

Is it just me, or does anyone else feel that gradual/optional typing isn't good enough? I've been trying out Typescript in a couple of nontrivial projects, and sure, it does catch some errors, but as long as you're forced to integrate with an unityped world it doesn't really catch enough problems to be worthwhile, IME. You can of course write type declarations for all your "foreign" libraries, but that's just an added burden that you (the programmer, not the language) have to get right. Plus, since the unityped language is so flexible (and thus conventions are different vs. a multityped language), there are things in the unityped language that cannot be sensibly typed without just resorting to saying "any" (which is the only type of the unityped language).

smrq 12y ago
The biggest benefit of Typescript in my opinion is the potential for stronger tooling. There's definitely room for improvement (I suspect type unions would fix a majority of the times you are forced to use "any"), but I have found type declarations to be relatively low overhead for a substantial gain. Re: foreign libraries, as long as you are using TSD / DefinitelyTyped (http://definitelytyped.org/tsd/ http://definitelytyped.org/tsd/), that burden is crowdsourced. I've written a few library type declarations, but used many more from others. The flipside of the complaint is that I've found it really quite nice to have type checking for libraries I don't know inside and out. And you can always cheat and declare your external libraries as "any" for the sake of making the compiler happy, if you don't want to go through the effort to get the reward. Obviously, to get something like DefinitelyTyped going, you need a critical mass of developers, so that may or may not work out for Typed Lua.
- lomnakkus 12y ago
  My experience is that DefinitelyTyped definitions are actually not very accurate in practice. This may be a consequence of language restrictions or just typical (and understandable) programmer laziness ("good enough!") -- or, as you say, the lack of type unions. It's better than nothing, but not really good enough. But then I have been spoiled by Ocaml and Haskell, so... (There's also the whole external/internal module confusion in TS, but that's not related to the general theme of gradual typing per se, so it's not really relevant to non-TS contexts.)
ufo 12y ago
I think that the biggest thing missing from Typescript is contract checking. The idea is that you use the type information to add assertions in the program and that should let you get more accurate stack traces even for the dynamic errors. An example would be getting an error in the line where you set a variable to null instead of getting an error latter on in the line where you try to call a method on that null variable.
samth 12y ago
If you've only used TypeScript, then you haven't really seen what gradual typing can do. In Typed Racket, you get actual guarantees about your types, and a type system that works for almost all existing untyped code. Of course, it might be more work to make it type check, since you have to get it right. ;) This is also true of other systems like GradualTalk, and other systems like Typed Clojure have much more expressive type systems than TypeScript, even if they don't guarantee soundness in the presence of untyped code. The designers of TypeScript went for simplicity first. This has real advantages, but also disadvantages, which you seem to be running into.
- lomnakkus 12y ago
  (Typed) Racket has been on my radar, though there have been some worries, e.g. the performance issues when crossing the typed/unityped boundary. Hopefully those can be fixed. I know it's my own failing, but I've also had a lot of trouble with the incredible amount of parens and symbols in TR/TC -- I'm used to the near-math notation of Haskell dammit! :). It's just one of those things -- I have actually written non-trivial code in Scheme, but I've been spoiled by Haskell. Intellectually, I deeply appreciate the value of homoiconicity, but sadly I just can't get past the aesthetics. EDIT: FWIW, if I were to go with gradual typing, I think TR would probably be close to ideal. It's an amazingly well thought-through language in terms of module system, integration of the macro system with modules, the syntax-parse macro system, etc. Kudos!

smrq 12y ago

The biggest benefit of Typescript in my opinion is the potential for stronger tooling. There's definitely room for improvement (I suspect type unions would fix a majority of the times you are forced to use "any"), but I have found type declarations to be relatively low overhead for a substantial gain. Re: foreign libraries, as long as you are using TSD / DefinitelyTyped (http://definitelytyped.org/tsd/ http://definitelytyped.org/tsd/), that burden is crowdsourced. I've written a few library type declarations, but used many more from others. The flipside of the complaint is that I've found it really quite nice to have type checking for libraries I don't know inside and out. And you can always cheat and declare your external libraries as "any" for the sake of making the compiler happy, if you don't want to go through the effort to get the reward. Obviously, to get something like DefinitelyTyped going, you need a critical mass of developers, so that may or may not work out for Typed Lua.

lomnakkus 12y ago
My experience is that DefinitelyTyped definitions are actually not very accurate in practice. This may be a consequence of language restrictions or just typical (and understandable) programmer laziness ("good enough!") -- or, as you say, the lack of type unions. It's better than nothing, but not really good enough. But then I have been spoiled by Ocaml and Haskell, so... (There's also the whole external/internal module confusion in TS, but that's not related to the general theme of gradual typing per se, so it's not really relevant to non-TS contexts.)

ufo 12y ago

I think that the biggest thing missing from Typescript is contract checking. The idea is that you use the type information to add assertions in the program and that should let you get more accurate stack traces even for the dynamic errors. An example would be getting an error in the line where you set a variable to null instead of getting an error latter on in the line where you try to call a method on that null variable.

samth 12y ago

If you've only used TypeScript, then you haven't really seen what gradual typing can do. In Typed Racket, you get actual guarantees about your types, and a type system that works for almost all existing untyped code. Of course, it might be more work to make it type check, since you have to get it right. ;) This is also true of other systems like GradualTalk, and other systems like Typed Clojure have much more expressive type systems than TypeScript, even if they don't guarantee soundness in the presence of untyped code. The designers of TypeScript went for simplicity first. This has real advantages, but also disadvantages, which you seem to be running into.

lomnakkus 12y ago
(Typed) Racket has been on my radar, though there have been some worries, e.g. the performance issues when crossing the typed/unityped boundary. Hopefully those can be fixed. I know it's my own failing, but I've also had a lot of trouble with the incredible amount of parens and symbols in TR/TC -- I'm used to the near-math notation of Haskell dammit! :). It's just one of those things -- I have actually written non-trivial code in Scheme, but I've been spoiled by Haskell. Intellectually, I deeply appreciate the value of homoiconicity, but sadly I just can't get past the aesthetics. EDIT: FWIW, if I were to go with gradual typing, I think TR would probably be close to ideal. It's an amazingly well thought-through language in terms of module system, integration of the macro system with modules, the syntax-parse macro system, etc. Kudos!