Let me tell you a story.

The story is about someone I knew back when I was doing my MSc.

He was really bright, but he had to repeat a year in the papers

part of his MSc.

Why?�� Because he didn't get statistics.

Differential equations?�� No problem.

Topology?�� No problem.

Operations research (which was his actual topic)?�� A walk in the park.

Statistics?�� He just couldn't get it.

Why not?

"I read the book, and I think I understand, and then I come to the

examples, and I can't see why they use the method they use, why

that is a good method for that problem."

I hope it made a difference to him when I replied

"You can't see why method X is a good choice for problem Y

because it isn't.�� If your goal is to illustrate the workings

of method X, problem Y will do.�� But if your goal is to

actually solve problem Y, method X is the last thing you should

try."

I actually worked through a couple of famous textbooks,

example by example, and found that for more than half of the

problems, if you followed the advice in the book about how

to select a method, you would never select the method in the

example, and the method you would select instead gave better

and on occasion much better results.

In this particular case, I don't give a damn about what

{1@0. 0@} looks like in a debugger, BECAUSE IT NEVER DID

APPEAR IN A DEBUGGER.

The one method needed to solve the problem is 18 lines.

The test code, including all available test cases, is 27

lines, of which 18 lines is the test data.�� Tests were

needed primarily to sort out what the problem actually *was*;

exercism doesn't even try to provide good specifications.

No debugging time at all was needed, precisely because the

code was so simple and obvious.�� If it *had* been needed,

viewing the result right next to the expression that yielded

it would have given me all the context I needed, in one window.

If you want to learn how to design a good set of classes,

this is an absolutely dreadful problem.�� In fact ALL of the

exercism problems are going to be dreadful for *that*

purpose because they are provided for languages that do not

*have* classes.�� If you want to learn how to *solve problems*,

then you need to learn to write code that is simple, clear,

testable, and so on.�� You certainly need to learn how to use

what is already there in the language (except where that is

expressly forbidden).��

I completely agree that designing a good set of classes is

a very very important skill for anyone who wants to do OOP.

I completely agree that practising this on problems you can

hold in your head is a good idea.

I completely agree that if *that* is your objective,

writing minimalist code is not the best strategy.

The problem with exercism is that while it does have a

criterion by which you can tell whether you have *solved the

problem*, it provides *no* way to assess your class design.

You don't get told "this is good, that is bloated"; there is

no feedback about the *quality* of your code except via

comments from those few people who can be bothered to look

at other people's solutions and comment on them.�� And since

many of them will also be beginners, their comments may not

always help.