Recent example: Code Golf for a^b mod n.
Is there a policy I'm missing about what's too easy? If not...
Should questions I personally dub too easy be...
What, if anything is too easy?
Would guidelines be different for code golf, code challenge or puzzles?
I don't necessarily object against easy tasks. Basically, an easy one can allow you to take a break from your hard golfing life and doodle something for fun which doesn't need the same amount of work like a harder or more complex task.
That being said, I do believe that too many too easy tasks are not particularly helpful. If people come to the site and see 25 different tasks, all just taken from 5th grade math text books, then something is wrong, I guess.
Once in a while that can be entertaining, but not multiple times a day. If the only challenge or puzzle to such a task is how short you can write the invocation of a formula or a single loop then those things aren't particularly interesting (to me at least). They also belong in a different category. Those aren't »easy«, they are »trivial«.
That being said, I'd rather not have every task on this site at the complexity level of Robot Finds Kitten. Even less so at the level of Implement PCRE in your language. The latter task is probably a mistake, though.
I will happily vote down tasks I consider trivial, boring or otherwise uninteresting. That's what votes are for in my opinion: To give feedback to the person posting the task whether it's received well or not. Votes are my own opinion and do not need to match others'. Sometimes, they do, though.
Someone might (correctly) note that I have answered a few of those I have downvoted as well. That's mostly boredom. Spending a minute of cobbling together a protest answer doesn't exactly hurt me, regardless of how I think of the task. I don't consider the number of answers to a question a criterion of quality. Trivial tasks encourage many, many answers that can be churned out in a short time. That doesn't make them good tasks and I hope people who write those tasks will not see the number of answers as encouragement to write more of them.
Another thing to note: Not every task that looks simple is it, necessarily. One seemingly simple task I actually enjoyed was Hitting 495 (Kaprekar). It calls for a relatively simple algorithm, probably a special case and some math. At least that's what they want you to think. J B came up with a wonderful answer that just stops at a fixed point for the algorithm and emits the number of steps until that happens; no special case, no embedded constant for 495 – very elegant. And I noticed when building my complete set of test cases that the number of steps depends on the first and last digits of the input number, nothing more, negating the need for actually executing the algorithm.
Such examples are rare, though. Not every simple task will have that much hidden complexity. Perhaps having different ways to solve a task is a criterion whether a simple task could be entertaining and have unexpected solutions. Not entirely sure of that, though. And I am guilty of posting tasks with a predefined idea how they are to solve as well. It is easier sometimes. Not necessarily better.
Good question. I see 2 problems, genuinely too easy questions, and questions that are too easy to solve in some languages because they implement the function partially or completely. The latter is the biggest problem. This brings back the question about setting a specific language for a question, I personally prefer that by far over questions that grow trivial.
In general code golf allow for some easier questions since it may be quite far from trivial to shorten a program even though the basic implementation is easy to write.
My definition of easy: algorithms that run in O(1) (assuming hardware numbers, where there is a upper bound of running time of parallel hardware arithmetic operations), which means most of the O(1) number problems have a trivial or non-trivial formula to solve it, and the puzzle creator allows them to do so.
However, not everyone are good at math and will find O(1) solutions for all sequence and series problems (e.g. geometric series).
Of course, implementing arithmetic and other numerical operations in esolangs or from scratch are reasonably challenging.
