5 ms·

Here's my strongest argument in favor of type safety: if you're building a project that is intended to have a long life and be seen by many people, type safety

Here's my strongest argument in favor of type safety: if you're building a project that is intended to have a long life and be seen by many people, type safety may be a hassle for you but it'll be a blessing for the hundreds of people who will have to eventually figure out your code.

maxyme 8y ago
My team has recently focused on adding JSDoc to most of our codebase and I've been thinking, JSDoc provides essentially all the benefits (and more) of typescript from a maintainability aspect and contains none of the headaches (outdated definitely typed definitions, fighting with types...). As long as you use something to validate the JSDoc comments (like the JSDoc eslint plugin) they are extremely helpful in ways very similar to typescript. Language Servers like that in VSCode (tsserver) will inherit types from JSDoc comments and provide useful annotations with both the types and descriptions. They can even be used to show code examples or statically generated into webpages. If your only argument is to use typescript for maintainability reasons doesn't using JSDoc extensively both solve and improve upon that goal?
- alangpierce 8y ago
  I guess depends on exactly how you use JSDoc, but it sounds like you're talking about relatively informal documentation with some best-effort machine validation. My experience is that you don't get anywhere close to the confidence that you get with a real typechecker. Docs can be overlooked, docs can be misinterpreted, docs can get out of date, docs can be wrong by mistake. And, inevitably, if you have many people working with the same code over the course of years, these issues will be common. Having an actual typechecker avoids all of these problems, at least for documentation of data formats. If you do mean annotating all types with the thoroughness that you'd annotate TypeScript code, then really you're just writing TypeScript in JS, and TypeScript is a much more concise language than JSDoc for that.
- chrischen 8y ago
  You can try something like facebook's flow which can be done as comments so no transpiler is needed.
- cozuya 8y ago
  THANK YOU. I thought I was going crazy by being apparently the now 2nd person in the world who is perfectly happy with normal JavaScript plus slapping on JSDoc (mostly via custom vsc snippet) onto non trivial functions plugged into eslint. If I could make it fail lint when JSDoc doesn't exist I'd be perfectly fine with the maintainability of what I'm doing.
wvenable 8y ago
The real truth though is type safety isn't a hassle. If your framework/libraries are already typed, then you will actually save a huge amount of effort. When you're working on your own code then you already know the types of the parameters; it takes only a moment to type them out. And then from that point forward, the mental effort is decreased because it's one less thing you have to think about in the code. Type inference solves all the issues where entering type information was redundant and stupid. I will admit that old-school Java is maddening to work with for that reason but those days are long past now.
- sephoric 8y ago
  Not only is TypeScript's typing system less verbose, but it's smarter than old school (Java-esque) type systems. I just released a new version of Autumn[1] this morning that uses TypeScript's union types and type literals, and has this built-in: `type ModString = "command" | "control" | "option" | "shift"` so that now, even though you're still passing strings to Hotkey.activate, the IDE will actually warn you if you pass a typo like "comman". Not only that, but if you press Control-Space (same as in VS Code), it will actually auto-complete valid options for you. TypeScript is full of little goodies like this that are IDE-friendly, which is why I chose it for Autumn instead of plain JavaScript or Lua. [1] the best macOS window manager: https://sephware.com/autumn/ https://sephware.com/autumn/
  - GordonS 8y ago
    I'm primarily a C# guy, so I'm no stranger to static typing - TypeScript's type system is a real joy to work with. Between C#, F# and TypeScript, the three seem to be borrowing more and more from each other as time goes by (e.g. default interfaces and nullable reference types are coming in C# 8). It almost feels like they'll all converge at some point!
    - ivankolev 8y ago
      C# and Typescript are both co-developed by Anders Hejlsberg, so no wonder.
  - 8y ago
mbostleman 8y ago
My argument is that if you value unit tests, why not get a whole slew of them for free from the compiler?
lucidstack 8y ago
Software should be designed for ease of reading, not ease of writing. - John Ousterhout
- ken 8y ago
  It's funny to see the creator of Tcl (where nearly everything is a string, including lists, and blocks of code) quoted in a thread praising type safety. Could it be that adding type safety isn't always an improvement to readability?

maxyme 8y ago

My team has recently focused on adding JSDoc to most of our codebase and I've been thinking, JSDoc provides essentially all the benefits (and more) of typescript from a maintainability aspect and contains none of the headaches (outdated definitely typed definitions, fighting with types...). As long as you use something to validate the JSDoc comments (like the JSDoc eslint plugin) they are extremely helpful in ways very similar to typescript. Language Servers like that in VSCode (tsserver) will inherit types from JSDoc comments and provide useful annotations with both the types and descriptions. They can even be used to show code examples or statically generated into webpages. If your only argument is to use typescript for maintainability reasons doesn't using JSDoc extensively both solve and improve upon that goal?

alangpierce 8y ago
I guess depends on exactly how you use JSDoc, but it sounds like you're talking about relatively informal documentation with some best-effort machine validation. My experience is that you don't get anywhere close to the confidence that you get with a real typechecker. Docs can be overlooked, docs can be misinterpreted, docs can get out of date, docs can be wrong by mistake. And, inevitably, if you have many people working with the same code over the course of years, these issues will be common. Having an actual typechecker avoids all of these problems, at least for documentation of data formats. If you do mean annotating all types with the thoroughness that you'd annotate TypeScript code, then really you're just writing TypeScript in JS, and TypeScript is a much more concise language than JSDoc for that.
chrischen 8y ago
You can try something like facebook's flow which can be done as comments so no transpiler is needed.
cozuya 8y ago
THANK YOU. I thought I was going crazy by being apparently the now 2nd person in the world who is perfectly happy with normal JavaScript plus slapping on JSDoc (mostly via custom vsc snippet) onto non trivial functions plugged into eslint. If I could make it fail lint when JSDoc doesn't exist I'd be perfectly fine with the maintainability of what I'm doing.

wvenable 8y ago

The real truth though is type safety isn't a hassle. If your framework/libraries are already typed, then you will actually save a huge amount of effort. When you're working on your own code then you already know the types of the parameters; it takes only a moment to type them out. And then from that point forward, the mental effort is decreased because it's one less thing you have to think about in the code. Type inference solves all the issues where entering type information was redundant and stupid. I will admit that old-school Java is maddening to work with for that reason but those days are long past now.

sephoric 8y ago
Not only is TypeScript's typing system less verbose, but it's smarter than old school (Java-esque) type systems. I just released a new version of Autumn[1] this morning that uses TypeScript's union types and type literals, and has this built-in: `type ModString = "command" | "control" | "option" | "shift"` so that now, even though you're still passing strings to Hotkey.activate, the IDE will actually warn you if you pass a typo like "comman". Not only that, but if you press Control-Space (same as in VS Code), it will actually auto-complete valid options for you. TypeScript is full of little goodies like this that are IDE-friendly, which is why I chose it for Autumn instead of plain JavaScript or Lua. [1] the best macOS window manager: https://sephware.com/autumn/ https://sephware.com/autumn/
- GordonS 8y ago
  I'm primarily a C# guy, so I'm no stranger to static typing - TypeScript's type system is a real joy to work with. Between C#, F# and TypeScript, the three seem to be borrowing more and more from each other as time goes by (e.g. default interfaces and nullable reference types are coming in C# 8). It almost feels like they'll all converge at some point!
  - ivankolev 8y ago
    C# and Typescript are both co-developed by Anders Hejlsberg, so no wonder.
- 8y ago

mbostleman 8y ago

My argument is that if you value unit tests, why not get a whole slew of them for free from the compiler?

lucidstack 8y ago

Software should be designed for ease of reading, not ease of writing. - John Ousterhout

ken 8y ago
It's funny to see the creator of Tcl (where nearly everything is a string, including lists, and blocks of code) quoted in a thread praising type safety. Could it be that adding type safety isn't always an improvement to readability?