5 ms·

I didn't get the general idea that the author thought they hid the complexity, but rather that they exposed and codified it. They gave the complexity that would

by knome 2y ago

I didn't get the general idea that the author thought they hid the complexity, but rather that they exposed and codified it. They gave the complexity that would previously live in your head somewhere it could be expressed. And once expressed, it can be iterated on.

dartos 2y ago
Encoding complexity in your type system forces you to deal with that complexity throughout your codebase. It doesn’t give complexity a specific place to live.
- knome 2y ago
  You were going to have to deal with that complexity either way. Now it's expressed somewhere, and if you craft it right, enforced so it's harder to get things wrong. 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...
  - BigJono 2y ago
    This view has always been bullshit. It doesn't differentiate between the complexity of the types themselves and the complexity of representing them in a static type system.
    - sfn42 2y ago
      It certainly isn't bullshit. I take advantage of type systems every day to help me write code that works on the first try. Obviously I'm not saying all my code works on the first try, but it often does even when it's quite complex. The main problem is that a lot of developers don't know how to use the type system well, so they write code in a way that doesn't take advantage of the type system. Or they just write bad code in general that makes life difficult despite a type system. It doesn't solve all problems, but if you use it well it can solve a lot of problems very elegantly.
- yakshaving_jgt 2y ago
  If you parse a value into a guaranteed non-null value at the system boundary, then you have eliminated the need to check for that nullability throughout the rest of your codebase. Did you mean to write the literal polar opposite of what you wrote?

5 ms·

I didn't get the general idea that the author thought they hid the complexity, but rather that they exposed and codified it. They gave the complexity that would

by knome 2y ago

dartos 2y ago
Encoding complexity in your type system forces you to deal with that complexity throughout your codebase. It doesn’t give complexity a specific place to live.
- knome 2y ago
  You were going to have to deal with that complexity either way. Now it's expressed somewhere, and if you craft it right, enforced so it's harder to get things wrong. 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...
  - BigJono 2y ago
    This view has always been bullshit. It doesn't differentiate between the complexity of the types themselves and the complexity of representing them in a static type system.
    - sfn42 2y ago
      It certainly isn't bullshit. I take advantage of type systems every day to help me write code that works on the first try. Obviously I'm not saying all my code works on the first try, but it often does even when it's quite complex. The main problem is that a lot of developers don't know how to use the type system well, so they write code in a way that doesn't take advantage of the type system. Or they just write bad code in general that makes life difficult despite a type system. It doesn't solve all problems, but if you use it well it can solve a lot of problems very elegantly.
- yakshaving_jgt 2y ago
  If you parse a value into a guaranteed non-null value at the system boundary, then you have eliminated the need to check for that nullability throughout the rest of your codebase. Did you mean to write the literal polar opposite of what you wrote?