Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Type Inference Was a Mistake

borretti.me

Post reply on HN
Print view View original

61–70 of 133 posts

Re: Type Inference Was a Mistake

#61

Post by hn_throwaway_99 »

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

Re: Type Inference Was a Mistake

#62

Post by dunham »

jupp0r wrote: post #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 th…

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

Re: Type Inference Was a Mistake

#63

Post by freedomben »

ilaksh wrote: post #49

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

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?

Re: Type Inference Was a Mistake

#64

Post by lostdog »

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.

Re: Type Inference Was a Mistake

#66

Post by germandiago »

freedomben wrote: post #53
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.

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

Re: Type Inference Was a Mistake

#67

Post by tromp »

Filligree wrote: post #14
josephcsible wrote: post #4

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

For top level functions maybe, but certainly not for helper functions defined in let ... in, or where clauses.

Re: Type Inference Was a Mistake

#68

Post by freedomben »

blueboo wrote: post #42
advisedwang wrote: post #11

Explicit typing is great until your code is littered with shared_ptr >>> everywhere.

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

Re: Type Inference Was a Mistake

#70

Post by wredue »

idle_zealot wrote: post #24
advisedwang wrote: post #11

Explicit typing is great until your code is littered with shared_ptr >>> everywhere.

If you're using a type like that repeatedly then it probably deserves an alias.

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.

Post reply on HN