OpenEuphoria

Re: The tutorial

• Posted by Quality <quality at ANNEX.COM> Jan 28, 1999
• 644 views

From: Ralf Nieuwenhuijsen <nieuwen at XS4ALL.NL>

[snip]
>That is, I see no point in providing the documentation again.
[snip]
>However, the actual documentation, should be used during the learning
procces.
>


I have read many many many tutorials in my day and I can tell you that the
ones I hated the most were the ones that  made me go looking elsewhere in
the middle of a learning experience. This is (IMHO) the fundamental
difference betwen a tutorial and a reference manual.

[snip]
>You dont just explain something to some one, there is a plan behind such a
thing:
>

On this we agree. See my post on using a "build a project" approach.

>The idea of having different learning methods for different persons is, for
>example, very interesting. (again, Greg, thanx)

>

Let's write ONE version to start and then we can adapt it if there really is
a need to do so. Assume the two types of students mentioned by David [1)
People who never programmed before 2) People who programmed before but not
in Euphoria.] and stage the learning for these but otherwise lets focus on a
single first draft version.

[snip]
>Yet, an tutorial (IMHO) should be more exploration, than explanation.
[snip]

I agree. The adage "You can lead a horse to water but you cant make him
drink." applies to learning. Lead the student to a point where they want to
try the concept for themselves.


>Actually, I like the idea, of 'story-like' tutorial, where some guy or
girl,
>or animal goes through lifes, and wonders about things.
[snip]
>This mini-story is not much of a story, other than a scratch book of days
in
>the live of some funny person. [snip]
>

Yes. I am reminded of a Pascal tutorial I read back about 15 years ago where
Sherlock Holmes & Doctor Watson built a "deduction engine" (a database) to
solve a criminal case. It was a very effective tutorial. Perhaps your "funny
person" could be a 60's Berkley student walking around campus in a Euphoria
haze <grin>.

[snip]
> to illustrate the amount of preparation the structure of such a
>project needs: just try to define programming.
>A first, quick & dirty attempt at a definition would be: using a computer
>language to express the charactistics and aspects of a certain model of
>behaviour/interaction.
>
>Pretty vague, already, I think.
>


Programming: Telling a computer what to do using terms it understands even
if you don't.  (^8

Seriously:

Program:  A series of detailed instructions (a procedure) describing
specific steps that must be done to accomplish a desired task. All programs
have Input, Process, and Output features.

Programming: Designing a program. Since computers cannot make *valid*
assumptions of any kind, it is a major role of a programmer to explicitly
define every issue that the computer might need to know in its effort to
execute the program.