[HN Gopher] TypeScript for Pythonistas
___________________________________________________________________
TypeScript for Pythonistas
Author : zdw
Score : 54 points
Date : 2021-12-16 04:39 UTC (1 days ago)
(HTM) web link (medium.com)
(TXT) w3m dump (medium.com)
| austincheney wrote:
| 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 wrote:
| 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.
| overgard wrote:
| 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.
| tshaddox wrote:
| > 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
|
| Isn't the normal way to do this in TS to use discriminated
| unions, where you just store the type right there on the object
| as a string (perhaps in a key called "tag" or "type")? I love
| discriminated unions, and needing to explicitly carry around
| that discriminator is a bit awkward coming from, say, OCaml,
| but it's still my default way of modeling most things in TS.
| 0xfffafaCrash wrote:
| 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.
| sizediterable wrote:
| 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
| kitd wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| striking wrote:
| I don't totally disagree, but I've found that you lose
| whatever dev time you might have thought you gained where
| bugs crop up and the type system isn't helping you fix
| them. I've ended up in a situation where the codebase was
| typed and the test cases weren't, and the test cases had
| plenty of issues that were ridiculously hard to debug
| because we let the tests remain untyped.
| twofornone wrote:
| So... is there a difference between structural typing and duck
| typing?
| austincheney wrote:
| 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/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.
| wk_end wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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).
___________________________________________________________________
(page generated 2021-12-17 23:01 UTC)