Are there (m)any other languages with type systems as flexible and powerful as Typescript's?
[deleted]
Extreme explorations of TypeScript's type system
31–40 of 64 posts
Re: Extreme explorations of TypeScript's type system
#32Are there (m)any other languages with type systems as flexible and powerful as Typescript's?
I believe that typescript type system is so flexible, powerful and complex just because it had to be adapted and built around the shortcomings and limitation of javascript. It makes no sense to have something like it if you build a language from the ground up (or if you could just scrap backward compatibility in a bad designed one)
Re: Extreme explorations of TypeScript's type system
#33> If you do find a need to use type operations, please—for the sake of any developer who has to read your code, including a future you—try to keep them to a minimum if possible. Use readable names that help readers understand the code as they read it. Leave descriptive comments for anything you think future readers might struggle with. Also, as you start getting complicated logic in your types, you need to test your…
I lost it when at my previous job I found a 20 multiline super complex type defined by another dev, asked him to describe it because I was in a tight deadline and had not time to parse whatever he was defining. He starts with "it's pretty simple" and then used like 10 minutes to describe me what he meant while writing on paper the various pieces getting confused two times. At the end of the day it could be simplified in a one line union type of a few strings which would cover 99% of the usecases and the other 1% was something we had never used and would never use.
I really wish people would focus more on keeping types as simple as possible instead of using that complexity just because the language allowed it.
Re: Extreme explorations of TypeScript's type system
#34Some other type-only TS projects: - RegExp matching through types: https://github.com/desi-ivanov/ts-regexp - Lambda calculus through types: https://github.com/desi-ivanov/ts-lambda-calc - Brainfuck through types: https://github.com/susisu/typefuck
These are wonderful, thank you!
Re: Extreme explorations of TypeScript's type system
#35You can do some truly silly things with sufficiently ridiculous uses of typescript. I built a typecheck-time spell checker[0] in it such that: import { ValidWords } from "./spellcheck"; // Typechecks cleanly: const result: ValidWords = "valid"; // Throws a type error const result: ValidWords = "valid"; [0] https://github.com/kkuchta/TSpell
How long does this take to compile?
Re: Extreme explorations of TypeScript's type system
#36> If you do find a need to use type operations, please—for the sake of any developer who has to read your code, including a future you—try to keep them to a minimum if possible. Use readable names that help readers understand the code as they read it. Leave descriptive comments for anything you think future readers might struggle with. Also, as you start getting complicated logic in your types, you need to test your…
We do a _lot_ of this in the Redux library repos (examples: [0] [1] [2] ). We have some incredibly complicated types in our libraries, and we have a bunch of type tests to confirm expected behavior. Generally, these can just be some TS files that get compiled with `tsc`, but it helps to have a bunch of type-level assertions about expected types. I actually recently gave a talk on "Lessons Learned Maintaining TS Libra…
Hey Mark, I’m actually currently looking at a similar problem.
I’m writing a HTTP client based on composition. The exact details aren’t important, but one of the goals is to have a strong type system for describing a valid pipeline of things like response parsers. Imagine something like
Doing “type tests” alone isn’t too hard - we can just use conditional types and the extends keyword. If the code compiles, fine.
But the harder part is negative type tests. “Given this code, the developer should get this error from TSC”. But this is just as important a part of the API; your types are there to convince the consumer that they can call a type-checked API with confidence.
In theory it should be plausible to run TSC programmatically. The issue is that TypeScript’s ScriptProcessor API really wants to be called with files on the filesystem rather than source text. So I am having to do some bodging. If I can get something sorted I may write a repo to demo it, I think it is a common problem.
Re: Extreme explorations of TypeScript's type system
#37Earlier quoted context omitted.
We do a _lot_ of this in the Redux library repos (examples: [0] [1] [2] ). We have some incredibly complicated types in our libraries, and we have a bunch of type tests to confirm expected behavior. Generally, these can just be some TS files that get compiled with `tsc`, but it helps to have a bunch of type-level assertions about expected types. I actually recently gave a talk on "Lessons Learned Maintaining TS Libra…
Hey Mark, I’m actually currently looking at a similar problem. I’m writing a HTTP client based on composition. The exact details aren’t important, but one of the goals is to have a strong type system for describing a valid pipeline of things like response parsers. Imagine something like Doing “type tests” alone isn’t too hard - we can just use conditional types and the extends keyword. If the code compiles, fine. But…
I use @ts-expect-error for testing the negative case, but if there was a practical way of testing the actual error reported that would be wonderful.
Re: Extreme explorations of TypeScript's type system
#38You can do some truly silly things with sufficiently ridiculous uses of typescript. I built a typecheck-time spell checker[0] in it such that: import { ValidWords } from "./spellcheck"; // Typechecks cleanly: const result: ValidWords = "valid"; // Throws a type error const result: ValidWords = "valid"; [0] https://github.com/kkuchta/TSpell
so that's great and I know this wasn't your point but ....
I use this VSCode extension
https://marketplace.visualstudio.com/items?itemName=streetsi...
To spell check my code. It's surprisingly useful. It doesn't check at compile time but it does check camelCase and snake_case and even in typescript code I've found it highlight various actual issues.
Re: Extreme explorations of TypeScript's type system
#39Are there (m)any other languages with type systems as flexible and powerful as Typescript's?
I believe that typescript type system is so flexible, powerful and complex just because it had to be adapted and built around the shortcomings and limitation of javascript. It makes no sense to have something like it if you build a language from the ground up (or if you could just scrap backward compatibility in a bad designed one)
I think I disagree (though happy to be corrected). It's common to have dervied types (example Base = Shape, Derived = Circle, Rectangle, Hexagon). Often you have a collection of Shape and often there is some runtime code that can go from a Base type to a Dervied type based on some key or value but the relationship between the key and the Dervied type is rarely directly expressed in the type system where as in typescript it can be.
I think an example is how typescript can know, based on the first argument to a listener, what the Event type coming in will be
elem.addEventListner('mousedown', (foo) => {...});
elem.addEventListner('keydown', (bar) => {...});
Of course you could argue that `addEventListener` is just bad design but I feel like there are legit uses to being able to associate an enum or string with type and I haven't seen that feature in other languages I've used.
Re: Extreme explorations of TypeScript's type system
#40Earlier quoted context omitted.
So does spellcheck contain a gigantic array of the English language?
the source code to answer your question is directly above your question
I'm inclined to cut someone a bit of slack for not following the link to the implementation if the context suggests deeply nested template meta programming golf is involved. It's surprisingly much less complicated than I would have expected.