4 ms·

Yes, but "Type inference has usability problems". http://web.eecs.utk.edu/~azh/blog/typeinference.html http://web.eecs.utk.edu/~azh/blog/typeinference.html

leshow 7y ago
I'm curious why you quote this like it's a fact when it's an opinion. The understanding of type inference used as the basis for making the argument in that blog post is superficial. Type inference doesn't just allow you to leave off type information from variables. A good inference engine will infer the most generic type for variables (and functions!), it's a discovery that you can query the compiler for in order to do type driven development. A full rebuttal of this blog post would take much longer, but suffice to say inference does the exact opposite of what they are claiming; it increases readability and usability.
- azhenley 7y ago
  I quoted the title of my blog post. Do you have any evidence for your claim that it increases readability or usability? A few human-subjects studies from different labs have recently been ran on this and the findings mostly agree with my opinions. Papers forthcoming.
  - pwm 7y ago
    I don’t agree with readibility (there are pros and cons, ie. terser code vs. implicit types) but, at least in Haskell, it improves usability by inferring the most generic type to your expression.
  - leshow 7y ago
    Agree on what? "Type inference" is a broad feature, feel free to post the resources. edit: In Haskell it goes beyond just locally inferring variables, it enables a new type of development with typed holes that feels more like a back and forth conversation with the compiler. I don't see how "I can leave the types off my C# variables" has anything to do with that.
  - sweeneyrod 7y ago
    If type inference damaged readability, we would expect companies/projects that use languages such as OCaml and Haskell where type inference is possible but not mandatory to have policies against it in their style guides. In my experience with OCaml, the widely agreed on style is to only annotate types of functions that are part of some public interface (although since this annotation is necessary to define the public interface of a library, it's not even necessarily true that type inference impairing readability is the primary reason for this). Also, if lack of type annotations were a common problem, you would expect Java programmers who switch to Python to frequently want to annotate all their types. But as far as I know this is not the case: even now that mypy is becoming popular, people only annotate the types that it can't infer.
    - azhenley 7y ago
      Companies do have policies against using type inference (e.g., the use of var in C#). But how would companies/people know if it damaged readability? There has been little research on this (a few studies are currently in peer review!) and our intuition about such things is often inaccurate. There are so many other confounding factors that it is hard to isolate just type inference/annotations.
      - yawaramin 7y ago
        > Companies do have policies against using type inference (e.g., the use of var in C#). That's a language that historically has not had type inference. Any examples of companies mandating type annotations in historically type-inferred languages?
        azhenley 7y ago
        Yes! Any company that has adopted MyPy or TypeScript often have policies for this. One team I spoke to at Facebook said that any new code should have type annotations. I believe Dropbox had a nice blog post about new code should have type annotations too. It is hard to get these details from companies/teams (and be allowed to talk about it).
yawaramin 7y ago
In practice, not really. A good type inference system like Hindley-Milner infers the most general type of any expression you give it. This usually makes your code more polymorphic i.e. generic than if you would have manually written down the types. You talk about cognitive load of looking up type info but there's also a cognitive load to having to parse every type annotation over and over again whenever you read the code. And since code is read more often than it's written, that's really just optimizing for the wrong load. As you re-read a codebase over time you'll get familiar with its types. And then the annotations start to get in the way. This is in fact one of the reasons people prefer dynamic typing. > My response? Go refactor your hideous code. To what? Would be very interesting to see your suggested refactor of that code. > Before every language designer blindly accepts type inference as a good thing, I propose that some research be conducted. What would be the research question(s) specifically?

leshow 7y ago

I'm curious why you quote this like it's a fact when it's an opinion. The understanding of type inference used as the basis for making the argument in that blog post is superficial. Type inference doesn't just allow you to leave off type information from variables. A good inference engine will infer the most generic type for variables (and functions!), it's a discovery that you can query the compiler for in order to do type driven development. A full rebuttal of this blog post would take much longer, but suffice to say inference does the exact opposite of what they are claiming; it increases readability and usability.

azhenley 7y ago
I quoted the title of my blog post. Do you have any evidence for your claim that it increases readability or usability? A few human-subjects studies from different labs have recently been ran on this and the findings mostly agree with my opinions. Papers forthcoming.
- pwm 7y ago
  I don’t agree with readibility (there are pros and cons, ie. terser code vs. implicit types) but, at least in Haskell, it improves usability by inferring the most generic type to your expression.
- leshow 7y ago
  Agree on what? "Type inference" is a broad feature, feel free to post the resources. edit: In Haskell it goes beyond just locally inferring variables, it enables a new type of development with typed holes that feels more like a back and forth conversation with the compiler. I don't see how "I can leave the types off my C# variables" has anything to do with that.
- sweeneyrod 7y ago
  If type inference damaged readability, we would expect companies/projects that use languages such as OCaml and Haskell where type inference is possible but not mandatory to have policies against it in their style guides. In my experience with OCaml, the widely agreed on style is to only annotate types of functions that are part of some public interface (although since this annotation is necessary to define the public interface of a library, it's not even necessarily true that type inference impairing readability is the primary reason for this). Also, if lack of type annotations were a common problem, you would expect Java programmers who switch to Python to frequently want to annotate all their types. But as far as I know this is not the case: even now that mypy is becoming popular, people only annotate the types that it can't infer.
  - azhenley 7y ago
    Companies do have policies against using type inference (e.g., the use of var in C#). But how would companies/people know if it damaged readability? There has been little research on this (a few studies are currently in peer review!) and our intuition about such things is often inaccurate. There are so many other confounding factors that it is hard to isolate just type inference/annotations.
    - yawaramin 7y ago
      > Companies do have policies against using type inference (e.g., the use of var in C#). That's a language that historically has not had type inference. Any examples of companies mandating type annotations in historically type-inferred languages?
      - azhenley 7y ago
        Yes! Any company that has adopted MyPy or TypeScript often have policies for this. One team I spoke to at Facebook said that any new code should have type annotations. I believe Dropbox had a nice blog post about new code should have type annotations too. It is hard to get these details from companies/teams (and be allowed to talk about it).

yawaramin 7y ago

In practice, not really. A good type inference system like Hindley-Milner infers the most general type of any expression you give it. This usually makes your code more polymorphic i.e. generic than if you would have manually written down the types. You talk about cognitive load of looking up type info but there's also a cognitive load to having to parse every type annotation over and over again whenever you read the code. And since code is read more often than it's written, that's really just optimizing for the wrong load. As you re-read a codebase over time you'll get familiar with its types. And then the annotations start to get in the way. This is in fact one of the reasons people prefer dynamic typing. > My response? Go refactor your hideous code. To what? Would be very interesting to see your suggested refactor of that code. > Before every language designer blindly accepts type inference as a good thing, I propose that some research be conducted. What would be the research question(s) specifically?