The tutorial
Ok, my 'Dutch' book (rethorics are part of 'Dutch' language class here..
dont ask me why) tells me, for any text, you should wonder about a couple of
things. And you know what, they're not right about much, but they are right
about this. Lets, before writing anything, agree and/or discuss the points
below: (i skipped those unrelevant)
1- What is it we are gonna tell ? (definition of subject and perspective
used upon subject)
2- To whom do we want to tell it to ? (audience, previous experience, etc.)
3- How are we going to tell it ? (considering point 2) (tone of voice,
teaching methods, rethorics)
--------- What I really dont give a *beep* about are:
1- The title. At the end we have to choose an tittle that catches attention.
Its part of the little marketing you do, to get people to read/use the
tutorial. It has absolutely no influence on the quality of the content. Any
futher discussion is irrelevant.
2- Platforms, languages, hardware, example programs. The theory of
programming is independent of all of them. To illustrate what I mean, I'll
explain how our 'Geography' exams are: everything you've learned of
Geography is being applied onto *one* country. A different country every
year. All ideas, terms, and perspectives are thus applied onto a practical
example. Why ? Because it is impossible to learn (and remember) all the
geographical (thus: demgrafical, political, cultural, economical) aspects of
every place on earth. For math, this is logical. Are we trained to know the
tangens of every corner, or are we trained in such way, we can apply it to
any corner ? Same goes for programming. Language, platform, etc. is not part
of the tutorial. However, the ideas of the tutorial should be applied upon,
in this case: Euphoria, MSDOS & Windows OS, etc. And dont think: "not this,
its too complicated: lets give a trivial example instead". There is no such
thing as a bad example, except when it doesnt apply.
------ Now I will fill in the 3 points I do care about:
Comment on them. Eventually, we have to agree upon them, before we can begin
to write anything:
1- We're going to give insight into programming. We are not going to teach
them, how to do what a programmer (software engineer) does, but we are going
to teach them to program. An elegant, yet, dangerous distrintion. And like
with anything one can teach. We try to lead them into the 'thinking route'
(or drain of thoughs) that will lead them into either making the same
conclusions as we did, or better.
2- We will try to keep it as cultural and background independent. For any
ration human being, capable of some english. (maybe I'll do a dutch/english
translation: that is a dutch translation, using english terms) However, we
will not fear to introduce new words. Not with an official introduction. But
by silently/secretly use them once, and then more often. Words are perfect
to gain more grip on abstract ideas. Personally I hate those newcomer
friendly terminology. It makes it impossible to explain, show, grisp and/or
discuss things. For the same reason Im using the English version of Windows,
and Word, etc. The dutch translation is often so silly, you really wonder,
what the hell they are talking about. For example: you once had directories.
According to MS, you no longer have directories, but folders. However, in
Holland we dont even have folders. We have maps. Dont you think thats great
? I can now make an document in my map vanish, by transporting it to the
recycling station 
... Dont understand me wrong: I love figurative
explenations. However, soon after that, I will want to use a more appropiate
term. You can only re-assign a word, when it matches the current definition
and scope. If not, the scope will become unclear, and the term no longer
serves its purpose: to generalize (thats what words do) and thereby
simplifying information/ideas so we can gain more grip on them, and use the
associated ideas more effectively. Not to mention off course, the advantage
for communication. We can explain an idea, by referring to other ideas. But
when the scope of any of those ideas is unclear any defenition based upon
them will be vague.
3- Well, we should not tell to much. The art of grasping an idea, is to
apply it. Not by exercizes, no. Things should fall in place automatically.
When someone tells you things on earth fall down, when there is only air
below them, and that they gain a certain velocity, and somebody else tells
you granades explode when they hit the ground with a certain velocity. And
from your own experience you know that when you push something off a
mountain, air is usually below it. How many things do you know ? 3 ? 4 or 5
? You will know 5 things. Which other 2 things would you know ? Well, when
push a granade off a mountain it will fall down. When a granade falls down,
it wll explode. Same goes with teaching things. For example, when telling a
known method to solve a certain problem.... should we explain the advantages
and disadvantages of the method ? Or tell in which situations it was applied
or being developped in and have the reader make the conclusions ? Often,
more information is told 'between the lines' than actually within them.
I also want to emphasize 'tone of voice'. Im personally not very good at it,
but its a great communication tool. Together with jokes it not only makes it
easier to read, but can shorten many explenations. When they can hear (well,
hear ?) from the tone of voice (word order/structure thus, and which words
you use) an subjective opinion, or just the perspective they should have
regarding the sentence, you can use that 'perpective' without having to
strictly define or explain that 'perspective'. How often, were you unable to
explain how you feel regarding a certain person, but you best friends could
understand you, simply by looking at your face ? No, I do not want to create
an opinionated tutorial. But the line between opinion, and perpective is
very subtle.
Tell me what you think regarding the above 3 points..
Ralf
|
Not Categorized, Please Help
|
|
