5 ms·

Let me rephrase: A statically typed language typically asks us to redirect our brains from asking the question, "Is type verification really needed in this par

Let me rephrase: A statically typed language typically asks us to redirect our brains from asking the question, "Is type verification really needed in this particular instance to deliver my business value?" to instead solving the type-checker puzzle du jour.

dragonwriter 9y ago
Plenty of modern statically-typed languages have dynamic escape valves (and plenty of dynamically typed languages have opt-in static validation.) It's true that choosing to use a static language without a dynamic escape valve for a component constitutes making the decision that, for the pieces of that component, dynamic freedom isn't an option that needs further considered.
pyrale 9y ago
This is effortless once you have experience[1]. Besides, understanding the type of your data is beneficial, and so is it to be able to use types as an exploratory tool in a codebase you don't know. [1] Just like having experience in editor shortcuts bear an initial cost to make you more productive forever...
- wellpast 9y ago
  Which part is effortless? Solving the type checker puzzle, or asking whether type verification is truly needed in a particular given instance?
  - pyrale 9y ago
    Thinking in types. 95% of the time, the type checker silently validates my input and the remaining 5% of the time, the trouble I get is understanding valuable information. 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.
    - 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 ago
        The 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 ago
        Using 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.
    - jernfrost 9y ago
      Lots of valid code, won't pass the type checker. That is the problem with static type checkers. You have to adapt your code to satisfy the type checker even when you know your logic is right. Static type checking also significantly complicated meta programming, macros and code generation. But hey I like statically typed languages too. A big fan of Swift which has borrowed many functional ideas. I just don't think static typing is the silver bullet that many of its proponents think. It works well for some problems, but not all. E.g. I can't think of any statically typed language which can compete with Julia for numerical work and data science. Haskell e.g. is just terrible at doing numerical work, as it poor at mutation. You can work effectively with lots of big matrices if you don't allow easy access to mutation.

dragonwriter 9y ago

Plenty of modern statically-typed languages have dynamic escape valves (and plenty of dynamically typed languages have opt-in static validation.) It's true that choosing to use a static language without a dynamic escape valve for a component constitutes making the decision that, for the pieces of that component, dynamic freedom isn't an option that needs further considered.

pyrale 9y ago

This is effortless once you have experience[1]. Besides, understanding the type of your data is beneficial, and so is it to be able to use types as an exploratory tool in a codebase you don't know. [1] Just like having experience in editor shortcuts bear an initial cost to make you more productive forever...

wellpast 9y ago
Which part is effortless? Solving the type checker puzzle, or asking whether type verification is truly needed in a particular given instance?
- pyrale 9y ago
  Thinking in types. 95% of the time, the type checker silently validates my input and the remaining 5% of the time, the trouble I get is understanding valuable information. 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.
  - 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 ago
      The 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 ago
      Using 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.
  - jernfrost 9y ago
    Lots of valid code, won't pass the type checker. That is the problem with static type checkers. You have to adapt your code to satisfy the type checker even when you know your logic is right. Static type checking also significantly complicated meta programming, macros and code generation. But hey I like statically typed languages too. A big fan of Swift which has borrowed many functional ideas. I just don't think static typing is the silver bullet that many of its proponents think. It works well for some problems, but not all. E.g. I can't think of any statically typed language which can compete with Julia for numerical work and data science. Haskell e.g. is just terrible at doing numerical work, as it poor at mutation. You can work effectively with lots of big matrices if you don't allow easy access to mutation.