TL;DR version:
"But if the purpose of problems is to lead students in new ways of
thinking about structuring OO solutions for maintainability"
That is not the purpose of the exercism problems. It would be very good
if somebody did craft such a set of exercises, and Pharo would be a very
good environment for them. The exercism exercises will not do.
Betrand Meyer has an OOP course that gets students started *modifying* a
non-trivial program, a traffic simulator I believe, instead of writing
free-standing toy programs. Worth thinking about.
On Wed, 24 Apr 2019 at 04:58, Ben Coman <b...@openinworld.com> wrote:
> On Mon, 22 Apr 2019 at 23:15, Richard O'Keefe <rao...@gmail.com> wrote:
> >
> > I already discoursed on this at some length.
> > (1) In my own answer, I used code to map direction names to vectors.
> > But the Dictionary answers are absolutely fine.
> > (2) I pointed out that there are ALREADY "turn left" and "turn right"
> > operations on Points.
> > (3) An elegant solution is one which wastes no effort.
> > Introducing classes that you don't need is definitely wasted
> > effort.
>
> Elegance in art is in the eye of the beholder. You've got one position on
> it.
> I'll just balance it with an alternative view for students to consider
> around "classes that you don't need".
>
> > WARNING: untested first draft code (can't find the tested stuff).
> > obey: commands
> > |position direction|
> > position := 0@0.
> > direction := 1@0.
> > commands do: [:each |
> > each caseOf: {
> > [$A] -> [position := position + direction].
> > [$L] -> [direction := direction leftRotated].
> > [$R] -> [direction := direction rightRotated]
> > }].
> > ^{position. direction}
> > You will need to fiddle with this a bit to get the mapping between
> > problem coordinates and solution coordinates right, and you'll
> > need that Dictionary mapping directions to direction names, but
> > that's pretty much it.
>
> > If you define more than one class for this problem, your code is not
> elegant.
>
> If the purpose of the problems is simply to solve the problem, then
> doing the absolute minimum is a reasonable view of elegance.
> After all, its throw away code. You're never going to be maintaining it.
>
> But if the purpose of problems is to lead students in new ways of
> thinking about structuring OO solutions
> for maintainability within Pharo, then I feel its lacking. I remember
> an instructor from my youth
> advising that "practicing a kata poorly is the habit that will be
> reproduced automatically (in a crisis)"
>
> > ^{position. direction}
>
> For me, viewing {2@3. 1@0 } in a debugger is a much greater
> cognitive load than {2@3. 'Facing east'}
> to determine which direction its facing. So I consider the latter
> more elegant. TDD helps minimise class over-engineering,
> but for me the latter is a "need". In terms of throw-away exercises,
> its about what habits students want to gain from doing them.
>
> Just another perspective.
> cheers -ben
>
>
