7 ms·

Responding to your gradual typing anti-pattern bit: Agree that dynamic language behaviors can be extreme but it’s also easy to get into crazy type land. Putting

Responding to your gradual typing anti-pattern bit: Agree that dynamic language behaviors can be extreme but it’s also easy to get into crazy type land. Putting aside a discussion of type systems, teams can always add runtime checks like pydantic to ensure your types match reality. Sorbet (Ruby typechecker) does this where it introduces a runtime checks on signatures. Similarly in ts, we have zod.

MeetingsBrowser 1y ago
> teams can always add runtime checks like pydantic to ensure your types match reality. That's the problem with bugs though, there's always something that could have been done to avoid it =) Pydantic works great in specific places, like validating user supplied data, but runtime checks as a replacement for static type checkers are not really feasible. Every caller would need to check that the function is being called correctly (number and position of args, kwarg names, etc) and every callee would need to manually validate that each arg passed matches some expected type.
- eternityforest 1y ago
  Pydantic also takes CPU time and doesn't do anything till runtime. Type checking is real time in the IDE and lets you fix stuff before you waste fifteen minutes actually running it.
- Spivak 1y ago
  pydantic does have @validate_call for this use-case.
  - guappa 1y ago
    Profile it and see how much slower it gets :)
- belmont_sup 1y ago
  To be clear, I myself prefer sound type systems. But the reality is that teams have started with untyped Python, Ruby, and Javascript, have been productive, and now need to gradually add static types to remain productive. > Every caller would need to check that the function... The nice part here is where the gradual part comes in. As you are able to type more of your code, you're able to move where you add your runtime validation, and eventually you'll be able to move all validation to the edges of your system.

MeetingsBrowser 1y ago

> teams can always add runtime checks like pydantic to ensure your types match reality. That's the problem with bugs though, there's always something that could have been done to avoid it =) Pydantic works great in specific places, like validating user supplied data, but runtime checks as a replacement for static type checkers are not really feasible. Every caller would need to check that the function is being called correctly (number and position of args, kwarg names, etc) and every callee would need to manually validate that each arg passed matches some expected type.

eternityforest 1y ago
Pydantic also takes CPU time and doesn't do anything till runtime. Type checking is real time in the IDE and lets you fix stuff before you waste fifteen minutes actually running it.
Spivak 1y ago
pydantic does have @validate_call for this use-case.
- guappa 1y ago
  Profile it and see how much slower it gets :)
belmont_sup 1y ago
To be clear, I myself prefer sound type systems. But the reality is that teams have started with untyped Python, Ruby, and Javascript, have been productive, and now need to gradually add static types to remain productive. > Every caller would need to check that the function... The nice part here is where the gradual part comes in. As you are able to type more of your code, you're able to move where you add your runtime validation, and eventually you'll be able to move all validation to the edges of your system.