What constitutes a trivial solution to a problem on this stack exchange?

Should there be a different rule for different languages (e.g. one token for very esoteric languages like Jelly, or just a built in property for C#)?

  • \$\begingroup\$ Not an answer, but xnor's proposal for consolidation clearly declares that combining "just a built-in" answers is to be done; that seems to me the clearest definition but it almost seems like it's throwing it back to what constitutes a "built-in" as well, as that comment is often raised in the Sandbox on challenges banning built-ins (although that in itself is discouraged). \$\endgroup\$
    – Giuseppe
    Dec 20, 2017 at 15:17
  • 1
    \$\begingroup\$ This should really have a per-language discussion. \$\endgroup\$
    Dec 21, 2017 at 0:34
  • \$\begingroup\$ Not exist a trivial solution to down vote (when it pass all input output tests) \$\endgroup\$
    – user58988
    Nov 2, 2018 at 7:41

4 Answers 4


A Trivial answer is one where the language documentation alone identifies a construct in that language as solving the challenge.

Although this remains somewhat ambiguous due to languages having different levels of detail and such in their official documentation, or where unofficial documentation is more useful, I believe it captures the important concept of "trivial" answers: that the poster doesn't demonstrate any understanding of the language.

For example, suppose a challenge were to say "Given a list of strings A and a separator B as inputs, output the elements in A with B inserted between each one". Just by reading the wiki of what things are in Jelly, I could quickly guess that j is probably a valid answer, despite not knowing anything about how to construct programs in Jelly. Similarly, by reading the .NET Framework specification, I could find that System.String.Join would be an equally valid solution (as long as I indicated that the format for calling it is System.String.Join(B,A)), and equally trivial because that's just exactly what that method is defined to do. This also would require no actual knowledge or implementation beyond basic ability to comprehend the documentation and call methods. Now, these answers were particularly easy to find because the challenge I posed was a very common thing for languages to define, but any time that the solution posted to a challenge is "Accomplish this challenge by using the language construct which is defined as solving the challenge" I would call that trivial, even without defining what constitutes a "built-in" or "single operator".

  • \$\begingroup\$ Excluding this? Note that: 1. Trivial solution doesn't need to be fully golfed, e.g. Mathematica trivial solution ManhattanDistance can be golfed more. 2. Ability to call methods may not be trivial for some languages. \$\endgroup\$
    Dec 21, 2017 at 0:33
  • \$\begingroup\$ @user202729 The answer which prompted that thread, in my opinion, was not trivial. It required understanding multiple facets of Jelly to realize that it would solve the challenge. \$\endgroup\$ Dec 21, 2017 at 14:15
  • \$\begingroup\$ Hm... that's what I say? Because it's not trivial, it should be excluded from being considered trivial. \$\endgroup\$
    Dec 21, 2017 at 14:19
  • \$\begingroup\$ @user202729 Then I'm not sure what you're getting at? I agree, that answer is not trivial. I don't see how this proposal would consider that answer trivial. \$\endgroup\$ Dec 21, 2017 at 14:22
  • \$\begingroup\$ By "construct" I assume it's meant something like a single expression/statement? Some language documentations go to the extent of giving examples like a functional FTP server or GUI calculator, using several lines of code (Racket and Rebol to name only two that do that kind of thing). \$\endgroup\$
    – fede s.
    Dec 23, 2017 at 5:56
  • \$\begingroup\$ @fede if the documentation provides an example of an FTP server, and a challenge asks for an FTP server, then copying the reference implementation is trivial regardless of length. In theory I would extend it to copying from ANY source, but that's even more difficult to recognize so I didn't bother. \$\endgroup\$ Dec 24, 2017 at 14:15

A trivial solution is one where a language built-in (a feature provided by the language, rather than being written by the solution author) does the lion's share of the work towards solving a challenge. This is somewhat subjective, but it's hard to write an objective definition that covers all cases.

Some examples of trivial solutions:

  • Using a built-in integer addition operator in a challenge to add two integer
  • Using a built-in string repetition function in a challenge to repeat a string N times
  • Using a built-in matrix determinant function in a challenge to compute the determinant of a matrix

Some examples of non-trivial solutions:

  • Using a built-in integer addition operator in a challenge to add two matrices
  • Using a built-in string repetition function in a challenge to retrieve the N % len(string)th character in a string
  • Using a built-in matrix determinant function as part of input validation to compute the inverse of a matrix

Of course, there are a wealth of possibilities not covered, and those that are not obvious will need to be considered on a case-by-case basis.


I would say that a trivial solution is one that contains a single operator, be that some wonderfully obscure character in Jelly/APL or a single word in Python/Rust.

e.g. "sort this array of numbers ascending"

would result in trivial answers for most languages.

  • \$\begingroup\$ What constitutes most languages, a lot of verbose languages has a builtin for getting the console size, but not a lot of esoteric languages, so does that constitute trivial? \$\endgroup\$
    – LiefdeWen
    Dec 20, 2017 at 16:04
  • \$\begingroup\$ @LiefdeWen I think it's not about "most languages" but the fact that in every language with a single operator/function/whatever it's called that (does X), the answer is just that operator. \$\endgroup\$
    – Giuseppe
    Dec 20, 2017 at 17:06
  • \$\begingroup\$ @LiefdeWen, I would also highlight that this particular question is "What constitutes a trivial solution" (emphasis mine), not whether the question is trivial. In your example solutions that have a builtin for getting console size would be trivial examples in those languages, but an answer in Jelly (for example) likely isn't straightforward, and thus is not a trivial solution. \$\endgroup\$
    – mkst
    Dec 21, 2017 at 13:09

The problem with some of the answers I see here is that they fail to address the problem of an answer being solved multiple built-ins. For example, in a challenge to "sum the prime factors of a number", the Haskell answer sum.primeFactors (let's pretend primeFactors is a Prelude function here) should be considered trivial, even though it technically consists of three builtins: sum, primeFactors, and (.) (function composition).

Another issue is that even when a challenge can be solved in a single builtin, that does not always mean that the answer is trivial. For example, I'd argue this answer is not trivial, since it involves clever use of a builtin that is not immediately obvious.

As such, here's my slightly more clunky definition that hopes to cover these cases:

A trivial solution is one that consists mainly of builtin operations or idiomatic combinations of builtin operations that are obviously relevant to the challenge and that solve a significant portion of it, along with minimal "wrapper" or "padding" builtins.

To clarify a few things:

  • By "builtin" I mean any operation pre-defined by the language implementation, including anything from standard libraries, etc.
  • By "idiomatic combination" I mean a very common pattern, such as :+ (fold-with addition) which is used to compute the sum of an array in CJam.
  • Minimal wrappers and padding builtins include input and output, function composition, etc. What is a "wrapper" or "padding" varies from answer to answer, because common builtins can still be used in clever ways (e.g. using , to zero a cell in BF). In a Haskell submission like putStrLn=<<getLine, (=<<) would be considered a padding builtin, whereas in a submission like this it would not.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .