3 ms·

I'd kinda prefer it then, too. If it's short and I'm just scripting stuff up it's probably mostly calls to existing code (libraries) so almost all the static ty

I'd kinda prefer it then, too. If it's short and I'm just scripting stuff up it's probably mostly calls to existing code (libraries) so almost all the static typing would do is tell me when I'm screwing up and give me hints for valid arguments with types and names, with little or no added overhead. It'd be very nice.

MaulingMonkey 6y ago
Consuming types in that context is nice, defining them is what's generally a PITA / extra boilerplate / overhead. To take a concrete example that could go both ways: Say you want to parse a JSON blob for some task. On the one end, you could access it through dynamic typing, or tools like jq, that don't need a schema for the entire data format. At the other extreme, you could make typescript definitions defining a schema for the entire format. The more the same data gets (re)used, the more worthwhile taking the time to define a full schema is. But to download and add type definitions (often out of date and in need of further tweaking) for every once-off API request? Way more effort than it's worth.
- seer 6y ago
  Most static type systems do not force you to say what’s the entire shape of the data, just what the shape of the data you need is. In fact its a good practice to do in general. So that when processing the json blob you tell what only your processing requires. What you get is that if for example you do your validation, but then by chance you touch more data that you’ve checked for, the types will tell you you are dangerous waters, and you can go update the validations. This is especially useful if you’re not the original author or if you’ve written it several months back and don’t remember the details. Static types are really cool that way, and can be treated as just a faster to write and faster to run and always up to date unit test.

MaulingMonkey 6y ago

Consuming types in that context is nice, defining them is what's generally a PITA / extra boilerplate / overhead. To take a concrete example that could go both ways: Say you want to parse a JSON blob for some task. On the one end, you could access it through dynamic typing, or tools like jq, that don't need a schema for the entire data format. At the other extreme, you could make typescript definitions defining a schema for the entire format. The more the same data gets (re)used, the more worthwhile taking the time to define a full schema is. But to download and add type definitions (often out of date and in need of further tweaking) for every once-off API request? Way more effort than it's worth.

seer 6y ago
Most static type systems do not force you to say what’s the entire shape of the data, just what the shape of the data you need is. In fact its a good practice to do in general. So that when processing the json blob you tell what only your processing requires. What you get is that if for example you do your validation, but then by chance you touch more data that you’ve checked for, the types will tell you you are dangerous waters, and you can go update the validations. This is especially useful if you’re not the original author or if you’ve written it several months back and don’t remember the details. Static types are really cool that way, and can be treated as just a faster to write and faster to run and always up to date unit test.