Keep your hands off that bit-count functionality provided by your standard library! Solve this one yourself using other basic tools instead.
A couple of days after reviewing and approving the PR that added the exercise to the Clojure track, I decided to add an appendix file stating that any bit-* functions should not be used. Unfortunately, by excluding all bit-* functions, I was also excluding functions like bit-shift-right, which is allowed. Then, the maintainer who created the PR clarified that the restriction was intended to prevent solutions using a single function to solve the exercise. Realizing my mistake, I removed the appendix file and merged.
A day later, I understood the problem: since Clojure lacks a bit-count functionality, I had misinterpreted the instructions. If I misunderstood, I expect others might as well. In fact, many may interpret the restriction as:
don't use bit-* functions, and don't use the count function
To prevent similar confusion not only in Clojure but also across other tracks, Iâd like to suggest a different way to phrase the restriction:
Avoid using any library functions that directly count the number of bits in a number. Instead, try solving this yourself using more basic tools.
Thoughts from other maintainers?
Edit: The word âdirectlyâ isnât strictly necessary. A more general restriction would be:
Avoid using any library functions that count the number of bits in a number. Instead, try solving this yourself using more basic tools.
It might be that adding âif it existsâ would be enough, in that first sentence.
It is coming from Problem Specifications and as that addresses all the tracks, it might be good for the change to happen there. An addendum is possible for expanding the information in the individual track.
Thatâs another possibility, but my main concern is that if something doesnât exist, it can easily be misinterpreted. Clojure has both bit-* functions and a count function. Iâd rather have a description that clearly states the intention of the restriction, rather than leaving people to guess.
The appends file is meant to clarify track specific communication, and I think that if the communication is unclear in problem specifications, we can âgenerallyâ improve it by suggesting that we are stating something that may not be true for the language, and then have the track maintainer clarify that in the append for each track in which this is true.
That is what it is there for, anyway. So, for Clojure, I suppose, we should discuss that in the Clojure - Exercism category, and for each language track.
I would say that some tracks have a count functionality that has nothing to do with bit operations that may be used, and so stating to not use them may not, also, be the right direction to try to distract. There is just too much variances that we can not cover them all in the main description on Problem Specifications and any clarifications that need to be done should be done in the additional document that gets processed for the individual track as it applies.
This is why I would likely go with something that does admit âambiguityâ such as âif it is existsâ as the main document is best to describe the exercise description and perhaps general suggested approaches, but not specific approaches, as it can not possibly cover those.
@kotp I agree; however, the proposed change is just a rewording of the existing restriction. I donât intend to modify anything else.
As for append files, Iâm not really a fan. They seem like a continuation of the description, but theyâre not synced automatically with the main text. This creates the risk of them going out of sync with the main description or containing redundant or duplicated information.
For this specific exercise, Iâd rather not add an append file, as this could steer students toward specific implementations.