5 ms·

Typescript is bad for library developers who have produced bad[0] APIs and don't want[1] to refactor them. Overloads exist in Typescript because as a language

Typescript is bad for library developers who have produced bad[0] APIs and don't want[1] to refactor them. Overloads exist in Typescript because as a language it needs to support what javascript supports - regardless of whether the pattern is "good". Overloads are heavily used in DefinitelyTyped because contributors there haven't had the luxury of designing the APIs they're typing. If you're designing your own API, you shouldn't be heavily using overloads because typed languages don't encourage the ridiculous trend of movable arguments that jQuery pioneered in the JS world. Similarly, if you're writing all of your own code you shouldn't need type manipulation because you shouldn't be leaning heavily on variable mutation. Dogmatic stances on immutability are reasonably a matter of debate, but it's fairly uncontroversial to state that minimising mutation in your data flows helps prevent your code becoming an unmaintainable mess. Etc. [0］Writing good APIs is hard - bad APIs are inevitable. Typed languages make refactoring faster. [1] Refactoring untyped languages is very hard and the tendency not to is deeply ingrained and very natural/reasonable.

ajkjk 4y ago
This, 100%. In this very comment section there are a bunch of people saying "I maintain <API with crazy unnecessary complexity in it> and I can't figure out how to translate it to TS". Well yeah, that API sucks, make a simple one instead.
- progx 4y ago
  You never had a complex project?
  - Aeolun 4y ago
    Not by choice. If it’s my library I have options.
  - lucideer 4y ago
    There's two types of complexity: necessary and unnecessary. You may need to reread the comment above.
jcparkyn 4y ago
> You shouldn't need type manipulation because you shouldn't be leaning heavily on variable mutation What does type manipulation have to do with variable mutation? The main examples in the OP were of redux and related libraries, which use huge amounts of type manipulation but almost no mutation. I'm honestly not sure where the link between these two things would be, because to me they seem completely orthogonal.
- lucideer 4y ago
  "type manipulation" is a broad section in the TS handbook - it even includes very core things like generics. So I admit I did jump the gun on focusing on parts of it that may be more exceptional/messy in their application (& lead to difficult-to-work-with types); like conditional types or assertions. After diving into the OPs linked examples, it appears that all they mean when they say "type manipulation" is just... generics. Generics can be as simple or as convoluted as you write them. The linked examples certainly does look over-engineered: if you've got identifiers like `ActionCreatorForCaseReducerWithPrepare` in your library, you're entering into Java managermanager meme level of silliness there. That's not something you can blame Typescript for.
lmeyerov 4y ago
I much rather blame the type system designers, however heroic and brilliant they may be, than the folks using them. Especially so in scenarios like large & collaborative evolving code bases, legacy, module composition, evolving tools, etc. That some API doesn't conform to the abysmal ergonomics and astounding stupidity of most type systems isn't a problem with the API, but an endemic problem of modern type systems being dumb, weak, and hard-to-use. To an embarrassing extent, even most "advanced" type systems aren't super far from what came out of the 1970s. After writing ML-typed code for years, you learn the disappointingly primitive level of reasoning most textbook solvers can handle, and warp your code style ahead of time to that. Simpler calling conventions, all sorts of hints to inferencers, hacks around IO, etc. Language implementors know these systems have major issues in practice and thus tack layer after layer of weird special forms to handle what is "natural" in modern code. And then you get junior developers on a team, and have to pretend that this is all good and then hope they don't quit when they get byzantine type errors. And not tear your hair out when some library updates around these changes. In a world where you can write 10 words of English and get synthesized a unique photorealistic image, or can sketch some code and get it autocompleted, maybe the problem is most type systems (still) suck. It's not inherent because we can manually reason about code & even run it -- and shifts to previously sacrilegious research like plugging in SMT solvers and neural networks has been changing historically conservative fundamental assumptions at a snails pace -- but that's where we are. So again, I wouldn't categorically blame the poor developers subjected to embarrassingly dumb solvers & UX's.
- dmix 4y ago
  You’re probably right but much of that is the consequence of having the baggage of using JS and the legacy of popular libraries that will get mashed through typescript with heavy influence on its spec. TS (probably) didnt have the luxury of thinking it out the necessary constraints and foundations for a top tier type system. Of course there were some bad choices like the XOR Union stuff mentioned elsewhere in this thread, but all of those make sense when you consider the type of code typically written in JS (before TS). Typescript was probably never going to become popular if it tried to reach that ideal. But it provides way more safety bumpers for junior devs than JS previously had so regardless it’s a major step forward than whatever custom creation we used to hand each dev.

ajkjk 4y ago

This, 100%. In this very comment section there are a bunch of people saying "I maintain <API with crazy unnecessary complexity in it> and I can't figure out how to translate it to TS". Well yeah, that API sucks, make a simple one instead.

progx 4y ago
You never had a complex project?
- Aeolun 4y ago
  Not by choice. If it’s my library I have options.
- lucideer 4y ago
  There's two types of complexity: necessary and unnecessary. You may need to reread the comment above.

jcparkyn 4y ago

> You shouldn't need type manipulation because you shouldn't be leaning heavily on variable mutation What does type manipulation have to do with variable mutation? The main examples in the OP were of redux and related libraries, which use huge amounts of type manipulation but almost no mutation. I'm honestly not sure where the link between these two things would be, because to me they seem completely orthogonal.

lucideer 4y ago
"type manipulation" is a broad section in the TS handbook - it even includes very core things like generics. So I admit I did jump the gun on focusing on parts of it that may be more exceptional/messy in their application (& lead to difficult-to-work-with types); like conditional types or assertions. After diving into the OPs linked examples, it appears that all they mean when they say "type manipulation" is just... generics. Generics can be as simple or as convoluted as you write them. The linked examples certainly does look over-engineered: if you've got identifiers like `ActionCreatorForCaseReducerWithPrepare` in your library, you're entering into Java managermanager meme level of silliness there. That's not something you can blame Typescript for.

lmeyerov 4y ago

I much rather blame the type system designers, however heroic and brilliant they may be, than the folks using them. Especially so in scenarios like large & collaborative evolving code bases, legacy, module composition, evolving tools, etc. That some API doesn't conform to the abysmal ergonomics and astounding stupidity of most type systems isn't a problem with the API, but an endemic problem of modern type systems being dumb, weak, and hard-to-use. To an embarrassing extent, even most "advanced" type systems aren't super far from what came out of the 1970s. After writing ML-typed code for years, you learn the disappointingly primitive level of reasoning most textbook solvers can handle, and warp your code style ahead of time to that. Simpler calling conventions, all sorts of hints to inferencers, hacks around IO, etc. Language implementors know these systems have major issues in practice and thus tack layer after layer of weird special forms to handle what is "natural" in modern code. And then you get junior developers on a team, and have to pretend that this is all good and then hope they don't quit when they get byzantine type errors. And not tear your hair out when some library updates around these changes. In a world where you can write 10 words of English and get synthesized a unique photorealistic image, or can sketch some code and get it autocompleted, maybe the problem is most type systems (still) suck. It's not inherent because we can manually reason about code & even run it -- and shifts to previously sacrilegious research like plugging in SMT solvers and neural networks has been changing historically conservative fundamental assumptions at a snails pace -- but that's where we are. So again, I wouldn't categorically blame the poor developers subjected to embarrassingly dumb solvers & UX's.

dmix 4y ago
You’re probably right but much of that is the consequence of having the baggage of using JS and the legacy of popular libraries that will get mashed through typescript with heavy influence on its spec. TS (probably) didnt have the luxury of thinking it out the necessary constraints and foundations for a top tier type system. Of course there were some bad choices like the XOR Union stuff mentioned elsewhere in this thread, but all of those make sense when you consider the type of code typically written in JS (before TS). Typescript was probably never going to become popular if it tried to reach that ideal. But it provides way more safety bumpers for junior devs than JS previously had so regardless it’s a major step forward than whatever custom creation we used to hand each dev.