Thoughts on mini Smalltalk exercises

Hi - I’m trying to help Sam kickstart Pharo working Ian the exercism platform. For those less familiar, exercism is a platform with a series of exercises that users/students “checkout” and then run a test to guide them through completing the code to then progress to the next challenge. There is also the ability to comment on each other’s progress and see examples of other’s solutions. Most languages are more traditional file based examples, so it would be nice to have Smalltalk as something a bit different. Although we think Tonel 2 will be an excellent vehicle for participating alongside other languages as it helps us fit in a little easier (nice how all our initiatives are coming together to make this easy).

As you can imagine, exercises start out very simple and then increase in complexity. My question however, is about the early exercise like HelloWorld, LeapYear etc.

These tend to be single method problems of just a few lines, requiring no instance variables (this all comes later).

I’m wondering about people’s thoughts on whether we should introduce early Smalltalk examples as just class methods and later introduce instance methods and “class constructor methods “? Or is this more confusing for students? Essentially we are battling with the familiarity of the C “main” method - and looking at python and ruby solutions, they initially start with no objects and just main style methods.

E.g. hello world can be simply:  HelloWorld sayHello. vs HelloWorld new sayHello.

I can see pro’s/con’s either way - but wondering what others think.

Tim

Sent from my iPhone

Le 11/07/2018 à 16:43, Tim Mackinnon a écrit :
> I can see pro’s/con’s either way - but wondering what others think.

IMHO, the simpler the better, particularly for users with no knowledge
on Pharo.

Hello world could be class-less just: Transcript show: 'Hello world'

Hilaire

--
Dr. Geo
http://drgeo.eu

Even shorter:

  'Hello World!' crLog.

A variant using the Growl disappearing popup:

  self inform: 'Hello World!'.

Using a dialog:

  UIManager default alert: 'Hello World!'.

Using a window:

  'Hello World!' asMorph openInWindow.

For real terminal output, there is this possibility:

Stdio stdout << 'Hello World!'; lf; flush.

All these are nice alternatives that can be used to explain different approaches/techniques, although they might be beyond what is expected.

Sven

Hi guys, they’re all great ideas - but I guess I should have added the caveat - “that you can easily test”.

It sounds like maybe using class methods puts it closer to the simpler camp you are suggesting - and I would like to push the idea of using the debugger to create the missing method (a unique feature we can sing about).

We’re trying to help bridge a balance between unique and familiar, and to be honest the quicker we can move people to the harder problems the better.

It’s not clear to me if you can just invent new problems - but if so, we might hit you guys up for some more ideas.

Tim

Sent from my iPhone



Sent from my iPhone

On 11 July 2018 at 22:43, Tim Mackinnon <[hidden email]> wrote:
I've installed Sam's PR and my main thought is that the System Browser
defaults to the instance side,
so its easier for fresh students to misplace code when it ends up on
the class side, when they close a browser and open a new one.

The unit test the students run takes care the of needing to send #new
to get an object,
so I think its simpler to keep implementations on the instance-side.

One downside is that the Quality Assistant indicates that utility
methods (having no reference to instance variables)
should belong on the class side.   It might be good that this warning
is disabled globally when the Exercism tool is installed.
I think using a Manifest to do this would look complicated to newcomers.

Later on some specific Factory Pattern exercises might be useful to
introduce students to using class-side methods.

cheers -ben