4 ms·

The API problems you cite aren’t prevented in dynamically typed systems. If anything they are worse, because they could lead to silent failures, whereas a stati

by klmr 8y ago

The API problems you cite aren’t prevented in dynamically typed systems. If anything they are worse, because they could lead to silent failures, whereas a statically typed API statically checks and guarantees the contract. Contrary to what you imply, a statically typed API can’t return an unexpected type. That’s an advantage. > It always seems to end up in types where every field is optional “Always”? Not by a long shot. These situations where this is the case can be isolated and dealt with explicitly. You may object to the explicitness but — again, for reasons of robustness — proponents of static typing prefer this.

rhacker 8y ago
There's nothing stopping a dynamically typed system from using something like grpc or graphql that can check for missing fields. Or something like json schema to check for missing fields in a lot of those scenarios. A type system doesn't necessarily catch missing fields, but a communication framework of some kind, does.
- klmr 8y ago
  I entirely agree, see my orthogonal comment reply.
pmontra 8y ago
> whereas a statically typed API statically checks and guarantees the contract I didn't work much with static typed languages lately, so I'm really puzzled by your comment. If I expect an int in the age field of a JSON response and the server suddenly sends me a string, maybe with value "NaN", how do you check for that at compile time? I expect the program to either crash or manage the error at run time (try/catch, die-and-restart a-la-Erlang, etc) Maybe JSON doesn't count as "statically typed API", but how many of them do common Internet services expose to the public? And how to we make sure that the server or any in between proxy doesn't misbehave and violates the contract?
- steveklabnik 8y ago
  The way this works is, when you say “please turn this JSON string into a data structure”, it’s a fallible operation. So, if that JSON string does not have what you expect, the serialization operation will fail. You can “check at compile time” by the system ensuring that you handle the success and failure cases. Additionally, it means that if you have an instance of that data structure, it is always valid; it is checked (at runtime) upon creation. Does that make sense? I can show you some code if you’d like.
- klmr 8y ago
  There are different kinds of APIs. You seem to be talking about inherently dynamic ones, such as your JSON blob example. Of course you cannot statically guarantee their contents, which is why statically typed JSON layers provide ways of asserting a schema. Using such schema checkers is best practice even in dynamically typed languages. Either way, you need to handle such failures, both in statically and in dynamically type-checked languages. The only difference is whether the handling happens explicitly throughout your code or automagically by an API that gives you back a well-behaved object. And both of these ways are possible in both static and dynamic languages (but static languages tend to go for the latter, whereas dynamic languages tend to make you do the former).

by klmr 8y ago

rhacker 8y ago

There's nothing stopping a dynamically typed system from using something like grpc or graphql that can check for missing fields. Or something like json schema to check for missing fields in a lot of those scenarios. A type system doesn't necessarily catch missing fields, but a communication framework of some kind, does.

klmr 8y ago
I entirely agree, see my orthogonal comment reply.

pmontra 8y ago

> whereas a statically typed API statically checks and guarantees the contract I didn't work much with static typed languages lately, so I'm really puzzled by your comment. If I expect an int in the age field of a JSON response and the server suddenly sends me a string, maybe with value "NaN", how do you check for that at compile time? I expect the program to either crash or manage the error at run time (try/catch, die-and-restart a-la-Erlang, etc) Maybe JSON doesn't count as "statically typed API", but how many of them do common Internet services expose to the public? And how to we make sure that the server or any in between proxy doesn't misbehave and violates the contract?

steveklabnik 8y ago
The way this works is, when you say “please turn this JSON string into a data structure”, it’s a fallible operation. So, if that JSON string does not have what you expect, the serialization operation will fail. You can “check at compile time” by the system ensuring that you handle the success and failure cases. Additionally, it means that if you have an instance of that data structure, it is always valid; it is checked (at runtime) upon creation. Does that make sense? I can show you some code if you’d like.
klmr 8y ago
There are different kinds of APIs. You seem to be talking about inherently dynamic ones, such as your JSON blob example. Of course you cannot statically guarantee their contents, which is why statically typed JSON layers provide ways of asserting a schema. Using such schema checkers is best practice even in dynamically typed languages. Either way, you need to handle such failures, both in statically and in dynamically type-checked languages. The only difference is whether the handling happens explicitly throughout your code or automagically by an API that gives you back a well-behaved object. And both of these ways are possible in both static and dynamic languages (but static languages tend to go for the latter, whereas dynamic languages tend to make you do the former).