3 ms·

If you can't explain to the type system what you mean, what makes you think you can explain to your co-worker what you mean?

by sime2009 4y ago

Smaug123 4y ago
That's like asking "If you can't explain to a three-year-old what you mean, what makes you think you can explain to your coworker what you mean?". The entire point of the parent comment is that almost all type systems in wide use today are extremely dumb compared to an actual human.
- sime2009 4y ago
  I've used and debugged type issues in Redux, but even when we figured out what was going on I was often left with the feeling that it was trying to be too clever. In the same way that we should strive towards simpler and easier to understand code, we should do the same with the types we use. Wanting ways of doing even more complex types using ever more complex type systems, seems like the wrong direction. IMHO, much of that complexity is due to what we desire, not weaknesses in the type systems themselves.
- lucideer 4y ago
  > almost all type systems in wide use today are extremely dumb compared to an actual human This isn't really true in the specific sense though (obviously it's inherently true in the general sense, but that's less relevant here). Type systems are true & accurate representations of data structure and usage - any given actual human (a) may have an inaccurate mental representation of that at any given time, (b) that mental representation may change over time, (c) that mental representation will almost always be incomplete for any reasonably complex system. Being "dumb" or intelligent isn't about representing data structures in memory, but the particular problem being discussed here is very much about that: in that context, humans are usually "dumber" than type systems.
  - lmeyerov 4y ago
    I'm using "dumb" to refer to computationally limited reasoning for even small programs. Think linear regression vs neural networks, or in this case, ML-family type systems (with all the modern trimmings) vs an SMT solver. The "explaining your code to a three year old vs a professional colleague" comment is spot on.

If you can't explain to the type system what you mean, what makes you think you can explain to your co-worker what you mean?

Smaug123 4y ago

That's like asking "If you can't explain to a three-year-old what you mean, what makes you think you can explain to your coworker what you mean?". The entire point of the parent comment is that almost all type systems in wide use today are extremely dumb compared to an actual human.

sime2009 4y ago
I've used and debugged type issues in Redux, but even when we figured out what was going on I was often left with the feeling that it was trying to be too clever. In the same way that we should strive towards simpler and easier to understand code, we should do the same with the types we use. Wanting ways of doing even more complex types using ever more complex type systems, seems like the wrong direction. IMHO, much of that complexity is due to what we desire, not weaknesses in the type systems themselves.
lucideer 4y ago
> almost all type systems in wide use today are extremely dumb compared to an actual human This isn't really true in the specific sense though (obviously it's inherently true in the general sense, but that's less relevant here). Type systems are true & accurate representations of data structure and usage - any given actual human (a) may have an inaccurate mental representation of that at any given time, (b) that mental representation may change over time, (c) that mental representation will almost always be incomplete for any reasonably complex system. Being "dumb" or intelligent isn't about representing data structures in memory, but the particular problem being discussed here is very much about that: in that context, humans are usually "dumber" than type systems.
- lmeyerov 4y ago
  I'm using "dumb" to refer to computationally limited reasoning for even small programs. Think linear regression vs neural networks, or in this case, ML-family type systems (with all the modern trimmings) vs an SMT solver. The "explaining your code to a three year old vs a professional colleague" comment is spot on.