scale-generator: use flat and sharp symbols

[wolf99]

This PR switches hash symbols (#) to the sharp symbols (♯) and use of b to the flat symbol (♭) in the description.md.

This seems more "musically" accurate, or more domain-correct.
On the other hand, it causes a divergence between the description.md and the canonical-data.json.

I thought about updating the canonical-data.json also, but that may cause issues for any language for which UTF-8 is non-trivial.

What do you think?

[petertseng]

Interesting. there are a few ways I imagine dealing with that discrepancy.

• At the problem-specifications level, we mention that tests will represent ♯ with # and ♭ with b. For tracks that want to actually use ♯ and ♭, they'll have to delete that text (we don't currently have a good mechanism for deleting text from a problem-specifications-sourced description, only adding)
• At the problem-specifications level, we mention that tests may represent ♯ with # and ♭ with b. The ambiguity may be a little frustrating as now you don't know whether the tests are actually doing so without looking.
• At the problem-specifications level, merge this PR as-is. At the track level, if a track wishes to keep # and b, they insert a comment in the test file and/or description saying "for simplicity, we will represent ♯ with # and ♭ with b". If they instead wish to update their tests to use ♯ and ♭, they just do so.
• There may be other ways I did not think of.

[ErikSchierboom]

The discrepancy is indeed interesting. With Exercism v3, we now support a instructions.append.md file to append text to, so tracks can have an appended message stating that they opt to encode the flats and sharps as regular ascii characters. That said, currently all tracks woukd have to add that message, so that's a downside.

Option 3 is probably the cleanest, while option 2 is more of a compromise but would lead to less contradictory tests vs instructions.

[petertseng]

Another question. Is this scenario a possibility and concern, and if so, what can be done about it?

• A track chooses to start using ♯ and ♭ in their tests
• A student of this track doesn't realise these characters are in any way different from # and b, and in implementing a solution, uses # and b.
• Tests fail. Student frustrated.

[petertseng]

Upon further reflection, I believe I came up with an answer to my earlier question. I think my suggestion to a track that does choose to use ♯ and ♭ in their tests would be that they can clearly indicate (perhaps in their stubs, so that the student is sure to see it) that the specific characters ♯ and ♭ are being used.

In that case, I think we have a path forward, with the third option I had presented being taken:

At the problem-specifications level, merge this PR as-is. At the track level, if a track wishes to keep # and b, they insert a comment in the test file and/or description saying "for simplicity, we will represent ♯ with # and ♭ with b". If they instead wish to update their tests to use ♯ and ♭, they just do so.

[ErikSchierboom]

Upon further reflection, I believe I came up with an answer to my earlier question. I think my suggestion to a track that does choose to use ♯ and ♭ in their tests would be that they can clearly indicate (perhaps in their stubs, so that the student is sure to see it) that the specific characters ♯ and ♭ are being used.

I think this can work well enough. Tracks could also consider adding a note to the tests, just to be safe.