1. 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
2. Re: The tutorial
thank you for interjecting a little bit of sanity into this far from sane
conversation, I agree 100%.
Adam Weeden
WeeedenSoft Technologies
3. Re: The tutorial
At 06:22 p.m. 27-01-99 +0100, you wrote:
>1- What is it we are gonna tell ? (definition of subject and perspective
>used upon subject)
My attemp of a Table of Contents:
Part I: For the newbie
Introduction
Aims & Goals
Acknoledgments
What is programming
CPU vs. human brain
Algorithms & efficiency
Part II: Introduction to Euphoria
What is Euphoria
Language features
Interpreters vs. Compilers
Euphoria vs. other languages
Language definition
Data types
Sequences
Atoms
Integers
Objects
Strings
Program structure
Expressions
Reserved words
Procedures & Funtions
Scope
Execution flow control statements
Debbuging & profiling
Distributing your application
Part III: Advanced Euphoria
Code optimization
File access
Graphics programming
Memory allocation & machine code execution
Part IV: Windows programming in Euphoria
Euphoria & Win32
Benefits
Limitations
Windows programming fundamentals
Win32 & Pre-emptive multitasking
What is Win API
Messages
Using the API within Euphoria
Creating windows
Child windows
GDI
Common API Calls reference
RegisterClass
CreateWindow
etc...
Bibliography:
Each Part could be developed by a different group. Part II is basically a more
examplified version of the Euphoria Reference manual. Part III includes topics
like memory allocation/deallocation, using interrupts, executing machine
code, etc. Part IV
If a file content/viewer is implemented, each user may only download the
Parts that he/she needs only.
Regards,
Daniel Berstein
daber at pair.com
4. Re: The tutorial
-----Original Message-----
From: Ralf Nieuwenhuijsen <nieuwen at XS4ALL.NL>
To: EUPHORIA at LISTSERV.MUOHIO.EDU <EUPHORIA at LISTSERV.MUOHIO.EDU>
Date: Wednesday, January 27, 1999 12:22 PM
Subject: The tutorial
>1- What is it we are gonna tell ? (definition of subject and perspective
>used upon subject)
We are "gonna" tell how to program using Euphoria ;)
>2- To whom do we want to tell it to ? (audience, previous experience, etc.)
The target audience would be two groups:
1) People who never programmed before
2) People who programmed before but not in Euphoria.
>3- How are we going to tell it ? (considering point 2) (tone of voice,
>teaching methods, rethorics)
Tone of voice...um...light, maybe some humour?
Teaching method...combination of text and visual aids.
Rethoric..you got me there.
David Gay
5. Re: The tutorial
Daniel, that's a great attempt at a table of contents. I suggest we try to
separate keyboard and screen I/O from file I/O as it gets the person able to
write functional programs in the short run (i.e. the "hello world" program
comes to mind). Other than that, I think your list is pretty close to what
the tutorial will have.
David Gay
6. Re: The tutorial
Just an idea.... but why not a neat little setup program, for the
tutorial, that sets it up for your particular learning style?
It just asks you a handful of questions, and picks the right type of
tutorial for you?
see
http://www.chaminade.org/inspire/learnstl.htm
for a little chart on learning styles, and questions that pertain to
them.
Greg
--
Greg Phillips
i.shoot at rednecks.com
http://euphoria.server101.com
--
Useless fact of the day:
On an American one-dollar bill, there is an owl in the upper left-hand
corner of the
"1" encased in the "shield" and a spider hidden in the front upper
right-hand corner.
7. 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
8. Re: The tutorial
- Posted by David Gay <moggie at INTERLOG.COM>
Jan 27, 1999
-
Last edited Jan 28, 1999
>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.
Once again I must stress not everyone can learn in that fashion. RDS has
written an excellent manual, but it does not explain what a variable is for
example, or a byte, or how memory works. Those concepts are important in
order to use the library routines. Also, I've never considered trying to
reach the beginner a "wrong" perspective. In fact, I've always felt that the
teaching of programming should include the general public and not just the
hardcore programming clique. There's always a first time for everyone. If
that were not the case, those yellow "Big Dummy's Guide
To"...whatever...would not be so successful. Even a language like C, usually
the domain of the experienced programmer, is now covered for the newcomer,
even though there are reference manuals for the C language right beside
those books.
I think Daniel hit it right on the head with his ToC where he included
everyone with that single list
Your idea of presenting the tutorial as a story I do like. It makes the
learning process interesting. We would have to make the story so that it
does not come across as corny. The target audience age must be defined
clearly for the story to be successful without coming across as immature or
too sophisticated.
David Gay
9. Re: The tutorial
At 02:17 a.m. 28-01-99 +0100, you wrote:
>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 is just a way to outline the topics I think relevant to be included
on this project. Under this simple outline the way each topic is discussed
is your point... don't overlook outlines, they can be a powerful tool for
organizing your brainstorming.
>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
Don't forget that RDS documentation is a cold description of the language,
there
are little "in my experience with Euphoria..."
>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
IMHO I hate that 'story-like' thing. I think using analogies (as with
trees) are
good for introducing new abstract concepts, but that's where it ends.
A tutorial should treat real life programming situations. How I do this,
why I can't
do that, when do I do this other, etc...
>Also, to illustrate the amount of preparation the structure of such a
>project needs: just try to define programming.
Programming is the act of creating a program
Now, define a program ;)
(If you've got time define a programming language)
Regards,
Daniel Berstein
daber at pair.com
10. Re: The tutorial
Just in case anyone is interested:
I started writing a tutorial (in Portuguese) some days ago,
because I have some friends that would like to program but
didn't know anything about it. I wrote only the first chapter
and the very beggining of the second one. If someone wants to
see it, tell me and I will try to translate it. The chapter
I've already written is about the programming basics (loops,
variables, routines etc.), not about Euphoria itself. I gave
some silly examples about how a "cook-computer" could be
programmed to boil an egg, to peel (is this the right word?)
five potatoes and so on.
In fact, I think it wouldn't come out very good anyway, so
maybe when the new one is ready I will simply translate it
into Portuguese.
____________________________________________________________________
Get free e-mail and a permanent address at http://www.amexmail.com/?A=3D1=
11. Re: The tutorial
Just in case anyone is interested:
I started writing a tutorial (in Portuguese) some days ago,
because I have some friends that would like to program but
didn't know anything about it. I wrote only the first chapter
and the very beggining of the second one. If someone wants to
see it, tell me and I will try to translate it. The chapter
I've already written is about the programming basics (loops,
variables, routines etc.), not about Euphoria itself. I gave
some silly examples about how a "cook-computer" could be
programmed to boil an egg, to peel (is this the right word?)
five potatoes and so on.
In fact, I think it wouldn't come out very good anyway, so
maybe when the new one is ready I will simply translate it
into Portuguese.
Regards,
Davi Figueiredo
davitf at usa.net
____________________________________________________________________
Get free e-mail and a permanent address at http://www.amexmail.com/?A=3D1=
12. Re: The tutorial
>The target audience would be two groups:
>
>1) People who never programmed before
>2) People who programmed before but not in Euphoria.
>
May I suggest an oranizational "dividing line" between type 1 & type 2 (ie:
Chapter 1 -- "If you already know a programming language (such as Basic or
Pascal etc) you may wish to skip to Chapter 2 now.").
Also, as to overall design of the tutorial. I am personally fond of a "build
a project" approach, where each chapter explores new concepts & features of
the language and applies them to a master project such as a simple database
or editor. Not knowing a whole lot of Euphoria I do not know if this would
be good in this case.
Q
13. Re: The tutorial
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.
14. Re: The tutorial
Bad name idea... "Beginner's Teuphorial"
I just couldn't resist (^8
15. Re: The tutorial
>Once again I must stress not everyone can learn in that fashion. RDS has
>written an excellent manual, but it does not explain what a variable is for
>example, or a byte, or how memory works. Those concepts are important in
>order to use the library routines. Also, I've never considered trying to
>reach the beginner a "wrong" perspective. In fact, I've always felt that
the
>teaching of programming should include the general public and not just the
>hardcore programming clique. There's always a first time for everyone. If
>that were not the case, those yellow "Big Dummy's Guide
>To"...whatever...would not be so successful. Even a language like C,
usually
>the domain of the experienced programmer, is now covered for the newcomer,
>even though there are reference manuals for the C language right beside
>those books.
Thats my whole point! It is why, i stress the fact that we should *not*
explain all tricks of Euphoria (yet anyway).
Rather than redoing the documentation, and explain all stuff euphoria can
do, teach them what programming in general is about: (thus: what a variably
is, how memory works, *those* things) If they know that RDS documentation is
great for looking things up. My point is like the documentation, the
techniques of programming are not so hardware and/or OS related. In the end
it all comes down onto designing an algorithm. And I do want to cover Win32
api, and such specific things. But the win32 should not be 'taught'. The
audiance should receive that 'perspective' they need, to understand a
technical document. And we should include such technical documents. We
should *not* (IMHO) convert the win32 api into something very beginner
friendly, but useless thing. They alreadt did this with GUI's: Windows 95
and whee what a perfect choice it was. (financially maybe
>Your idea of presenting the tutorial as a story I do like. It makes the
>learning process interesting. We would have to make the story so that it
>does not come across as corny. The target audience age must be defined
>clearly for the story to be successful without coming across as immature or
>too sophisticated.
Well, story is a big word. Some character that introduces itself once.
And has a 10 to 15 line 'event' where something happens, (some question pops
up), afterwhich it is applied upon *real* programming, and ends with a lot
of example code, terminology listing of words already used so much they
should be familiar by now, and some strict definitions for the terminology.
And for each trivial programming technique we teach, such a short event
story (with hopefully many funny remarks: we need some one extremely funny..
I cant even make a clown smile ;-( ) I want to each general concepts.
Esspecially for those with no or little programming experience.
No offense to anyone, but there is no such thing, as a programming that
needs more than RDS gives us. We should just teach beginners to become
programmers. Im not saying some one is or is not a programmer. I just mean,
if RDS documentation isnt enough, we need to teach 'theory' (what
programming is about) rather than 'implementation' (which routines, etc.)
The guide I want to write, should be useless to any real software engineer.
Why ? Because they need nothing more than RDS' documenation)
Ralf
16. Re: The tutorial
>May I suggest an oranizational "dividing line" between type 1 & type 2 (ie:
>Chapter 1 -- "If you already know a programming language (such as Basic or
>Pascal etc) you may wish to skip to Chapter 2 now.").
No offense, but when the RDS documentation is not clear enough for you, you
know too little of programming, and need the first chapter anyway. If the
switching over causes so-much confusing, etc. that the person would benefit
alot of a tutorial, then the person is question knew Basic or Pascal (your
example languages), however, he/she did not know how to program.
Im not saying I did. (hell, I was 14, I think, when I discovered Euphoria)
But even for me, RDS documentation, some questions on the list & some
example programs were enough. Not even being in my native tongue.
I dont want to insult people here. But many hobbist and also professional
programmers, are trained in a certain language, rather than in programming
itself.
>Also, as to overall design of the tutorial. I am personally fond of a
"build
>a project" approach, where each chapter explores new concepts & features of
>the language and applies them to a master project such as a simple database
>or editor. Not knowing a whole lot of Euphoria I do not know if this would
>be good in this case.
I like the big project idea, however, if you do not fully understand any of
the parts, your complete project fails. We should also try not to shape the
structure of the tutorial to the project. However, Many routines and
techniques that you create during the tutorial, can all come together at the
end of the tutorial into one big project. That would work.
Ralf Nieuwenhuijsen
nieuwen at xs4all.nl
17. Re: The tutorial
>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.
The tutorial that I hate are the ones, that at the end of some project, list
20 routines that belong to that chapter. For example: 20 I/O routines, their
describtion, etc. I could never remember that all. And a tutorial is
something you read through. You dont look things up in a tutorial.
*Which* routines to use, can be pointed out by the tutorial, but how to use
them: see library.doc / library.htm or just press F1 in David Editor when
the cursor is below the routine call.
(maybe we should 'patch' some windows editor, to also have F1 help-support
and optionally the tutorial in a side-ways, or below-ways panel)
>>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.
Oh, yes ONE version, Indeed.
However, to explain every concept on multiple ways, is no loss.
For every 'essential concept' they need to know (which is unrelated to a
programming language and OS/hardware) we could have an optionally
introduction part (the sketch/story), an reference page (with short
definiitons of the terms used, example programs associated, etc.), etc.
>>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>.
Yes, that is more or less what I have in mind. However, I will use 'items'
in that story for anologies.
Did any of you read the book 'Zen and the Art of motorcycle .. ' .. ive read
the Dutch translation.
Its a really philosophical book, but you can maintain grip at what he says,
because he is constantly applying it on the people around him, making
analogies with elements of the story behind the book. (of a guy crossing
around on a motorcycle with his son)
>> 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
What to do ? Hmm, well, actually the computer has to make decisions.
I would rather say, Telling a computer how to think using terms it
understands.
>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.
There are programming language that are not instruction-based.
Languages were you can define rules that must constantly be applied.
Then the above definition would not work. We need a less-specific
definition thus.
I am glad your mentioned the basic model of every program. I was looking
for it in Daniel's ToC.
Input >> Interpretating that input >> Proccesing (making decisions based
upon that input) >> Preparing Output >> Output
The second and the fourth are not so conventional as the other three,
but I feel they are important as well.
For every program, there is an amount of 'interpretation' of the input,
after which it is in such a form we can base decisions on them.
Then we 'prepare' the output. We convert what we have in such a form
that we can output.
Most of this interpretation & preperation is nowadays done through
devices in windows and often hardware support is available.
(a videocard: preperation of output)
>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.
Not every issue. Thats the whole point of a computer. Rather than
looking up an respond for every issue and or every input, it can make a
decision based upon input, and the choose/calculate/format its output.
Ralf Nieuwenhuijsen
nieuwen at xs4all.nl
18. Re: The tutorial
At 08:26 a.m. 28-01-99 +0100, you wrote:
>No offense to anyone, but there is no such thing, as a programming that
>needs more than RDS gives us. We should just teach beginners to become
>programmers. Im not saying some one is or is not a programmer. I just mean,
>if RDS documentation isnt enough, we need to teach 'theory' (what
>programming is about) rather than 'implementation' (which routines, etc.)
>
>The guide I want to write, should be useless to any real software engineer.
>Why ? Because they need nothing more than RDS' documenation)
At first I thought your vision of the tutorial was far more complete than
mine, but
I'm realizing it's the opposite Ralf. Let me explain my self:
I agree that "learn to think like the computer" is quite difficult for most
people
(many of classmates take almost a year to fully understand how a pseudo-code
algorithm works!). There are some of us that had been in touch with compute
from early days (I started at 12, Sinclair ZX-81) and during the years
have some
king of simbiotic relationship with chips ;)
Rather than seeing a tutorial I see a book to master programming using the
Euphoria programming language. Perhaps some day O'Reilly publish it with
some strange animal on the cover... an Alien probably on 2050 :)
A good, solid and understandable introduction *is* a must on our (the Euphoria
community) proyect. I believe that's your point Ralf. But that's not all.
RDS documentation clearly describes the language and the RT library. But
dominating a programming language requires a learning curve. The tutorial goal
IMHO should be to reduce this learning curve as much as possible. RDS gives
the tool intructions, we can provide our empirical experience. Have you
seen how
many Windows API books are out there? The WinAPI documentation is freely
available... so why people buy those books?
This proyect should be divided in self-contained content specific sections
(reminds
me of the TOC ;) developed by different (but colaborative) groups. You'll do a
great job on the "Programming 101" section (and others). I may help with Win32
(do you join David? Ad?).
I can think now of these sections:
a) Programming fundamental (Ralf?)
b) The Euphoria programming language (RDS, ABTE?)
c) High performace with Euphoria (Michael "Speed Demon" Bolin still alive?)
d) Graphics programming in Euphoria (Neil creator (Pete I think)?)
e) Client/Server programming (Jesus Consuegra?)
d) Windows programming (David? Ad? me?)
e) Glue all the aboves together (?)
To the Euphoria community: cooperate with the area you're more familar or
fluent.
In spanish there's a saying: "Panadero a tus pasteles" (look a dictionary).
Let's see what can we do!
Regards,
Daniel Berstein
daber at pair.com
19. Re: The tutorial
Daniel Berstein wrote:
>I may help with Win32
> (do you join David? Ad?).
Well, I can write down my own experiences and frustrations trying to pr=
ogram in Win32, but don't consider me to be a guru. Far from that. Mayb=
e I'm not a good programmer at all.
I mean, my programming is mostly quick and dirty, I'm combining code an=
d tricks I've seen other people use, but there are a lot of concepts th=
at I don't grasp, till now.
I think I could use a lot of tutoring myself, by some one like Ralf, to=
break down bad programming habits, and build up good new ones.
Apart from that, I would like to be on a team trying to help other peop=
le to become good programmers. I hope to become good myself too, that w=
ay.
Thanks, Ad.
| Gratis e-mail en meer: http://www.dolfijn.nl/
| Een product van Ilse: http://www.ilse.nl/
