librelist archives

« back to archive

Ambiguous specifications?

Ambiguous specifications?

From:
Colin Morris
Date:
2014-09-24 @ 01:46
I'm really enjoying exercism, but I've noticed a lot of the READMEs that
come with problems are ambiguous or underspecified, which feels frustrating.

Some examples from Python problems...

*Bob*
- Bob answers 'Sure.' if you ask him a question and says 'Chill out' if you
yell at him. WHAT IF I YELL A QUESTION AT HIM?
- (This one is especially frustrating because the most reasonable thing is
to assume that precedence follows the order in which the rules are given,
which is not the case.)

*Anagram*
- Why can't a word be an anagram of itself? As a programmer, I kind of like
living in world where we don't put special-case pylons around trivial
cases. `''python'.startswith('python') and '' in 'python' and all([])` :)
- Anagram detection is supposed to be case insensitive, but the example in
the README doesn't show this.

*Wordcount*
- The README makes no mention of this, but according to the unit tests,
we're supposed to downcase the input and strip trailing punctuation.
- I wrote a solution that involved stripping all punctuation. Someone
nitpicked "What if the input is 'the#quick#brown#fox'?". To which I replied
that my output would be X and I have no idea whether that would be correct
or not because there are no unit tests with interior punctuation and the
README doesn't say anything about what a word is. (
http://exercism.io/submissions/17d2a2d052abeb46577661ad)


When I get test failures, I'd prefer it to be because I made a logical
mistake, not because I failed to incorporate some arbitrary special case or
rule that never could have been inferred from the spec. (Also, I feel like
novice programmers might confuse these two scenarios, and end up feeling
more pessimistic about their skills than they should be.)

Am I missing the point here? Are these specs intentionally ambiguous
because that's how problems are often posed in the real world?

If this isn't intentional, I'm happy to start writing some pull requests
rather than just whining. I just wanted to make sure I understood first.

Re: [exercism] Ambiguous specifications?

From:
Katrina Owen
Date:
2014-09-24 @ 05:39
On 09/23, Colin Morris wrote:
> I'm really enjoying exercism, but I've noticed a lot of the READMEs that
> come with problems are ambiguous or underspecified, which feels frustrating.

Originally that was kind of intentional, because the ambiguity opened up
some really interesting questions.

I'm actually not convinced that it's very useful to keep that ambiguity, 
and I think
that it would be worth improving the detail of the READMEs overall.

> *Anagram*
> - Why can't a word be an anagram of itself? As a programmer, I kind of like
> living in world where we don't put special-case pylons around trivial
> cases. `''python'.startswith('python') and '' in 'python' and all([])` :)
> - Anagram detection is supposed to be case insensitive, but the example in
> the README doesn't show this.

The definition of an anagram on Wikipedia is:

> An anagram is a type of word play, the result of rearranging the
> letters of a word or phrase to produce a new word or phrase, using all
> the original letters exactly once

In other words, if the letters have not been rearranged to produce a new
word, it's not an anagram.

The case insensitive thing is actually something that I'm not sure
about. I think that anagrams are case insensitive, but I've had people
who are quite certain that I'm wrong.

I'd love to find a definitive answer to that.

> *Wordcount*
> - The README makes no mention of this, but according to the unit tests,
> we're supposed to downcase the input and strip trailing punctuation.
> - I wrote a solution that involved stripping all punctuation. Someone
> nitpicked "What if the input is 'the#quick#brown#fox'?". To which I replied
> that my output would be X and I have no idea whether that would be correct
> or not because there are no unit tests with interior punctuation and the
> README doesn't say anything about what a word is. (
> http://exercism.io/submissions/17d2a2d052abeb46577661ad)

This is a really good question. I think that word count could benefit
from a lot more thought both in terms of the README and the test suites.

> When I get test failures, I'd prefer it to be because I made a logical
> mistake, not because I failed to incorporate some arbitrary special case or
> rule that never could have been inferred from the spec.

Good point. I've been looking at the test suites as training-wheels...
the tests you might have written yourself had I asked you to think about
this (somewhat vague) problem.

They're not like an exam that you need to pass, but I can totally see
how it might feel that way.

> (Also, I feel like
> novice programmers might confuse these two scenarios, and end up feeling
> more pessimistic about their skills than they should be.)

This is definitely something I want to avoid. Again, it goes back to how
I don't see the test suite as being like grading homework, only as an
exploration of a problem-space.

If others don't experience them in that way, then we certainly need to
talk about how to improve the READMEs.

> Am I missing the point here? Are these specs intentionally ambiguous
> because that's how problems are often posed in the real world?

Naw, not really. In the beginning it sort of started out that way, but a
lot of that is accidental.

> If this isn't intentional, I'm happy to start writing some pull requests
> rather than just whining. I just wanted to make sure I understood first.

I would really appreciate that!

Katrina

Re: [exercism] Ambiguous specifications?

From:
Mark IJbema
Date:
2014-09-25 @ 06:16
I like part of the ambiguity though. For instance, in word count, you can
use either split or scan. To me, scan feels more correct, but because the
specs aren't hammered down it is still possible to have discussions about
which is better. I think this does reflect the real world scenario of
having an incomplete specification. And in the case of anagram: I like how
it requires on exception from what would be the prettiest program; this
makes you think about how to make good-looking, elegant programs in real
life, where you also have these exceptions.

What you mention, but don't explicitly call out, is another problem I've
seen from (my now very little) recent interactions with exercism. Sometimes
the nitpicks aren't so much about elegance and such, but about correctness.
I think most of these comments are actually wrong. Another variant of this
is the "this won't pass the tests". I think it's important to keep guiding
nitpickers in giving friendly, good nitpicks, and this has been a hard
problem from the start. But I think we do not want all specs to be 100%
watertight, because that also removes the wiggle room of having wildly
different solutions to the problem.

Mark

On Wed, Sep 24, 2014 at 7:39 AM, Katrina Owen <_@kytrinyx.com> wrote:

> On 09/23, Colin Morris wrote:
> > I'm really enjoying exercism, but I've noticed a lot of the READMEs that
> > come with problems are ambiguous or underspecified, which feels
> frustrating.
>
> Originally that was kind of intentional, because the ambiguity opened up
> some really interesting questions.
>
> I'm actually not convinced that it's very useful to keep that ambiguity,
> and I think
> that it would be worth improving the detail of the READMEs overall.
>
> > *Anagram*
> > - Why can't a word be an anagram of itself? As a programmer, I kind of
> like
> > living in world where we don't put special-case pylons around trivial
> > cases. `''python'.startswith('python') and '' in 'python' and all([])` :)
> > - Anagram detection is supposed to be case insensitive, but the example
> in
> > the README doesn't show this.
>
> The definition of an anagram on Wikipedia is:
>
> > An anagram is a type of word play, the result of rearranging the
> > letters of a word or phrase to produce a new word or phrase, using all
> > the original letters exactly once
>
> In other words, if the letters have not been rearranged to produce a new
> word, it's not an anagram.
>
> The case insensitive thing is actually something that I'm not sure
> about. I think that anagrams are case insensitive, but I've had people
> who are quite certain that I'm wrong.
>
> I'd love to find a definitive answer to that.
>
> > *Wordcount*
> > - The README makes no mention of this, but according to the unit tests,
> > we're supposed to downcase the input and strip trailing punctuation.
> > - I wrote a solution that involved stripping all punctuation. Someone
> > nitpicked "What if the input is 'the#quick#brown#fox'?". To which I
> replied
> > that my output would be X and I have no idea whether that would be
> correct
> > or not because there are no unit tests with interior punctuation and the
> > README doesn't say anything about what a word is. (
> > http://exercism.io/submissions/17d2a2d052abeb46577661ad)
>
> This is a really good question. I think that word count could benefit
> from a lot more thought both in terms of the README and the test suites.
>
> > When I get test failures, I'd prefer it to be because I made a logical
> > mistake, not because I failed to incorporate some arbitrary special case
> or
> > rule that never could have been inferred from the spec.
>
> Good point. I've been looking at the test suites as training-wheels...
> the tests you might have written yourself had I asked you to think about
> this (somewhat vague) problem.
>
> They're not like an exam that you need to pass, but I can totally see
> how it might feel that way.
>
> > (Also, I feel like
> > novice programmers might confuse these two scenarios, and end up feeling
> > more pessimistic about their skills than they should be.)
>
> This is definitely something I want to avoid. Again, it goes back to how
> I don't see the test suite as being like grading homework, only as an
> exploration of a problem-space.
>
> If others don't experience them in that way, then we certainly need to
> talk about how to improve the READMEs.
>
> > Am I missing the point here? Are these specs intentionally ambiguous
> > because that's how problems are often posed in the real world?
>
> Naw, not really. In the beginning it sort of started out that way, but a
> lot of that is accidental.
>
> > If this isn't intentional, I'm happy to start writing some pull requests
> > rather than just whining. I just wanted to make sure I understood first.
>
> I would really appreciate that!
>
> Katrina
>

Re: [exercism] Ambiguous specifications?

From:
barrett clark
Date:
2014-09-25 @ 13:06
I don't know that I've really ever thought about the ambiguity in the 
READMEs. There have been some where I wasn't really sure what was going 
on, and so I looked the subject up and read through the tests. Liking the 
subject up is also good so that you know the vernacular of the subject for
variable naming and such.

I'm not opposed to the notion of taking a pass through the exercise 
instructions. I do fall in the camp of the ambiguity is good (or not bad).
That's life, and I also like that it leaves room for exploration.

Speaking of exploration, I just did a few rounds of the Roman numeral 
exercise. Holy cow that's a good one. Usually I knock the code out pretty 
quickly, but this one took some real effort. In the end I shipped a couple
of very different versions as I moderated myself through the process.

~Barrett

> On Sep 25, 2014, at 01:16, Mark IJbema <markijbema@gmail.com> wrote:
> 
> I like part of the ambiguity though. For instance, in word count, you 
can use either split or scan. To me, scan feels more correct, but because 
the specs aren't hammered down it is still possible to have discussions 
about which is better. I think this does reflect the real world scenario 
of having an incomplete specification. And in the case of anagram: I like 
how it requires on exception from what would be the prettiest program; 
this makes you think about how to make good-looking, elegant programs in 
real life, where you also have these exceptions.
> 
> What you mention, but don't explicitly call out, is another problem I've
seen from (my now very little) recent interactions with exercism. 
Sometimes the nitpicks aren't so much about elegance and such, but about 
correctness. I think most of these comments are actually wrong. Another 
variant of this is the "this won't pass the tests". I think it's important
to keep guiding   nitpickers in giving friendly, good nitpicks, and this 
has been a hard problem from the start. But I think we do not want all 
specs to be 100% watertight, because that also removes the wiggle room of 
having wildly different solutions to the problem.
> 
> Mark
> 
>> On Wed, Sep 24, 2014 at 7:39 AM, Katrina Owen <_@kytrinyx.com> wrote:
>> On 09/23, Colin Morris wrote:
>> > I'm really enjoying exercism, but I've noticed a lot of the READMEs that
>> > come with problems are ambiguous or underspecified, which feels frustrating.
>> 
>> Originally that was kind of intentional, because the ambiguity opened up
>> some really interesting questions.
>> 
>> I'm actually not convinced that it's very useful to keep that 
ambiguity, and I think
>> that it would be worth improving the detail of the READMEs overall.
>> 
>> > *Anagram*
>> > - Why can't a word be an anagram of itself? As a programmer, I kind of like
>> > living in world where we don't put special-case pylons around trivial
>> > cases. `''python'.startswith('python') and '' in 'python' and all([])` :)
>> > - Anagram detection is supposed to be case insensitive, but the example in
>> > the README doesn't show this.
>> 
>> The definition of an anagram on Wikipedia is:
>> 
>> > An anagram is a type of word play, the result of rearranging the
>> > letters of a word or phrase to produce a new word or phrase, using all
>> > the original letters exactly once
>> 
>> In other words, if the letters have not been rearranged to produce a new
>> word, it's not an anagram.
>> 
>> The case insensitive thing is actually something that I'm not sure
>> about. I think that anagrams are case insensitive, but I've had people
>> who are quite certain that I'm wrong.
>> 
>> I'd love to find a definitive answer to that.
>> 
>> > *Wordcount*
>> > - The README makes no mention of this, but according to the unit tests,
>> > we're supposed to downcase the input and strip trailing punctuation.
>> > - I wrote a solution that involved stripping all punctuation. Someone
>> > nitpicked "What if the input is 'the#quick#brown#fox'?". To which I replied
>> > that my output would be X and I have no idea whether that would be correct
>> > or not because there are no unit tests with interior punctuation and the
>> > README doesn't say anything about what a word is. (
>> > http://exercism.io/submissions/17d2a2d052abeb46577661ad)
>> 
>> This is a really good question. I think that word count could benefit
>> from a lot more thought both in terms of the README and the test suites.
>> 
>> > When I get test failures, I'd prefer it to be because I made a logical
>> > mistake, not because I failed to incorporate some arbitrary special case or
>> > rule that never could have been inferred from the spec.
>> 
>> Good point. I've been looking at the test suites as training-wheels...
>> the tests you might have written yourself had I asked you to think about
>> this (somewhat vague) problem.
>> 
>> They're not like an exam that you need to pass, but I can totally see
>> how it might feel that way.
>> 
>> > (Also, I feel like
>> > novice programmers might confuse these two scenarios, and end up feeling
>> > more pessimistic about their skills than they should be.)
>> 
>> This is definitely something I want to avoid. Again, it goes back to how
>> I don't see the test suite as being like grading homework, only as an
>> exploration of a problem-space.
>> 
>> If others don't experience them in that way, then we certainly need to
>> talk about how to improve the READMEs.
>> 
>> > Am I missing the point here? Are these specs intentionally ambiguous
>> > because that's how problems are often posed in the real world?
>> 
>> Naw, not really. In the beginning it sort of started out that way, but a
>> lot of that is accidental.
>> 
>> > If this isn't intentional, I'm happy to start writing some pull requests
>> > rather than just whining. I just wanted to make sure I understood first.
>> 
>> I would really appreciate that!
>> 
>> Katrina
> 

Re: [exercism] Ambiguous specifications?

From:
Russell Dunphy
Date:
2014-09-25 @ 15:49
I'm also in the ambiguity is good (or not bad) camp. Taking the Bob 
exercise as an example, the fact that the precedence order of the cases 
doesn't match the order in the readme means you are confronted with the 
importance of precedence while writing it. Otherwise, if the tests just 
passed, you may never have thought about it.

> On 25 Sep 2014, at 14:06, barrett clark <barrett.clark@mac.com> wrote:
> 
> I don't know that I've really ever thought about the ambiguity in the 
READMEs. There have been some where I wasn't really sure what was going 
on, and so I looked the subject up and read through the tests. Liking the 
subject up is also good so that you know the vernacular of the subject for
variable naming and such.
> 
> I'm not opposed to the notion of taking a pass through the exercise 
instructions. I do fall in the camp of the ambiguity is good (or not bad).
That's life, and I also like that it leaves room for exploration.
> 
> Speaking of exploration, I just did a few rounds of the Roman numeral 
exercise. Holy cow that's a good one. Usually I knock the code out pretty 
quickly, but this one took some real effort. In the end I shipped a couple
of very different versions as I moderated myself through the process.
> 
> ~Barrett
> 
>> On Sep 25, 2014, at 01:16, Mark IJbema <markijbema@gmail.com> wrote:
>> 
>> I like part of the ambiguity though. For instance, in word count, you 
can use either split or scan. To me, scan feels more correct, but because 
the specs aren't hammered down it is still possible to have discussions 
about which is better. I think this does reflect the real world scenario 
of having an incomplete specification. And in the case of anagram: I like 
how it requires on exception from what would be the prettiest program; 
this makes you think about how to make good-looking, elegant programs in 
real life, where you also have these exceptions.
>> 
>> What you mention, but don't explicitly call out, is another problem 
I've seen from (my now very little) recent interactions with exercism. 
Sometimes the nitpicks aren't so much about elegance and such, but about 
correctness. I think most of th ese comments are actually wrong. Another 
variant of this is the "this won't pass the tests". I think it's important
to keep guiding nitpickers in giving friendly, good nitpicks, and this has
been a hard problem from the start. But I think we do not want all specs 
to be 100% watertight, because that also removes the wiggle room of having
wildly different solutions to the problem.
>> 
>> Mark
>> 
>>> On Wed, Sep 24, 2014 at 7:39 AM, Katrina Owen <_@kytrinyx.com> wrote:
>>> On 09/23, Colin Morris wrote:
>>> > I'm really enjoying exercism, but I've noticed a lot of the READMEs that
>>> > come with problems are ambiguous or underspecified, which feels frustrating.
>>> 
>>> Originally that was kind of intentional, because the ambiguity opened up
>>> some really interesting questions.
>>> 
>>> I'm actually not convinced that it's very useful to keep that 
ambiguity, and I think
>>> that it would be worth improving the detail of the READMEs overall.
>>> 
>>> > *Anagram*
>>> > - Why can't a word be an anagram of itself? As a programmer, I kind of like
>>> > living in world where we don't put special-case pylons around trivial
>>> > cases. `''python'.startswith('python') and '' in 'python' and all([])` :)
>>> > - Anagram detection is supposed to be case insensitive, but the example in
>>> > the README doesn't show this.
>>> 
>>> The definition of an anagram on Wikipedia is:
>>> 
>>> > An anagram is a type of word play, the result of rearranging the
>>> > letters of a word or phrase to produce a new word or phrase, using all
>>> > the original letters exactly once
>>> 
>>> In other words, if the letters have not been rearranged to produce a new
>>> word, it's not an anagram.
>>> 
>>> The case insensitive thing is actually something that I'm not sure
>>> about. I think that anagrams are case insensitive, but I've had people
>>> who are quite certain that I'm wrong.
>>> 
>>> I'd love to find a definitive answer to that.
>>> 
>>> > *Wordcount*
>>> > - The README makes no mention of this, but according to the unit tests,
>>> > we're supposed to downcase the input and strip trailing punctuation.
>>> > - I wrote a solution that involved stripping all punctuation. Someone
>>> > nitpicked "What if the input is 'the#quick#brown#fox'?". To which I replied
>>> > that my output would be X and I have no idea whether that would be correct
>>> > or not because there are no unit tests with interior punctuation and the
>>> > README doesn't say anything about what a word is. (
>>> > http://exercism.io/submissions/17d2a2d052abeb46577661ad)
>>> 
>>> This is a really good question. I think that word count could benefit
>>> from a lot more thought both in terms of the README and the test suites.
>>> 
>>> > When I get test failures, I'd prefer it to be because I made a logical
>>> > mistake, not because I failed to incorporate some arbitrary special case or
>>> > rule that never could have been inferred from the spec.
>>> 
>>> Good point. I've been looking at the test suites as training-wheels...
>>> the tests you might have written yourself had I asked you to think about
>>> this (somewhat vague) problem.
>>> 
>>> They're not like an exam that you need to pass, but I can totally see
>>> how it might feel that way.
>>> 
>>> > (Also, I feel like
>>> > novice programmers might confuse these two scenarios, and end up feeling
>>> > more pessimistic about their skills than they should be.)
>>> 
>>> This is definitely something I want to avoid. Again, it goes back to how
>>> I don't see the test suite as being like grading homework, only as an
>>> exploration of a problem-space.
>>> 
>>> If others don't experience them in that way, then we certainly need to
>>> talk about how to improve the READMEs.
>>> 
>>> > Am I missing the point here? Are these specs intentionally ambiguous
>>> > because that's how problems are often posed in the real world?
>>> 
>>> Naw, not really. In the beginning it sort of started out that way, but a
>>> lot of that is accidental.
>>> 
>>> > If this isn't intentional, I'm happy to start writing some pull requests
>>> > rather than just whining. I just wanted to make sure I understood first.
>>> 
>>> I would really appreciate that!
>>> 
>>> Katrina
>> 

Re: [exercism] Ambiguous specifications?

From:
Peter Minten
Date:
2014-09-25 @ 16:03
I think it's useful to distinguish between different cases of unclear 
specification:

* We've seen cases where the same exercise in different tracks has 
subtly different requirements. This is a bad thing unless there are good 
reasons for it, such as the common reqs not being sensible for the 
language of the track. Usually this is about trivial stuff (like "Woah" 
vs "Whoa").

* There are instances where the spec is vague and you have to do your 
due diligence (reading test cases closely or reading external 
documentation). This is a good thing, provided the exercises are placed 
at the right point in the track (harder exercises -> later in the track).

* Sometimes ambiguity is used by the test designer as a learning tool. 
For example in list-ops there are generally two ways to approach the 
problem: with a naive elegant solution and a tail recursive solution. I 
wrote a few test cases that have undesirable operational semantics with 
the naive solution (they take forever or eat up all your memory). Sure, 
it's annoying when you run into those but it will make you remember how 
easy it is to get that kind of problem. Telling people wouldn't have the 
same impact.

My take on this is that ambiguity is useful but it needs to be the 
intention of the test designer to add the ambiguity. Unintended 
ambiguity is more likely to cause problems without having benefits.

Greetings,

Peter

On 09/25/2014 05:49 PM, Russell Dunphy wrote:
> I'm also in the ambiguity is good (or not bad) camp. Taking the Bob
> exercise as an example, the fact that the precedence order of the cases
> doesn't match the order in the readme means you are confronted with the
> importance of precedence while writing it. Otherwise, if the tests just
> passed, you may never have thought about it.
>
> On 25 Sep 2014, at 14:06, barrett clark <barrett.clark@mac.com
> <mailto:barrett.clark@mac.com>> wrote:
>
>> I don't know that I've really ever thought about the ambiguity in the
>> READMEs. There have been some where I wasn't really sure what was
>> going on, and so I looked the subject up and read through the tests.
>> Liking the subject up is also good so that you know the vernacular of
>> the subject for variable naming and su ch.
>>
>> I'm not opposed to the notion of taking a pass through the exercise
>> instructions. I do fall in the camp of the ambiguity is good (or not
>> bad). That's life, and I also like that it leaves room for exploration.
>>
>> Speaking of exploration, I just did a few rounds of the Roman numeral
>> exercise. Holy cow that's a good one. Usually I knock the code out
>> pretty quickly, but this one took some real effort. In the end I
>> shipped a couple of very different versions as I moderated myself
>> through the process.
>>
>> ~Barrett
>>
>> On Sep 25, 2014, at 01:16, Mark IJbema <markijbema@gmail.com
>> <mailto:markijbema@gmail.com>> wrote:
>>
>>> I like part of the ambiguity though. For instance, in word count, you
>>> can use either split or scan. To me, scan feels more correct, but
>>> because the specs aren't hammered down it is still possible to have
>>> discussions about which is better. I think this does reflect the real
>>> world scenario of having an incomplete specification. And in the case
>>> of anagram: I like how it requires on exception from what would be
>>> the prettiest program; this makes you think about how to make
>>> good-looking, elegant programs in real life, where you also have
>>> these exceptions.
>>>
>>> What you mention, but don't explicitly call out, is another problem
>>> I've seen from (my now very little) recent interactions with
>>> exercism. Sometimes the nitpicks aren't so much about elegance and
>>> such, but about correctness. I think most of th ese comments are
>>> actually wrong. Another variant of this is the "this won't pass the
>>> tests". I think it's important to keep guiding nitpickers in giving
>>> friendly, good nitpicks, and this has been a hard problem from the
>>> start. But I think we do not want all specs to be 100% watertight,
>>> because that also removes the wiggle room of having wildly different
>>> solutions to the problem.
>>>
>>> Mark
>>>
>>> On Wed, Sep 24, 2014 at 7:39 AM, Katrina Owen <_@kytrinyx.com
>>> <mailto:_@kytrinyx.com>> wrote:
>>>
>>>     On 09/23, Colin Morris wrote:
>>>     > I'm really enjoying exercism, but I've noticed a lot of the READMEs that
>>>     > come with problems are ambiguous or underspecified, which feels 
frustrating.
>>>
>>>     Originally that was kind of intentional, because the ambiguity
>>>     opened up
>>>     some really interesting questions.
>>>
>>>     I'm actually not convinced that it's very useful to keep that
>>>     ambiguity, and I think
>>>     that it would be worth improving the detail of the READMEs overall.
>>>
>>>     > *Anagram*
>>>     > - Why can't a word be an anagram of itself? As a programmer, I 
kind of like
>>>     > living in world where we don't put special-case pylons around trivial
>>>     > cases. `''python'.startswith('python') and '' in 'python' and 
all([])` :)
>>>     > - Anagram detection is supposed to be case insensitive, but the
>>>     example in
>>>     > the README doesn't show this.
>>>
>>>     The definition of an anagram on Wikipedia is:
>>>
>>>     > An anagram is a type of word play, the result of rearranging the
>>>     > letters of a word or phrase to produce a new word or phrase,
>>>     using all
>>>     > the original letters exactly once
>>>
>>>     In other words, if the letters have not been rearranged to
>>>     produce a new
>>>     word, it's not an anagram.
>>>
>>>     The case insensitive thing is actually something that I'm not sure
>>>     about. I think that anagrams are case insensitive, but I've had
>>>     people
>>>     who are quite certain that I'm wrong.
>>>
>>>     I'd love to find a definitive answer to that.
>>>
>>>     > *Wordcount*
>>>     > - The README makes no mention of this, but according to the unit tests,
>>>     > we're supposed to downcase the input and strip trailing punctuation.
>>>     > - I wrote a solution that involved stripping all punctuation. Someone
>>>     > nitpicked "What if the input is 'the#quick#brown#fox'?". To 
which I replied
>>>     > that my output would be X and I have no idea whether that would 
be correct
>>>     > or not because there are no unit tests with interior punctuation and the
>>>     > README doesn't say anything about what a word is. (
>>>     >http://exercism.io/submissions/17d2a2d052abeb46577661ad)
>>>
>>>     This is a really good question. I think that word count could benefit
>>>     from a lot more thought both in terms of the README and the test
>>>     suites.
>>>
>>>     > When I get test failures, I'd prefer it to be because I made a logical
>>>     > mistake, not because I failed to incorporate some arbitrary 
special case or
>>>     > rule that never could have been inferred from the spec.
>>>
>>>     Good point. I've been looking at the test suites as
>>>     training-wheels...
>>>     the tests you might have written yourself had I asked you to
>>>     think about
>>>     this (somewhat vague) problem.
>>>
>>>     They're not like an exam that you need to pass, but I can totally see
>>>     how it might feel that way.
>>>
>>>     > (Also, I feel like
>>>     > novice programmers might confuse these two scenarios, and end up feeling
>>>     > more pessimistic about their skills than they should be.)
>>>
>>>     This is definitely something I want to avoid. Again, it goes back
>>>     to how
>>>     I don't see the test suite as being like grading homework, only as an
>>>     exploration of a problem-space.
>>>
>>>     If others don't experience them in that way, then we certainly
>>>     need to
>>>     talk about how to improve the READMEs.
>>>
>>>     > Am I missing the point here? Are these specs intentionally ambiguous
>>>     > because that's how problems are often posed in the real world?
>>>
>>>     Naw, not really. In the beginning it sort of started out that
>>>     way, but a
>>>     lot of that is accidental.
>>>
>>>     > If this isn't intentional, I'm happy to start writing some pull requests
>>>     > rather than just whining. I just wanted to make sure I understood first.
>>>
>>>     I would really appreciate that!
>>>
>>>     Katrina
>>>
>>>