Should the existing text-based exercises be merged?

[rmunn]

As I mentioned in #325, there are already four different exercises with the basic idea of "Here is some text with a repeating pattern; write a function to print out that text". Then I proposed a fifth one.

Five exercises with a similar theme is almost certainly too much. Just one or two would be better. The question is, which one(s) should be dropped, and/or which one(s) can be merged into a single exercise? (E.g., "create a function to print the beer song, and another one to print the Twelve Days of Christmas song" in a single exercise).

I feel like the "Polar Bear, Polar Bear, what do you hear?" exercise I proposed in #325 overlaps with the "I know an old lady who swallowed a fly" song, so #325 may not add anything of value. (On the other hand, it does require you to process the "a / an" distinction in English, whereas the structure of the food-chain song never requires that because it has no animals whose names start with vowels.)

So, should any of these exercises be merged? Or eliminated entirely?

My thoughts:

• Beer Song and Twelve Days of Christmas are very similar, and perhaps only Twelve Days of Christmas should be kept. Beer Song is a classic, but that also means it's easy to find solutions online to copy and paste; Twelve Days of Christmas is probably less tempting to cheat on.
• Food Chain and Polar Bear (Idea for new exercise (Polar bear) #325) are very similar, and perhaps Food Chain should be dropped in favor of Polar Bear. Though I have a lot of childhood nostalgia attached to the Food Chain song, so I don't like the idea of dropping it.
• The "house that Jack built" exercise also overlaps somewhat with the Twelve Days of Christmas in its structure. Having two separate exercises for this may not be necessary.

So a radical approach would pare these four (or five!) exercises down to just two: Twelve Days of Christmas, and either the Polar Bear song or the Food Chain song. I'd vote for Food Chain even though Polar Bear adds a slight amount of difficulty (you have to deal with case and the "a / an" distinction in Polar Bear).

[Insti]

The existing ones are: beer-song, food-chain, twelve-days, house

I don't think it's necessary to remove any.
If it were, my choices/reasoning on which to remove differ from yours.

As you have already noted, that there are already 4 is a good reason not to add a 5th, but I don't think we've reached the stage yet where we have too many exercises to choose from.

[kotp]

As a practice site, as long as the string of exercises sufficiently separate the similar, it is like having a refresher kata to do, it helps to reinforce the ideas. And if you have added some other thought process in, and it doesn't exactly mirror another, even if plurality and the an/a difference is similar, I think it has value.

I think that after doing dissimilar exercises in between means that you can have some "thing" click where you realize you can use what you learned and explored in a dissimilar exercise and apply it to a problem domain where you are now at least somewhat familiar with.

[rbasso]

We are discussing what to do with beer-song, food-chain and house in the Haskell track, because some users find it boring to solve the song exercises.

One of the solutions we are considering is to provide working solutions as stubs, leaving it clear that those exercises are just about refactoring, maybe using the HINTS.md file.

Considering that the Haskell track has a lot of exercises, we can probably keep 2 or three song exercises, if they are sufficiently separated in the track. They could act as a kind of refactoring therapy. Maybe what makes people hate theses exercises it, not the refactoring, but all the useless work in getting a first version running.

About which exercises to keep, I'm not sure, but I don't think we should care about cheating, because this is not a competition.

[ErikSchierboom]

I'm also in favor of merging them to two exercises, as @rmunn proposed. To me, the redundancy of the exercises lessens the quality of the track. Most people will probably recognize that they've solved something like this before, and just copy the previous solution (I know I did).

[kytrinyx]

Three of the text-heavy solutions are cumulative:

• house
• twelve-days
• food-chain

House is simplest, food-chain is the most complex (and the most interesting).

House could be made more interesting by expanding the exercise to include variants, which would force a refactoring: echo-house where each phrase is repeated, and random house where the order of the phrases are randomized. Some languages don't have easy ways to test randomization.

Sandi Metz has done a talk about the design choices in this exercise (in Ruby, with the above-mentioned variations) here: https://www.youtube.com/watch?v=29MAL8pJImQ

I have done a talk about refactoring/design choices in food-chain (in Ruby) here:
https://www.youtube.com/watch?v=59YClXmkCVM

Beer Song is not a cumulative algorithm, but an iterative one with looping. Sandi Metz and I are writing a book about the refactoring/design ideas that can be learned from it.
http://www.sandimetz.com/99bottles

[cowlike]

I find the entire category of this kind of problem to be tedious so I'd vote for paring them down as well. There is value if figuring out how to apply the language to some general type of problem, which is to generate some repetitive pattern here. However, doing more of it via variations having to do with exceptions in the repetition, just isn't very interesting to me.

[balazsbotond]

I know that this is a matter of personal preference, but I've found these exercises very frustrating and tedious, and I'm not sure the experience I've gained from solving them was worth the effort.

I think two such exercises would be enough, a simpler and a more complex one. I think Beer Song and Food Chain are the best candidates.

Beer Song is an interesting one - it looks simple on the surface but there is a lot of depth to it. It forces you to think about the balance between duplication and overgeneralization (or readability and conciseness).

As someone from a non-English-speaking culture, I haven't heard the Food Chain song before, and I've found it very funny. In addition, the slight irregularity (that damn spider!) makes it a great, if a bit annoying, exercise.

These two would also be good choices because this way both iterative and cumulative text-generating problems are represented (as @kytrinyx mentioned).

[ErikSchierboom]

I also feel that having beer-song and food-chain as the only text generating exercise would be the best option.

[kytrinyx]

I've found these exercises very frustrating and tedious, and I'm not sure the experience I've gained from solving them was worth the effort.

@balazsbotond that's very helpful feedback. These exercises are some of the ones I learned the most from in terms of design and refactoring, but design/refactoring is a bit outside the normal use case for Exercism which is basic fluency in the syntax and idioms of a language.

Would the house exercise be more interesting if we added randomization and echos, per Sandi's talk?

[kytrinyx]

I'm adding the design-research label here, because this tackles the topic of linear vs non-linear progressions in the language tracks.

[rbasso]

One thing that is not clear to me is: "Is it expected that tracks implement most of the exercises in x-common?"

If yes, we definitely need to avoid excessive redundancy in x-common.
If no, this can be done a track-level, but that doesn't imply we should not do it in x-common also.

A while ago, we decided to removed a few exercises in #276. Following the same reasoning, we should probably not allow a huge number of similar text-generating exercises.

That said, I don't see what it costs to have redundant exercises in x-common, so I'm inclined to think what I proposed in #276 may have been detrimental to Exercism.

If we expect tracks-maintainers to design good progressions of exercises picking problems from a pool of exercises, one could say: The more the merrier.

Underlying this issue, is the problem of deciding what x-common should be. Until we have a clear answer for this question, I don't think we should deprecated exercises because they are redundant.

[kytrinyx]

Underlying this issue, is the problem of deciding what x-common should be. Until we have a clear answer for this question, I don't think we should deprecated exercises because they are redundant.

I agree. I'm working with a team to define some of the questions we're trying to ask, and this is related to an area of research and experimentation that we will tackle. When we do, we'll be asking for input and reporting our findings. I think we'll have a clearer picture of what actions to take after that.

[iHiD]

There's a few things that jump out at me here:

1. Some people like having multiple of the same type of exercises. Other people don't. Therefore it strikes me that that's a good example of where exercise-labelling is key.
2. I also wonder if there's a hierarchy of similar exercises that we could do. So do we a "primary" text-based exercise that teaches the most important thing, then subsequent ones that dig deeper but are option.
3. This means that tracks could still be primarily linear but have divergent subpaths for more depth.
4. This all seems to emphasise the need for clear labelling that end-users can see, which helps them choose whether an exercise is going to be valuable to them before they invest time into it.
5. If some exercises are "primary" and others are "secondary", should this be marked in x-common so that language tracks can priorities the primary exercises and then attack the secondary ones if they think there is value to them in that specific language?

Just ideas and thoughts. As @kytrinyx says, there's a lot of interlinked and broader questions here that need deeply investigating outside of this specific use-case, but it's a great example to consider as context for a lot of these issues.

[nicholaslawton]

I'm another person who has found the repetition of these exercises tedious. For reference, I didn't find any distinction between them in terms of design (iterative vs cumulative). For me, they were all trivial exercises in procedurally factoring out the common elements, from which I felt I learnt little or nothing.

[petertseng]

Is it expected that tracks implement most of the exercises in x-common

Well, I'll say that I don't feel an obligation to do so. I can't think of a situation right now where I'd reject a PR that proposed to add a given exercise though...

if there's a hierarchy of similar exercises that we could do. So do we a "primary" text-based exercise that teaches the most important thing, then subsequent ones that dig deeper but are option.

Ah, seems like a few similar things were discussed in the past in:

• Implementing multi-step exercises? discussions#5 a series of exercises where each explicitly builds on top of the previous ones
• all-your-base: split into phases? #461 is only slightly related - it's about taking one exercise and more explicitly dividing it into constituent steps, rather than separate exercises. Note that the exercise in question was made to replace a bunch of base-conversion exercises, so it has already gone through the merge process...!

---

If you ask me how I feel about these exercises... most of the time, I skip them :x ... because I felt once was enough, and I was not getting enough bang for the buck (not learning enough per time spent) in how much it let me explore the features of each language that I would potentially do these exercises in.

[ErikSchierboom]

I think people would object a lot less if we could combine these exercises into a single, song-based exercise. Perhaps choosing two song-based exercises and merging them into one?

[kytrinyx]

I suspect that the final solution will be to not have a fully linear track, but to have some optional exercises that people can dig into if they want to.

I'd suggest temporarily deprecating some of them until we decide how to deal with optional exercises.

[rbasso]

I suspect that the final solution will be to not have a fully linear track, but to have some optional exercises that people can dig into if they want to.

Not linear track...interesting...

Are you considering something like a tree or a directed graph?

I imagine that this would demand gib changes in the website and command line client, though.

[cowlike]

Why not keep it linear but have the client retrieve the one after your last submission, by default? Then you could skip over the boring ones but keep progressing without being forced to manually select them.

[NobbZ]

@cowlib, the client does fetch the next exercise.

When I do an exercism f <lang> and one of these text-exercises is fetched I simply do exercism skip <lang> <slug>; exercism f <lang> and I do get the next exercise.

[cowlike]

Aha I didn't know about skip. Thanks!

[kytrinyx]

I imagine that this would demand [big] changes in the website and command line client, though.

Yeah, definitely. We're digging into some of the fundamental questions about how Exercism works. Since it kind of happened organically there are a lot of assumptions we made that we need to reconsider (they might be correct, but we need to ask the question).

For more on this process check out exercism/discussions#113

[kytrinyx]

Today we published the first set of documents that explore questions around enhancing and supporting people's motivation to learn and practice on Exercism: https://github.com/exercism/docs/blob/master/about/conception/README.md

The section on expectancies of success, and the related document on progression lay out how we're thinking about progression, which will make it so that we don't need to collapse all the text-heavy exercises, but people also won't have to do them all.

Thanks, everyone for taking the time to explore this topic so thoroughly, it's been invaluable to hear all of your perspectives.

[kytrinyx]

Oh, also: We have an issue open requesting thoughts and feedback on these design documents: exercism/discussions#154