[Discussion] How to handle exercises that differ from the problem spec

[junedev]

The Go track has a couple of exercises that exist in the problem spec repo but the Go version differs from the problem spec version.

Here a list of the ones I saw (as part of https://github.com/exercism/go/pull/1913) and my proposal how to address them.

• [x] accumulate
  • The problem spec version of this exercise only works for languages that are not strongly typed, that's probably why Go has a custom version that only uses strings/ a function that modifies strings.
  • There was a discussion here https://github.com/exercism/problem-specifications/issues/129 that accumulate should be deprecated because it is a part of the list-ops exercise (this also applies to the Go track). It is not clear why the deprecation wasn't really done in the end.
  • ➡️ I would suggest we follow through with deprecating this exercise. The documentation how to do this can be found here: https://exercism.org/docs/building/tracks/deprecated-exercises
• [x] error-handling
  • This exercise has not proper description in problem spec: https://github.com/exercism/problem-specifications/blob/main/exercises/error-handling/description.md and has no canonical test data.
  • ➡️ I think we should keep our custom instructions here. (If people agree, the exercise can be ticked off directly.)
• [x] phone-number
  • The problem spec exercise only expects the user to write one function, the Go exercise added two more small functions. They are not super involved but a nice touch. Currently the instructions file is changed to incorporate those extra functions.
  • There is even a generator for the test cases that adds the additional fields needed to test the additional functions.
  • ➡️ I think we should keep the additional functions. We can use the problem spec version of the instructions and then put the additional instructions for those functions in the append file.
• [x] simple-cipher
  • The latest problem spec instructions expect the student implement just one cipher in the end. The instructions are only divided into steps to guide the student to the solution.
  • The Go version currently has different instructions that require the student implement a different cipher per step in the instructions. On the other hand it does not contain the part about generating a random key from the problem spec instructions.
  • ➡️ I think the part about random key generation is a valuable part of the exercise and there is usually a lot to discuss about that part in mentoring. The additional Ceasar and Shift ciphers that were added in Go don't add a lot of value to the exercise imo. I think the exercise should be changed so it fits the problem spec version. That means the student would only implement one cipher (currently called Vigenere) but would additionally need to implement a random key generation.
• [x] tree-building
  • The problem spec instructions are about refactoring existing code.
  • The Go version removed that refactoring part from the instructions.
  • ➡️ I don't think refactoring exercises fit Exercism very well and there is a discussion about this in problem spec as well https://github.com/exercism/problem-specifications/issues/1174. So I agree with the difference to problem spec made here, we should keep it as is.

There might be more exercises with that should be in the list but we have not identified them yet.

Once we discussed how to move forward with these exercises, we can create individual issues for each of them.

[andrerfcsantos]

• accumulate - I agree we should deprecate. A map operation on a slice is already asked in list-ops. I also agree that the name for this exercise is horrible. I remember doing this exercise for the first time and being extremely confused because of the name of the function - the instructions were suggesting a map, but the name of the function is suggesting having an accumulator of sorts.

• error-handling - It's probably fine to leave it as is for now. My only complaint about this exercise is that is too complex and tries to do too much at the same time. In only a couple of lines requires the student to do a bunch of defers, recover from panics inside those defers, check for several error types and modify the return using a named return as a way to recover from the error. It seems a bit artificial by trying to pack so much in a single exercise. However, it is not rare for students submit good solutions for mentoring on this exercise, so it might just be me thinking this way.

• phone-number - I agree with your suggestion.

• simple-cipher

  The additional Ceasar and Shift ciphers that were added in Go don't add a lot of value to the exercise imo.

  To me this is reason enough to change this exercise and simplify it. If adhering to the spec also simplifies it, then we should just do it :)

• tree-building - I vote to leave it as is. I think refactoring exercises do have a place in exercism, but I think the way we are doing it currently is not great. Right now we just say "here's the code, change it, have fun!" and often the functions for the exercises where we are doing this are somewhat big. This leaves little incentive for the student to actually refactor the code. Why not just treat it as a normal exercise and start from the beginning? I think a better approach would be to do some more targeted refactoring, like "this code is great and it's working, but there are these 2 little functions that could be improved". But this is maybe a discussion for another day. Funnily enough, one of these days I was presenting Exercism to a friend and I was surprised that one of his first questions was "do you have any refactoring exercises? it would be cool to change code that was already working". Probably more students are in the same boat and would like some refactoring exercises, but I don't think tree-building is a good candidate for it.

[junedev]

Thanks for your feedback!

• I created an issue for deprecating "accumulate"
• Totally agree that "error-handling" is weird exercise but that's another discussion.
• I will create issues for "phone-number" and "simple-cipher" later on.
• Great insight regarding the refactoring exercises, thanks for that, I will keep it in mind.

[junedev]

I created the remaining issues. I will close this one. If someone has additional feedback later because they saw the post on Slack, please post it nevertheless.