Type Inference Was a Mistake • Hacker News Board

Re: Type Inference Was a Mistake

#81

Post by buzzert » Sat, Mar 30, 2024, 6:11 PM UTC

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.

Re: Type Inference Was a Mistake

#82

Post by angarg12 » Sat, Mar 30, 2024, 6:11 PM UTC

thesuavefactor wrote: post #27

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…

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

Re: Type Inference Was a Mistake

#83

Post by hinkley » Sat, Mar 30, 2024, 6:14 PM UTC

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

Re: Type Inference Was a Mistake

#84

Post by TulliusCicero » Sat, Mar 30, 2024, 6:15 PM UTC

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.

Re: Type Inference Was a Mistake

#85

Post by williamcotton » Sat, Mar 30, 2024, 6:15 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.

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.

Re: Type Inference Was a Mistake

#86

Post by piva00 » Sat, Mar 30, 2024, 6:15 PM UTC

lisper wrote: post #48

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.

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.

Books are definitely not obsolete technology, you can consider them old or even traditional but they aren't obsolete by any means.

Re: Type Inference Was a Mistake

#87

Post by palata » Sat, Mar 30, 2024, 6:16 PM UTC

littlestymaar wrote: post #38

thesuavefactor wrote: post #27

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.

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

Re: Type Inference Was a Mistake

#88

Post by williamcotton » Sat, Mar 30, 2024, 6:18 PM UTC

breatheoften wrote: post #56

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

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.

Re: Type Inference Was a Mistake

#89

Post by hinkley » Sat, Mar 30, 2024, 6:18 PM UTC

lostdog wrote: post #64

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.

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.

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.

Re: Type Inference Was a Mistake

#90

Post by palata » Sat, Mar 30, 2024, 6:20 PM UTC

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 = ` and compile, such that the compiler says something like "expected an Int, got a HashMap". But pretty rarely.

So yeah, I kind of like type inference.