3 ms·
> There is no such thing as type checker puzzle once you have learned types, just like you don't stop on each word once you're literate. Your analogy doesn't a
by wellpast 9y ago
> There is no such thing as type checker puzzle once you have learned types, just like you don't stop on each word once you're literate.
Your analogy doesn't apply.
I can read a book in O(n) time, where n is the number of words in the book. I can read a single word in O(1) time.
When I get a type error, that is not a O(1) fix. The type error is connected to my program in the large and I have to understand/process more than just the single line where the error is called out. The worst case, obviously, is O(n).
- wellpast 9y agoThe worst case for the number of places I have to go fix is O(n). I.e., the verification half is O(n). The solution search side ("solving the puzzle") may be worse, because I have to generate/find the code that fits the type checker.
- pyrale 9y agoUsing a static type checker means that an error doesn't creep across all my code. The worst case you describe pretty much never happens, and the smaller instances I get are reified to a generic form I am trained to analyze and solve quickly. > Your analogy doesn't apply. One would think I am well placed to describe my own experience of interacting with a type system.