A bike-shedding thread on top as usual.

I understand the frustration (probably no one feels it more than we do, because it's our job to help discussion stay meaningful). But please don't respond by posting like this.

It takes time for the contrarian dynamic to work itself out (https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...), and once that happens, the original problem subsides but and the secondary problem (shallow objection to the objection) sticks out like a sore thumb.

It's usually enough to downvote (or, in egregious cases) flag a post that shouldn't be at the top. In really egregious cases, emailing hn@ycombinator.com is also a fine idea.

From the guidelines: "Please don't sneer, including at the rest of the community." - https://news.ycombinator.com/newsguidelines.html

Yeah I see this a lot on HN. I think people feel the need to make precise and accurate statements about things. I think a lot of them, if they'd deep breath and waited 30 minutes, they wouldn't comment.

The internet is filled with pedantics, creeps and dogs posing as cats. The whole "take a breath" thing was early abandoned in favor of the now traditional "reply until the other party gives up" approach, which requires you to really dig into their messages and point out spelling mistakes, fallacies, and for programmers, variable names.

Code quality is not bike shedding.

It is, however, off topic and beside the point. And whether short names are a code quality issue is a rather contested and context-dependent topic.

Code quality of... an example snippet?

Especially

especially now that the example is gonna end up in some LLM somewhere and folks will just copy pasta.

It's hard to read, especially in the lambdas.

It's a small critique, I'm sorry it got upvoted by other people.

Usually I'd cosign, but I get it, after a similiar issue I had a couple days ago with a Rust article that was insanely frustrating to deal with.

It's a brain scramble because you can't just read in toto.

Well, you can literally, but, you don't feel like you grok it.

And when you take a second pass you gotta slow down and stop and parse "what's r here? is it relevant? oh rows?"

It's one of those things that's hard to describe because it doesn't sound like much if you got it. And this example is trivial, especially if you're not open to the idea its a problem (r/c = rows/columns) But it's nigh-impenetrable in other scenarios.

You feel like you're barely understanding something that you actually might grok completely.

> It's one of those things that's hard to describe because it doesn't sound like much if you got it. And this example is trivial, especially if you're not open to the idea its a problem (r/c = rows/columns) But it's nigh-impenetrable in other scenarios.

I agree, it's highly context-specific.

In a small demo for a small blog post with basically no complexity? Go ahead, use 1 character variable names, it really isn't difficult.

In the 1000 long CUDA kernel where you barely understand what's going on even though you understand the concepts? I'd be favoring longer descriptive names than one letter names for sure.