12 ms·

You can't shove every single assumption into the type system...

by dataflow 1y ago

Nevermark 1y ago
[flagged]
- badc0ffee 1y ago
  Leave the dingos alone
- kevindamm 1y ago
  > with admirable tunnel vision, bullheadedness and mission for maximally general algebraic and arbitrary constraint type systems. I believe they're called keyhole optimizations, greedy search, and "the customer is always right..."
layer8 1y ago
True, but there are still documented interface contracts you can program against. The compiler won’t catch violations of the non-type parts, but the requirements are still well-defined with a proper interface contract. It is a trade-off, but so is repeating the same case distinction in multiple parts of the program, or having to pass around the context needed to make the case distinction.
treyd 1y ago
You can express a lot of concepts just through types in languages with richer type systems.
- shiandow 1y ago
  Even without a rich type system you can express a lot of things just through naming. You just can't enforce those assumptions.
  - eyelidlessness 1y ago
    You can enforce them (statically) by other means if you’re determined enough, eg by using lint rules which enforce type-like semantics which the type system itself doesn’t express.
    - treyd 1y ago
      This does rely on the language having a sophisticated-enough type system to be able to extract enough type information for the rules to work in the first place.
knome 1y ago
You can and should put as many as you can there https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/ https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va... If instead of validating that someone has sent you a phone number in one spot and then passing along a string, you can as easily have a function construct an UncheckedPhoneNumber. You can choose to only construct VerifiedPhoneNumbers if the user has gone through a code check. Both would allow you to pluck a PhoneNumber out of them for where you need to have generic calling code. You can use this sort of pattern to encode anything into the type system. Takes a little more upfront typing than all of those being strings, but your program will be sure of what it actually has at every point. It's pretty nice.
- deleted 1y ago
  [deleted]
- alfiedotwtf 1y ago
  Yep! I have seen so much pushed into a type system that in the end there was hardly any code needed to do validation or scaffolding… to the point where it felt magical
sn9 1y ago
You can at least shove them into the constructors.

You can't shove every single assumption into the type system...

Nevermark 1y ago

[flagged]

badc0ffee 1y ago
Leave the dingos alone
kevindamm 1y ago
> with admirable tunnel vision, bullheadedness and mission for maximally general algebraic and arbitrary constraint type systems. I believe they're called keyhole optimizations, greedy search, and "the customer is always right..."

layer8 1y ago

True, but there are still documented interface contracts you can program against. The compiler won’t catch violations of the non-type parts, but the requirements are still well-defined with a proper interface contract. It is a trade-off, but so is repeating the same case distinction in multiple parts of the program, or having to pass around the context needed to make the case distinction.

treyd 1y ago

You can express a lot of concepts just through types in languages with richer type systems.

shiandow 1y ago
Even without a rich type system you can express a lot of things just through naming. You just can't enforce those assumptions.
- eyelidlessness 1y ago
  You can enforce them (statically) by other means if you’re determined enough, eg by using lint rules which enforce type-like semantics which the type system itself doesn’t express.
  - treyd 1y ago
    This does rely on the language having a sophisticated-enough type system to be able to extract enough type information for the rules to work in the first place.

knome 1y ago

You can and should put as many as you can there https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/ https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va... If instead of validating that someone has sent you a phone number in one spot and then passing along a string, you can as easily have a function construct an UncheckedPhoneNumber. You can choose to only construct VerifiedPhoneNumbers if the user has gone through a code check. Both would allow you to pluck a PhoneNumber out of them for where you need to have generic calling code. You can use this sort of pattern to encode anything into the type system. Takes a little more upfront typing than all of those being strings, but your program will be sure of what it actually has at every point. It's pretty nice.

deleted 1y ago
[deleted]
alfiedotwtf 1y ago
Yep! I have seen so much pushed into a type system that in the end there was hardly any code needed to do validation or scaffolding… to the point where it felt magical

sn9 1y ago

You can at least shove them into the constructors.