Type Inference Was a Mistake

> It makes code harder to read

One could argue it's better for type inference to not just be part of the language but also part of the IDE. E.g. you type

auto x = ...

And then the IDE offers to replace the auto with vector

That way you can both write code with type inference, but read code with fully annotated types!

In Haskell the culture is to always do it, more or less for this reason.

I think the article's take on type inference is a bit heavy-handed and misses some of the nuances of modern software development.

First off, the complaint about reduced readability outside of IDEs feels like a niche problem. Sure, it's a valid point when you're reading code on paper or in a basic text editor, but let's be real: most of us live in IDEs with excellent type hinting capabilities. The argument kind of falls apart when you consider that good variable naming can often make the need for explicit types less critical. Plus, isn't the goal of any good codebase to be as self-documenting as possible?

Regarding OCaml's type inference being a "footgun," it seems like a bit of an exaggeration. Yes, OCaml's system is powerful and can lead to some head-scratching moments, but isn't that just part of the learning curve with any powerful tool? It sounds like the frustration comes more from not leveraging the type system correctly rather than an inherent flaw with type inference. And honestly, adding type annotations for debugging is a pretty standard practice across many languages—not just OCaml.

The point about academic effort being wasted on type inference research also misses the mark. This research pushes the boundaries of what's possible with programming languages, leading to more expressive and safer languages. To frame this as a waste is to ignore the broader benefits of advancing programming language theory. Sure, it'd be nice if papers spent more time on practical applications, but that doesn't mean the theoretical aspects aren't valuable.

It feels like the article is conflating personal gripes with systemic issues. Type inference, when used correctly, can significantly reduce boilerplate and make code more concise and readable. Of course, it's not a silver bullet, and there are situations where explicit type annotations are beneficial for clarity, especially in public APIs. But to dismiss type inference outright seems like throwing the baby out with the bathwater.

In the end, it all boils down to using the right tool for the job and understanding the trade-offs. There's no one-size-fits-all answer in programming, and dismissing type inference entirely overlooks its benefits in many scenarios.

This is not good. One of the author's arguments is that type inference in an IDE is bad because sometimes I read code in a book where I don't have type inference...

I don't know about other folks, but the vast majority of code I read is in my editor, where the type inference saves me a ton of time and pain.

OCaml's type system allows for expressing complex data structures and behaviors in a concise and readable manner. These types can significantly improve code clarity by providing explicit declarations of intent and structure. Here are some examples:

  type 'a binary_tree =
    | Leaf
    | Node of 'a binary_tree * 'a * 'a binary_tree

  type http_response = [
    | `Ok of string
    | `Error of int
    | `Redirect of string
  ]

  module type QUEUE = sig
    type 'a t
    exception Empty
    val empty: unit -> 'a t
    val enqueue: 'a -> 'a t -> 'a t
    val dequeue: 'a t -> 'a option * 'a t
  end

  type _ expr =
    | Int : int -> int expr
    | Bool : bool -> bool expr
    | If : bool expr * 'a expr * 'a expr -> 'a expr

  type person = {
    name: string;
    age: int;
    address: string; 
  }