The real benefit of a statically typed language, especially one like TypeScript with a rich type system, is that you get to express your application in terms of the type system, and that you tend to think a lot more about your data structures.
You can, for example, make invalid states impossible to represent. This can catch a huge number of bugs and prevent some types of bugs from ever appearing.
If you're using something like ChatGPT or some other automated system to add types to your code you have adopted a type system with receiving very little of the benefits. You end up with many of the drawbacks and only a little of the reward.
You can, for example, make invalid states impossible to represent. This can catch a huge number of bugs and prevent some types of bugs from ever appearing.
I've yet to see these claims realised not by a handful of type gurus with ad-hoc type-level DSLs, but in a more-or-less generic way applicable in every day use.
You definitely have seen it work if you've worked in any statically typed language, for example:
// this will (hopefully) not compile in your favorite language
int i = "Hello World"
Using type systems to enforce business logic is applying the same concept, just at higher levels of abstraction.
Usually you will want (or need) to use the more advanced type features that your language offers, like generics and algebraic data types.
There certainly is a cost to learning these concepts, but the good thing is that many languages borrow these same concepts, so the knowledge easily transfers.
The gulf between this and "make invalid states impossible to represent" is a vast as the void between two galaxies.
Using type systems to enforce business logic is applying the same concept, just at higher levels of abstraction.
"Just"
There certainly is a cost to learning these concepts, but the good thing is that many languages borrow these same concepts, so the knowledge easily transfers.
To repeat myself: I've yet to see these claims realised not by a handful of type gurus with ad-hoc type-level DSLs, but in a more-or-less generic way applicable in every day use.
It's sort of postponing the actual work, though: there is indeed value in asserting that your code adheres to some domain model, but it's not entirely clear to me whether the value is outweighed by the friction when that arbitrary ChatGPT-generated domain model disagrees with your domain. There is dramatically more value in asserting that your code adheres to the correct domain model, and you can only know that by, well, modelling your domain.
This is true, but: it’s far easier to get there once you have gotten types in place in the first place—because that kind of domain modeling very often entails non-trivial refactoring work. Our guidance to folks when I was at LinkedIn was that as much as PRs possible adding types should not change the runtime code at all, only describe what was already there (even if it was really dumb!). That meant TS conversions were never going to be at fault for prod issues, only for fixing prod issues; and it therefore also meant that those PRs were much less likely to get reverted… which is super important since a revert would then have knock-on effects on any other modules which relied on the types from the reverted PR.
Comments
The real benefit of a statically typed language, especially one like TypeScript with a rich type system, is that you get to express your application in terms of the type system, and that you tend to think a lot more about your data structures.
You can, for example, make invalid states impossible to represent. This can catch a huge number of bugs and prevent some types of bugs from ever appearing.
If you're using something like ChatGPT or some other automated system to add types to your code you have adopted a type system with receiving very little of the benefits. You end up with many of the drawbacks and only a little of the reward.
I've yet to see these claims realised not by a handful of type gurus with ad-hoc type-level DSLs, but in a more-or-less generic way applicable in every day use.
You definitely have seen it work if you've worked in any statically typed language, for example:
// this will (hopefully) not compile in your favorite language
int i = "Hello World"
Using type systems to enforce business logic is applying the same concept, just at higher levels of abstraction.
Usually you will want (or need) to use the more advanced type features that your language offers, like generics and algebraic data types.
There certainly is a cost to learning these concepts, but the good thing is that many languages borrow these same concepts, so the knowledge easily transfers.
The gulf between this and "make invalid states impossible to represent" is a vast as the void between two galaxies.
"Just"
To repeat myself: I've yet to see these claims realised not by a handful of type gurus with ad-hoc type-level DSLs, but in a more-or-less generic way applicable in every day use.
You can do a refactoring later, or reap the benefits of typescript for all new code.
ChatGPT here doesn't need to do a good job. You get value just by getting a codebase type-annotated.
It's sort of postponing the actual work, though: there is indeed value in asserting that your code adheres to some domain model, but it's not entirely clear to me whether the value is outweighed by the friction when that arbitrary ChatGPT-generated domain model disagrees with your domain. There is dramatically more value in asserting that your code adheres to the correct domain model, and you can only know that by, well, modelling your domain.
This is true, but: it’s far easier to get there once you have gotten types in place in the first place—because that kind of domain modeling very often entails non-trivial refactoring work. Our guidance to folks when I was at LinkedIn was that as much as PRs possible adding types should not change the runtime code at all, only describe what was already there (even if it was really dumb!). That meant TS conversions were never going to be at fault for prod issues, only for fixing prod issues; and it therefore also meant that those PRs were much less likely to get reverted… which is super important since a revert would then have knock-on effects on any other modules which relied on the types from the reverted PR.
also when i edit one file, i can just run tsc --noEmit and i will see the list of affected files.
smoothest workflow ever.