Your comment made me think of the adage: "Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live"

Another, less extreme version: "Your most important collaborator is yourself six months ago, and they won't respond to your emails."

I just spat coffee all over my desk. This is hilarious yet depressing since it reminds me that perhaps the human mind is like the ship of Theseus.

I don't know about my whole brain, but my programming brain totally is.

Now that I've been programming for a nontrivial number of years, it's happened enough that I no longer trust future me to understand anything clever that I do, so I spend much more time structuring code to require minimal context. Failing that, ample documentation, because future me will appreciate having an essay to read much more than current me wants to write it.

This is depressingly familiar. I can't tell you the number of times I've got an error, searched, ended up on StackOverflow reading the answer, full of stuff I have no knowledge of. Get to the end, it was answered by me. More than twice.

Seriously.

I'm now more obsessed with documentation and the kind of code structuring you mention and have come to hate, viscerally, projects that lack documentation.

As a potential aside, I once took a course in ASP. We had a bit of time before the class started and the tutor had a chat with a couple of us. Some huge government projects were in the news for having failed and gone well over budget. He told me he'd worked for the company behind them and that they used to obfuscate the code just by stripping out all the comments so the government had to keep going back to them for work.

I think of that any time I hear "but the code is the documentation"…

Or perhaps created anew every morning.

https://existentialcomics.com/comic/1

This is great! Thank you food sharing this!

Last week I found a bug where if I could go back in time 6 months, I'd go back and slap myself silly.

The version I've evolved, for teaching students why I care about style:

You need to communicate clearly with a number of coworkers, the most important of whom is future-nerdponx. Sometimes future-nerdponx is smarter than you, and sometimes future-nerdponx is dumber than you, but either way they know where you live, and their misery is your misery.

Sometimes I write my future self emails (well, logs), especially when I'm carefully stepping through knowledge domains or decisions I don't understand.

It's so helpful when I do it that I probably ought to do it more, and if there weren't so much overhead I'd probably do it everywhere.

Just watched Tenet yesterday and this comment reminded me of the pincer technique

This is literally one of the topics covered in the article and the author advocates for the same solution, documenting the alternative in the error/deprecation message...

Is supporting the article's position frowned upon?

No. But when it's not explicitly mentioned as support, it can appear as an implicit contradiction to readers. We also want the discussion about an article to build on what the article proposes, and explicitly tying comments to the article help with that.

Agreed. There's been a lot more "commenting without reading the article" here recently than in the past. So when someone comments on an article without anything in the comment that refers back to the article and merely offers the exact advice that was in the article without further analysis or insight:

1. That gives the appearance of a user who hasn't read the article

2. Even if the user did read the article I'm not sure what their comment adds to discussion of the article. For comparison, imagine participating in a conversation with a few friends in real life, friend X says "It's a good idea to write tests for your code," then friend Y replies "It's a good idea to write tests for your code." Usually the way people discuss things is to reply or offer addendums to the original idea. It's not a rule, it's just good conversation.

In this case, I think the generous interpretation is that the poster simply missed that section of the article. The generous interpretation basically requires one to conclude he read it, because otherwise he wouldn't make the connection to deprecation from the title alone.

The article in question is usually not the topic of conversation on HN. It is better to consider it to be the launching point for the conversation. Some will discuss the article, certainly, but you can expect the conversation to branch out very quickly to related items (especially if those items are mentioned in the article). While it's probably not a good idea to discuss the plight of African elephants in these threads, drawing attention to a minor, but specific point in the article is perfectly cromulent.

In this case, the post has value. It does two things. First, it draws attention to a subtopic that was only an aside in the article. (One I happened to miss the first read-through.) Second, the phrasing in the article is somewhat general and vague about this, and the post is relatively more specific and direct.

It's a shame people don't actually read the articles because, assuming the article is actually insightful, you can have better discussions after the community has actually read the article.

And in the case where people don't read the article and just read the headline, many comments have nothing to do with the article, and end up discussing a less interesting misconception of the submitted article's title/headline.

It's great to be generous with our interpretations of comments here on HN. But I would like to push for a higher standard of discussion, which has always been the draw of this community, particularly for technical articles (and this is actually a high quality technical article!). So I don't think I'll ever be happy being generous to a low value comment that re-states an opinion from the submitted article without adding anything or even without adding much.

Seems to me that if you want shitlists to drive development then often there won't be an immediate replacement.

That’s because you don’t understand what deprecated means.

Deprecated means “still supported but its use is discouraged.” It does not mean “no longer supported.”

I've always understood Deprecated to mean "This works, but we don't want you to use it in new code, and we plan/hope to remove it in the future."

This is the practical usage, it is really language dependent, though.

C++/Wikipedia uses the definition of the original poster, while Java's @Deprecated annotation literally has a `forRemoval` boolean value attached. Personally, I am used to how it is used in semantic versioning where it is just a helpful hint for what the next release's breaking changes may be while introducing the migration behavior if possible in this release. This allows for clients to incrementally migrate instead of making it all or nothing.

Deprecation without an obvious replacement is pretty toothless, because people will keep using the deprecated thing for lack of an obvious replacement. This is how we ended up with disasters like the Python 2/3 transition.