[nosefurhairdo]

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.

[lostdog]

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.

[hinkley]

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.

[loeg]

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

A good reason to use logical typedefs, though.

[lisper]

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.

[piva00]

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

[seanmcdirmid]

Books are those things you load on your kindle right? I mean, ya, they aren’t obsolete, but it’s not the main way I absorb information anymore.

[hinkley]

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.

[nosefurhairdo]

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.

[kqr]

But also when printing code in a book I would annotate with types, inference or not.

[hinkley]

Bruce Eckel (Thinking in Java) gave a presentation to the Seattle Java User’s Group sometime around 2008. I thought he would talk about Java things but he surprised us by talking about how annoying it is to get code snippets into books. He had interns writing a tool to extract live code and plop it into the book. It was something very similar to the tool I would find in jcite a few years later when my team had a bullseye on our back for being the only team close to on schedule (because we were using dev processes that were industry standard but not company standard and that pissed some people off).

They pointed out every place we weren’t following The Rules and one of those was that we weren’t creating a developer manual for people to use our library. Which was somewhat fair except I’d already walked people on every team through it, in person with a sequence diagram for doing their part of the workflow. But that was going to take me days of busy work every release and suck all of the joy out of my life. It was a clever chess move.

So what I did instead was fix our functional tests to be compatible with JCite, mash the printed form javadoc and some wiki pages together, and shoehorned them into a template of the corporate document format, programmatically. I couldn’t quite get the footers and indexes right, but I asked our less senior tech writer if she would be okay having to spend an hour fixing typesetting problems every release and she agreed. So instead of two developer days it was one hour of typesetting, by a tech writer. It took almost a year to break even on the time investment but it was well worth it in the long run.

To draw this curvy line back into a circle, I would think it perfectly reasonable not to utilize type inference in a functional or integration test. For the reason that you’d want something to break that tells you that you have a breaking change in this release.

[kqr]

Generating documentation from working code – as long as it's not at the expense of quality descriptions – is by far the superior way to make documentation. Every time I have not done that, the examples have become outdated within a year.

[Adverblessly]

I also find myself reading code in a browser, for example in GitHub or any other system for source control, issue management, code review etc.

[vorticalbox]

If you press ".” when on a repo on GitHub it will open vscode in your browser

[hn_throwaway_99]

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

[nosefurhairdo]

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.

[freedomben]

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.

[germandiago]

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

[freedomben]

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.

[AnimalMuppet]

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

[germandiago]

The type of a lambda cannot be spelled. The type of a local class return cannot be named from outside either.

[AnimalMuppet]

By "local class return", do you mean a function that returns what Java calls an "inner class"? That's perfectly describable (in C++ as well) if the inner class is public rather than private. It's unnameable, not because of the type, but because of the access (private).

[germandiago]

You can create a class inside a function and return an object of it. That name is not legal outside of the function but its methods can be called.