Type Inference Was a Mistake(borretti.me)
borretti.me
Type Inference Was a Mistake
https://borretti.me/article/type-inference-was-a-mistake
132 comments
The author does have a good point about the readability of code snippets, but the right approach is to render code with type annotations when outputting these formats, similar to syntax highlighting.
I do not miss having to change in32_t to int64_t at every location in my code when I changed my mind about types.
I do not miss having to change in32_t to int64_t at every location in my code when I changed my mind about types.
Jetbrains can catch those problems, but only if all of the code is in its scope of files. I’m not disagreeeing with you, I’m saying that the “toy problem” of small teams and individuals muddies the water because it seems like a solved problem but isn’t.
For enterprise scale problems it’s difficult to get the full context for a line of code. It could be in a repo you don’t even know about, run by people who you have only met once and never think about.
For enterprise scale problems it’s difficult to get the full context for a line of code. It could be in a repo you don’t even know about, run by people who you have only met once and never think about.
> I do not miss having to change in32_t to int64_t at every location in my code when I changed my mind about types.
A good reason to use logical typedefs, though.
A good reason to use logical typedefs, though.
What's a "book"?
Seriously, that argument is like saying that long variable names are bad because sometimes you have to write code on punched cards. The solution to the drawbacks of obsolete technology is to not use obsolete technology.
Seriously, that argument is like saying that long variable names are bad because sometimes you have to write code on punched cards. The solution to the drawbacks of obsolete technology is to not use obsolete technology.
Books are definitely not obsolete technology, you can consider them old or even traditional but they aren't obsolete by any means.
Books are those things you load on your kindle right? I mean, ya, they aren’t obsolete, but it’s not the main way I absorb information anymore.
While I read most of other people’s code in my IDE, the second most common spot is in code reviews. Hopefully that’s true for you as well, because I don’t really have time for the opinions of people who don’t participate in code reviews. They aren’t part of the conversation and can sod off.
So far, color highlighting is about the most I can expect from a CR tool. Though I’d be very open to being able to do CRS from my IDE.
So far, color highlighting is about the most I can expect from a CR tool. Though I’d be very open to being able to do CRS from my IDE.
Yes, code review is the second most common place for me to read code. For larger pull requests I generally check out the branch and run the code myself anyway. If you use VSCode and GitHub there's an extension that lets you review code in your editor too.
But also when printing code in a book I would annotate with types, inference or not.
Bruce Eckel (Thinking in Java) gave a presentation to the Seattle Java User’s Group sometime around 2008. I thought he would talk about Java things but he surprised us by talking about how annoying it is to get code snippets into books. He had interns writing a tool to extract live code and plop it into the book. It was something very similar to the tool I would find in jcite a few years later when my team had a bullseye on our back for being the only team close to on schedule (because we were using dev processes that were industry standard but not company standard and that pissed some people off).
They pointed out every place we weren’t following The Rules and one of those was that we weren’t creating a developer manual for people to use our library. Which was somewhat fair except I’d already walked people on every team through it, in person with a sequence diagram for doing their part of the workflow. But that was going to take me days of busy work every release and suck all of the joy out of my life. It was a clever chess move.
So what I did instead was fix our functional tests to be compatible with JCite, mash the printed form javadoc and some wiki pages together, and shoehorned them into a template of the corporate document format, programmatically. I couldn’t quite get the footers and indexes right, but I asked our less senior tech writer if she would be okay having to spend an hour fixing typesetting problems every release and she agreed. So instead of two developer days it was one hour of typesetting, by a tech writer. It took almost a year to break even on the time investment but it was well worth it in the long run.
To draw this curvy line back into a circle, I would think it perfectly reasonable not to utilize type inference in a functional or integration test. For the reason that you’d want something to break that tells you that you have a breaking change in this release.
They pointed out every place we weren’t following The Rules and one of those was that we weren’t creating a developer manual for people to use our library. Which was somewhat fair except I’d already walked people on every team through it, in person with a sequence diagram for doing their part of the workflow. But that was going to take me days of busy work every release and suck all of the joy out of my life. It was a clever chess move.
So what I did instead was fix our functional tests to be compatible with JCite, mash the printed form javadoc and some wiki pages together, and shoehorned them into a template of the corporate document format, programmatically. I couldn’t quite get the footers and indexes right, but I asked our less senior tech writer if she would be okay having to spend an hour fixing typesetting problems every release and she agreed. So instead of two developer days it was one hour of typesetting, by a tech writer. It took almost a year to break even on the time investment but it was well worth it in the long run.
To draw this curvy line back into a circle, I would think it perfectly reasonable not to utilize type inference in a functional or integration test. For the reason that you’d want something to break that tells you that you have a breaking change in this release.
Generating documentation from working code – as long as it's not at the expense of quality descriptions – is by far the superior way to make documentation. Every time I have not done that, the examples have become outdated within a year.
I also find myself reading code in a browser, for example in GitHub or any other system for source control, issue management, code review etc.
If you press ".” when on a repo on GitHub it will open vscode in your browser
> 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...
That feels like a bit of a straw man because you just took the weakest example from the author's list and took that single one out of context. The full quote was:
> But there are many other contexts where I read code: a book, a blog post, a Git diff. When editing code in a limited environment, e.g. stock vim in a VM.
In other words, there are other contexts that most programmers encounter in their day-to-day that don't have the benefit of autocomplete or popups. I think the general principle of "the code should stand alone" is a fair one to point out without just scoffing "Who reads code in a book??".
That feels like a bit of a straw man because you just took the weakest example from the author's list and took that single one out of context. The full quote was:
> But there are many other contexts where I read code: a book, a blog post, a Git diff. When editing code in a limited environment, e.g. stock vim in a VM.
In other words, there are other contexts that most programmers encounter in their day-to-day that don't have the benefit of autocomplete or popups. I think the general principle of "the code should stand alone" is a fair one to point out without just scoffing "Who reads code in a book??".
A tool lacking portability does not mean the tool is bad. It means there are opportunities to support that tool (or its concept) in other environments and media. There are tools for code review in your editor which supports type inference. Snippets in books can include annotations. The author's argument and conclusion is to throw the baby out with the bathwater.
As a vim user, I have the same problems. I don't even have a mouse to hover over symbols either to see what their type is.
But even when I've used IDEs in the past, type inference still seems an unnecessary slowdown and pain in the ass to save 1 second of typing. Explicit types make the code a lot more readable, even if your IDE is capable of showing you the type.
But even when I've used IDEs in the past, type inference still seems an unnecessary slowdown and pain in the ass to save 1 second of typing. Explicit types make the code a lot more readable, even if your IDE is capable of showing you the type.
There are thing that cannot be even named. Or nested types in C++ that are super long. auto says nothing about its type, but:
``` forward_iterator auto it = ...; ```
shows intention. Auto has saved me lots of headaches, particularly in generic code: what is the type of some arithmetic operation? Type inference can help. What is the return type of a lambda? auto helps, it is impossible to spell. What is the result of a non-type-erased range view pipeline? Almost impossible to get right.
There are lots of examples where auto is valuable at least in C++.
``` forward_iterator auto it = ...; ```
shows intention. Auto has saved me lots of headaches, particularly in generic code: what is the type of some arithmetic operation? Type inference can help. What is the return type of a lambda? auto helps, it is impossible to spell. What is the result of a non-type-erased range view pipeline? Almost impossible to get right.
There are lots of examples where auto is valuable at least in C++.
I mostly agree with you fwiw. I don't think type inference as a whole is a mistake, and especially regarding local variables I think it can make things a lot cleaner and save unnecessary work.
My main problem with it (in general, not specifically C++) is that most implementations leave it up to people's judgment about when and where to use it, and they almost always use it too liberally. This is a mistake I make myself because it's not usually clear at write-time where the readability cost will out-weigh the benefit, and when the code is freshly in your head you don't need the extra information that comes from explicit typing (and indeed it can feel superfluous).
But I think it's worth pointing out that the GP comment on this thread (which I was replying to) was essentially advocating for maximum type inference because the IDE can show you at any time what the type is, so any explicit typing is superfluous to them.
My main problem with it (in general, not specifically C++) is that most implementations leave it up to people's judgment about when and where to use it, and they almost always use it too liberally. This is a mistake I make myself because it's not usually clear at write-time where the readability cost will out-weigh the benefit, and when the code is freshly in your head you don't need the extra information that comes from explicit typing (and indeed it can feel superfluous).
But I think it's worth pointing out that the GP comment on this thread (which I was replying to) was essentially advocating for maximum type inference because the IDE can show you at any time what the type is, so any explicit typing is superfluous to them.
> There are thing that cannot be even named.
Um, can you give me an example? (Can you give an example without naming it?)
Types that cannot be written, or are too long to be reasonably written, are likely to also be too hard to really understand. Maybe their existence should be regarded as a code smell.
Um, can you give me an example? (Can you give an example without naming it?)
Types that cannot be written, or are too long to be reasonably written, are likely to also be too hard to really understand. Maybe their existence should be regarded as a code smell.
The type of a lambda cannot be spelled. The type of a local class return cannot be named from outside either.
By "local class return", do you mean a function that returns what Java calls an "inner class"? That's perfectly describable (in C++ as well) if the inner class is public rather than private. It's unnameable, not because of the type, but because of the access (private).
You can create a class inside a function and return an object of it. That name is not legal outside of the function but its methods can be called.
Ah, I see. Inner to the function, not inner to the class. So the C++ syntax would need to be something like:
But if you return it from a function, how do you declare the variable you assign it to? auto?
And, is auto a valid return type from a function? If not, how do you declare the function that returns this object?
ClassName::functionName::innerName
But if you return it from a function, how do you declare the variable you assign it to? auto?
And, is auto a valid return type from a function? If not, how do you declare the function that returns this object?
Exactly. You spell auto or an interface or base class whose derived class cannot be named. I think both are ok. In the latter case you can name the interface instead of auto.
Yes, auto is a perfectly valid return type, usually quite useful in generic code.
However, in generic code, starting at C++20, I would recommend to use concepts to name a return type that can be many different thing but that is compliant with the same "compile-time" interface.
You could do:
Yes, auto is a perfectly valid return type, usually quite useful in generic code.
However, in generic code, starting at C++20, I would recommend to use concepts to name a return type that can be many different thing but that is compliant with the same "compile-time" interface.
You could do:
forward_range auto f(auto && input);
> Type inference is bad. It makes code harder to read, and languages that use it too much are harder to write.
If inference is bad, maybe the second sentence shouldn't leave it up to the reader to infer what "it" means. Surely it would be much easier to read as "Type inference [...] type inference [...] type inference".
If inference is bad, maybe the second sentence shouldn't leave it up to the reader to infer what "it" means. Surely it would be much easier to read as "Type inference [...] type inference [...] type inference".
Funny enough this is the approach taken in legal writing as to limit misinterpretation... especially purposeful misinterpretation from opposition legal teams!
This results in highly repetitive, and as you've pointed out, somewhat tedious reading.
F# is my daily driver at work and I definitely benefit from both the type inference as well as my IDE making those types explicit for my reading pleasure!
This results in highly repetitive, and as you've pointed out, somewhat tedious reading.
F# is my daily driver at work and I definitely benefit from both the type inference as well as my IDE making those types explicit for my reading pleasure!
The type inference in F# is somewhat limited in a pleasing way. It prevents getting too far lost without doing yourself the favor of adding types here and there. My understanding was that it was a deliberate choice to simplify/speed up compilation.
I’m sincerely in awe at the cleverness of this bit of snark.
Bad:
- Omitting return types in non-private interfaces (eg crossing module or package boundaries, or anything used as input to generate documentation of same)
- Omitting concrete input parameter types
- Omitting explicit, known constraints on generic/polymorphic parameters
Subjective:
- Omitting any of the same on private equivalents which form something like an internal interface
- Omitting annotations of constant/static aspects of an interface whose inferred types are identical to their hypothetical annotation
Subjective but mostly good:
- Relying on inference in type derivation, where type derivation is the explicit goal of that API
- Preferring inference of interface/protocol/contract types over explicit annotation of concrete types which happen to satisfy them
- Omitting annotations for local bindings without distant indirection
Unambiguously good:
- Omitting local annotations of direct assignment where the type is obvious in situ
- Omitting redundant annotations of the same type which have the same effect without that redundancy
- Omitting return types in non-private interfaces (eg crossing module or package boundaries, or anything used as input to generate documentation of same)
- Omitting concrete input parameter types
- Omitting explicit, known constraints on generic/polymorphic parameters
Subjective:
- Omitting any of the same on private equivalents which form something like an internal interface
- Omitting annotations of constant/static aspects of an interface whose inferred types are identical to their hypothetical annotation
Subjective but mostly good:
- Relying on inference in type derivation, where type derivation is the explicit goal of that API
- Preferring inference of interface/protocol/contract types over explicit annotation of concrete types which happen to satisfy them
- Omitting annotations for local bindings without distant indirection
Unambiguously good:
- Omitting local annotations of direct assignment where the type is obvious in situ
- Omitting redundant annotations of the same type which have the same effect without that redundancy
Sometimes you'll read something and think "I'm not taking the bait".
>> Sometimes you'll read something and think "I'm not taking the bait".
Like when I read about "auto" in C++. It still bugs me when I see it...
Like when I read about "auto" in C++. It still bugs me when I see it...
It's not even factual.
> In Rust and Haskell you have to at least annotate the parameter types and return type of functions. Type inference is only for variable bindings inside the function body.
This is false for Haskell. Can't speak for Rust.
> In Rust and Haskell you have to at least annotate the parameter types and return type of functions. Type inference is only for variable bindings inside the function body.
This is false for Haskell. Can't speak for Rust.
In rust, you are required to annotate at least the interface. In Haskell, if I remember it well, it is allowed but not required.
Even in Rust, I tend to specify types at variable bindings if the type gets overly complex, just to push errors closer to their cause.
A nice feature of Rust is you can specify partial types, wih underscores for the still-to-infer part. E.g. let x:Vec<_>=someexpression; is a vector of something, but you don't know what exactly.
Even in Rust, I tend to specify types at variable bindings if the type gets overly complex, just to push errors closer to their cause.
A nice feature of Rust is you can specify partial types, wih underscores for the still-to-infer part. E.g. let x:Vec<_>=someexpression; is a vector of something, but you don't know what exactly.
> you can specify partial types, wih underscores for the still-to-infer part
Yup. I love that. And it even lets you say things like for example:
Yup. I love that. And it even lets you say things like for example:
let res: Result<Vec<_>, _> = someexpression;Rust does require explicitly writing out the signature of top-level functions.
I believe it was a conscious decision to limit de cascading of type errors from global type inference, the base algorithm was capable of it.
I believe it was a conscious decision to limit de cascading of type errors from global type inference, the base algorithm was capable of it.
Yes, particularly due to the design decision that Rust code should strive to be explicit in intention and mechanism.
[deleted]
it's technically false for Haskell, but is considered mostly good practice. It would be true for Idris.
At least it wasn't titled, "Type Inference Considered Harmful". That one always infuriates me.
Hard disagree. One of the reasons I fell in love with F# was the succint code one can write, specifically due to the compilers ability to infer types.
Don't you at least type function params and returns?
Also, what do you build in F#? I think if I moved out of Python that would be it. OCaml is one of my favorite languages ever, and F# looks rad.
Also, what do you build in F#? I think if I moved out of Python that would be it. OCaml is one of my favorite languages ever, and F# looks rad.
Not OP, but that's exactly what I do - type my public functions fully.
I built a basic static program analyzer for Solidity smart contracts over the past 7 months. I'm re-writing it to work off CozoDB now, as I want to be able to express more complex mutually-recursive concepts and I believe Datalog is much better suited for that.
I built a basic static program analyzer for Solidity smart contracts over the past 7 months. I'm re-writing it to work off CozoDB now, as I want to be able to express more complex mutually-recursive concepts and I believe Datalog is much better suited for that.
Only public APIs - all of my internal logic I mainly let the compiler figure it out.
I have run into situations where piping causes a type inference error but the equivalent function call doesn't, which is annoying because I have to use two different conventions in that case. I'm still an F# noob, so it's possible I'm doing something wrong.
I also get nervous that I'll change my function logic and the wrong type will be inferred, and it'll compile because the old and new types just happen to be logically compatible, but I get the wrong behaviour (or maybe this is just trauma from my VB6 days).
I tend to type my public function parameters and return parameters for this reason.
I also get nervous that I'll change my function logic and the wrong type will be inferred, and it'll compile because the old and new types just happen to be logically compatible, but I get the wrong behaviour (or maybe this is just trauma from my VB6 days).
I tend to type my public function parameters and return parameters for this reason.
F# is rigid enough IMHO to stop you from making mistakes like this. The rule of thumb is that it compiles it's usually a corect program.
"My favorite languages feature types very prominently, therefore any software engineering approach that doesn't do so is invalid, and here are some reasons I thought of".
He posts this on HN, which happens to be built in Arc Scheme, a Lisp dialect (which is dynamically typed). I wonder if the author has written software that has better uptime and more popularity than HN? Is the author's codebase truly easier to understand?
He posts this on HN, which happens to be built in Arc Scheme, a Lisp dialect (which is dynamically typed). I wonder if the author has written software that has better uptime and more popularity than HN? Is the author's codebase truly easier to understand?
Dynamically typed is a different scenario than statically typed with type inference. There are a whole lot more factors/considerations at play, and it's not helpful to confuse the two.
And what does it matter what HN is built on? Do you think any criticisms of C should not be posted on a site that runs on top of the linux kernel because the kernel is written in C?
And what does it matter what HN is built on? Do you think any criticisms of C should not be posted on a site that runs on top of the linux kernel because the kernel is written in C?
He did not actually say his criticism only applies to statically typed languages. He almost implied that he would consider dynamically typed languages invalid by default without the types.
It does matter that there is a lot of successful software written in languages that are dynamically typed or use type inference when some want to dismiss these approaches entirely. Because it proves that these approaches can still result in useful and reliable software and productive software engineering.
It does matter that there is a lot of successful software written in languages that are dynamically typed or use type inference when some want to dismiss these approaches entirely. Because it proves that these approaches can still result in useful and reliable software and productive software engineering.
He is an author of several Common Lisp packages, so I think that angle is covered.
Explicit typing is great until your code is littered with shared_ptr<vector<shared_ptr<map<string,T>>>> everywhere.
If you're using a type like that repeatedly then it probably deserves an alias.
Every time you want to iterate over a map, for example, you're using std::pair<T,U> or std::unordered_map<T,U>::iterator. This gets very annoying without auto, and making an alias doesn't really address any of the complaints the article has.
The issues around type inference could be an annotation (extra overhead) on a function or line to enable some form of it, for simplicity of mapping or conversion, but leave it out by default. Now you get the best of both worlds.
Aliases have their own problems. You may have to propagate the alias, or define different aliases with the same type all over the place. Then you have issues with changing code.
Complex composed types just have this issue to be honest, and personally I like having inference as a tool to avoid the litter.
Complex composed types just have this issue to be honest, and personally I like having inference as a tool to avoid the litter.
But the bad news, then, is all that complexity is hidden, metastasising
Exactly. Just because you don't have to read it, doesn't mean it isn't there. It's still there, just hidden from you, and worse now you have less incentive to actually simplify it...
Yeah. “Auto” was probably one of the best additions to C++ ever.
When trying to figure out something's type is the same as trying to fully comprehend a regex pattern, you know things have gone too far.
[deleted]
Yeah, I think he hasn’t programmed Java.
> In Rust and Haskell you have to at least annotate the parameter types and return type of functions.
In Rust you do, but in Haskell you don't.
In Rust you do, but in Haskell you don't.
What about when writing a function with polymorphic recursion, rank-N types, or the monomorphism restriction?
There are plenty of examples where a type declaration is required to get functionality, especially when we consider what GHC offers as being "Haskell".
I agree the author could be more clear about this—that Haskell and GHC only sometimes require type annotations in certain circumstances.
There are plenty of examples where a type declaration is required to get functionality, especially when we consider what GHC offers as being "Haskell".
I agree the author could be more clear about this—that Haskell and GHC only sometimes require type annotations in certain circumstances.
To be clear these are extremely rare circumstances. You virtually never need type annotations.
And even in some cases where you used to need them a simple type application is often enough now.
You can go an entire career without writing a single type annotation. It depends heavily on what style of Haskell you write.
And even in some cases where you used to need them a simple type application is often enough now.
You can go an entire career without writing a single type annotation. It depends heavily on what style of Haskell you write.
In Haskell the culture is to always do it, more or less for this reason.
For top level functions maybe, but certainly not for helper functions defined in let ... in, or where clauses.
Haskell, or hlint, also has the concept of eta reduce which removes documenting variable names. Just awful.
The eta reduction code hint is a weird one for sure, although let's be real with Haskell naming conventions that usually means dropping an 'x'.
If the linter cares so much about making code point-free maybe they should start suggesting refactors like
If the linter cares so much about making code point-free maybe they should start suggesting refactors like
foo x = bar x (baz x)
foo = bar <*> baz
Or another example:
where
genBranchLabels = do
(,,,) <$> freshBranchLabel "if_"
<*> freshBranchLabel "then_"
<*> freshBranchLabel "else_"
<*> freshBranchLabel "endif_"
Cg<Tuple4<String, String, String, String>> genBranchLabels() {
return freshBranchLabel("if_")
.flatMap(i -> freshBranchLabel("then_")
.flatMap(th -> freshBranchLabel("else_")
.flatMap(el -> freshBranchLabel("endif_")
.map(ei -> new Tuple4<>(i, th, el, ei)))));
}For me it makes sense to distinguish between type inference at the call site or the definition site. As a caller of a function, I don't want to have to spell out type parameters for that function if they can be inferred (but forcing inference is also not great because it's helpful to have type parameters that have nothing to do with the inputs and merely depend on the outputs).
At the definition site, I agree with the author that type inference is more of a burden for the most part, at least if the function is more than a hidden implementation detail of the class/module/file.
At the definition site, I agree with the author that type inference is more of a burden for the most part, at least if the function is more than a hidden implementation detail of the class/module/file.
> For me it makes sense to distinguish between type inference at the call site or the definition site.
Bidirectional type checking kinda sorts this out by requiring annotations on top level functions and inferring or checking the rest in a mechanical manner. That's kind of a sweet spot or me. (And reportedly it's faster and gives better error messages.) Most dependent typed languages do this. I believe out of necessity. And Typescript also requires top level function definitions, but I haven't cheked if it is using the bidirectional algorithm.
If that's what the author is trying to say, then I agree. And with a Hindey-Milner system it's still best to annotate (most of) your top level functions (IMHO).
And I've gotten into trouble not doing this in the past. I started a project at work with flowjs, got inscrutable type errors in a different file than wherever the root cause was and bailed for typescript. In hindsight, it wasn't the fault of flowjs, but rather my lack of annotations on top level functions. (I knew far less about type-checking at the time.)
Bidirectional type checking kinda sorts this out by requiring annotations on top level functions and inferring or checking the rest in a mechanical manner. That's kind of a sweet spot or me. (And reportedly it's faster and gives better error messages.) Most dependent typed languages do this. I believe out of necessity. And Typescript also requires top level function definitions, but I haven't cheked if it is using the bidirectional algorithm.
If that's what the author is trying to say, then I agree. And with a Hindey-Milner system it's still best to annotate (most of) your top level functions (IMHO).
And I've gotten into trouble not doing this in the past. I started a project at work with flowjs, got inscrutable type errors in a different file than wherever the root cause was and bailed for typescript. In hindsight, it wasn't the fault of flowjs, but rather my lack of annotations on top level functions. (I knew far less about type-checking at the time.)
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.
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.
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;
}Bullocks. I wrote thousands if not hundred thousandths lines of untyped Python code in over 15 years, for critical systems and thousands of users.
It works for me. I'm not confused about the code, I can code and debug quicker than many of my typed-language colleagues and even now that python supports type hints I often only use them in bigger projects or in places where they're actually convenient.
It's simply the way of working that a developer is used to.
I inherited thousands of untyped Python code for critical systems, and it was an unmaintainable hot mess that caused a constant stream of pain. No kidding that was one of the main reasons we had to build a second version of the system.
I love Python, but I use it carefully in large scale production settings. Python with a Typescript-like static type system would hit the sweet spot for me (and yes, I've used mypy, but it doesn't hit the same spot).
I love Python, but I use it carefully in large scale production settings. Python with a Typescript-like static type system would hit the sweet spot for me (and yes, I've used mypy, but it doesn't hit the same spot).
Man I wish I could somehow convince developers to learn the difference between "dynamically typed", "statically typed", and "gradually typed" languages. An "untyped" language nearly doesn't make any sense semantically: when you have more than one type of value, you have types.
In Python's case, there are probably thousands of types in the standard library alone.
In Python's case, there are probably thousands of types in the standard library alone.
This is one of those cases where I fully stand with the people saying that you should read the writers intent and assume that they just didn't have enough coffee that morning yet to be thinking pedantically.
You know exactly what that person meant.
You know exactly what that person meant.
Congratulations, you've achieved perpetual job security as no new developer can actually work on that codebase as well as you do.
Also you're confusing dynamic typing and type inference.
Also you're confusing dynamic typing and type inference.
> Also you're confusing dynamic typing and type inference.
I think you missed their point, which is that "it is fine for me in Python not to see the type in the source code, and therefore I believe that it should be fine in other languages (be it dynamic typing or type inference)".
I think you missed their point, which is that "it is fine for me in Python not to see the type in the source code, and therefore I believe that it should be fine in other languages (be it dynamic typing or type inference)".
The fact that people can get used to something and be productive with it doesn't mean that its not objectively worse than the alternative.
It's an existence proof that “objectively worse” is, at a minimum, context dependant.
A bicycle is objectively worse if you have many staircases to deal with, but that doesn't imply that getting used to one and being productive with it is fundamentally and necessarily misguided.
A bicycle is objectively worse if you have many staircases to deal with, but that doesn't imply that getting used to one and being productive with it is fundamentally and necessarily misguided.
Except that there’s basically no non-subjective evidence in favor of statically typed languages.
Don't conflate personal preference as objective truth.
But in this example, many of the programmers know the alternative (i.e they learned c++, java etc) and still prefer something else...
Objective merit is very dependent on the problem and the context. There is no absolute merit one way or the other.
Subjectively is what you mean. Typing out types has a cost when you want a REPL
Type inference has usability problems (2019): https://austinhenley.com/blog/typeinference.html
> Imagine you're told to calculate 3+9+15+18+5.
Too hard. I need to see the types:
> My response? Go refactor your hideous code.
Too hard. I need to see the types:
((((3::Int)+(9::Int)::Int)+(15::Int)::Int)+(18::Int)::Int)+(5::Int)::Int
> My response? Go refactor your hideous code.
I think this article makes some really valid points. Many languages try to address the spooky action at a distance type errors by requiring explicit annotation of types at certain boundary type conditions like function argument and return arguments -- which can help but can still also being annoying when the type system knows the types you want to write but you still have to figure them out and type them in yourself. A lot of times it's less cognitive load to verify that a type declaration is what you expect than it is to write it yourself (something we often do with tools like rust-analyzer or highlighting over variables in ide to see the type).
Personally I'd like to see languages embrace "format on save" as an explicit part of language ui to improve ergonomics here. Firstly, a first class auto formatting tool is just great and spamming cmd-s as you write code until it auto formats nicely is a really quick way to observe and address syntax issues -- to me that part of the experience is already important enough to explicitly incorporate making that developer experience work well a goal of language design.
But secondly -- if you do embrace auto format on save at language design level, there's a lot more you can do than just auto format the code! You also gain a really nice channel for communicating information about "program change" to the developer. Say you allow in the language to differentiate between inferred and not inferred types -- and then at auto format time, the inferred types are explicitly added to the code (in some heuristically useful set of places-- or even just everywhere that a non type inferenced language would require explicit types).
In that world, as you make changes to the code, your git diff state is going to start giving you a lot of potentially useful feedback about what actually happens in your program when you make certain changes. Additionally because the inferred types are automatically added -- you can easily have a mode to hide them when you want a less noisy view. Mayb the convention would become that committeed code is always serialized to a form that conveys more of the statically knowable program information by default -- which your ide can hide to give you a more streamlined view -- rather than the other way around). And then the parts of your code you know are boundaries or apis or not expected to change types, you just update the annotation to indicate that the type is not supposed to be reinferred and a type error will be issued if it doesn't match instead of being updated. Now you've got a nice way of constraining program evolution in desired directions to help tame complexity or at least force explicit acknowledgement as certain assumptions about the program structure become invalid over time ...
Personally I'd like to see languages embrace "format on save" as an explicit part of language ui to improve ergonomics here. Firstly, a first class auto formatting tool is just great and spamming cmd-s as you write code until it auto formats nicely is a really quick way to observe and address syntax issues -- to me that part of the experience is already important enough to explicitly incorporate making that developer experience work well a goal of language design.
But secondly -- if you do embrace auto format on save at language design level, there's a lot more you can do than just auto format the code! You also gain a really nice channel for communicating information about "program change" to the developer. Say you allow in the language to differentiate between inferred and not inferred types -- and then at auto format time, the inferred types are explicitly added to the code (in some heuristically useful set of places-- or even just everywhere that a non type inferenced language would require explicit types).
In that world, as you make changes to the code, your git diff state is going to start giving you a lot of potentially useful feedback about what actually happens in your program when you make certain changes. Additionally because the inferred types are automatically added -- you can easily have a mode to hide them when you want a less noisy view. Mayb the convention would become that committeed code is always serialized to a form that conveys more of the statically knowable program information by default -- which your ide can hide to give you a more streamlined view -- rather than the other way around). And then the parts of your code you know are boundaries or apis or not expected to change types, you just update the annotation to indicate that the type is not supposed to be reinferred and a type error will be issued if it doesn't match instead of being updated. Now you've got a nice way of constraining program evolution in desired directions to help tame complexity or at least force explicit acknowledgement as certain assumptions about the program structure become invalid over time ...
Do you have any sources or links where you or others expand on these ideas? I daydream about something like this every so often.
In my experience IDEs and language servers for a language like F# have a convenient "Add explicit type annotation" that will do just as you're suggesting.
I think a neat ide feature would be to auto hide all the types and only show them as a pop up tooltip or something similar.
This way you can read the code more easily and if you want to see the type it's there for you.
This way you can read the code more easily and if you want to see the type it's there for you.
From what I can tell most functional programming tooling has this feature, but in the inverted manner from what you're describing for a language with explicit typing. You can hide the inferred type annotations but then have a key chord for showing them. I tend to just leave the annotations visible.
This is available for Rust. It might be for other languages. You can show the types as hints in the editor, or you can hover the variables to see the types. The latter is available for many languages, including Python and Go.
100% agreed. I want to see the types, and not just when hovering.
Now, if the IDE autocompletes the type declaration for me somehow, that's great! That's a win-win: I save time but still maintain readability.
Now, if the IDE autocompletes the type declaration for me somehow, that's great! That's a win-win: I save time but still maintain readability.
"if the IDE autocompletes the type declaration for me somehow".
Then you will need type inference to some extend. :D
Then you will need type inference to some extend. :D
> languages that use it too much are harder to write. It’s a false economy whereby you save unobservable milliseconds of typing today and make everything else worse.
I enjoyed this reference to a false dichotomy while making one itself. Languages don't make programmers leave out annotations where it aids readability.
I enjoyed this reference to a false dichotomy while making one itself. Languages don't make programmers leave out annotations where it aids readability.
> Languages don't make programmers leave out annotations where it aids readability.
This is true, but most people are not going to incur write-time penalties to benefit read-time later on. Annotations (usually) benefit read-time at the expense of write-time. Having had to work on codebases that were written by people who were furiously trying to "get things done" because not shipping or shipping late might mean going out of business, they take whatever shortcuts they can. It ultimately saddles other people with tech debt for years and in some cases decades.
This is true, but most people are not going to incur write-time penalties to benefit read-time later on. Annotations (usually) benefit read-time at the expense of write-time. Having had to work on codebases that were written by people who were furiously trying to "get things done" because not shipping or shipping late might mean going out of business, they take whatever shortcuts they can. It ultimately saddles other people with tech debt for years and in some cases decades.
I think this is both right and wrong. Granting Sturgeon's law, most code is bad and hard to read and type annotations will usually help. On the other hand, in code that is very well written, type annotations are largely redundant visual clutter that do not improve the readability.
I'd say that for most people, use annotations most of the time is good advice, but there are exceptions and people should refrain from casting judgment on other's work due to a dogmatic instance on others using their preferred style.
I'd say that for most people, use annotations most of the time is good advice, but there are exceptions and people should refrain from casting judgment on other's work due to a dogmatic instance on others using their preferred style.
I agree completely, well said. It's probably 1 in 10 (in line with Sturgeon's Law) but there are some devs out there for whom their code is like poetry, and reading it is a genuine pleasure. For those, types and annotations and such really do add clutter and make it worse.
This is why we have gradual typing, or static type analysis added to dynamic languages. I work in a large Ruby/Rails codebase that has high Sorbet type annotation coverage. There really is no excuse to keep avoiding adding type info, or at least recognize that the pain is self-inflicted.
One of my dream ideas is to write a codemod that either adds all the implicit type inferencing explicitly, or removes it.
It's great that we don't have to type every type definition. But when reading code, it sure is much easier seeing exactly what every type is explicitly. You can look object by object in most ides by hovering over each item, but it doesn't have the at-a-glace see-it-all viewability; hence the idea, just rewrite the code with or without the explicit types, as desired.
There's still a lot of type narrowing and other things that happen that aren't super visible, that alter the known typing state as we go. I have less of an idea of what to do with that.
It's great that we don't have to type every type definition. But when reading code, it sure is much easier seeing exactly what every type is explicitly. You can look object by object in most ides by hovering over each item, but it doesn't have the at-a-glace see-it-all viewability; hence the idea, just rewrite the code with or without the explicit types, as desired.
There's still a lot of type narrowing and other things that happen that aren't super visible, that alter the known typing state as we go. I have less of an idea of what to do with that.
The claim about inferences rules in academic papers is false. Gentzen’s inference rules are usually used to specify how to type check and not type inference even though inference rules and type inference overlap in the use of the word inference.
Definitely disagree. The language where this really shines is Swift, where type inference is used really heavily.
It's really great for stuff like passing enums as function arguments. You can write `context.setColor(.red)` instead of `context.setColor(Color.red)`, the latter of which I find just unnecessarily repetitive.
The coolest part about this is when you're using a new unfamiliar API, you can let your IDE's auto complete suggest options for you just by typing '.' and pick from the list of options shown inline.
It's really great for stuff like passing enums as function arguments. You can write `context.setColor(.red)` instead of `context.setColor(Color.red)`, the latter of which I find just unnecessarily repetitive.
The coolest part about this is when you're using a new unfamiliar API, you can let your IDE's auto complete suggest options for you just by typing '.' and pick from the list of options shown inline.
I get their argument on reading code in less than an IDE environment (ie. book), but in general, I think _limited_ type inference is good (on classes/structs and functions). Not having local variable types is a net positive in general, but I agree with the author that full type inference (on functions) removes too much documentation. In OCaml one should therefore use interface files always IMO.
Type inference is a good thing. If you abuse it, the same way you abuse lambdas or any other feature, it can get bad.
The fact is that in many languages, type checking and type inference are coupled together (for languages with DT, bidirectional type checking is needed). When writing proofs, it is almost impossible to let user specify every type.
Ok, let’s go back to normal imperative programming. What about alias analysis? What to do with devirtualization? You NEED type inference. That is being said, I am not a fan of the “usual” ocaml’s style where ppl seem to write as less type annotations as they can. That is not user friendly.
Ok, let’s go back to normal imperative programming. What about alias analysis? What to do with devirtualization? You NEED type inference. That is being said, I am not a fan of the “usual” ocaml’s style where ppl seem to write as less type annotations as they can. That is not user friendly.
“I don’t want to infer types from my code. I’d rather infer the code from the types.”
Ditto.
The world where data and it’s type is the SSOT means you can trivially validate every bit of code that touches it.
Ditto.
The world where data and it’s type is the SSOT means you can trivially validate every bit of code that touches it.
> I don’t want to infer types from my code. I’d rather infer the code from the types.
I use type inference for this: the compiler looks at the existing types and then infers the type of the code I haven't yet written and tells me. I then write code based on the type given to me by the compiler.
I use type inference for this: the compiler looks at the existing types and then infers the type of the code I haven't yet written and tells me. I then write code based on the type given to me by the compiler.
Hmm I code a lot in vim without any plugins (I just have syntax highlighting). It has never really been a problem for me (say in C++, Rust or Kotlin): I guess I'm training my memory a bit more?
I'll admit, once in a while I write something like `let a: Int = <the_var_which_type_I_dont_know>` and compile, such that the compiler says something like "expected an Int, got a HashMap<String, Int>". But pretty rarely.
So yeah, I kind of like type inference.
I'll admit, once in a while I write something like `let a: Int = <the_var_which_type_I_dont_know>` and compile, such that the compiler says something like "expected an Int, got a HashMap<String, Int>". But pretty rarely.
So yeah, I kind of like type inference.
In C# I've been preferring to only use var when the type appears in the expression so that it can be inferred by humans if you printed it out. In rust I've been using type inference per the usual rust coding conventions. I haven't quite sorted out in my head which way I really think is better.
> Type inference is only for variable bindings inside the function body. This is a lot more tractable.
Type inference inside a function body, is still type inference. Type inference gives us options and can sometimes improve readability. I find the title and premise of this article rather silly.
Type inference inside a function body, is still type inference. Type inference gives us options and can sometimes improve readability. I find the title and premise of this article rather silly.
I agree with the idea that function return types should be explicit rather than inferred, but not the rest. In a lot of situations, inference makes it so you only have to spell the type once, instead of multiple times. That is valuable and doesn't reduce legibility.
> 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<SomeClass>
That way you can both write code with type inference, but read code with fully annotated types!
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<SomeClass>
That way you can both write code with type inference, but read code with fully annotated types!
That's actually how I use IntelliJ, I'll type something like
x = foo();
vector<Bar> x = foo();
Maybe write the types in the actual files and let the editors optimize it away instead of having it as a language feature. I don't want to see or write all the types in my daily work but when reviewing other peoples code I would like to have them.
Explicit is better than implicit.
But I can see the value of inference if the type is defined by a constant. If the rule is "Variables are the type of the constant that you assign in the definition, anything else is manual" it's pretty obvious.
But I can see the value of inference if the type is defined by a constant. If the rule is "Variables are the type of the constant that you assign in the definition, anything else is manual" it's pretty obvious.
(noun Explicit) (verb is) (adjective better) (conjunction than) (noun implicit).
Yeah no. OCamls is beautiful to write exactly because when you make a mistake, it will complain, and it's type inference works magic. You just have to learn the errors and think about what you changed when things broke.
The type is an overlay away. When you need it you can read it. When you know it you can hide it to leave more space for the code. What's the matter??
I admit, I like to use `auto` more than I like to read it
Some folks just have low tolerance for ambiguity and can't get past it. It has it's positives and negatives.
vscode just writes the type next to the auto variable. It also prints parameter names, initializer fields and even array initializer indexes.
All this visual help makes a lot of pet arguments obsolete.
All this visual help makes a lot of pet arguments obsolete.
I’ve been working with TypeScript and it’s literally wrong half the time. This code is 100% correct according to TS:
x: number[] = []
y: number = x[0]
The array type is missing information about the length of the array, and types are very often missing important information like this. Say you want to describe an array containing only odd integers - good luck.
Types are simply a heuristic for humans to try and remember vaguely what their code should do. If you want to do anything complex you need to abandon them anyway and use things like x!, and x as my_type. So designing around types seems like a bad idea.
You could do much better by abandoning text based programming languages and creating a visual programming language where you can zoom out and see what information gets passed where. The whole reason for types is to be a hack fix to the problem that we’re too zoomed in on their code and can only really reason about one function at a time given our crappy text-based programming languages.
x: number[] = []
y: number = x[0]
The array type is missing information about the length of the array, and types are very often missing important information like this. Say you want to describe an array containing only odd integers - good luck.
Types are simply a heuristic for humans to try and remember vaguely what their code should do. If you want to do anything complex you need to abandon them anyway and use things like x!, and x as my_type. So designing around types seems like a bad idea.
You could do much better by abandoning text based programming languages and creating a visual programming language where you can zoom out and see what information gets passed where. The whole reason for types is to be a hack fix to the problem that we’re too zoomed in on their code and can only really reason about one function at a time given our crappy text-based programming languages.
You need
"noUncheckedIndexedAccess": true
type OddNumber = number & { __BRAND_ODD_NUMBER: true }
OddNumber[]
const isOddNumber = (x: unknown): x is OddNumber => typeof x === 'number' && x % 2 === 1[deleted]
This SOUNDS like “types are bad”. The author’s message (towards the end of the article) is “I don’t want to infer types from my code. I’d rather infer the code from the types. Types are the spec…”
Yes. Always annotate types. Keep inference, it tells you when your annotations are inconsistent with tour code.
Yes. Always annotate types. Keep inference, it tells you when your annotations are inconsistent with tour code.
> Keep inference, it tells you when your annotations are inconsistent with tour code.
Isn't that plain type checking, rather than type inference?
Type checking detects inconsistencies, type inference assigns types in ways that avoid inconsistencies.
Isn't that plain type checking, rather than type inference?
Type checking detects inconsistencies, type inference assigns types in ways that avoid inconsistencies.
Right. I guess I meant annotate most of the things. (Top level things, complicated inner functions …) A few temporary values (next = current + 1) might go un-explicitly-typed. Anonymous functions will go untyped.
I should have said “ensure your intentions with regards to types are clear”.
Clearly u/z5h meant that type annotations should be optional and used where not inconvenient. That's how I took it anyways.
> This SOUNDS like “types are bad”
No, this sounds like:
* Type Inference Was a Mistake
* Type Inference Makes Code Less Readable
* Type Inference is a Footgun
* Type Inference Wastes Academic Effort
These are incompatible with:
> Keep inference
No, this sounds like:
* Type Inference Was a Mistake
* Type Inference Makes Code Less Readable
* Type Inference is a Footgun
* Type Inference Wastes Academic Effort
These are incompatible with:
> Keep 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.