On Thu, Sep 21, 2006 at 09:45:53PM -0700, Eric Winger wrote:
> 
> Le Sep 21, 2006, ? 8:25 PM, Matthew Fulmer a ?crit :
> 
> >On Thu, Sep 21, 2006 at 06:47:52PM -0700, Matthew Fulmer wrote:
> >>I created a document stating the plan, goals, and purpose of the
> >>Squeak Documentation Team:
> >>http://minnow.cc.gatech.edu/squeak/5870
> >
> >I really want to introduce beginners to (and learn myself) how
> >to write good unit tests, then develop a  class that conforms to
> >those unit tests inside the debugger. I have heard that that
> >capability is one of the best things about Smalltalk, and I know
> >that unit tests are a *very* good thing to use.
> >
> >Should I expose a Squeak beginner to this topic early on?
> >or should that be the topic of a separate tutorial?
> 
> I like what you mentioned in an earlier email about building an 
> application as a framework for a tutorial. And I think that doing 
> test-first development is wonderful. Even if its just a couple simple 
> tests on the model for the gui (assuming you choose to put a gui on it)

I am not sure what email you are referring to. Are you saying
that you think it is a good idea to walk the reader through the
development of a real application? If so, I assumed that this is
the only way to structure the tutorial.  Do you have a different
idea?

This paragraph is difficult to understand; could you restate it?

> >I do not know if my tutorial will target novice programmers or
> >not.
> >
> 
> I would target novice programmers. Why not start there with a really 
> well-done intro tutorial that's up to date with the latest squeak dev 
> image and can be easily kept up to date?

That is an interesting idea; I would write a tutorial for
non-programmers completely differently than one for a
programmer.

For a programmer, I would walk them through the environment,
then have them write a transcript-based program along the lines
of "Hello world", but a bit more functional. Then I would show
them how to build a window (I am assuming it is similar to Java
Swing or GTK) and make it display useful information.

I am unsure how I could incorporate test-driven programming into
that, as that is a *very* jarring concept to me, and hence to an
average programmer.


To target a non-programmer, I would take a completely different
approach: I would first show them how to put a widget into the
playfield, then how to manipulate it. I may or may not introduce
eToys to the reader. I would never show them the Transcript; it
seems useless when compared to Squeak's other debugging tools. I
would then show them the ifTrue:ifFalse: and do: methods. I may
introduce classes and inheritance; probably not. I am not sure
how I would introduce them to windows and layouts.  Trying to
think like a non-programmer is making my brain hurt :(

I don't see why I could not introduce test-driven programming to
a non-programmer at her inception; it is the way normal people
tend to think about problems. Normal people define a situation
(test case) and then define how the object should behave in that
situation.  Programmers are backwards: they tend to define what
the object can do, then warp the situation to fit the object.


I guess I need to choose which of three tutorials to write:

1. Programmer-targeted without test-driven programming (short)
    This is the easiest of the tutorials to write, and may be
    the one most in demand. Since I am in the same situation as
    my audience, this would probably be the most realistic
    tutorial.

2. Programmer-targeted with test-driven programming (medium)
    This may be difficult to write, since it may be very
    disorienting tutorial to the reader.

3. non-programmer targeted (long)
    This would be the most interesting to write, and will be the
    longest of the three choices. Writing this tutorial would be
    a very direct measure of Squeak's ease of use: the length of
    this tutorial should be inversely proportional to how
    comprehensible Squeak is to normal folk. (a zero length
    tutorial would be a perfect score by this metric)

Which would be the most useful? Do we need to make more than one
tutorial? Please comment.

-- 
Matthew Fulmer