Maybe write the types in the actual files and let the editors optimize it away instead of having it as a language feature. I don't want to see or write all the types in my daily work but when reviewing other peoples code I would like to have them.
Type Inference Was a Mistake
71–80 of 133 posts
Re: Type Inference Was a Mistake
#72Earlier quoted context omitted.
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.
The issues around type inference could be an annotation (extra overhead) on a function or line to enable some form of it, for simplicity of mapping or conversion, but leave it out by default. Now you get the best of both worlds.
Re: Type Inference Was a Mistake
#73> 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.
What about when writing a function with polymorphic recursion, rank-N types, or the monomorphism restriction? There are plenty of examples where a type declaration is required to get functionality, especially when we consider what GHC offers as being "Haskell". I agree the author could be more clear about this—that Haskell and GHC only sometimes require type annotations in certain circumstances.
To be clear these are extremely rare circumstances. You virtually never need type annotations.
And even in some cases where you used to need them a simple type application is often enough now.
You can go an entire career without writing a single type annotation. It depends heavily on what style of Haskell you write.
Re: Type Inference Was a Mistake
#74Yeah no. OCamls is beautiful to write exactly because when you make a mistake, it will complain, and it's type inference works magic. You just have to learn the errors and think about what you changed when things broke.
Re: Type Inference Was a Mistake
#75"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?
He did not actually say his criticism only applies to statically typed languages. He almost implied that he would consider dynamically typed languages invalid by default without the types.
It does matter that there is a lot of successful software written in languages that are dynamically typed or use type inference when some want to dismiss these approaches entirely. Because it proves that these approaches can still result in useful and reliable software and productive software engineering.
Re: Type Inference Was a Mistake
#76> 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 out of business, they take whatever shortcuts they can. It ultimately saddles other people with tech debt for years and in some cases decades.
Re: Type Inference Was a Mistake
#77I’ve been working with TypeScript and it’s literally wrong half the time. This code is 100% correct according to TS:
x: number[] = []
y: number = x[0]
The array type is missing information about the length of the array, and types are very often missing important information like this. Say you want to describe an array containing only odd integers - good luck.
Types are simply a heuristic for humans to try and remember vaguely what their code should do. If you want to do anything complex you need to abandon them anyway and use things like x!, and x as my_type. So designing around types seems like a bad idea.
You could do much better by abandoning text based programming languages and creating a visual programming language where you can zoom out and see what information gets passed where. The whole reason for types is to be a hack fix to the problem that we’re too zoomed in on their code and can only really reason about one function at a time given our crappy text-based programming languages.
Re: Type Inference Was a Mistake
#78Earlier 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…
I mostly agree with you fwiw. I don't think type inference as a whole is a mistake, and especially regarding local variables I think it can make things a lot cleaner and save unnecessary work.
My main problem with it (in general, not specifically C++) is that most implementations leave it up to people's judgment about when and where to use it, and they almost always use it too liberally. This is a mistake I make myself because it's not usually clear at write-time where the readability cost will out-weigh the benefit, and when the code is freshly in your head you don't need the extra information that comes from explicit typing (and indeed it can feel superfluous).
But I think it's worth pointing out that the GP comment on this thread (which I was replying to) was essentially advocating for maximum type inference because the IDE can show you at any time what the type is, so any explicit typing is superfluous to them.
Re: Type Inference Was a Mistake
#79Bad:
- Omitting return types in non-private interfaces (eg crossing module or package boundaries, or anything used as input to generate documentation of same)
- Omitting concrete input parameter types
- Omitting explicit, known constraints on generic/polymorphic parameters
Subjective:
- Omitting any of the same on private equivalents which form something like an internal interface
- Omitting annotations of constant/static aspects of an interface whose inferred types are identical to their hypothetical annotation
Subjective but mostly good:
- Relying on inference in type derivation, where type derivation is the explicit goal of that API
- Preferring inference of interface/protocol/contract types over explicit annotation of concrete types which happen to satisfy them
- Omitting annotations for local bindings without distant indirection
Unambiguously good:
- Omitting local annotations of direct assignment where the type is obvious in situ
- Omitting redundant annotations of the same type which have the same effect without that redundancy
Re: Type Inference Was a Mistake
#80> Type inference is bad. It makes code harder to read, and languages that use it too much are harder to write. If inference is bad, maybe the second sentence shouldn't leave it up to the reader to infer what "it" means. Surely it would be much easier to read as "Type inference [...] type inference [...] type inference".
Funny enough this is the approach taken in legal writing as to limit misinterpretation... especially purposeful misinterpretation from opposition legal teams!
This results in highly repetitive, and as you've pointed out, somewhat tedious reading.
F# is my daily driver at work and I definitely benefit from both the type inference as well as my IDE making those types explicit for my reading pleasure!