Type Inference Was a Mistake • Hacker News Board

Re: Type Inference Was a Mistake

#41

Post by p5a0u9l » Sat, Mar 30, 2024, 5:40 PM UTC

golergka wrote: post #31

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…

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.

Objective merit is very dependent on the problem and the context. There is no absolute merit one way or the other.

Re: Type Inference Was a Mistake

#42

Post by blueboo » Sat, Mar 30, 2024, 5:40 PM UTC

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

Re: Type Inference Was a Mistake

#43

Post by vacuity » Sat, Mar 30, 2024, 5:41 PM UTC

masklinn wrote: post #8

yazzku wrote: post #3

Earlier quoted context omitted.

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.

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.

Yes, particularly due to the design decision that Rust code should strive to be explicit in intention and mechanism.

Re: Type Inference Was a Mistake

#44

Post by kristopolous » Sat, Mar 30, 2024, 5:42 PM UTC

golergka wrote: post #31

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…

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.

Don't conflate personal preference as objective truth.

Re: Type Inference Was a Mistake

#45

Post by whatever1 » Sat, Mar 30, 2024, 5:42 PM UTC

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.

Re: Type Inference Was a Mistake

#46

Post by danielmarkbruce » Sat, Mar 30, 2024, 5:42 PM UTC

Some folks just have low tolerance for ambiguity and can't get past it. It has it's positives and negatives.

Re: Type Inference Was a Mistake

#47

Post by TillE » Sat, Mar 30, 2024, 5:42 PM UTC

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.

Every time you want to iterate over a map, for example, you're using std::pair or std::unordered_map::iterator. This gets very annoying without auto, and making an alias doesn't really address any of the complaints the article has.

Re: Type Inference Was a Mistake

#48

Post by lisper » Sat, Mar 30, 2024, 5:43 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.

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.

Re: Type Inference Was a Mistake

#49

Post by ilaksh » Sat, Mar 30, 2024, 5:43 PM UTC

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

Re: Type Inference Was a Mistake

#50

Post by cwillu » Sat, Mar 30, 2024, 5:44 PM UTC

golergka wrote: post #31

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…

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.