Re: Beginner's Language?

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

Marin David Condic (marin.condic.auntie.spam@pacemicro.com) wrote:

: If you are familiar with Lisp, try this: Write a small program to read in a
: couple of numbers from a keyboard, do some math with them and print the
: result to the screen. Now look at it. Could a neophite with literally *zero*


Then, Ola Rinta-Koski (with f'Up to iso-something):

"(let ((foo 0))
  (dotimes (i 5)
    (incf foo (read)))
  foo)

[is easy]"

: That's why I wouldn't recommend Lisp as a first programming language in an
: intro to CS course.

: Gee. I never thought I'd have to defend THAT statement! :-)

The above looks like Scheme with macros(?) and has a few didactical
problems, as I'd like to report, with some additional guesses thrown in.
(not to say that these problems are not present in many or all
other languages): You may have to answer some questions from your
inexperieced(!) listeners,
- what is let? and then: why do I have to place an additional pair
  of parens around foo 0?
- what is i for?
- what does it mean that this foo is standing on its own
  on the last line?
- if the first thing in a list is a function that does something
  with the rest, then what function is i?
- ...

As you may see by now, there _is_ some complexity even
behind the most "simple" syntax, and while, of course,
all these questions can be answered, the tree (or graph?)
of follow up questions is going to grow large.
So some of these things (like creating "variables") had
better explain themselves a bit more, i.e. without
overloaded parentheses, for example.

When it was my job to teach OO Prgramming with Java :-( to
grown ups with essentially only high school math background,
(it had to be Java, by contract) I was puzzled that there
was no problem in talking about graphs and trees of inheritance
at a very early stage (though not formally, and by example),
but it was _very_
difficult to explain the concept of a function, what it is,
what it is there for, let alone, what it is as a method of
some class.

(All these phaenomena may be my fault, but in this case, I don't
think so.)

 One reason seems to be abstraction: If they have
been doing math for years, it doesn't seem difficult to
see that there is a form in "multiply the number of
goods by their respective prices" that can be used for
anything that has a price, be it bread or a house or a
service. And to find a notation for this function.
But it does seem to become difficult at the point
where familiarity stops: real machines, real data,
real OSs, and the first new syntax, math background or not.

What worked well was flow charts. Very well, indeed.
But which language serves well in the transport of flow
charts to code, and does so after a few introductory words?
I'll vote for a language that has a lucid syntax for this
like "IF condition THEN do_this, OTHERWISE do_that."
until, after formal training, a alternative approach becomes
feasable.
(Maybe the punctiation (which carries meaning!) could
be replaced with words, so people don't become annoyed
with orthographical issues right from the beginning?
Or should they be drilled to formal exactitude? :-)

What I think is lively important in the choice of a 
first programming language, is to have a visual hook in them
to explain fundamental issues (like why "c = c + 1" is
valid in languages actually taught, and which needs
some notion of an accumulator or equivalent, on computers).

If you want to know how to code, you will
have to know a setq-free and a setq-only approach
(after all, there is memory, in real machines at some
level). Is there a good way to do only one of them at
the beginning? I don't know but I would love to read
some real empirical evidence.


Georg Bauhaus

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

PPS: And as for beginners with math skills, who cannot yet
master SICP, Abelson's LOGO book _is_ a good reading,
I find.