REBOL DOC for teaching - Some criteria I would like to share before applying
[1/15] from: gerardcote::sympatico::ca at: 25-Jan-2004 13:56
Hi List,
A couple of days ago, I again revisited my 3 official books about REBOL and each one
does a great job in is own way. And I really
think there is place for another "online" self-learning material about REBOL - some kind
of extensive tutorial . May be it will
simply complete what is already available but I would do a bit more in the sense of producing
some teaching material for school
usage.
The main problem I encountered in the past with many teaching or self-learning material
is often related with the targeted audience
vs the information level teachers and students were seeking for.
For the moment I think there is a need for beginner's material to fulfill and this is
the direction I choos to go with.
But when I say beginner I think to someone that is beginning to learn computer programming
and who would like to see what REBOL has
to offer in this way. May be someone too that is not too old - from 13 years old and
up seems like a great start base and I'll try
to do my best to keep in mind many fundamental things which are complementary to each
other :
- Material must be far from boring. Keeping it motivating is one of my prime objectives.
While some transparent interfacing is
required to let students use View features without having to grasp its complexity level.
For example:
if I permit the use of some LOGO like painting with View, there must be some way to let
the user's to interact with LOGO like
commands and never see the details involved under the cover.
- Examples must enforce the comprehension while kept aligned with sound learned concepts
while illustrating in parallel some well
established design-code-debug-test methodology - nothing more but this is no small task.
- There is always enough place left in the personal works for experimenting and understanding
the more advanced and stimulating
programming concepts - generally going with advanced language features and many other
external concepts to be acquired and mastered
too don't forget about it.
Finally I just reread some formal introductory material to CS which is related to many
current Programming languages including books
about formal language independant maths and algorithms design while others were based
on a specific language like BASIC, PASCAL,
VB, LOGO, JAVA, Lisp, SCHEME and C++.
I also found many excellent tutorials about CS and programming using Java, LOGO, Python
and Scheme (Dr.Scheme).
And today I found some text relating the interesting arguments that could help teachers
better sell REBOL as their candidate for
teaching CS to youngsters in schools. The complete text with its reference is enclosed
in the attached segment of the original text
that was of interest to me in this context.
If you want to comment this text as a basis to establish where REBOL fails in some way
to their arguments - for getting the best
adaptation of a teaching programming language feel free to discuss it here.
I'll also soon post here a first draft of my initial TOC and will require some comments
from you all to help enhance it before
starting for the real thing. I you have any small project you would think that could
be well adapted and fun to use as code example
in this tutorial - send it to me and I'll try to see where I can introduce it in the
pattern. Don't forget that most of the time I
plan to use the Core so examples have to be appropriate for this kind of UI. Later we'll
try to show how adapt some functional
scripts already using text UI to get them using a GUI instead.
Some planning is required but this seems feasible too since many of the simpler tasks
involving View are also really simple to go
with.
Until then I will also work an example at a time for most current dictionay Words to
begin with. The chosen order will be based on
my own needs for this tutorial. So it will work on both ends at a time since I will refer
to the illustrated by examples words from
this tutorial.
Many long evenings to come that are already filled in my head I think ...
Regards,
Gerard
-- Attached file included as plaintext by Ecartis --
-- File: 7-pas-vers-langage-ideal.txt
Seven Deadly Sins of Introductory Programming Language Design
Linda McIver & Damian Conway
Department of Computer Science
Monash University, Victoria, Australia
(The original paper can be found at :
http://www.csse.monash.edu.au/~damian/papers/PDF/SevenDeadlySins.pdf)
======================================================================
TOC Section 1 Seven Deadly Sins
Section 2 Seven Steps Towards More "Teachable" Languages
======================================================================
Section 1 Seven Deadly Sins (See the original article for details
---------------------------- of this first section)
1. Less is more.
2. More is more.
3. Grammatical traps.
4. Hardware dependence.
5. Backwards Compatibility.
6. Excessive Cleverness.
7. Violation of Expectations.
Section 2 Seven Steps Towards More "Teachable" Languages
---------------------------------------------------------
1. Start where the novice is.
=============================
A fundamental aspect of learning is the process of assimilating
new concepts into an existing cognitive structure
[19,20,21]. This process, known variously as connecting,
accretion or subsumption, is made all the more difficult if
parts of the existing structure have to be removed
(unlearning) or restricted (exceptions).
Hence, the novice who must unlearn that x or . means multiply,
and then substitute * in a programming context, faces a harder learning
task than the student who can continue to put their knowledge
of x to use.
Similarly, students have a large corpus of
knowledge regarding integer and real arithmetic, which
cannot be capitalised upon if they must disregard it to cope
with finite precision representations.
Another example of this type of difficulty is the use of
= variants for assignment.
Many students, when confronted with this operator, become
confused as to the nature of assignment and its relationship
to equality.
For example, seeing the following sequence of statements :
X = 3;
Y = X;
Y = 7;
novice students sometimes expect the value of X to be equal
to 7 (since "Y and X are equal").
The equivalent sequence:
X <- 3;
Y = X;
Y <- 7;
seems to evoke less confusion, possibly because the syntax
reinforces the notion of procedural transfer of value, rather
than transitive equality of value.
We have shown over one thousand novice programming
students the C/C++ expression:
the quick brown fox
+ "jumps over a lazy dog"
and asked them what they believe the effect of the + sign is.
Not one of them has ever suggested that the + sign is illegally
attempting to add the address of the locations of the
first characters of the two literal strings.
Without exception, they believed that the + should concatenate
the two strings.
We believe that introductory languages should be designed
so that reasonable assumptions based on prior nonprogramming-
based knowledge remain reasonable assumptions
in the programming domain.
In other words, the constructs of a teaching language should
not violate student expectations.
Note that this principle has both syntactic and
semantic implications in the selection and definition of operators,
functions and inbuilt data types.
2. Differentiate semantics with syntax.
=======================================
Novices experience great difficulty in building clear and
well-defined mental models of the various components of a
programming language.
Syntactic cues can be of significant
assistance in differentiating the semantics of different constructs.
Constructs which may, to the accomplished programmer,
seem naturally similar or analogous in concept, functionality,
or implementation (for example: using the integer
subset {0,1} as a substitute for a true boolean type, arrays
being analogous to discrete functions of finite domain and
range, arrays being implemented via pointers) still need to
be clearly syntactically differentiated for the novice.
We believe it is misguided to highlight the similarities
between such constructs with similar (or worse, identical)
syntaxes, because it initially blurs the crucial differences by
which students can first discriminate between programming
concepts, and later robs them of the opportunity to consolidate
understanding by identifying these underlying conceptual
connections themselves.
3. Make the syntax readable and consistent.
===========================================
Novice programmers, like all novices, have a weak
grasp of the "signal" of a new concept and are particularly
susceptible to noise.
This suggests that an introductory programming
language should aim to boost the conceptual signal
and reduce the syntactic noise.
One obvious means of improving the S/N ratio is to choose
a signal with which the recipient is already familiar.
For example its is preferable to use :
if rather than cond,
head/tail rather than car/cdr,
x rather than *.
Another approach is to select signals which are consistent,
distinct, and predictable.
For example, delineating code blocks within constructs
by <name>...end<name> pairs:
loop
if isValid(name)
exit loop
end if
output name
name <- getNextName()
end loop
It can be difficult to steer an appropriate path between
the syntactic extremities of "less-is-more" and "more-ismore".
On one hand, reducing syntactic noise might involve
minimizing the overall syntax, for example:
if x != y
y <- x
else
x <- y
rather than
if (x <> y) {
y:=x;
}else{
x:=y;
}
Alternatively, it may be better to increase the complexity
of the syntax in order to reduce homonyms which blur
the signal.
For example, the meaning of the various components
of the Turing expression (*7):
f(C(p).A(I))(N)
might be better conveyed with the syntax:
f(C::p->AI)[N]
The second form, whilst regrettably no more mnemonic
than the first, does at least provide adequate visual differentiation
between pointer dereference, array indexing, function
call, and substring extraction.
4. Provide a small and orthogonal set of features.
==================================================
Homonyms and synonyms are an acute problem in the
design of a teaching language.
We believe the best way to
minimize these pedagogical impediments is to select a
small set of non-overlapping language features and assign
them distinct (and mnemonic) syntactic representations.
A side effect of this recommendation is that, as the
number of language constructs is restricted, those which are
chosen must inevitably become more general and probably
more powerful.
In particular, we believe that it is important
to provide basic data types at a high level of abstraction,
with semantics which mirror as closely as possible the
real-world
concepts those data types represent.
For example, we would suggest that an introductory language
should not provide separate data types for a single
character and a character string.
Rather, there should be a single "variable length string" type,
with individual characters being represented by strings
containing a single letter.
A full complement of string operators should be supplied,
with operators for assignment, concatenation, substring extraction,
comparison, and input/output.
In addition, a set of
suitable inbuilt functions (or predicates or methods, according
to the language's paradigm) should be provided to implement
other common operations for which operators may
be inappropriate (for example: length of string, case transformations,
substring membership, etc).
As character strings
may be strictly ordered, the string type should be a valid indexing
type for case statements and user defined arrays.
Likewise, we suggest that an introductory language need
only provide a single numeric data type which stores rational
numbers with arbitrary precision integer numerators and
denominators.
The restriction to rationals still allows the
educator to discuss the general issue of representational limitations
(such as the necessary approximation of common
transfinite numbers such as PI and e), but eliminates several
large classes of common student error which are caused by
misapplication of prior mathematical understanding to fixed
precision arithmetic.
A single arbitrary precision numeric
type has the additional benefit of eliminating many hardware
dependence problems.
Other features which might be provided include:
.. A single non-terminating loop construct, possibly
modelled on the Turing or Eiffel loop statement,
with an associated exit loop command which may
be controlled by if statements within the loop.
.. A single generic list meta-type, allowing the user to
define homogeneous or heterogeneous lists, indexed
by any well-ordered type (numeric, boolean, string).
.. A single, consistent model and syntax for I/O.
5. Be especially careful with I/O.
==================================
With growing awareness of the importance of software
usability, it is natural that students should be encouraged to
engineer the input and output of their programs carefully.
Too often, however, they are hampered by "more-is-more"
programming language I/O mechanisms which are needlessly
ornate or complicated.
The essence of I/O is very simple: send a suitable representation
of a value to a device.
The complexity frequently
observed in the I/O mechanisms of introductory languages
often stems from a desire to provide too much control over
the value conversion process.
Somewhat surprisingly, the C++ language, not otherwise
known for its friendliness towards the novice (*8), provides
a reasonable (if over-featured) model of I/O.
Turing also offers a very straightforward I/O model and syntax.
We believe that the I/O mechanism for an introductory
language should be defined at the same high level of abstraction
as the other language constructs.
We see the basic features of a good pedagogical I/O model as being:
.. a simple character stream I/O abstraction, with specific
streams (for screen, keyboard, and files) represented
by variables of special inbuilt types.
.. uniform input and output syntaxes for all data types
(for example, infix "input" and "output" operators
which may be applied between a stream object and a
heterogeneous list of values and/or references)
.. a default idempotent9 I/O format for all data types
(including character strings and user defined types),
with appropriate formatting defaults for justification,
output field width, numerical precision, etc.
.. a reasonable, automatically-deduced output format for
user-defined data types (for example, output each
globally accessible data member of a user-defined
ADT, one value per line)
.. a simple and explicit syntax for specifying non-default
output formatting (for example: a generic
leftjustify function to convert any value to a
left-justified character string of specified field width.)
6. Provide better error diagnosis.
==================================
There is a widely cherished belief amongst educators
that one of the ways students learn best is by making their
own mistakes.
What is often neglected is that this mode of
learning is only effective if a student's otherwise random
walk through the problem space can be guided by prompt,
accurate, and comprehensible feedback on their errors.
Making and correcting an error is certainly a useful experience
for expert and beginner alike, but the process of
correction can be tortuous without meaningful guidance.
Compiler error messages are often couched in unnecessarily
terse and technical jargon which serves only to confuse and
distress the student.
By the time the messages have been deciphered and explained
by a teacher or tutor, any useful feedback which may have
been gained has been largely negated by the delay and stress involved.
The type of feedback that students receive when compiling
their programs typically runs along the lines of:
- Syntax error near line 4
- Not implemented: & of - No subexpression in procedure call
- Application of non-procedure "proc"
Even should they manage to compile their program, run
time errors typically produce useful feedback like:
- Segmentation violation: core dumped
- Application "unknown" exited (error code 1)
- <<function>>
Error diagnosis is a weak point of most compiler technology,
yet it is this compiler feature that novices spend
most of their time interacting with.
Whilst well-designed error feedback is not unknown (Turing
is exemplary in this respect) many language implementations,
particularly interpreters, have little or no error diagnosis.
In these cases, errors are detected when the program executes
in some unexpected way.
Detecting and correcting errors in these implementations
can be extremely difficult, particularly for a beginner,
who may be uncertain what the expected behaviour
of the program actually was.
For an introductory language, error messages should be
issued in plain language, not technical jargon.
They should reflect the syntactic or semantic error that was
discovered, rather than the behaviour of the parser.
Error diagnosis must be highly reliable or, where this is
infeasible, error messages must be suitably non-committal.
For example, given the statement:
int F(X);
// WHERE X IS AN UNDECLARED TYPE
a widely-used C++ compiler emits the error message:
')' expected
rather than explaining that:
An unknown type 'X' was used in the
parameter list of function 'F'.
In this case even a vague message like:
There seems to be a problem with the
parameter list of function 'F'.
would be of more use.
We suggest that a fully-specified error reporting mechanism
should be an integral part of any introductory programming
language definition.
Such a mechanism must mandate plain language error messages
and should ideally provide multiple levels of detail in error
messages (possibly through a "tell-me-more" option).
Common compilation errors (such as omitted end-of-statement
markers or mismatched brackets) should be accurately diagnosed
and clearly reported.
Cases where the root cause of an error is not easily established
should be reported as problems of uncertain origin, with one or
more suggested causes offered in suitably non-committal language.
Run-time errors should likewise be clearly and accurately
reported, at the highest possible level of abstraction.
It is sufficient for the expert to be informed that a segmentation
fault has occurred, but the novice needs a hint as to
whether the event was caused by an array bounds violation,
an invalid pointer dereference, an allocation failure, or
something else entirely.
7. Choose a suitable level of abstraction.
==========================================
When first introduced to programming, students often
have trouble finding the correct level of abstraction for
writing algorithms.
Some expect a very high level of understanding
from the computer, to the extent of assuming that
variable names will affect the semantics of the program (for
example, believing that naming a function max is sufficient
to ensure that it computes the maximum value of its arguments).
Others attempt to code everything, including basic
control structures, from scratch.
To require algorithms to be coded in languages with extreme
levels of abstraction (for example: high-end logic, functional
or pure object-oriented languages, or low-level assembler)
merely compounds the students' already abundant confusion.
It is critical for an introductory language to approximate
closely the abstraction level of the problem domain in
which beginners typically find themselves working.
Hence it is appropriate to provide language constructs suitable for
dealing with basic numerical computing, data storage and
retrieval, sorting and searching, etc.
For most introductory courses, language features which support
very low-level programming (for example: direct bit-manipulation of
memory) or very high-level techniques (such as continuations)
will merely serve to stretch the syntax and semantics
of the language beyond the novice's grasp.
Seven Criteria for Choosing an Introductory Language
====================================================
Each of the preceding design principles also provides a
criterion against which to evaluate the suitability of existing
programming languages for introductory teaching.
We would suggest that when evaluating a potential teaching
language, in addition to addressing the usual considerations
(such as language paradigm, compiler availability, textbook
quality, establishment and maintenance costs, popularity,
etc.), educators should also bear in mind the seven "sins"
we have enumerated.
The key questions are:
.. Is the syntax of the language excessively complex
(and therefore lexically "noisy") or too sparse (and
therefore insufficiently discriminating)? Are there
syntactic homonyms, synonyms or elisions which
may confuse the novice?
.. Are the control structures, operators and inbuilt functions
of the language reasonably mnemonic? Are they
likely to be consistent with students' previous
(mathematical) experience? How much "unlearning"
will they require of the novice?
.. Are the semantics of the language inconsistent, obscure,
or unnecessarily complicated? Are there constructs
whose invocation, behaviour or side-effects
are likely to confuse a student or violate novices' reasonable
expectations?
.. Are the error diagnostics clear and meaningful at a
novice's level of understanding? Are they unambiguous,
detailed and not overly technical? Are they accurate
where possible and non-committal otherwise?
.. Are parts of the language subject to unnecessary
hardware dependencies or implementation-related
constraints? Will necessary restrictions be difficult to
explain to the novice?
.. Is the language too big (over-featured) or too small
(restrictive)? Is the level of abstraction of the language
constructs appropriate for the practical components
of the course?
.. Are the apparent virtues of the language equally "apparent"
from the novice's perspective? Alternatively,
are they a product of the educator's familiarity with
the candidate language or with the languages which
were the candidate's genetic and memetic influences?
In the real world it is clear that the choice of any one
language must necessarily be a compromise between economic,
political and pedagogical factors.
The relative importance of each of these considerations will
depend on the specific aims and priorities of the institution,
educator and course.
Unfortunately, all too often pedagogical factors are
neglected, or sacrificed to more obvious and prosaic concerns.
We believe that this approach undermines the ultimate
goal of successful student learning.
Conclusion
==========
We have enumerated seven ways in which introductory
programming languages conspire to hinder the teaching of
introductory programming and have also suggested seven
principles of programming language design which may help
to reduce those hindrances.
We do not suggest that either list is exhaustive, nor that
the principles we expound are definitive or universally applicable.
The design of any programming language is an art, and the design
of a language whose purpose is to teach the fundamental
concepts of programming itself is high art indeed.
Just as no battle plan survives contact with the enemy,
no pedagogical language design (no matter how sound its
design principles or clever their realization) can hope to
survive contact with real students.
Yet the outcomes of such encounters are the only meaningful measure
of the success of an introductory language.
This implies that the most important tool for pedagogical programming
language design is usability testing, and that genuinely teachable
programming languages must evolve through prototyping rather
than springing fully-formed from the mind of the language
designer.
NOTES
=====
7 "Create a substring consisting of the Nth letter of the string returned by
the function f when passed the Ith element of the array member A of the
object within collection C which is pointed to by p".
8 or indeed towards the expert!
9 Idempotence of I/O means that outputting the value of a variable and
then reading that output value back into the same variable has no discernable
overall effect.
String I/O is non-idempotent in most programming languages, because strings
are typically written out in their full length, but read in word-by-word
(ie: to the first white-space character).
References
==========
[1] Wirth, N.
and Jensen, K.
Pascal User Manual and
Report, Springer-Verlag, 1975.
[2] Holt, R.C.
and Hume, J.N.P., Introduction to
Computer Science using the Turing Programming
Language, Prentice-Hall,1984.
[3] Geurts, L., Meertens, L.
and Pemberton, S., ABC
Programmer's Handbook, Prentice Hall, 1990.
[4] Kernighan, B.
and Ritchie, D., The C Programming
Language, 2nd ed., Prentice-Hall, 1988.
[5] Stroustrup, B., The C++ Progarmming Language,
2nd ed., Addison Wesley, 1991.
[6] Barnes, J.G.P., Programming in Ada, Addison-
Wesley, 1994.
[7] Harbison, S., Modula 3, Prentice Hall, 1992.
[8] Hudak, P.
and Fasel, J.H., A Gentle Introduction to
Haskell, SIGPLAN Notices, 27(5), May 1992, ACM
[9] Springer, G.
and Friedman, D.P., Scheme and the Art
of Programming, The Massachusetts Institute of
Technology, 1989.
[10] Feuer, A.
and Gehani, N., Comparing and Assessing
Programming Languages: Ada, C, and Pascal,
Prentice-Hall, 1984.
[11] Conway, D.M., Criteria and Consideration in the
Selection of a First Programming Language,
Technical Report 93/192, Computer Science
Department, Monash University.
[12] Koelling, M., Koch, B., Rosenberg, J., Requirements
for a First Year Object-Oriented Teaching Language,
Techical Report 94/488, Computer Science
Department, Sydney University.
[13] Mody, R.P., C in Education and Software
Engineering, SIGCSE Bulletin, 23(3), 1991.
[14] Wilensky, R., LISPcraft, Norton, 1984.
[15] Hofstadter, D., Godel, Escher, Bach: an Eternal
Golden Braid, Part II, Chapter 10: "Similar Levels",
Basic Books, 1979.
[16] Stroustrup, B., The Design and Evolution of C++,
Addison-Wesley, 1994.
[17] Holt, R.C., Matthews, P.A., Rosselet, J.A., Cordy,J.R.,
The Turing Programming Language: Design and
Definition, Prentice Hall, 1988.
[18] Clocksin, W.F.
and Mellish, C.S, Programming in
Prolog, Springer-Verlag, 1981.
[19] Thorndike, E.., The Fundamentals of Learning, New
York: Teachers College Press, 1932.
[20] Ausubel, D., The Psychology of Meaningful Verbal
Learning, Grune & Stratton, 1963.
[21] Rumelhart, D.
and Norman, D., Accretion, tuning and
restructuring: Three modes of learning, In.
W.
Cotton,
J.and Klatzky, R.
(eds.), "Semantic Factors in
Cognition", Erlbaum, 1978.
-- Binary/unsupported file stripped by Ecartis --
-- Type: application/pdf
-- File: SevenDeadlySins.pdf
[2/15] from: tim:johnsons-web at: 25-Jan-2004 14:16
* Gerard Cote <[gerardcote--sympatico--ca]> [040125 10:15]:
> I also found many excellent tutorials about CS and programming using Java, LOGO, Python
and Scheme (Dr.Scheme).
>
> And today I found some text relating the interesting arguments that could help teachers
better sell REBOL as their candidate for
> teaching CS to youngsters in schools. The complete text with its reference is enclosed
in the attached segment of the original text
> that was of interest to me in this context.
As an aside: The school district in this part of Alaska has been
teaching rebol as an intro to programming since 2001, when I designed
the course for them. On of the things that we looked at was TclTutor.
I have a copy of it. Looks like the markup approach to the lesson
files would be pretty easy to adapt to use Tcl to create a RebolTutor.
And it follows from that, it wouldn't be hard for someone familiar
with /View to create a /View RebolTutor. Could be a rebol seller.
tim
--
Tim Johnson <[tim--johnsons-web--com]>
http://www.alaska-internet-solutions.com<
[3/15] from: apwing:zonnet:nl at: 26-Jan-2004 13:23
Hi Gerard,
indeed I agree that good learning material is essential.
A short time ago I had to learn Microsoft Excel. I got hold of a few books,
but none of them really was what I liked.
So, then I came across a CD containing Excel tutorials, a lot of them being
video fragments, accompanied by somebodies voice, who told essential things
while just pointing, clicking and entering stuff on the keyboard.
Now, my experience is that you can learn a lot in a minimum amount of time
this way. It works better than executing "commands" on a one by one basis
from a book, since in the video tutorial one can see what is being done.
Currently I am experimenting with a software package (shareware) called
Hypercam ( http://www.hyperionics.com/ ). It is free to try and is very
promising!
Perhaps it is possible to write a "script" (like a film script) telling what
the tutorial should teach. Having written the script it is then easy enough
to build an AVI movie which clearly shows the steps one by one. It is even
possible to use Powerpoint to show the steps in clear text in a corner of
the screen as well.
If people in this list tend to agree with me on this, I am willing to put
some effort into it. Perhaps other (more experienced) people can write
Tutorial Scripts
and again other people (like me) then create AVI movies
from it.
Hope this may be of any help to us all.
Attached to this e-mail you will find a very easy example of what can be
done with the package.
Because of the size it is a ZIPped AVI file.
NOTE: since I am still trying out I use an unregistered version of
Hypercam!!!
Kind regards,
Arie van Wingerden
----- Original Message -----
From: "Gerard Cote" <[gerardcote--sympatico--ca]>
Cc: <[rebol-list--rebol--com]>
Sent: Sunday, January 25, 2004 7:56 PM
Subject: [REBOL] REBOL DOC for teaching - Some criteria I would like to
share before applying
> Hi List,
>
> A couple of days ago, I again revisited my 3 official books about REBOL
and each one does a great job in is own way. And I really
> think there is place for another "online" self-learning material about
REBOL - some kind of extensive tutorial . May be it will
> simply complete what is already available but I would do a bit more in the
sense of producing some teaching material for school
> usage.
>
> The main problem I encountered in the past with many teaching or
self-learning material is often related with the targeted audience
> vs the information level teachers and students were seeking for.
>
> For the moment I think there is a need for beginner's material to fulfill
and this is the direction I choos to go with.
> But when I say beginner I think to someone that is beginning to learn
computer programming and who would like to see what REBOL has
> to offer in this way. May be someone too that is not too old - from 13
years old and up seems like a great start base and I'll try
> to do my best to keep in mind many fundamental things which are
complementary to each other :
> - Material must be far from boring. Keeping it motivating is one of my
prime objectives. While some transparent interfacing is
> required to let students use View features without having to grasp its
complexity level. For example:
> if I permit the use of some LOGO like painting with View, there must be
some way to let the user's to interact with LOGO like
> commands and never see the details involved under the cover.
>
> - Examples must enforce the comprehension while kept aligned with sound
learned concepts while illustrating in parallel some well
> established design-code-debug-test methodology - nothing more but this is
no small task.
> - There is always enough place left in the personal works for
experimenting and understanding the more advanced and stimulating
> programming concepts - generally going with advanced language features and
many other external concepts to be acquired and mastered
> too don't forget about it.
>
> Finally I just reread some formal introductory material to CS which is
related to many current Programming languages including books
> about formal language independant maths and algorithms design while others
were based on a specific language like BASIC, PASCAL,
> VB, LOGO, JAVA, Lisp, SCHEME and C++.
>
> I also found many excellent tutorials about CS and programming using Java,
LOGO, Python and Scheme (Dr.Scheme).
> And today I found some text relating the interesting arguments that could
help teachers better sell REBOL as their candidate for
> teaching CS to youngsters in schools. The complete text with its reference
is enclosed in the attached segment of the original text
> that was of interest to me in this context.
>
> If you want to comment this text as a basis to establish where REBOL fails
in some way to their arguments - for getting the best
> adaptation of a teaching programming language feel free to discuss it
here.
> I'll also soon post here a first draft of my initial TOC and will require
some comments from you all to help enhance it before
> starting for the real thing. I you have any small project you would think
that could be well adapted and fun to use as code example
> in this tutorial - send it to me and I'll try to see where I can introduce
it in the pattern. Don't forget that most of the time I
> plan to use the Core so examples have to be appropriate for this kind of
UI. Later we'll try to show how adapt some functional
> scripts already using text UI to get them using a GUI instead.
>
> Some planning is required but this seems feasible too since many of the
simpler tasks involving View are also really simple to go
> with.
>
> Until then I will also work an example at a time for most current
dictionay Words to begin with. The chosen order will be based on
> my own needs for this tutorial. So it will work on both ends at a time
since I will refer to the illustrated by examples words from
> this tutorial.
> Many long evenings to come that are already filled in my head I think ...
<<quoted lines omitted: 430>>
> >
> 7 "Create a substring consisting of the Nth letter of the string returned
by
> the function f when passed the Ith element of the array member A of the
> object within collection C which is pointed to by p".
>
> 8 or indeed towards the expert!
>
> 9 Idempotence of I/O means that outputting the value of a variable and
> then reading that output value back into the same variable has no
discernable
> overall effect.
>
> String I/O is non-idempotent in most programming languages, because
strings
> are typically written out in their full length, but read in word-by-word
> (ie: to the first white-space character).
<<quoted lines omitted: 69>>
> To unsubscribe from this list, just send an email to
> [rebol-request--rebol--com] with unsubscribe as the subject.
-- Binary/unsupported file stripped by Ecartis --
-- Type: application/x-zip-compressed
-- File: rebol0008.zip
[4/15] from: apwing:zonnet:nl at: 26-Jan-2004 14:37
Hi guys,
as I see in the list the attachment in the previous post was stripped off.
If you're interested, let me know. I'll send it as a provate mail to you
then!
Grtz,
Arie
[5/15] from: greggirwin:mindspring at: 26-Jan-2004 9:28
Arie et al
Interactive, dynamic, tutorials can be great, I agree. I'd rather do
it with pure REBOL than AVI though. There are a few examples of people
doing this kind of "presentation" system in REBOL (Carl's presentation
app, EasyVID, Brett's "play app" that sends commands to other reblets,
etc.).
Keep those great ideas coming folks!
-- Gregg
[6/15] from: jason:cunliffe:verizon at: 26-Jan-2004 11:41
> Now, my experience is that you can learn a lot in a minimum amount of time
> this way. It works better than executing "commands" on a one by one basis
> from a book, since in the video tutorial one can see what is being done.
Great that you are interested in developing along these lines.
Over-the-shoulder video-type tutorials can be very helpful to many people.
Unfortunately video ..AVI files are huge and while DVD has opened this up
enormosly now, it does not solve video's very poor image handling of any
screenshots or typographics.
A valuable alternative is FlashCast - an editable screen capture and
annotation tool which generates Macromedia Flash .SWF format files.
http://www.multidmedia.com/software/flashcast/
Pros-- This results in much smaller file sizes, screen captures are which
very crisp and legible. In addition extra annotation including tutorial
voice-overs can be recorded and/or loaded. Further interactivity can be
added using additional Flash programming techniques and tools. FlashCast can
create standalone executables or can be embedded immediately in web pages.
Cons -- FlashCast itself is Windows only at this time, though the SWF output
is cross-platform [Win, Mac, Linux]. Also it is a commercial third party
app. The price seems pretty reasonable at $120 with no restrictions. [30 day
Free trial download available].
- Jason
[7/15] from: gerardcote:sympatico:ca at: 26-Jan-2004 19:27
Hi Jason, Gregg and Arie,
Thanks for your support. In fact I like the idea of getting some interactivity for viewing/demoing
using some animation but I also
agree with the fact that AVI are too weighty for the Job I plan.
I also - a couple of years ago when I began to look at /View - began to study the way
Carl did his presentation but I found the way
some figures were constructed is too much complicated for such a few gain. May be I will
reconsider a second try at this approach
since I would prefer to get anything done using REBOL.
However for the moment I began to structure my TOC and even wrote some preliminary text
- in French since I think a lot better in my
native language than I even write in English - using the Make-DOC-PRO format for getting
quick rendering of the output in a somewhat
interesting dressing. And all of this without much effort - thanks to Carl and Robert
for this.
Eventually I will get back and see if things have evolved but for the moment I plan to
stand firm on my position. When a sufficient
amount of material will have be written, tried and tested then I'll see for what is the
best tool to adopt for getting the tutorial
more attractive. In all cases it could not be worse than now - if I remember.
But I also remember of some nice product named ScreenCam that was signed by Lotus and
designed to run on old Windows machines. Since
I already got it in the past I will probably be able to get it reinstalled and try it
again just to see how much space it will
occupy.
In all cases, continue to explore, test and feed me with your ideas. Already we could
try each one on his side to drive some tests
running some small experiment in an interactive way so that we can show to the user some
kind of animation of all the execution
process - seen from the outside - with variable speed and possibility to stop too.
For example let's see if we could simulate - or let a real small app running - that can
be completely driven by the user ( in a
single direction for that time - forward only) and which would ask some input data (may
be a choice amongst many data options would
be nice too) and display some intermediate results (pre-planned by the creator) or at
least the final results. In fact it's almost
a symbolic debugger for straight programs, that is small programs that don't use too
much dynamic behaviour - to begin with.
And this could be driven by single mouse clicks or keyboard letters as the following
may be:
R - Run with almost normal speed in forward direction (From begin to end)
R/S - to single step - and the user would be abel to define what a step is - 1 or many
lines, a loop,
a breakpoint...
R/R - Run in reverse direction (Would be useful to SINGLE step backward, display intermediate
contents, enter corrections and restart forward or backward)
R/T - Run with another input data choice amongst suggested ones
(Don't forget that it's only canned for display - no real user interaction permitted)
R/I - Run with some internals displayed (Use the M command to indicate which Word(s)
to use for)
M - To mark what content is to be displayed when the run is stopped or when script
is exhausted.
May be we'll come to see a very surprising result at the end.
In fact when I came to REBOL it was precisely to be able to create this kind of tool
- using Parse and creating my own FRENCH
teaching language but for now I am far from my goal. At least it is fun and I learn a
lot of material not even from my REBOL related
readings but also from my exchange with you all. I must recognize that having no real
foundation in Computer Science other than my
readings I somewhat miss some parts of the advanced dialogs but I don't give up yet ...
now that my health really seems to feel
better ! I'm like a brand new Gerard reassembled from old pieces ;-)
Regards,
Gerard
[8/15] from: jason:cunliffe:verizon at: 26-Jan-2004 20:05
> However for the moment I began to structure my TOC and even wrote some
preliminary text - in French since I think a lot better in my
> native language than I even write in English - using the Make-DOC-PRO
format for getting quick rendering of the output in a somewhat
> interesting dressing. And all of this without much effort - thanks to Carl
and Robert for this.
Gerard that sounds like very sensible way to proceed..
With a foundation in rebol-friendly Make-Doc-Pro fomat there will still be
plenty opportunity to experiment later with fancier interactive options. If
you you need help with french-english translation I can help.
good luck
- Jason
[9/15] from: gerardcote:sympatico:ca at: 26-Jan-2004 23:55
Hi Jason,
You wrote:
> Gerard that sounds like very sensible way to proceed..
> With a foundation in rebol-friendly Make-Doc-Pro fomat there will still be
> plenty opportunity to experiment later with fancier interactive options. If
> you you need help with french-english translation I can help.
Your offer is really appreciated and as soon as possible I will send
you some texts to read, review and/or comment before we do anything else.
This way we'll not work for nothing if any major changes are required
following any welcomed suggestions that would be submitted.
Simply don't forget the audience that is targeted and the fact that
this first work doesn't stand as a complete Computer science course
but will look more like a gentle introduction to programming using
REBOL.
Later will come a more complete online course targeting at two objectives:
1- fill in many of the gaps noted in the actual doc.
2- Illustrate how CS concepts can be implemented using REBOL.
And for this second part many of the current library scripts could
and will be used as a basis for more elaborate analysis.
Thanks,
Gerard
[10/15] from: carl:cybercraft at: 27-Jan-2004 9:10
On 27-Jan-04, Gregg Irwin wrote:
> Arie et al
> Interactive, dynamic, tutorials can be great, I agree. I'd rather do
> it with pure REBOL than AVI though. There are a few examples of
> people doing this kind of "presentation" system in REBOL (Carl's
> presentation app, EasyVID, Brett's "play app" that sends commands to
> other reblets, etc.).
Maybe someone should write a tutorial dialect?
> Keep those great ideas coming folks!
> -- Gregg
--
Carl Read
[11/15] from: greggirwin:mindspring at: 27-Jan-2004 0:38
Hi Carl,
CR> Maybe someone should write a tutorial dialect?
Oooohhh...yeah. :)
-- Gregg
[12/15] from: didec:tiscali at: 27-Jan-2004 18:30
Re: REBOL DOC for teaching - Some criteria I would like to share before applying
Hi Gerard,
Just to comment that we, on the French forum, are making the same sort of analyse than
yours. We begin to think of the same sort of work.
As you are a french speaking people, May be you already knows about http://www.rebolfrance.org
, but I invite you and Jason C. to meet us on the french forum : http://www.codeur.org/forum/forum.php?theme=17
Perhaps we can join our efforts and work with each other on this task, and in french
as in english.
DideC
[13/15] from: jason:cunliffe:verizon at: 27-Jan-2004 13:26
> As you are a french speaking people, May be you already knows about
http://www.rebolfrance.org , but I invite you and Jason C. to meet us on the
french forum : http://www.codeur.org/forum/forum.php?theme=17
> Perhaps we can join our efforts and work with each other on this task, and
in french as in english.
Thanks DideC...
My reading and conversational French is ok, but my written skills are only
suitable for translating French into English. Anyway, see you on codeur.org
- Jason
[14/15] from: gerardcote:sympatico:ca at: 27-Jan-2004 18:31
Hi Didec,
You wrote:
> Just to comment that we, on the French forum, are making the same sort of analyse than
yours. We begin to think of the same sort
of work.
I recently went to your REBOLFRANCE web site and even read some threads from your Forum.
Simple but efficient way to post and
present the msgs. In fact your idea is welcome as I asked myself how I could start some
discussion about this subject with the goal
of getting some collaborators to help select, define et prepare the exercices themselves
that would serve to illustrate the many
concepts. this is generally what takes most of the time. For sure the explanation level
accompanying each script doesn't have to be
very deep but nevertheless there is a minimum we should state about. Remember that it
has to be adapted to newbies aged from 13 up
to say 17 or a bit more that don't know anything about programming or CS.
I also found some REBPAD script written by Fran=E7ois Jouen - an editor written entirely
with REBOL - that could serve us a a starting
base for illustrating some advanced /View particular features - later in the teaching
process - but the idea here is that we don't
have to reinvent the wheel. There is a lot of material here and then that just waits
to be discovered, chopped in pieces and
explained in small understandable fragments. Just this would be a useful add-on to our
library.
As an example, I found the Ropus.r script from Gabriele Santilli yesterday in the Library
ans since I was trying to find a way to
illustrate the Console use, I thought about using it. It took my old 2.3 Core version
before I went into a working version. The
newer ones (2.5) never did the job. After a couple of hours looking for what the trouble
is I was not able to precisely find it but
I suspect the way the keyboard buffer is impemented. I checked manually for the good
functioning of most output functions and all
worked using the virtual console Gabriele implemented. Finally when the product worked
on my 2.3 Core version I was no more advanced
since No DOC came with it, just a HELP MENU summarizing the meaning of each key. This
was not sufficient to me for a quick try. I
will have to dig again in the code to learn more about what each function and object
do and how they are interrelated to finally
hope to find how to use it and extract the routines I need to illustrate my keyboard
concepts.
This give you an idea of the job we must face to with this project. But this is interesting
and if we can coordinate split and
delegate well our many tasks, then may be we would leverage our man power to shrink the
required time. But don't forget I do this
first for my own fun while learning and second to be useful to others too.. So the time
limits must not be too restricting for me
since this is the year period where I just begin to go skiing after the big January and
sometimes February colds here in Quebec
City. ANd even worse my doctor will probbly send me back to work a bit a time for about
1 to 2 days each week very soon. So my time
will be more restricted during next few weeks but for now this is not a problem yet.
A lot of my friends would be very happy to
mimic me by now but ... ;-)
So when will we meet together for exchanging about the first ideas I already put on paper
? Later tonight I will see how I can
subscribe myself to the French Forum on REBOLFRANCE. See you then or at least I'll post
in some way for letting you to know that I'm
alive...
Thanks for your "sollicitude",
Gerard
[15/15] from: gerardcote:sympatico:ca at: 27-Jan-2004 18:44
Hi everybody,
> CR> Maybe someone should write a tutorial dialect?
>
> Oooohhh...yeah. :)
>
> -- Gregg
I agree but we could begin with some tools to easily draw some simple figures with text
or other figures applied as overhead
transparencies (layers) to illustrate and animate easily some concepts, draw hierarchical
diagrams and the like, all using REBOL.
That could give something more or less like the powerful tools created a long time ago
by Dan Bricklin, the author of Visicalc (the
first spreadsheet if I remember) and named DEMO-IT or its successor DEMO2. Later he did
the Web site innnovative creator products
Trellix and TrellixWeb.
But one thing at a time. If someone can put together the features of Layout-ed from Carl
with somew of its presentation demo
concepts refined a bit - from a current user perspective - and add some whistle and bells
around it - from the paint program amongst
many others - and wrapped with some dialect too we are on road ...
Who (and how many to support) is voluntary ? Sorry I'm not good enough for the moment
but I am voluntary to try and test the many
revisions if any ;-)
Regards,
Gerard
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted