7 ms·

TypeScript for Pythonistas

87 points by zdw 5y ago

ansgri 5y ago
This made me want to learn TS — finally a non-boring type system in a mainstream language.
austincheney 5y ago
When used as a vehicle to increase productivity TypeScript type files begin to resemble XSD files (XML Schema definitions) if you have ever used those. This tends to become more true the larger a project becomes. So TypeScript is to JavaScript as XSD is to XML. The analogy isn't perfect, but it's close. The analogy doesn't seem to work for DOM composition at all. I mentioned TypeScript used for productivity. What that means is not reducing code authorship time, but instead reducing time everywhere else such as maintenance and refactoring time. The common use cases are restricting primitives to unions of accept values where appropriate, defining functions to use required typed arguments and typed output, and defining all objects against respective static types. You want your editor to yell at you as you are making code changes when things don't fit as you intended opposed to finding these problems at execution time.
- frosted-flakes 5y ago
  I recently wrote an XSD file for a fairly complex XML document format that is mostly hand-authored. It's amazing, and I agree with the analogy. VS Code even picked up on it and started to suggest valid values and highlight errors. XML seemed like the wild west before, like JS, but XSD tamed it for me.
- DangitBobby 5y ago
  When you're working on something where requirements are changing and function signatures are changing (I'm looking at you, every frontend codebase ever written), having your editor yell at you about types until you've fixed everything really cuts down on bugs.
sizediterable 5y ago
Always happy to see companies thinking about typing I wrote-up a high-level comparison between the type systems of TypeScript and mypy here that might be of interest to type enthusiasts https://news.ycombinator.com/item?id=29249328 https://news.ycombinator.com/item?id=29249328
- kitd 5y ago
  I've been writing Python for the last few months. This week I've been hacking on some JS scripts. I was missing the type hints I'd get in Python via vscode. Until it occurred to me that vscode might support jsdoc out of the box. And lo and behold it does. I was pleasantly surprised. Sometimes hints and intellisense are 90% of what you need from a type system.
  - ddoolin 5y ago
    VSCode's support of TypeScript is a boon even if you're writing vanilla JS, because it will pick up types defined by your libraries in use and now you can very quickly/easily get to the interface information without having to dig into source.
    - dopeboy 5y ago
      TS in VS code is such an elegant experience. I wanted my terminal vim to work (my setup for the past five years) but the productivity gains were too much to ignore.
      - striking 5y ago
        You can set up the TypeScript LSP for neovim! It works rather well (though I've begun to favor the Doom Emacs implementation myself).
  - mattwad 5y ago
    agree.. you don't even need "strict: true" to get 90% of the value of Typescript + probably 50% more dev time back not fighting types, but I get downvoted whenever I suggest this. I mean blame the TS team for including it if you think it's such a bad feature.
overgard 5y ago
Structural typing is really necessary in Typescript just because Javascript objects don't generally carry a class around (at least not if it's defined with the {} literal syntax). I find though, that now that I've used structural typing nominative typing is a lot more restrictive and I generally prefer the structural approach. It's especially nice with JSON objects coming from remote APIs. It is a tradeoff though, there is one thing I tend to like better about nominative typing that isn't quite as easy with structural typing, and that's reflection. Sure, you can query about keys/fields in the instance itself, but you can't match it back to say a type annotation on a class very easily. Type guards (for things like overloads) can also be a bit weird to write, for instance you can't really do an "instanceof" because that information is lost at run time, so instead you write these functions that can return "T is Cat", and that function will check for something like if the instance has a "meow" function attached. Once you get used to it it's basically fine, but it can be a bit cumbersome sometimes.
- 0xfffafaCrash 5y ago
  A lot of people don’t seem to be aware that there are a bunch of excellent runtime validation libraries that one can use to encode runtime validation checks which produce the typescript types for you (so you rarely have to write ”T is Cat” yourself where it is easy to introduce a false type) but instead can write (or even generate) trustworthy decoders that give you the types. There’s too many of these very-similar libraries to list but some of the more popular ones include io-ts, zod, purify-ts,and suretype. And while there’s no instanceof that works for non-class structured data like this, (and it wouldn’t be particularly necessary in TS only codebases), even if you were in a mixed repo where there’s a bunch of untyped JS, you could fairly easily create a wrapper with the same behavior of instanceof even without resorting to classes by using symbols. So long as the data is nonmutable, you can effectively get the equivalent of an O(1) instanceof check in JS code, but with a bit more ceremony.
  - akaptur 5y ago
    I didn't get into this in the blog post, but we use io-ts at Pilot, and we generate most of the codecs based on the type annotations on the Python side. It works reasonably well, although I think the io-ts syntax confuses people who are new to TypeScript.
twofornone 5y ago
So... is there a difference between structural typing and duck typing?
- wk_end 5y ago
  Structural typing is enforced at compile time, duck typing is "enforced" at runtime (by going up in a burst of smoke if you provide something that doesn't quack like a duck).
  - ninkendo 5y ago
    Duck typing can still be a compile-time thing… C++ templates are “duck typed” in that the template can’t specify the bounds for the passed-in type, but if you pass the wrong type, it still breaks at compile time instead of runtime. (It’s just that the error messages are way more impenetrable than they otherwise could be.)
    - wk_end 5y ago
      I’d argue that either “runtime is compile time in the case of C++ templates” and/or “C++ templates are structurally typed”, especially now that concepts are a thing. ETA: and/or that talking about C++ templates as "typed" one way or another is problematic, given that they're a part of the type system.
- RedNifre 5y ago
  I'd say structural typing is static typing (you declare the shape you want upfront), whereas duck typing is dynamic typing (it works as long as it fits, as soon as it doesn't it crashes).
- austincheney 5y ago
  Just to ensure we are talking about the same things I am using these as definitions: * https://en.wikipedia.org/wiki/Structural_type_system https://en.wikipedia.org/wiki/Structural_type_system * https://en.wikipedia.org/wiki/Duck_typing https://en.wikipedia.org/wiki/Duck_typing These are non=competing qualities. In duck typing there is no actual code interpretation, as in run time evaluation. Instead instances are compared against a type definition looking for conformance and presumed good so long as the compiler does not see a misalignment to the type definition. This is generally good enough when both the type definitions and the code instances are static qualities in the code, but exceptions can occur if there are dynamic mutations the compiler does not recognize such as extending extending a base type with a dynamic quality. Structural typing uses structures to define relationships and those relationships become points of evaluation to determine subsets. Relational evaluation is most useful in tree models such as DOM (HTML, XML), file system, certain database models like DB2, some machine learning models. The useful qualities of relationship evaluation are that you can evaluate correctness via a path, as in navigation from one node to another, and determine if a code instance is properly composed. There is some overlap between those two type definitions in TypeScript in that an object interface can be defined from various smaller interfaces. This is mostly done for code reuse, but benefits composition.
Waterluvian 5y ago
For those who are both TypeScript and Python + type hints veterans: Compared to TS, are Python typings as second class, uncomfortable, often overly verbose as I remember them to be? Have things improved?
- hsbauauvhabzb 5y ago
  Typescript is also fairly enforced by the compiler, mypy acted less restrictively. Has this changed?
- 6gvONxR4sf7o 5y ago
  I’m new to TS and have done python forever. Mypy and python type signatures are catching up, but it’s nowhere as good as typescript yet (in my limited honeymoon experience).
- amitport 5y ago
  Thing have improved, but... Compared to TS, Python typings as second class are uncomfortable and often overly verbose (probably as you remember).

87 points by zdw 5y ago

This made me want to learn TS — finally a non-boring type system in a mainstream language.

When used as a vehicle to increase productivity TypeScript type files begin to resemble XSD files (XML Schema definitions) if you have ever used those. This tends to become more true the larger a project becomes. So TypeScript is to JavaScript as XSD is to XML. The analogy isn't perfect, but it's close. The analogy doesn't seem to work for DOM composition at all. I mentioned TypeScript used for productivity. What that means is not reducing code authorship time, but instead reducing time everywhere else such as maintenance and refactoring time. The common use cases are restricting primitives to unions of accept values where appropriate, defining functions to use required typed arguments and typed output, and defining all objects against respective static types. You want your editor to yell at you as you are making code changes when things don't fit as you intended opposed to finding these problems at execution time.

frosted-flakes 5y ago
I recently wrote an XSD file for a fairly complex XML document format that is mostly hand-authored. It's amazing, and I agree with the analogy. VS Code even picked up on it and started to suggest valid values and highlight errors. XML seemed like the wild west before, like JS, but XSD tamed it for me.
DangitBobby 5y ago
When you're working on something where requirements are changing and function signatures are changing (I'm looking at you, every frontend codebase ever written), having your editor yell at you about types until you've fixed everything really cuts down on bugs.

sizediterable 5y ago

Always happy to see companies thinking about typing I wrote-up a high-level comparison between the type systems of TypeScript and mypy here that might be of interest to type enthusiasts https://news.ycombinator.com/item?id=29249328 https://news.ycombinator.com/item?id=29249328

kitd 5y ago
I've been writing Python for the last few months. This week I've been hacking on some JS scripts. I was missing the type hints I'd get in Python via vscode. Until it occurred to me that vscode might support jsdoc out of the box. And lo and behold it does. I was pleasantly surprised. Sometimes hints and intellisense are 90% of what you need from a type system.
- ddoolin 5y ago
  VSCode's support of TypeScript is a boon even if you're writing vanilla JS, because it will pick up types defined by your libraries in use and now you can very quickly/easily get to the interface information without having to dig into source.
  - dopeboy 5y ago
    TS in VS code is such an elegant experience. I wanted my terminal vim to work (my setup for the past five years) but the productivity gains were too much to ignore.
    - striking 5y ago
      You can set up the TypeScript LSP for neovim! It works rather well (though I've begun to favor the Doom Emacs implementation myself).
- mattwad 5y ago
  agree.. you don't even need "strict: true" to get 90% of the value of Typescript + probably 50% more dev time back not fighting types, but I get downvoted whenever I suggest this. I mean blame the TS team for including it if you think it's such a bad feature.

overgard 5y ago

Structural typing is really necessary in Typescript just because Javascript objects don't generally carry a class around (at least not if it's defined with the {} literal syntax). I find though, that now that I've used structural typing nominative typing is a lot more restrictive and I generally prefer the structural approach. It's especially nice with JSON objects coming from remote APIs. It is a tradeoff though, there is one thing I tend to like better about nominative typing that isn't quite as easy with structural typing, and that's reflection. Sure, you can query about keys/fields in the instance itself, but you can't match it back to say a type annotation on a class very easily. Type guards (for things like overloads) can also be a bit weird to write, for instance you can't really do an "instanceof" because that information is lost at run time, so instead you write these functions that can return "T is Cat", and that function will check for something like if the instance has a "meow" function attached. Once you get used to it it's basically fine, but it can be a bit cumbersome sometimes.

0xfffafaCrash 5y ago
A lot of people don’t seem to be aware that there are a bunch of excellent runtime validation libraries that one can use to encode runtime validation checks which produce the typescript types for you (so you rarely have to write ”T is Cat” yourself where it is easy to introduce a false type) but instead can write (or even generate) trustworthy decoders that give you the types. There’s too many of these very-similar libraries to list but some of the more popular ones include io-ts, zod, purify-ts,and suretype. And while there’s no instanceof that works for non-class structured data like this, (and it wouldn’t be particularly necessary in TS only codebases), even if you were in a mixed repo where there’s a bunch of untyped JS, you could fairly easily create a wrapper with the same behavior of instanceof even without resorting to classes by using symbols. So long as the data is nonmutable, you can effectively get the equivalent of an O(1) instanceof check in JS code, but with a bit more ceremony.
- akaptur 5y ago
  I didn't get into this in the blog post, but we use io-ts at Pilot, and we generate most of the codecs based on the type annotations on the Python side. It works reasonably well, although I think the io-ts syntax confuses people who are new to TypeScript.

twofornone 5y ago

So... is there a difference between structural typing and duck typing?

wk_end 5y ago
Structural typing is enforced at compile time, duck typing is "enforced" at runtime (by going up in a burst of smoke if you provide something that doesn't quack like a duck).
- ninkendo 5y ago
  Duck typing can still be a compile-time thing… C++ templates are “duck typed” in that the template can’t specify the bounds for the passed-in type, but if you pass the wrong type, it still breaks at compile time instead of runtime. (It’s just that the error messages are way more impenetrable than they otherwise could be.)
  - wk_end 5y ago
    I’d argue that either “runtime is compile time in the case of C++ templates” and/or “C++ templates are structurally typed”, especially now that concepts are a thing. ETA: and/or that talking about C++ templates as "typed" one way or another is problematic, given that they're a part of the type system.
RedNifre 5y ago
I'd say structural typing is static typing (you declare the shape you want upfront), whereas duck typing is dynamic typing (it works as long as it fits, as soon as it doesn't it crashes).
austincheney 5y ago
Just to ensure we are talking about the same things I am using these as definitions: * https://en.wikipedia.org/wiki/Structural_type_system https://en.wikipedia.org/wiki/Structural_type_system * https://en.wikipedia.org/wiki/Duck_typing https://en.wikipedia.org/wiki/Duck_typing These are non=competing qualities. In duck typing there is no actual code interpretation, as in run time evaluation. Instead instances are compared against a type definition looking for conformance and presumed good so long as the compiler does not see a misalignment to the type definition. This is generally good enough when both the type definitions and the code instances are static qualities in the code, but exceptions can occur if there are dynamic mutations the compiler does not recognize such as extending extending a base type with a dynamic quality. Structural typing uses structures to define relationships and those relationships become points of evaluation to determine subsets. Relational evaluation is most useful in tree models such as DOM (HTML, XML), file system, certain database models like DB2, some machine learning models. The useful qualities of relationship evaluation are that you can evaluate correctness via a path, as in navigation from one node to another, and determine if a code instance is properly composed. There is some overlap between those two type definitions in TypeScript in that an object interface can be defined from various smaller interfaces. This is mostly done for code reuse, but benefits composition.

Waterluvian 5y ago

For those who are both TypeScript and Python + type hints veterans: Compared to TS, are Python typings as second class, uncomfortable, often overly verbose as I remember them to be? Have things improved?

hsbauauvhabzb 5y ago
Typescript is also fairly enforced by the compiler, mypy acted less restrictively. Has this changed?
6gvONxR4sf7o 5y ago
I’m new to TS and have done python forever. Mypy and python type signatures are catching up, but it’s nowhere as good as typescript yet (in my limited honeymoon experience).
amitport 5y ago
Thing have improved, but... Compared to TS, Python typings as second class are uncomfortable and often overly verbose (probably as you remember).