Do [sed], [regex] and similar tag questions need to be treated differently

A couple of users encouraged me in good faith to write this. I was a bit skeptical, but today I figured, why not. Here goes.

I want to make an argument for why certain tags, sed, regex etc, are treated differently at Stack Overflow, and, perhaps more controversially, must be treated differently. I think the approach I am suggesting is pragmatic, doesn't really break SO's design, is consistent with SO's remit, and most importantly, will resolve so much of the conflict seen.

Hear me out.

Send me teh codez tags

I am going to focus on sed mostly because I know sed very well, but similar considerations extend to other tags like regex, awk, sql, css, etc.

These tags have been described in comments here as send me teh codez tags. That is, the questions often can't be broken down further; it is hard if not impossible to google for the answers; the alternative to asking at SO would be to just fully read the manuals; no one honestly expects the OPs to actually do that; there is often no real way to reduce these questions to minimal, complete, verifiable examples anyway; sometimes it is difficult to put into words what you're trying to do if you don't understand the language; showing what you tried already doesn't necessarily add much to the question; and, besides. These queues have at least 10 competitive, rep-huntin' regulars who are going to answer the questions anyway within minutes of posting, if not within seconds.

So what can we do?

One user suggested cynically that these tags need to be recognised as "lost cause" tags. Another put it more positively and said that because the queues help lots of people get their jobs done, it could be that the regulars have more insight here, and maybe all the rep-huntin' isn't the big problem it appears to be. Yet another Meta hardliner suggested that, no, the problem begins and ends with the disobedient rep-huntin' regulars who simply refuse to enforce the site's rules, because they care about rep.

Why these questions are different

Inherently different languages

In the case of sed, and I think certainly regex too, and probably all the others, these questions are inherently different to regular higher-level programming language questions.

Sed, specifically, is a tiny, Turing-complete programming language. It consists of a regular expression engine; about 30 builtin single-letter functions; 2 buffers; and a very simple grammar.

Understanding why sed needs to be treated differently begins with recognising that sed is tiny, relative to other languages, and every question about it has been asked before. Many times.

Additionally, sed lacks features familiar to other programmers like variables, user defined functions, libraries etc. Solving problems in sed involves thinking about problems in a very different way.

The end result of this is consumers of sed scripts typically want one-line scripts that are just known to work. They often don't even want to know how they work (even if a good answer should explain it all the same).

Almost every possible question has been asked before

After 10 years (SO's age), I expect that every sed question is duplicated by another sed question. Somewhere. Exceptions to this would be sed programmers actually trying to write long scripts in it - something no one should ever do!

Questions can't be googled for

The problems faced by sed users can't really be googled for in sed's own terms. Try typing into google, "how to use sed's e command". Confusingly to the non-sed programmer, you'll see hits for the s/// command, and other hits for sed's -e command line switch, but nothing for sed's actual e command.

Askers really have no choice but to ask for the code

So, there are really only 2 possibilities:

The user comes to SO genuinely trying to learn sed- but as someone who knows sed, the only advice I can give that person is: don't! Don't use SO to learn sed; just read the manual.
Or, the user comes to SO genuinely not interested in learning sed, but as someone who just wants the code! That's, by the way, 99% of sed users, and probably 99% of people reading this, who ever used sed.

MCVEs not applicable to one-line scripts

Since a sed program is typically a one-line script, there is usually no way to break a problem down further. I don't think I have ever seen a MCVE in the sed queue before. And I am struggling to imagine what it would look like if I ever did see one.

Often hard to show your research

As noted above, it is often impossible to find these answers by Googling. As I also said, the only useful research I could recommend to anyone is to read the whole sed manual. If project timelines don't allow a 2 day window for "engineer learning sed" I think it is ethically sound for someone to not show research, and just ask the question here at SO.

What should we expect of askers then

What I expect

Not much, in the sed queue, honestly. I expect to see that they tried their best to put explain what they're trying to do, and make it as easy as possible for us to help them. But I am understanding of the fact that sed is confusing, and they often will have no idea of how to put it into words - especially if English is not their first language.

Could I expect more? I'm not sure.

What would enforcing the rules look like

At this point I'm switching into Devil's Advocate mode. What if we just enforced the rules instead? What would that look like?

As I mentioned, I think every question has been asked before. Thus, those of us inhabiting the sed queue could spend a lot of time on cleanup and other such administrative volunteer time. If ideal canonicals were found, these could be cleaned up, and it might become easier to know which questions to dupe each new question in the queue over to.

The maintainers of these queues could then sit and wait as maybe 10 questions a day came in, only to figure out how to properly dupe or close them.

But we are talking about a lot of unpaid work here, and no rep as incentive.

I answer sed questions because I enjoy it. I enjoy solving the problems; I enjoy seeing the other sed solutions; I enjoy helping people; and I enjoy learning while I do it. And, of course, I do it for rep as well.

I also enjoy cleaning up (my profile shows 186 posts edited at the time of writing), but if cleanup became the only thing I could contribute in the sed queue, then I think that would not be sufficient incentive for me to continue contributing.

In addition to this, closing questions as dupes of other questions probably wouldn't help askers, most of the time. I can't get any satisfaction from ruining someone's day. I enjoy being the one who helped some random data scientist solve their problem.

(I should add that I have no issue at all with voting-to-close as a dupe after I asked the OP if that will help them and they say yes. That's my preferred way of handling dupes.)

Summary

I argued that these send me teh codez questions deserve to be treated separately. I've noted that they're inherently different to questions about some other high level programming languages; I've noted that the expectations on both the askers and the answerers is, and must be, different; and I've proposed that this status quo should be recognised as a good thing, not a bad thing.