Exercises should not be over-prescriptive

[kytrinyx]

This has come up on a number of occasions, and I'd like to discuss the topic and then document our decisions about how we want to deal with this when it comes up. This will allow us to point to the topic when someone else points out somewhere that the exercise is pushing towards a particular implementation unnecessarily, and it will also give us a suggested way of dealing with it.

I personally think that we should avoid having problem descriptions that are too prescriptive with regards to how the problem should be approached, or what the solution should look like.

In some exercises we've asked people to avoid certain approaches. I'm not sure what I think is the right answer here. On the one hand, exercises tend to be more interesting and people will learn more from it if they don't use the one-liner from the standard library. On the other hand, sometimes what you need is to learn how to do a thing idiomatically, and that would be to take the standard library approach.

So the first question is philosophical—what do we at exercism believe makes a good exercise?

The other questions are more tactical: How do we encourage exercise implementors to work towards those goals? What do we do when we realize that an exercise is too prescriptive? (This might be just at the README level for the exercise, or maybe the README is fine but a given implementation has tests that force people in one specific direction).

See:

• adding bowling elixir#188
• Intermediate functions: To test or not to test? #41
• largest-series-product: Should tests test for implementation details (slices, digits)? problem-specifications#192
• Add crypto-square.json problem-specifications#250

[petertseng]

I do like to see different approaches to solving a problem, to see what I can learn from them. It is good for me if there can be room for varied approaches.

If the exercise is solely about re-implementing something available in a language's standard library (if we had an exercise whose sole question is "Write a function that sorts a list"), it makes sense to say we should see what a solution would look like if you had to implement it yourself. I can't learn as much from a one-liner solution - I can learn of the presence of this standard library function and I would probably use it in real code, but it can be valuable to think about how I'd do it myself.

Many exercises are more involved but are there any with significant standard library restrictions?

[Insti]

@petertseng Here are 3 from Ruby which are easily solved using standard library.
https://github.com/exercism/xruby/tree/master/exercises/accumulate
https://github.com/exercism/xruby/tree/master/exercises/nth-prime
https://github.com/exercism/xruby/tree/master/exercises/sieve

But there are no intermediate tests and it is left to reviewers to call out any "cheating".
(Which I think is fine.)

[kotp]

It also brings to the conversation how to find out what implementations the language is using, which can be valuable in itself.

[kytrinyx]

I'm going to go ahead and close this. My biggest take-aways from this have been that a great exercise allows different approaches (e.g. "implement this specific algorithm" is typically not a great choice for an exercise).

I've also discovered that I prefer exercises that avoid jargon (e.g. exercises that have a more playful story, and don't arbitrarily raise the barrier to solving them by using words that are only familiar to people with domain knowledge).