Live data from Hacker News

Type Inference Was a Mistake

borretti.me

31–40 of 133 posts

Re: Type Inference Was a Mistake

#31

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 wa…

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.

Re: Type Inference Was a Mistake

#32
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.

Re: Type Inference Was a Mistake

#33
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.

Re: Type Inference Was a Mistake

#35

> 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 Haskell the culture is to always do it, more or less for this reason.

Haskell, or hlint, also has the concept of eta reduce which removes documenting variable names. Just awful.

Re: Type Inference Was a Mistake

#36

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.

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

Re: Type Inference Was a Mistake

#37
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.

Re: Type Inference Was a Mistake

#38

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 wa…

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.

Re: Type Inference Was a Mistake

#39

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 wa…

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.

Subjectively is what you mean. Typing out types has a cost when you want a REPL

Re: Type Inference Was a Mistake

#40

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 wa…

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.

Except that there’s basically no non-subjective evidence in favor of statically typed languages.
Post reply on HN