Bumped hamming to 2.3.0

[uzilan]

Bumped hamming to 2.3.0 and changed the tests according to https://raw.githubusercontent.com/exercism/problem-specifications/master/exercises/hamming/canonical-data.json

Left out tests for empty left or right strand after discussion in Slack: https://exercism-team.slack.com/archives/GC3K95MRR/p1570051281069500

Could this PR be labeled with hacktoberfest please?

[uzilan]

Travis seems to not supprot jdk8 anymore. Updated to jdk11.

[stkent]

@uzilan just so you know, these PRs should count towards your Hacktoberfest progress even if they aren't labelled. The labels are just to help discoverability of suitable issues :)

[uzilan]

Ah cool, thanks. These were required last year, I guess they changed it

[kotp]

This seems like it should be its own pull request. It isn't related to the Hamming exercise, other than to allow Travis to pass, but this is more general than only Hamming.

[uzilan]

Ok, cool. Created a new PR, #323 for changing the jdk only.

[kotp]

We could bring the changes in, I just would not want to lose the history of the commit that updates the JDK.

[kotp]

Thanks @uzilan

[uzilan]

Updated test names using backticks, I hope you're fine with this.

[dector]

@uzilan Can you update this PR please as #323 is merged?

[uzilan]

Done

[dector]

Sorry, Slack archive is not available anymore.
But seems like 2.3.0 version of this exercise has 9 tests, but only 7 are present here.

[uzilan]

Here's the discussion we had: https://gist.github.com/uzilan/2b807a852b802683bca48ad5a387a113

[uzilan]

So basically we've decided to skip the tests that checked for empty strands and instead encourage mentees to use require to compare their lengths

[dector]

Got it, thanks!

Maybe it's better to implement this tests (but comment-out them?).

I'm not sure that we can change test cases and bump used specification versions as our's test cases will not reflect actual specification.

[uzilan]

I don’t think Exercism is so rigid that we can’t decide stuff like that on our own but I could add commented tests if you want them

[dector]

It's just my opinion, but I find partially-implemented specification (without explicit notice) quite misleading for those who will support this repo later. 😅

[eparovyshnaya]

Colleagues, I was asked to form and expose my opinion on the case, and here it is.

We have two separate things here to discuss, and it's important to distinguish them.

1. a task for a student

We have an interesting theme (Hamming Distance) and strive to design it to the best task for a student.
What does the best mean? The best task is easy to catch, interesting to implement,
and the very task statement leads you to key concepts to explore.

What useful construction a student will exploit for the first exception demanded?
require (pointed at or found). It's a concise and handy tool under a belt. Yep, we think, we've design this part right.

What student will learn on the second exception over the same data, when one cannot use require anymore?

In any solution there are two parts: plot (algorithm and idioms selection for it) and chores.
Plot is exactly what drives us crazy and makes us feel like we learn something.
What do we feel about chores? We rest, we settle, we put things in order, it's a relaxing and a bit boring activity, and there is nothing burning.

I think, we should keep our student burning by any means we have. Actually there lots of thing in the outer world, that distract them.
Chores are necessary, but definitely should be minimized and totally eliminated where possible.
I think, we should leave chores to ferocious production programming - it inevitably finds those who code for money, and never can be omitted.

For our case, IMHO, additional exception messages are chores.
The first one definitely does the educational job for a student.

2. requirement consistency

If we do not implement these requirement as tests - why to keep requirements in the first place?
Is there a language under Exercism guidance, where such an exceptional cases branching adds something to learn?
I just do not have enough knowledge and ask for help.

I conclude:
Agree with eliminating the cases from Kotlin test suit. It's a tactical part.
But harmonization with the common requirements is strategically important. Can we debate specification correction?

[dector]

@eparovyshnaya Thanks for you thoughts here!
As an option we can make stub solution for this exercise that already contains requires {} with proper error message.

Tbh, I'm quite against silent specification violation - because it's like intentionally creating a mess. :)
However I don't understand why we should teach students bad practices from the beginning (e.g. writing only positive cases and not doing simple error-checking - as I said error-checking may be predefined if it's considered as something that is too difficult for the second exercise).

💭 Should be discussed in another thread, but what if we'll provide some useful links to documentation with each exercise.

[dector]

Let it go like this for now. We'll sanitize our tests later.