Re: The tutorial
>It just asks you a handful of questions, and picks the right type of
>tutorial for you?
Well, this idea is leading to somewhere I think. Thank you for the link,
Greg.
Rather than discussing ToC's .. I would prefer to focus on the goals, and
methods we are using to teach it, before we would even consider any
real-life implementation of those methods, and thus form a ToC.
The ToC posted by Daniel is practical, yet very specific. (no offense
intended)
I would personally prefer a bit more 'ambitious' and 'original' approaches,
since using the current methods of teaching and writing, and structuring an
tutorial, I would personally be dissatisfied. Also, RDS already made perfect
docmenation, for those already having the right or at least a sharp
perspective of what programming is. Rather than making a tutorial that is
adjusted to the 'wrong' or 'beginners' perspective, lets learn them enough
about programming, so the standard documentation is enough. That is, I see
no point in providing the documentation again. Off course a few hardware/os
related articles should be provided, but as reference, rather than tutorial.
An quick intro into current ideas, and techniquesch for quick graphics, for
mouse, for win32lib, etc. However, the actual documemtation, should be used
during the learning procces.
What I mean, is that we could give an example 'problem' and the beginner,
ambitious as he/she is, will try to solve it. It would be ok to include a
list, of associated routines, so they dont have to search through the
documentation. But they have to see the actual and strict definitions by
RDS. This also avoids version issues. But this all is more about the actual
structure of the tutorial. First the methods we will use to explain
something. A trivial thing, yet, lets first come to terms about it. You dont
just explain something to some one, there is a plan behind such a thing:
The idea of having different learning methods for different persons is, for
example, very interesting. (again, Greg, thanx)
Consider for the learning approach, three different 'methods':
- Figurative explenation. Trivial example: a sequence is like a tree
(imaginairy/visual)
- Use terminology, and give strict definitions: Trivial example: you can
*merge* two sequence, or a sequence and an atom (auditory).
- Provide example code, pseudo code, and examples from other languages:
Kinesthetic & Tactile
Yet, an tutorial (IMHO) should be more exploration, than explenation. For
example, sequences could be a word, sneaking in, describing how one could
store an directory-tree on a piece of paper. In the end of the
'chapter'/'section'/'whatever' we give a strict definition, and show how to
do so in Euphoria. However, programming teachniques are more than using data
store. The actual trick of finding the 'right' algorithm, studying the
underlying behaviour of a certain routine.
Actually, I like the idea, of 'story-like' tutorial, where some guy or girl,
or animal goes through lifes, and wonders about things. And this small,
small story of this wondering character can serve perfectly for figurative
explenations, moving from one 'programming elementary' to another. Each
'programming elementary' ends into a strict definition of some terms,
already used a number of times. Example code, and a clear figurative
example. (a very short one: A one or two liner). Together with, I dont call
them 'excersizes', but a combination of un-intuitive remarks about this
'elementary' and 'phoney' questions. (So, the reader has something of ' I
thought I understood, why not in this and this case ? ' and he/she wonders,
and wonders, and re-reads, looks at the 'prove code' and will understand. At
such a point, they have a certain grip at the terms used, and they've been
already introduced (and guided through) the most annoying and confusing
situations).
This mini-story is not much of a story, other than a scratch book of days in
the live of some funny person. More like 'sketches'. The less they have to
do with programming and a computer in general the better. Example:
explaining primairy interface aspects by asking way to many questions about
the how the phone is made. (wondering if it would better to have the
'dial-numbers' in the hand-set rather than on the phone, so they can only be
used when the phone is off the book, which is the only moment it is
appropiate. Things like that). And off course, such sketches have a purpose
in tone of voice and easy-reading as well.
Does any understand and feel something for this, at first glance, pretty
silly idea:
* using (cynical maybe) story/real-life sketches, to illustrate the the
idea behind certain terms and techniques, slowly moving towards an actual
'Programming Elementary'
* have terminology slowly sneaked in
* end with strict definition, and 'remarks/questions' about the most
confusion situations, with guidance (an example program) towards an
explenation/solution.
* The first time Euphoria code appears, a quick intro. Afterwards, new
grammer elements are explained. Together with the comments & the RDS'
documentation, the example programs should tell the Euphoria-specific
details they need to know. (simple notes will do: abort (1) -- this
procedure halts your program and sets the dos-errorlevel to 1.
* Have a number of acticles regarding often used techniques and some
knowledge base. A primer on databases, networking, game-programming,
win32-api, compression, 3d, parsing, etc. Preferbly together with a good
list of references to books and/or other type of material.
Thats it. My first attempt at quick & dirty list of aspects of the tutorial
as I could come up with it. I appriciate any feedback.
How do you all feel about this setup ?
Also, 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.
Ralf
|
Not Categorized, Please Help
|
|
