3 ms·

So blinding is pretty much impossible for something like typing. The programmer can't be ignorant to whether the language is typed, it's central aspect of using

So blinding is pretty much impossible for something like typing. The programmer can't be ignorant to whether the language is typed, it's central aspect of using the language. The reason blinding works so well in medicine is because you don't consciously interact with the medicine's mechanism. Your body does. If you had to understand the shape of the molecules in a pill, say, for it to work, you wouldn't be able to blind.

eesmith 3y ago
Yes, you can. A language may not have explicit type declarations, but still have machine-inferable types. "Work In Progress: an Empirical Study of Static Typing in Ruby" gives an example. > In this paper, we present an empirical pilot study of four skilled programmers as they develop programs in Ruby, a popular, dynamically typed, object-oriented scripting language. Our study compares programmer behavior under the standard Ruby interpreter versus using Diamondback Ruby (DRuby), which adds static type inference to Ruby. The aim of our study is to understand whether DRuby’s static typing is beneficial to programmers. I can imagine a similar experiment where both groups use Python, but one setup uses just Python and the other uses Python+mypy, to report type issues. (The WIP paper points out how DRuby is a lot slower than Ruby, so users aren't blind to the effect. The Python experiment should probably run Python+mypy for both cases, but only report the mypy output for one case.)
- habitue 3y ago
  Getting better diagnostics from secretly running a type checker as a "linter" is not the same as writing a program in a language you know is typed and which you design the types first before constructing the program. I'm sorry but this seems uncontroversial to me, I don't think this negates the point I was making at all.
  - eesmith 3y ago
    The linked-to literature review considers it a relevant paper. Take up your controversial issue with Dan Luu. > not the same as writing a program in a language you know is typed and which you design the types first before constructing the program You know that's not the only way to work with static types, right? Furthermore, the same DRuby paper hypothesizes "that programmers have ways of reasoning about types that compensate for the lack of static type information". It suggests that programmers are designing with types first, in their head, even in programming languages which don't support types. So I think you meant to write something more like "express" or "implement" the types first, not "design."

eesmith 3y ago

Yes, you can. A language may not have explicit type declarations, but still have machine-inferable types. "Work In Progress: an Empirical Study of Static Typing in Ruby" gives an example. > In this paper, we present an empirical pilot study of four skilled programmers as they develop programs in Ruby, a popular, dynamically typed, object-oriented scripting language. Our study compares programmer behavior under the standard Ruby interpreter versus using Diamondback Ruby (DRuby), which adds static type inference to Ruby. The aim of our study is to understand whether DRuby’s static typing is beneficial to programmers. I can imagine a similar experiment where both groups use Python, but one setup uses just Python and the other uses Python+mypy, to report type issues. (The WIP paper points out how DRuby is a lot slower than Ruby, so users aren't blind to the effect. The Python experiment should probably run Python+mypy for both cases, but only report the mypy output for one case.)

habitue 3y ago
Getting better diagnostics from secretly running a type checker as a "linter" is not the same as writing a program in a language you know is typed and which you design the types first before constructing the program. I'm sorry but this seems uncontroversial to me, I don't think this negates the point I was making at all.
- eesmith 3y ago
  The linked-to literature review considers it a relevant paper. Take up your controversial issue with Dan Luu. > not the same as writing a program in a language you know is typed and which you design the types first before constructing the program You know that's not the only way to work with static types, right? Furthermore, the same DRuby paper hypothesizes "that programmers have ways of reasoning about types that compensate for the lack of static type information". It suggests that programmers are designing with types first, in their head, even in programming languages which don't support types. So I think you meant to write something more like "express" or "implement" the types first, not "design."