Encourage high-quality interpreter challenges
I really enjoy interpreter challenges. Why?
- They are often non-trivial. (I'll address counterexamples below.) I like more-complex challenges in general, and it seems like challenges to interpret a toy language or a tarpit frequently hit the right balance between difficult and doable. Answers to them can showcase some really intensive golfing.
- They are approachable. Some of us aren't experienced with abstract math,
or physics, or cryptography. But we all know programming languages, and enjoy playing with them. Learning how to write an interpreter isn't too much of a learning curve.
- They can be educational. The languages we're asked to interpret in these challenges draw from a wide variety of programming paradigms: stack-based, functional, 2-dimensional, etc., etc. Simply understanding how the language is supposed to work can be a mind-stretching experience in itself.
Now, one potential downfall of interpreter challenges is that they are hard to do well. Because they are more complicated, they need to be very carefully specified; they frequently have lots of caveats and corner cases that must be considered. An incomplete spec can easily result in the question getting closed--as it should! But DJMcMayhem is right:
That's a problem with each challenge, not the category of challenges.
So, how do we encourage high-quality interpreter challenges?
- Pick an interesting but manageable language to interpret. I know trivial "languages" get upvotes, but I'd like to see languages that actually do something--not necessarily Turing-complete, but at least with some control flow to handle (loops, gotos, recursion). On the other hand, an "Interpret Python" challenge is going to be way too involved for this site (probably). Turing tarpits are a good choice, since they have very few instructions that need to be implemented. Try to design the language to be as small as possible while still being interesting.
- Search existing challenges to see if something similar has been done before. A quality interpreter challenge should add something new to the genre; we don't need fifty "Interpret this variant of BF" challenges. There's enough variety and downright weirdness among programming languages to find something interesting to implement.
- Use the sandbox. This isn't going to solve all the problems, for two reasons: 1) some people don't use the sandbox, and 2) even after sandboxing, a complex challenge will inevitably have more corner cases that didn't get caught. However, posting in the sandbox and asking for feedback over the course of a couple weeks will greatly increase the quality of a challenge, especially a complicated one. It can also help weed out the boring ones before they hit the main site. Get as many eyes on your challenge as possible. If/when your sandbox post stops getting feedback, post in chat asking for more feedback.
- Implement it yourself. Writing your own reference implementation forces you to tackle the corner cases and work out the exact behavior you want, which you can then write into the spec. But more importantly, a reference implementation is very helpful to potential answerers who will inevitably look at your spec and go, "Huh?" I may not understand how the language works from reading about it, especially if it uses an unusual execution model. But if I can experiment on my own with an existing interpreter, I'll be able to figure it out.
- A corollary to the above point: Write extensive example programs in the language (i.e., test cases). Example programs need to use all the features of the language, particularly any corner cases or "gotchas." If I can run all the example programs successfully with my submission, I should be pretty confident that my submission works according to spec.
This list is nothing new: these are essentially the ways we encourage high-quality challenges of any type. But these considerations are more important for categories like interpreter where the task and the spec are complicated. Trivial challenges may be ready to go after a short time in the sandbox, but for complex ones a longer stay is almost mandatory.
When low-quality challenges pop up, address them in the same way as any bad challenge. Downvote if it's trivial/uninteresting. Vote to close as unclear if it's unclear. Comment on improvements that can be made.
Finally, let me point out that the interpreter tag actually has quite a lot of good challenges, and only a few low-quality ones. As Wheat Wizard points out, several of the low-quality challenges are recent, which may contribute to your negative impression of the tag. I suggest browsing through some of the older ones--there are quite a few with 10-25 upvotes that deserve more attention.