I also feel like i’m late for the discussion, but here’s my two cents:
I agree with DJ.
Some tracks have implemented this incorrectly and I think changing the tests would be a better option, or where it’s not easily doable, adding an addendum to the instructions to specify if ordering is significant.
I’m on it.
Once this JS (TS too?) tracks are updated (@Cool-Katt maybe you wanna try both), the new instructions work. I will likely still add the append to help people not stick to a specific solution in the solution space.
Either way, @BethanyG how do you feel about the proposed appends from @IsaacG? I know you won’t have one on python but if he gets a few go-for-its it can be done 
I’m fine with any changes to the instructions.
Unless the exercise explicitly addresses the uniqueness of elements or a specific order (which this one does not seem to do), I expect the track to adapt certain aspects of the specifications, such as the type of structure used.
So, for me, the source of truth is the tests as they have been implemented in the track. If the terminology used in the description conflicts with the certain things that i’d like to use to the tests, i’ll just add an append file and call it a day.
If the instructions are updated based on Isaac’s suggestion, I would not add any append file in the Clojure track.
Honestly? I am hard-core ambivalent about the changes. Not opposed enough to argue — although I have a preference for @BNAndras suggestion of using group, which reads clearer to me than some, and allows an interpretation of using a variety of data structures to contain that group:
Your task is to, given a target word and a group of candidate words, to find those candidates that are anagrams of the target.
But really - I was fine with the instructions as they read right now (and mostly ok with the edits), and if I wasn’t, I’d append to talk about how Python implements the exercise. Which I feel others should have done in the first place if there was ambiguity or confusion.
Reading this long debate sucked a lot of energy out of me.
If JS and TS are testing order independent, I’ll have CoffeeScript also follow suit for consistency.
Isaac’s proposed changes to the instructions addresses my concerns. I’m lukewarm on adding appends to my tracks until I can see if the instructions changes would be enough, but at the same time, I wouldn’t turn down PRs for those appends.
PR to update the specs: Remove references to "sets" and ordering in the anagram instructions by IsaacG · Pull Request #2523 · exercism/problem-specifications · GitHub
I can stage PRs for the various tracks to add the append files.
I think I misclassified zig. I now believe it uses a set.
Per-track append files have PRs opened.
True, but using “some”, which is less specific, allows for more flexibility. Some tracks might choose to implement a multi-arity function. For example in Clojure we can write something like
(defn f
[target & candidates]
;; function body
)
This would allow us to supply all candidates as arguments like so: (f target candidate1 candididate2 ...)
Some is an unspecified quantity, but it’s often in my experience used to describe a population of more than one element. Although you can have a single-member group, my first thought would similarly be more than one element.
The reason I bring this up is we have a few test cases with only a single candidate. So “Given a target word and at least one candidate word” would be an appropriate tweak to Isaac’s proposed instructions.
What about, “Given a target word and one or more candidate words"
Works for me.
Updated with that change
Okay, I am joining in a bit late. First I would like to say that this has moved wayyy to fast, I usually complain about that things moves slowly but it hasnt been more than a day or two before mass send outs of prs with changes to all track.
So first of all, the changes to problem spec have I no problem with. But this:
- PR all tracks with one insert or the other (ordered or not ordered)
I don’t understand the reasoning, okay sure why not say that the order has to be kept explicitly, but the instructions for more or less every exercise leaves out information that is missing for implementation (on some tracks at least). And I will give an example from a track I co-maintain (which will likely upset as few people as possible). Lets take an easy exercise, two-fer on the Ruby track.
When starting the exercise I am meat with this, here I have no real stub expect that it is telling me to read the test file but if we ignore that.
Lets write a fully reasonable solution, but wait! It is wrong…
Seamingly the exercise wants me to put the method in a class or a module. Another possible issue would be that the exercise might give nil to mark the absent of a name instead of just leaving the argument out. That isn’t clear if you arent reading the test file, but if I have to read the test file to solve a problem. I could likely figure out if the output should be an array and if it has to be sorted. And if one exercise should have an append saying how to solve the exercise. I think all exercises should have that. And yes by saying this I am in a way wanting to stall this, but on another hand it for me feels a bit wrong to just do fixes when people complain but not actually have a real strategy around this (since yes there are more exercises with this exact problem, talking order or non ordered list). And I think noteworthy also is that most maintainers don’t want an appendum as you can see above me.
The problem with this is that you won’t notice until late, and if your solution is unordered, you don’t really get “joy” from making it ordered.
The ambiguity issue here isn’t just for the exercise maker / student. It’s also for the maintainer. When the descriptions become ambiguous, we increase the cognitive complexity on the track maintainers to maintain things.
I don’t want that on the tracks I maintain therefore I have accepted the appends. Each track is free to do or not do that.
Yes, that’s an excellent point. Personally, I would like to see all instructions adjusted to avoid conflicts with tracks. In Clojure, I’m constantly dealing with instructions that mention lists, whereas tests typically use vectors. This forces me to add an append file to “undo” the confusion so people don’t get mixed up or start complaining, which has happened before. I’m ok with append files that clarify things, but i’m not ok when i have to “undo” things.
Since the instructions are read by people who likely don’t realize they’re shared across tracks — and most tracks don’t have append files — the best approach, in my view, would be to make the instructions more generic. This way, the canonical data can serve as the primary source of truth. Tracks would then have the freedom to either follow the canonical data or adapt it as needed.
This is the general consensus.
However, making something more generic is not free. We should do it, and in some cases a change in description is enough. In other cases we may believe tracks must apply a change. In this case I (still) strongly believe that having an append is welcome and not a burden for maintainers as Isaac has done that work.
We also took this opportunity to update the JS and TS exercises (and CoffeeScript followed), because we all realised that the original less-generic problem specifications had a point.
Adding a custom matcher for CoffeeScript was pretty straightforward. The tests work with arrays or sets so the student can use whichever they’d like
