The displayed level of difficulty for exercises

Exercism
21

Yeah, I think this one is hard regardless of the language — it requires quite a bit of domain knowledge.
But the original comment was about the JavaScript track.

The instructions alone are packed with unfamiliar terms (unless you’re a musician), so I really don’t see how this could be considered “easy.”

https://exercism.org/tracks/javascript/exercises/scale-generator

In my opinion, an “easy” exercise should have a naive solution path that’s either obvious or at least hinted at in the description.

22

We’re working on removing the exercise from the Javascript track (WIP). Prompted by your comment, we also dropped it from C#, F#, nim and Unison. There are plans to remove it from Swift and it might be dropped from Kotlin. This isn’t a Javascript specific issue but hopefully it will cease being an issue shortly :slight_smile:

1 Like
23

The Javascript PR has merged so that exercise should no longer show up on the track (for people that haven’t already started it). That should fix the difficulty rating ;)

24

Thanks for the quick fix - personally, I would’ve preferred a difficulty adjustment, but I get why removing it made sense. :wink:

25

The scale generator was deprecated in the problem spec one year ago. The problem spec is the “source of truth” common source for practice exercises. If it’s deprecated there, then that’s, by default, often the direction tracks move in. Having those decisions on a global level means it doesn’t need to be discussed 65 times for each track :slight_smile:

1 Like
26

One quibble here. There is no requirement that tracks depreciate when something is taken out of problem specs, nor are tracks required to implement all problem spec exercises or only implement problem spec exercises.

While it is super-convenient to have a large common repository of problem specifications, I don’t think the point of it is to limit or constrict what a track can do in the service of offering idiomatic exercises in their programming language.

There are numerous examples of tracks choosing to keep an exercise when it is deprecated from problem specs, construct an exercise that doesn’t get described in problem specs, or otherwise implement (or not implement) exercises that are described in problem specs. Especially when those exercises get at language features or challenges more specific to a certain programming language.

While I support why this exercise is being deprecated across multiple tracks (as those maintainers have agreed to do in this case), it is also being kept on some others.

And that shouldn’t be considered a problem. :slightly_smiling_face:

4 Likes
27

You’re absolutely right. I updated my post.

1 Like