Re: Beginner's Language?

[sb463ba@l1-hrz.uni-duisburg.de (Georg Bauhaus)]

Ola Rinta-Koski (ola@cyberell.com) wrote:

[Georg says:
 (let ((foo 0)) ...) may confuse beginners because of double parens]

:   And is there a rationale for this statement? Would it be better to
:   use brackets or curly brackets, so as not to use parentheses for
:   different purposes?

Every language has syntactical quirks, no doubt, I think this has
been said many times in this thread. In this case, using LET
involves several advanced concepts, or at least, it could,
for beginners. And as you have written, it is the teachers job
to explain them.

Now there are languages where variables spring into existence
when you name them. Good for beginners? Is scoping, besides
beeing required and good knowledge, an obstacle in some first
"Read five numbers" program? (Well, I don't think so,
_after_ some explanaitions about simpler language facilities.)

How many basic concepts do you need? Is this number relevant?
If so, to what? How difficult are they to remember syntax-wise?
From the little I know, most languages used will do, in combination
with good teachers and texts, so lets hope there are enough
good teachers :-) (I'm not a teacher, but in times, I teach
and can only say this is a hard job if you are seriously 
trying to explain basics, no matter what language is used.)

Some posts have shown up that give credits to verbosity,
so should the syntax be verbose as well? 

function square a number
 with argument num
 returning squared
is defined as
 squared becomes num * num
return

Well...
I have no chance to try this out, has someone some
experience with this issue? (if this is an issue, i.e.:-) 

So, yes:

:   No language, even one designed solely for the purpose of teaching,
:   will be completely self-explanatory for a neophyte. What remains to
:   be debated is the degree of help needed for the student to "get
:   it". I am not advocating (Common) Lisp as a first language per se; I
:   am merely stating that it would not automatically be a worse choice
:   than <pick-your-lingo>.


: > PS: What I find puzzling is the lack of an abundance of statements
: > from people who have actually taught several very different
: > languages...

:   On what basis do you make this statement? I can't speak for others,
:   but I have taught C and C++ in addition to Lisp. If you want
:   comments from only those with at least (say) five (or ten, or
:   twenty, or...) languages on the list, you'll have a quiet
:   conversation.

Chances are that this is due to them not reading or posting news,
I'd say. OTOH, there are many who have defended their dearest language
when language superiority for (task x not= teaching) is
not the issue.  For example, you could use Ada without nested
procedures for a start, and certainly without generics.
You could use some LISP without passing functions around,
although both are essential features of the respective
languages. (Meyer has dedicated a whole chapter in OOSC2 to teaching
Eiffel to students at different levels, BETA has been used
here some time ago, so who knows...)
But could you use languages that, internally, can be considered
as understandable in terms of trees, like PROLOG, when those
who have to learn programming, don't have a clear notion of trees yet?

From an old primer for SNOBOL4, I remember a sentence from
the preface that stated that you would have to know the meaning
of the most basic technical terms, or else programming will soon
become frustrating. Therefore, if the number of such technicalities
even for a subset of some language is high, it may not be the best
choice. class Obstacle { public static void main (String[] args) {
}}, a variation of what Jochen said. (From my experience, it is
_not_ the boilerplate stuff, but the syntax clutter, that makes C
syntax hard to comprehend: most symbols don't do anything that
has to do with data manipulation or calculations.)

One thing I would like to add to the discussion is
the quality of error messages. Imagine the translator complains
about an error and you cannot see the relation to your code
without some deeper knowledge of your language ...


Georg Bauhaus