robot-name rewrite

[masters3d]

Currently the robot-name exercise suggests

1. a Robot can assign itself a name upon boot up.
2. a Robot can reset its name with out ever giving itself a previously used name.
3. a Robot (Optionally) can never reuse a name previously assigned to any robot.

This name is more of a serial number.
In a more realistic scenario:

1. a Robot would never get shipped out without a serial number. More than likely a factory would have a random serial number generator which would assign a serial number to a new Robot.
2. a Robot would never be able to give itself a new "serial number", unless this robot is at the factory where a random serial number generator could give it a new serial number and identity.
3. By having a central registry at the factory, a robot could truly have a unique name across all created robots.

Most implementations create a class called Robot() which implements most of the description. All good. The issue is this paragraph:

Your solution should not allow the use of the same name twice when avoidable. In some exercism language tracks there are tests to ensure that the same name is never used twice.

Out of 26 implementations only 6 decided to test for uniqueness across all ever created robots.

name	hints or comments
go	provides two different implementations and tests.
scala	// Making this test pass is an optional extra exercise, should you want more of a challenge. It's ignored by default, to make it run, simply change "ignore" below to "it". There are 26^2 * 1,000 = 676,000 possible robot names - you have to ensure that none are repeated. The Robot code needs to be efficient enough to allow all 676,000 unique names to be generated.
xocaml	Optionally: make this test pass. There are 26 * 26 * 10 * 10 * 10 = 676,000 possible Robot names. This test generates all possible Robot names, and checks that there are no duplicates. It's harder to make pass than the other tests, so it is left as optional. To enable it, uncomment the code in the run_test_tt_main line at the bottom of this module.
php	none
ecmascript	none
javascript	none

I am proposing to remove the optional test case from the description.

1. It simplifies new implementations.
2. It would require tracks that implement the optional test to annotate their test case like Ocaml and Scala.

I've had a long conversation on the JS/ ES track about this. Initially I thought it would be better to remove these optional test cases (from the implementations) but I think the issue is that they are not annotated.

[jtigger]

I generally agree with the sentiment, here, @masters3d. When a part of an exercise feels like a whole 'nother adventure, seems like we want to either:

1. break it off as an optional suggested exploration (i.e. "try this!")
2. make it a whole different exercise (and could be suggested in that optional section); useful when the suggestion makes an original test case invalid.

@petertseng I've searched high and low for an issue that discusses how to handle "optional extensions" of exercises... coulda sworn I was involved in such a conversation, but can't find it. Are you aware of any such discussion?

If we have a general answer to ways to handle what amounts to a multi-part exercise, this dialogue would merely be about which of those ways to take with robot-name.

[petertseng]

@petertseng I've searched high and low for an issue that discusses how to handle "optional extensions" of exercises... coulda sworn I was involved in such a conversation, but can't find it.

The most recent instances of this were #511 and #512 - maybe it is what you were looking for?

[Insti]

If we have a general answer to ways to handle what amounts to a multi-part exercise, this dialogue would merely be about which of those ways to take with robot-name.

I can also remember having conversations about this, my position was that:

• A problem should be self contained and have tests for everything it specifies and there should not be tests for extensions.
• If an extension is interesting it should be its own problem.

(Which was what @petertseng found in #511 and #512)

[masters3d]

That was my original intent; I wanted to remove the optional truly unique tests that's most tracks have not implemented.

I want to move forward with a solution. What does everyone propose?

[Insti]

I propose making name uniqueness a requirement: #765

If you want an exercise to just generate some random strings, I suggest a new exercise, something like:
Number Plate - Where you have to generate random car licence plates based on some kind of format specification. e.g. Three letters - three numbers = ABC-123

Don't "dumb down" robot name.

[masters3d]

Which tracks do you maintain?

[Insti]

xruby, why do you ask?

[masters3d]

How does ruby test for all possible permutations?

https://github.com/exercism/xruby/blob/master/exercises/robot-name/robot_name_test.rb

How is making a test explicitly optional dumb down the excersice?

[Insti]

How does ruby test for all possible permutations?

It does not. Do you need an example?

How is making a test explicitly optional dumb down the excersice?

'dumb down' in this context means to make it less challenging.
The first step is to make the more challenging section optional, then second step is to remove the optional section because it's 'optional'.

[masters3d]

'dumb down' in this context means to make it less challenging.

I guess this is what I am having trouble with. The "optional" part was already optional; Making it clear that is optional should not change the challenging aspect of exercise.

The first step is to make the more challenging section optional
I think a better way would be to introduce a new name for this exercise. (Rename)
exercism/discussions#12
RobotName is a bad name. A better name would be RobotRegistry.
https://github.com/exercism/xphp/blob/master/exercises/robot-name/example.php#L30

Require all permutations to be accounted for under the new exercise then deprecate the old RobotName.

I've been spinning wheels on this for about year so I want to get it resolved. If introducing a new exercise and deprecating this one is the way to go then, lets do it.

[Insti]

introducing a new exercise and deprecating this one

How about introducing a new exercise that has the properties you want and making the "extension" a required part of this one? (As proposed here: #765)

---

Electronic dog collars:
The first time you boot them up, a random name is generated in the format of a dog name chosen from a list followed by three random digits, eg FIDO837 or SPOT811.

Every once in a while we need to reset a collar to its factory settings, which means that their name gets wiped. The next time you ask, it will respond with a new random name.

The names must be random: they should not follow a predictable sequence. Random names means a risk of collisions. Your solution should not allow the use of the same name twice when avoidable.

List of dog names: 'FIDO', 'SPOT', 'ROVER' etc..

(And something about preventing multiple dogs in the neighbourhood having the same name if you want that constraint as well.)

[masters3d]

What's so especial about RobotName that shields it from depreciation?

If you want to require all permutations to be accounted for then I would suggest to start implementing it in all the tracks then change the requirement on the description.
Even then I would still argue that the RobotName name is terrible because in order to do a good job at implementing correctly one must implement two classes like in PHP but then it is hard to require this in the tests.

[Insti]

Are you arguing that you want to globally deprecate an exercise because it is hard to write the tests in a particular language?

Tracks can choose which problems to include, it sounds like you need just need to remove 'robot-name' from the exercises section of config.json in the tracks you care about.
(and maybe add it to the forgone section if you don't want anyone to accidentally add it back in.)

[masters3d]

Are you arguing that you want to globally deprecate an exercise because it is hard to write the tests in a particular language?

No. I've looked at all the implementations of this particular exercise. You convinced me that the problem is the name. I believe that you like the "idea" of this requirement but have not spent the time implementing or solving it the way you want every other track to do it. The name doesn't work, specially with the requirement you are proposing. See the JS track discussion. Once you rename the problem, the differences are factored away. Do not make Robot name a sacred cow.

[masters3d]

@Insti Additionally, I am trying to do exactly what you want but in a different name. Why are you opposed to a new name?

[Insti]

I believe that you like the "idea" of this requirement but have not spent the time implementing or solving it the way you want every other track to do it.

I have solved this problem and implemented tests for it in Ruby. (These are not present in the xruby test suite, but I guess I could put them somewhere if you want to look at them.)

The name doesn't work, specially with the requirement you are proposing.

Robot-name seems like a good name, since it's about robot names.
The name/slug of the exercise does not need to be the name of the class/method/function you write to solve it. And your 'serial number generator' solution from the OP is only one specific way of solving the problem, there are many others.

Why are you opposed to a new name?

I am opposed to a new name because renaming exercises is a non-trivial operation if people still need to be able to access their previous solutions and you don't want to break links to solutions and review comments on the exercism.io site.

[kotp]

If you have a solution on this, and custom tests, @Insti submit them to the ruby track, including the tests. It is a great point for discussion on the track for folks anyway. The discussion of what and why and the tests included.

[petertseng]

Confused at what the issue is.

Let:

• RandomStringUnique be an exercise that asks for generating random strings and requires uniqueness against some set of other strings
• RandomStringOptional be an exercise that asks for generating random strings and optionally tracks may add a test of uniqueness against some set of other strings

Clarify which of the following statements is true?

• I believe that the current robot-name README implies that robot-name is RandomStringUnique, and the problem is that not all tracks implement the required test.
• I believe that the current robot-name README implies that robot-name is RandomStringOptional, and the problem is some tracks forgot to mark the test as optional.

Reading the comments in this thread, I believe that everyone's current belief more closely resembles the latter statement: the README https://github.com/exercism/x-common/blob/master/exercises/robot-name/description.md implies it is RandomStringOptional because it says "In some exercism language tracks there are tests to ensure that the same name is never used twice", emphasis mine. This is despite the fact that the immediately-preceding sentence is, without qualification, "Your solution should not allow the use of the same name twice when avoidable", emphasis mine. That sentence implies RandomStringUnique.

Yeah so it's like the README waffles back and forth on whether it's RandomStringUnique or RandomStringOptional, isn't it. Okay. Yes, it's a problem. The README would provide better guidance to the tracks if it would express exactly one of the two.

---

Confused at what the proposed solution is.

In addition to above, let:

• RandomString be an exercise that asks for generating random strings, but does not test uniqueness at all.
• an active exercise be one that has a definition in x-common and is not deprecated in x-common.

Desired final/ideal state of the above three hypothetical exercises?

• Only RandomString is active?
• Only RandomStringUnique is active?
• Only RandomStringOptional is active?
• RandomString and RandomStringUnique are active? (These would be quite similar, but I assume tracks can solve the problem by forgoing one once the other is implemented)
• Some other combination? (I would consider any other combination strange, but convince me and/or maybe I missed one)

If you would let me opine on all the variants that ask for uniqueness... it's true that I personally would rather not encourage global variables (side question: are class variables better?). And I would explicitly pass in the set of names against which uniqueness is to be checked.

So is one argument that the exercise name "robot-name" encourages tracks to have undesirable properties, such as global variables?

Is this a problem to be solved by the individual tracks, or does there come a point where we should try to guide tracks into encouraging good practices? No matter what we do, every track has the ability to twist any exercise into requiring a bad practice if they really try (e.g. any track can write hello-world tests that expect the requisite string to be written to a global variable or a file on disk). But the question now is whether a description and/or exercise name is likely to encourage a bad practice, and what we should do about it, right?

[petertseng]

following trail of current state: 86952e2 -> exercism/exercism#757

[petertseng]

Not even the people in #130 had any idea.

[Insti]

Summary of this issue as I see it:

For reference: Current README/description

@Insti (me):
"I believe that the current robot-name README implies that robot-name is RandomStringUnique, and the problem is that not all tracks implement the required test. that the readme is not specific about the requirement."

PR #765 clarifies the language of the description to be explicit about the uniqueness requirement.

@masters3d (not me, this may be inaccurate and I welcome correction.):
"I believe that the current robot-name README implies that robot-name is RandomStringOptional, and the problem is some tracks forgot to mark the test as optional."

PR #748 clarifies the language of the description to be explicit about the optional-ness of the uniqueness requirement.

Desired final/ideal state of the above three hypothetical exercises?

I think we both agree:

• RandomString and RandomStringUnique are active.

My opinion:

An attempt to move the problem from RandomStringUnique to RandomStringOptional, implies that the ultimate goal is RandomString, since not implementing the Optional part leaves you with RandomString.

Rather than changing the current RandomStringUnique robot-name into RandomString, and/or renaming the problem, I proposed adding a new RandomString exercise, electronic-dog-collar (see earlier in this thread) which, with #765, would take us to the desired final state.

[Insti]

So is one argument that the exercise name "robot-name" encourages tracks to have undesirable properties, such as global variables?

I don't believe this is inherent in the problem, there are many ways to solve it, one of which is global variables.

One of the interesting aspects of the problem is how to assign names and maintain the required shared state.

It is true that many tracks have tests which force a particular implementation, but that is the case for many problems, and it is just that this problem tends to have a forced implementation that is more offensive.

[masters3d]

20/26 of the implementations are RandomString. 6/26 are RandomStringOptional. None of the implementations currently require RandomStringUnique since the 3 PRs for marketing these optional have been merged.

Making this exercise RandomStringUnique would require most tracks to reimplement the excercise.
I know renaming is a pain, but is that better than changing 80% of the tracks?

[masters3d]

My solution would be to introduce a new RandomStringUnique that could live alongside the current RandomString/Optional. The 6 tracks that have already implemented the optional tests can make them Non optional, depricated RobotName and adopt something new like RobotRegistry. This deprivation can happen slowly. I refer to this a a rename but it is not.

RobotName carries too many responsibilities. A robot itself should not be able to gobably change its own name and this is the implementations that must would choose.

[petertseng]

If we were being forced to choose just one of the three possible exercises, then there would be the question of: Should x-common reflect how we want things to be, or how they currently are?

Since it seems everyone wants to split it up into two exercises RandomString and RandomStringUnique, this question is not really important and this section can be skipped.

The question was asked before at #510 (comment) and I personally thought at #510 (comment) that the answer should be how we want things to be and not how things currently are.

It does factor into the question if many tracks would be in contravention of how we want things to be. Now, on the one hand, just because 80% of the tracks have to change doesn't mean that any one individual has to do all the work (unless that individual really wants to, for some reason!), since tracks have different maintainers. On the other hand, it is good to consider our fellow maintainers, since we are all in this together and it would be too callous to simply say "I only care about my track and don't care about those other 80% of tracks".

---

I guess since all are agreed on RandomString plus RandomStringUnique, the question is just how robot-name fits into the scheme to get to the desired final state? It is true that renames are hard and y'all have already linked to exercism/discussions#12. It does require database access to achieve, so I would not be of help here.

• If robot-name became RandomString and a new exercise (let's assume the suggestion of robot-registry) became RandomStringUnique, it would be great if those tracks that currently have the uniqueness requirement could get their existing robot-name submissions moved under the new exercise.
• If robot-name became RandomStringUnique (and/or we think it already is) and a new exercise (if we assume the suggestion of electronic-dog-collar) became RandomString, it would similarly be great if tracks that don't have the uniqueness requirement get their existing submissions moved. They would look weird, because they would probably reference robots instead of dog collars, but it would be more reflective of the problem description being solved.
• Or is robot-name not a part of the picture at all, and two new exercises come to take its place?

[masters3d]

I am in favor of the third option. Introduce two new excersices that focus on the two different positions. #616

[kytrinyx]

What's so especial about RobotName that shields it from depreciation?

Just a quick note that I made up the robot name exercise on a whim, it's not special, and if it's problematic I would have absolutely no problem removing it for a better exercise (e.g. the license plate exercise sounds like it would be easier to define and explain than the kind of ambiguous robot name).

I'm not going to voice any particular opinion about the options here, I think that you all are doing a better job than I am of going through and figuring out what the points of pain are with this exercise, I just wanted to remind you all that there is nothing inherently special about the exercise, and that removing it completely is a valid option among all of the given options.

[masters3d]

nexercism address this since each problem is different in each track :)