I make this request because my solution does not progress with this error. It is a single character in the exercise test file that is causing this problem. It is possible to work around this using other coding methods, but they can be a bit confusing. It would be easier for me and others if this was fixed.
Are you sure that’s an error? The instructions say to remove lowercase Greek letters, but that’s an uppercase Omicron, isn’t it? It seems odd, but my experience is that there are plenty of apparent errors in the tests that turn out to be baffling requirements instead.
You probably want to link to the PR or code that you’re refering to 
@padeso You’ve said this on a few issues now.
I want to be clear about Exercism’s methodology so you have a yardstick to understand whether things are broken or not in our eyes.
- The description and the tests should never be in conflict.
- The tests can add some extra cases that aren’t mentioned in the description, but they should be consistent with the description. The test shouldn’t add any baffling requirements that aren’t in the description. For example, the description might say “Take an array of letters ABC and output the array reversed as a string” and there might be a test to check that an error occurs if the letter
Dis given. However, there shouldn’t a test that expects the letters not to be reversed but still output if aDis given - that would be a baffling extra thing.
We don’t want to give people pages of requirements in text form, and we do believe that test-driven-development is a useful way to solve problems, so we use our tests as the specifications and our descriptions as a way of giving an overview of the problem. But things shouldn’t ever feel confusing or weird.
The one exception to this is Learning Exercises, where the description should be fully comprehensive and broken down into individual steps that you take as you solve the eercise.
If there are places where the tests are not consistent with the description or the description is not clear, then we’ll fix it. You can tag me in any posts where you feel that’s the case if you feel like .
2 Likes
I’ve come around to accepting that in Exercism the tests are the requirements, so they can never be in error. I don’t think I’m alone in finding that confusing and weird at first, and I’m not sure that’s how TDD is meant to work, but I’m not beating that dead horse anymore.
In this case, the “baffling requirement” in “Squeaky Clean" is that uppercase Greek letters are not meant to be filtered out. That requirement, however unexpected, is highlighted in the text as well as enforced in the tests, so there is nothing that needs to be fixed.
What makes something baffling if it is clearly and explicitly stated as a requirement? This sounds like you are preconceiving what requirements ought to be and not reading the actually, documented requirements, then getting confused when your preconceived ideas prove wrong. Does that make the exercise baffling? Is that an indication that it might be good to slow down and read the requirements an extra time or two to ensure you understand all the details?
You’ve hit the nail right on the head @IsaacG, and that’s the point I was trying to make. It might be baffling that cleaning a string of unwanted characters would mean removing lowercase but not uppercase Greek letters, but it’s not a fault in the exercise. The only way to succeed in any of these exercises is to look closely at the tests, whatever your perception of the task may be.
I apparently have a bad reputation from an earlier snarky comment I made. While I found the “requirement-less TDD” approach frustrating at first, I regret if I seem contemptuous of Exercism in general. In fact, I like it a lot, despite what I see as shortcomings in it.
1 Like
While I found the “requirement-less TDD” approach frustrating at first, I regret if I seem contemptuous of Exercism in general. In fact, I like it a lot, despite what I see as shortcomings in it.
Thanks for saying this
I apparently have a bad reputation from an earlier snarky comment I made.
You don’t have a bad reputation with me, but I have noticed a lot of frustrated comments, which haven’t necessarily moved the discussion forward (e.g. in this one where the tests/description are united), so I wanted just to get on the same page so that we can move forward productively
I agree that removing lowercase but not uppercase Greek letters is, at first glance, utterly bizzare and I don’t know why it’s there. I think that’s a different issue to saying the tests/descriptions don’t sing from the same sheet, which you’ve already mentioned though, as they very explicitly do here. But it would be good to clarify the exercise so that requirement doesn’t feel so weird. I’m not sure just removing the step is the right approach as it will potentially break lots of existing solutions though.
@ErikSchierboom Any thoughts on the greek character requirement - why it’s there, if we can tie it into the story better somehow, etc?
Right! I may not have worded it very well, but if you read my comment in this thread without including the baggage from any other regrettable things I’ve said in the past, I think you’ll find that it means nothing more than it says: That you have to study the tests to know what the requirements are. Even if something seems off, it is not necessarily an error in the exercise.
Yeah. In general that’s true. But as this is a Learning Exercise, it shouldn’t be the case (as students can’t see the tests in the online editor). So if this requirement was only in the tests, I’d definitely consider this a full-on bug that needed fixing. In this case though the requirements in the instructions for this exercise clearly say that you only omit lower case letters and the example given does show that (with a capital not omitted).
I think we’re on the same page though - let’s not labour this more
All that said, I don’'t see why this (seemingly esoteric) rule is here though and I’d like it improved, even if it’s just somehow added to the story. What’s also confusing is that in the example, it looks like the (greek) Ο is an (latin) O but it’s not, which sort of invalidates the example!
This all definitely needs work, and I’m sure @ErikSchierboom as the C# maintainer will want to improve it
That’s okay for you, but I’m going to not labor it more.
First of all, let me start by saying that I agree that the rule doesn’t really make sense from the story. I can tell you why the rule was added, and that was to “force” the student to do a range check on a character. The exemplar solution has this code: ch < ALPHA || ch > OMEGA, where var ALPHA = 'α'; and var OMEGA = 'ω';.
I’m open to any suggestions to change the story, but I would still like the student to compare a character against another character using a comparison operator.
Add some line about how lowercase green characters are reserved for special things in the program so need to be stripped out of the input, or something?