6 ms·

This is definitely something that typescript constantly lures you into. I recently switched back to JS for a prototype of a programming language. I immediatel

by Garlef 6y ago

This is definitely something that typescript constantly lures you into. I recently switched back to JS for a prototype of a programming language. I immediately felt more productive. At times, the TS systems feels like a theorem prover. Until it doesn't. And then you're left with a bunch of types that almost do what you want... but not quite; Always tempted to experiment again for a day or two. But let's see what happens down the road. Maybe I'll miss the incidental documentation the typings provide.

teh_klev 6y ago
This isn't a fault of TypeScript, but any language. Trying to predict the future, trying to predict and eliminate technical debt, in a rapidly developing product.
- dimitrios1 6y ago
  But it is the fault of TypeScript for having such an obvious path for falling into that trap. Part of what it means to have TypeScript code is to have typing files. Part of good language design is attempting to minimize bad programming habits. In this case, a language with a HM type system would avoid the issue all together, while affording the same productivity gains from having static types.
  - eyelidlessness 6y ago
    This isn’t actually a fault of TS, it’s an explicit goal. They design the type system not to guide usage but to make existing usage explicit and trustworthy. The places where the type system encourage rabbit holing are almost always where bad types/APIs are already prevalent. Where you’re starting at the type level and don’t have an inclination to allow all manner of dynamic nonsense it’s not that different from types in an ML-family language.
munchbunny 6y ago
One of the things I learned, not from TypeScript but from other languages with type systems that work similarly, is to minimize the use of type decorations and let type inference do most of the heavy lifting. It took some getting used to because things end up a bit less obvious, but I found that with the IDE's syntax highlighting capabilities, actually inspecting the inferred types isn't as much of an issue. And then you spend less time typing out type names.
orangecat 6y ago
Huh. I recently built a language parser in TypeScript and it was a very positive experience. As just one example, discriminated unions for AST nodes worked great. Always tempted to experiment again for a day or two. Maybe that's it. I've never felt bad about settling for 95% of the benefits of static typing and slapping any/unknown on the edge cases.
lmm 6y ago
Yeah, see how it goes when your system gets past about 20kloc. In my experience working without types starts out great but you soon hit a wall.
seer 6y ago
I used to think this way too, but working over the years with TypeScript has gotten me so accustomed to it that it’s now the other way around. I feel much more productive in TS in general. With TS its like you’re writing the unit test and your code at the same time, and if your types are expressed well enough you can also skip the compile+run+verify step. I’ve had cases where I would spend days just writing code, refactoring and iterating, without building the project once, compile it at the end, and have a complex feature work correctly on first try, passing all the functional tests. It’s like I have a pair working with me constantly compiling my code and pointing out syntax and interface errors while I concentrate on the business logic and big picture stuff. When I go back to JS it’s as if I now have to do all that manual labour too, as well as constantly write and run unit tests myself to make sure what I write actually works. Though it definitely took some time to get this comfortable with the TS type system.
- bdefore 6y ago
  Perhaps much like the parent, I want to create without the foundation of TDD or unit tests, so I find the mixture to be expensive in the cases I'm typically working.
mewpmewp2 6y ago
For my company production code I definitely spend way too much trying to implement the correct types, however for side projects and MVPs I do quickly what I have already learned or just sometimes if it's too complicated I'll just go with "any" styled solutions or similar things. I think using TypeScript flexibly for prototypes helps me do that "first compile test" will work out of the box very easily.
reader_mode 6y ago
Don't treat types as theorem provers, treat them as formalized docs - getting dirty with dynamic under the hood is perfectly acceptable to me (say you're doing some metaprogramming - typing that out is usually a lot of effort for low gain) - the types just help define intended use. In code consuming types I relie on inference 80% of the time, sometimes I need to specify generics, if it fails I do dirty casts, if that fails I do dynamic blocks.

by Garlef 6y ago

teh_klev 6y ago

This isn't a fault of TypeScript, but any language. Trying to predict the future, trying to predict and eliminate technical debt, in a rapidly developing product.

dimitrios1 6y ago
But it is the fault of TypeScript for having such an obvious path for falling into that trap. Part of what it means to have TypeScript code is to have typing files. Part of good language design is attempting to minimize bad programming habits. In this case, a language with a HM type system would avoid the issue all together, while affording the same productivity gains from having static types.
- eyelidlessness 6y ago
  This isn’t actually a fault of TS, it’s an explicit goal. They design the type system not to guide usage but to make existing usage explicit and trustworthy. The places where the type system encourage rabbit holing are almost always where bad types/APIs are already prevalent. Where you’re starting at the type level and don’t have an inclination to allow all manner of dynamic nonsense it’s not that different from types in an ML-family language.

munchbunny 6y ago

One of the things I learned, not from TypeScript but from other languages with type systems that work similarly, is to minimize the use of type decorations and let type inference do most of the heavy lifting. It took some getting used to because things end up a bit less obvious, but I found that with the IDE's syntax highlighting capabilities, actually inspecting the inferred types isn't as much of an issue. And then you spend less time typing out type names.

orangecat 6y ago

Huh. I recently built a language parser in TypeScript and it was a very positive experience. As just one example, discriminated unions for AST nodes worked great. Always tempted to experiment again for a day or two. Maybe that's it. I've never felt bad about settling for 95% of the benefits of static typing and slapping any/unknown on the edge cases.

lmm 6y ago

Yeah, see how it goes when your system gets past about 20kloc. In my experience working without types starts out great but you soon hit a wall.

seer 6y ago

I used to think this way too, but working over the years with TypeScript has gotten me so accustomed to it that it’s now the other way around. I feel much more productive in TS in general. With TS its like you’re writing the unit test and your code at the same time, and if your types are expressed well enough you can also skip the compile+run+verify step. I’ve had cases where I would spend days just writing code, refactoring and iterating, without building the project once, compile it at the end, and have a complex feature work correctly on first try, passing all the functional tests. It’s like I have a pair working with me constantly compiling my code and pointing out syntax and interface errors while I concentrate on the business logic and big picture stuff. When I go back to JS it’s as if I now have to do all that manual labour too, as well as constantly write and run unit tests myself to make sure what I write actually works. Though it definitely took some time to get this comfortable with the TS type system.

bdefore 6y ago
Perhaps much like the parent, I want to create without the foundation of TDD or unit tests, so I find the mixture to be expensive in the cases I'm typically working.

mewpmewp2 6y ago

For my company production code I definitely spend way too much trying to implement the correct types, however for side projects and MVPs I do quickly what I have already learned or just sometimes if it's too complicated I'll just go with "any" styled solutions or similar things. I think using TypeScript flexibly for prototypes helps me do that "first compile test" will work out of the box very easily.

reader_mode 6y ago

Don't treat types as theorem provers, treat them as formalized docs - getting dirty with dynamic under the hood is perfectly acceptable to me (say you're doing some metaprogramming - typing that out is usually a lot of effort for low gain) - the types just help define intended use. In code consuming types I relie on inference 80% of the time, sometimes I need to specify generics, if it fails I do dirty casts, if that fails I do dynamic blocks.