Closed junedev closed 2 years ago
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.
Thanks for your feedback!
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.
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.
list-ops
exercise (this also applies to the Go track). It is not clear why the deprecation wasn't really done in the end.Vigenere
) but would additionally need to implement a random key generation.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.