exercism
Assignments for updated exercises and new exercises
To avoid duplicate work, assign yourself an exercise that you plan to work on by posting it here.
cc @ErikSchierboom
update for pig-latin :white_check_mark: update for acronym :white_check_mark: update for change :white_check_mark:
- [ ] update for yacht
- [x] update for sublist
- [x] update for space age
- [ ] new: alphametics
- [x] new: killer-sudoku-helper
- [x] new: game-of-life
- [x] new: state-of-tic-tac-toe
update for hamming :white_check_mark: update for series :white_check_mark: update for binary-search :white_check_mark: update for collatz-conjecture :white_check_mark: update for rna-transcription :white_check_mark:
I'll pass on the bowling exercise for now, as i'm a bit confused by the instructions, as usual.
update for transpose :white_check_mark: new: connect (fingers crossed) :white_check_mark:
update for matching-brackets :white_check_mark: update for atbash-cipher :white_check_mark: update for grains :white_check_mark: update for pythagorean-triplet :white_check_mark:
I'm trying to update binary-search now. The current tests check for (thrown-with-msg? Throwable #"not found"). The specs suggest an error with msg "value not in array", but also mention that we should use what's idiomatic for the language.
Any idea what would be idiomatic here? Throwing exception does not look like the correct approach here, and i'm not even able to find an appropriate exception type. What do you think about returning -1? This looks more reasonable to me.
I checked Java's built-in Arrays.binarySearch and it's returning (-(insertion point) - 1) when not found.
See https://docs.oracle.com/javase/8/docs/api/java/util/Arrays.html#binarySearch-int:A-int-
This looks reasonable, but it also feels like a bit overkill, as the insertion point might not be clearly communicated by the tests. It can be mentioned in an append file, though.
I think throwing an exception is wrong, and not finding a value is not something exceptional.
What do you think about returning -1?
That's fine, but I think that is mostly done in languages that don't allow for returning a nullable integer. What about just using nil? After all, that's the value for "there's nothing here.".
I have considered using nil because it is indeed the value for something that's not there. But the problem is that it just can't be used in every case where we are trying to find something that's not there. It's so tricky to use properly, that i prefer to stay away from it.
I was reading a book that talked about it. There was a chapter with title: nil should be the absence of only a few values. It said, and i quote the book:
We cannot consider a function that returns nil in isolation; we have to look at the downstream functions to make sure they interpret our nil correctly
Some examples from the book:
- For
conj,cons, andnth,nilis the absence of a seq (e.g.(conj :nil :x)returns(x) - For
count,nilis an empty collection (e.g.(count nil)returns 0)
and so on.
It did go into some lengthy explanation about what happens if nil is misused (returning it instead of throwing errors). It also suggested that we should avoid using the common idiom (when x). This just returns nil, but it's difficult for other functions to interpret it properly. The conclusion was:
If
nilcan be coerced to an empty collection, we should do that. If not, we should throw an error. Anything else sows needless confusion.
Obviously, using nil in this exercise isn't going to be causing any issues, and we also don't always have to throw errors. But my preference would be to avoid using it completely, if possible.
Then I would prefer to use -1. That's quite a common pattern used in other languages
Trying to update sieve. Looks like the last test has the result as an array split into multiple lines, with each line showing 14 numbers. Is there any way to keep it formatted like that? Currently i'm only able to either put all numbers in one very long line, or all numbers in one very long column. Any idea about the best approach here?
Currently i'm only able to either put all numbers in one very long line, or all numbers in one very long column. Any idea about the best approach here?
Ehm, maybe we could allow generators to opt-out off auto formatting of the code?
I think switching off auto-formatting sounds very reasonable, and nice to have as an option. However, in this particular case, I don't think that having a very long row of integers is too problematic.
updates for:
eliuds-eggs ✅ dominoes ✅ sieve ✅ run-length-encoding ✅ strain ✅ list-ops ✅ nth-prime ✅ perfect-numbers ✅ prime-factors ✅ protein-translation ✅ raindrops ✅ spiral-matrix ✅ flatten-array ✅ luhn ✅
Trying to update protein-translation. The current implementation does not include input validation at all. The specs say that those tests are optional. Should they still be left out? I'm leaning towards including them, but this would obviously break existing solutions — something that already happens we update an exercise that has error handling, so I'm not too worried.
@ErikSchierboom Thoughts?