Type Inference Was a Mistake • Hacker News Board

Re: Type Inference Was a Mistake

#101

Post by karmakaze » Sat, Mar 30, 2024, 7:06 PM UTC

freedomben wrote: post #76

karmakaze wrote: post #26

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

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

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.

Re: Type Inference Was a Mistake

#102

Post by jauntywundrkind » Sat, Mar 30, 2024, 7:08 PM UTC

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.

Re: Type Inference Was a Mistake

#103

Post by cryptonector » Sat, Mar 30, 2024, 7:10 PM UTC

kqr wrote: post #15

z5h wrote: post #9

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.

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

Clearly u/z5h meant that type annotations should be optional and used where not inconvenient. That's how I took it anyways.

Re: Type Inference Was a Mistake

#104

Post by grumpyprole » Sat, Mar 30, 2024, 7:16 PM UTC

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

Re: Type Inference Was a Mistake

#105

Post by maleldil » Sat, Mar 30, 2024, 7:18 PM UTC

whatever1 wrote: post #45

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

Re: Type Inference Was a Mistake

#106

Post by nosefurhairdo » Sat, Mar 30, 2024, 7:18 PM UTC

hinkley wrote: post #83

nosefurhairdo wrote: post #18

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.

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

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.

Re: Type Inference Was a Mistake

#107

Post by AnimalMuppet » Sat, Mar 30, 2024, 7:21 PM UTC

germandiago wrote: post #66

freedomben wrote: post #53

Earlier quoted context omitted.

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.

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…

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

Re: Type Inference Was a Mistake

#108

Post by schrodingerzhu » Sat, Mar 30, 2024, 7:27 PM UTC

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.

Re: Type Inference Was a Mistake

#109

Post by nosefurhairdo » Sat, Mar 30, 2024, 7:30 PM UTC

hn_throwaway_99 wrote: post #61

nosefurhairdo wrote: post #18

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.

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

Re: Type Inference Was a Mistake

#110

Post by eternityforest » Sat, Mar 30, 2024, 7:55 PM UTC

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.