difference-of-squares: Last test may be too hard for beginners

[rbasso]

Since I reviewed this iteration, I'm wondering if we should remove the last test case or move this exercise a little later in the track.

Most users try to solve this exercise using sum, and there is no way for that to work with a huge list.

Other comments about it:

• http://exercism.io/submissions/765f0083fde1479a96f3e40043b7ffab
• http://exercism.io/submissions/b92f05a157724dbdb336b42577fc259e
• http://exercism.io/submissions/e53c9da929444e88817b9bd6dfc0012b
• http://exercism.io/submissions/dfa730dd5a95460187c649a9f7b8070c

We are certainly missing more people reviewing the exercises...

There are two paths to pass the last test:

• using foldl'.
• using more math.

Should we do something about it? What?

[petertseng]

Let's see, looks like it was added in #255. And where was difference-of-squares before #402 moved it to be the fifth problem in the track? about 36th (I may have miscounted since I did it by hand).

What would be the benefit of keeping it? To require students to think about efficiency?

I'm about a 1/10 on the caring scale, but if you made me pick I'd vote to remove.

[abo64]

I see two solutions:

• We could comment it out as I did for the alphametics tests.
• We could add more hints. I created an issue to have more hints in the Scala track, and I think the same argument holds for Haskell, too: Just think about the many times you had to write similar comments for your beloved Leap exercise, @rbasso ! ;-) (btw, I love your gitbook about it. Could we have more of this for other exercises?)

Or a combination of the two.

[rbasso]

I'm usually against commenting out tests, because I think that users shouldn't have to read or edit them.

A HINTS.md would be fine, but In that case I think that the exercise should still be moved later in the track.

I agree with any of these three solutions:

• Remove the last test.
• Remove all the track-specific test and change the stubs to use Integer, to keep consistence with other exercises that allow multiple types.
• Add HINTS.md and move it later in the track.

I think that the first to open a PR should choose. What about it? 😄

(btw, I love your gitbook about it. Could we have more of this for other exercises?)

I was just playing with gitbook to see how it works and also wanted to have a markdown file to play with Hakyll. Glad that you enjoyed!

I would also like to have more examples, but I think that it should be a community thing. What would be the best way to allow people to contribute with refactoring examples and also allow people commenting the code, explaining parts that are not clear? I have no idea.

[tewe]

I started with a strict implementation and it locked up my machine so hard I had to do a reset. Since this is to be expected there should be a giant warning in the solution template, or smarter test code.

[rbasso]

Sorry to hear that, @tewe!

In the past we had a lot of test suites that used huge numbers or really big lists to test if an implementation was reasonable, forcing people to write efficient programs to pass the tests.

Some of those tests where removed as we rewrote the test suites, but I guess you found one that is still there. 😄

In fact, we never decided if we should keep or not test cases about performance/memory.

For now I'll just comment out this test, as @abo64 suggested, and open an issue to discuss the more general problem.