31–40 of 82 posts
[flagged]
At this point, folks are seeing how far they can push the Typescript type system because it's capable of expressing so, so much more with its types than is seen typically(including in most other languages).
[flagged]
Earlier quoted context omitted.
The static types depicted in typescript are entirely fictitious. Any similarity to runtime types is purely coincidental.
This is such a cynical take. The point is to model what types exist at runtime in the type system, so that you can reason about those same runtime types statically. They’re only “fictitious” if they’re defined incorrectly, or if the type system can’t sufficiently express certain of their nuances. The former is usually only the case when developers intentionally work around the safety provided by the type system; the…
When defining types in other languages, the task is prescriptive (you specify what fields there are in a type and the runtime accepts this as law), but in Typesxript the task is meant to be descriptive (as you say, one models the types that exist at runtime which is the inverse).
I was excited about Typescript when I learned it, but found myself disillusioned by actual experience when using it (of course others love it and have good reason to). Had defined classes in Typescript so I can have some of my types reflected at runtime.
Reminds me of Idris: https://gist.github.com/chrisdone/672efcd784528b7d0b7e17ad9c... Recently though, I've been wondering whether advanced type system stuff is the right approach. It usually becomes pretty complicated, like another language on top of the regular language. Maybe it would be easier to have some kind of framework for compiler plugins that do extra checks. Something that would make it easy to check forma…
Go has adopted a similar approach to this - they've made it fairly easy to write separate plugins that check stuff like this. The plugins aren't executed as part of the compiler though, they're standalone tools. For example, see golangci-lint, which bundles together a load of plugins of this kind.
Some of these plugins are shipped within the go command directly, as part of the "go vet" subcommand. (including a printf format check, which is similar to what's described in this post, i.e. it checks that arguments are of the correct type).
I've been kind of curious why tricks like this aren't used more to make sql and such. Heck, you could do similar tricks for shell execution. Or any general "string that is parseable." Seems we always take the route of not parsing the string as much as we can?
Some languages don't support this.
The languages that do would require extensive systems to implement this feature. It may simply not be a priority over other requirements like thread safety, atomicity, etc.
> similar tricks for shell execution
Shell only supports strings, integers and lists. The type system is too limited for this level of type-checking.
This works in typescript due to the advanced type operations built into the language.
Which is to say, these names almost always make types like this more clear:
- Head: the first item in the input type you’re iterating through
- Tail: the remaining items or unprocessed structure you’ll likely recurse on next
- Acc (or pick your favorite “reduced” idiom): a named type for the intermediate product which will become the final type when you finish iterating. This can be provided as an optional parameter with an empty tuple as its default, largely modeling a typical reduce (apart from inverting the common parameter order).
It also helps, IME, to put a “base case” first in the type’s conditions.
When all of these names and patterns are utilized, the resulting type tends to look quite a lot like an equivalent runtime function you could encounter for producing the value equivalent to its type. This is great because you can even write the runtime function to match the type’s logic. This demonstrates both what the type is doing for people who find these “complex types” intimidating, and that the type accurately describes the value it’s associated with.
Minor nit: I’ve found types like these—that is, iterative recursive types—benefit from using terminology common to map/reduce. And by “benefit from”, I mean become more understandable by a wider audience—not necessarily the HN audience per se, but quite likely teammates and future selves. Which is to say, these names almost always make types like this more clear: - Head: the first item in the input type you’re iterat…
They’re great in small doses where you really need them, but overuse or widespread use of complex types will make your build slower. It’s much better to avoid generics or mapped types if you can. The typings for a tagged template literal (without digit format specifiers like %d4) don’t require any generics.
I love to write code like this, but I’m guilty of over using fancy types and I flinch when I see a typescript build profile showing 45s+ spent on generic types I wrote without realizing the cost.
Earlier quoted context omitted.
Pretty easy to succeed when it's the only language a browser supports.
It wasn't the only language browsers (vbscript was allowed client side in early ie) supported and also isn't anymore with wasm
I don't buy this, considering that wasm still doesn't actually have access to the Web APIs that JavaScript has access to (and relies on JS to even be loaded in the first place).
In my opinion, if that's what counts as being a supported language, then JS was never the only supported language to begin with since you could always compile other languages to run on the web through JavaScript (for example Emscripten with the asm.js target predates WebAssembly). The only thing that wasm currently offers over the previous status quo is that it's faster (for some workloads).
Earlier quoted context omitted.
The static types depicted in typescript are entirely fictitious. Any similarity to runtime types is purely coincidental.
Yeah. I see a lot of "typescript is more readable" arguments out there, but I find this code dense and verbose. The more words you use to explain something the more likely you are to be misunderstood. What we're looking at here is basically a restricted wrapper for console.log and a regex implementation meant to simulate a logger in another language. Why not just write a cross-compiler for that language? There's no l…
The reason you wouldn't want a cross-compiler for that other language is that there are true semantic differences between languages, and many languages simply cannot fully support the JS runtime- and if your primary application is still in Typescript, trying to cross-compile for a single feature is downright ridiculous.
> The invention, support and defense of Typescript baffles me. It feels like an intensely wasteful work-around for poorly written interpreter error messages concocted by comp-sci grads who think compiled languages are superior to interpreted ones in all situations and they want to bring this wisdom to developers of loosely typed languages.
I sincerely don't think statically typed languages are superior, but I'd argue a large part of the increase in quality over the last few years of the ecosystem is due in large part to Typescript.
Is it going to fix all, or even a majority of the issues? Probably not. But if it can improve upon the situation I don't see why we'd make perfect the enemy of good.