Hello,
I am making this announcement since there is an article contest and this might
fit into that. I started writing what I hoped would turn into a fairly complete
book. I am releasing the current content under the creative commons license. If
this is reasonable for submission in the contest the great, but I just thought
it would be good to get what I have out there while a number of other articles
are going to be getting some attention. Now on to the details.
This book is intended to teach programming from the ground up. As such it isn't
about comparing languages or discussing specific features. We all know D would
make a very good first language, and I want to provide some material that makes
this possible. And I really want the user to go from first time "Python"
programmer to basic "C" programmer.
While I am no where near complete and I really have never worked out an
outline, I am providing both a PDF and a tex file for those that actually know
what they are doing. One approach that I think many will like is the Common
Errors sections which is meant to help people identify what the compiler is
saying when things go wrong.
http://nascent.freeshell.org/programming/D/LearningWithD.pdfhttp://nascent.freeshell.org/programming/D/LearningWithD.tex

We all know D would make a very good first language, and I want to provide
some material that makes this possible.<

This is a very interesting experiment, thank you for writing it.
Regarding languages to be used as first language for adults or near-adults, I
think there is no very good language for this purpose (for children the
situation is better, there are many Logo variants, some graphical languages,
etc). And even if you invent a language very good for this purpose, probably no
one uses it, there are no libs and ecosystem for it, so it keeps being a mostly
useless and buggy toy. I don't see many ways out of this situation.
Bye,
bearophile

provide some material that makes this possible.<
This is a very interesting experiment, thank you for writing it.
Regarding languages to be used as first language for adults or near-adults,
I think there is no very good language for this purpose (for children the
situation is better, there are many Logo variants, some graphical languages,
etc). And even if you invent a language very good for this purpose, probably
no one uses it, there are no libs and ecosystem for it, so it keeps being a
mostly useless and buggy toy. I don't see many ways out of this situation.
Bye,
bearophile

Well about learning a programming language as your first; I really think its
worth considering that several universities (AU atleast) introduces their
students to programming, using java, simply because it offers several
pedagogical learning tools alike; Greenfoot, that makes the introduction
more of a game than really an exercise.
I honestly think, it would make D more attractive as a first language to
learn, if it had these 'pedagogical' teaching tools.
--
// Yours sincerely
// Emil 'Skeen' Madsen

Regarding languages to be used as first language for adults or
near-adults, I think there is no very good language for this purpose
(for children the situation is better, there are many Logo variants,
some graphical languages, etc). And even if you invent a language very
good for this purpose, probably no one uses it, there are no libs and
ecosystem for it, so it keeps being a mostly useless and buggy toy. I
don't see many ways out of this situation.

Uuuurrr... this is just wrong on so many levels. To avoid writing an
10,000 word essay, I'll just stick to: Python and Groovy have proven to
be excellent languages for teaching first year undergraduates and
adults. Using robots wandering round screens is as good a technique for
adults as it is for children. This is not speculation this is annually
provable fact witness various teachers in various universities actually
doing it.
Possibly the single most important factor is having an edit/execute
environment that works in terms of compilation units, though usually
files. Groovy has the Groovy console which is brilliant, Python has
idle, which is about adequate. REPLs are just not good enough for this
task despite the obsession with using them in the Lisp, Scala, Clojure,
Prolog, Haskell, etc. communities.
--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road m: +44 7770 465 077 xmpp: russel russel.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder

Uuuurrr... this is just wrong on so many levels. To avoid writing an
10,000 word essay, I'll just stick to: Python and Groovy have proven to
be excellent languages for teaching first year undergraduates and
adults.

I have chosen Python to teach programming at new university students that know
nearly nothing about programming. I think Python is among the best languages
currently available to teach programming (Python partially comes from ABC, a
language mostly designed for teaching), but it's far from perfect still for
this purpose:
- I appreciate Python significant indentation a lot, but I've seen it cause
problems to some students.
- Dynamic typing is handy, but it makes it a bit harder to learn the discipline
of types.
- Confusing variable creation and variable update is not good to teach
programming to newbies and causes problems.
- Many programming newbies are blind to the diffences in case, for them FOR and
for are the same word, so a case agnostic language as Pascal is may be better
for such people.
- The lack of built-in rationals doesn't help.
- Lazy computations, introduced since some years in Python are a useful and
powerful tool, but for a newbie it's one more complexity to learn and manage.
- All variables managed by reference (by name) is good for uniformity (and
efficiency!), but it also introduces some complexities and bugs that newbies
don't like a lot.
- Python doesn't support recursion in a good enough way.
- Python error messages and debugging is far from the best. If you take a look
at the IDE of Racket Scheme you see something far more newbie-friendly.
Note: your posts come out empty through the web interface:
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.announce&article_id=20572
Bye,
bearophile

Uuuurrr... this is just wrong on so many levels. To avoid writing an
10,000 word essay, I'll just stick to: Python and Groovy have proven to
be excellent languages for teaching first year undergraduates and
adults.

I have chosen Python to teach programming at new university students that know
nearly nothing about programming. I think Python is among the best languages
currently available to teach programming (Python partially comes from ABC, a
language mostly designed for teaching), but it's far from perfect still for
this purpose:
- I appreciate Python significant indentation a lot, but I've seen it cause
problems to some students.

What kind of problems? (related to tabs vs spaces?)

- Dynamic typing is handy, but it makes it a bit harder to learn the
discipline of types.

Yeah, I personally don't like dynamic typing at all.

- Confusing variable creation and variable update is not good to teach
programming to newbies and causes problems.
- Many programming newbies are blind to the diffences in case, for them FOR
and for are the same word, so a case agnostic language as Pascal is may be
better for such people.

I strongly disagree. The first language they learn should *not* be
agnostic to case, so they learn that case matters (because it does in
most languages).

- The lack of built-in rationals doesn't help.
- Lazy computations, introduced since some years in Python are a useful and
powerful tool, but for a newbie it's one more complexity to learn and manage.
- All variables managed by reference (by name) is good for uniformity (and
efficiency!), but it also introduces some complexities and bugs that newbies
don't like a lot.
- Python doesn't support recursion in a good enough way.
- Python error messages and debugging is far from the best. If you take a look
at the IDE of Racket Scheme you see something far more newbie-friendly.
Note: your posts come out empty through the web interface:
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.announce&article_id=20572
Bye,
bearophile

- I appreciate Python significant indentation a lot, but I've seen it cause
problems to some students.

What kind of problems? (related to tabs vs spaces?)

Tabs Vs spaces is not a big problem once you have told students to set up all
their editors to never emit a tab :-) So this is not the real problem.
Different people have very different brains, some people find easy certain
things and other people find easy other things. A good teacher must adapt
himself/herself/hirself to the brain of the different students. Significant
indentation has some good advantages, it reduces noise, it makes the semantics
of the code the same of what you see, etc. But some programming newbies just
aren't precise enough, they lose control and count of indentations, etc. For
them spaces are nothing, they don't even see them, so for them braces are
probably better, despite the increase in noise.

- Dynamic typing is handy, but it makes it a bit harder to learn the
discipline of types.

Yeah, I personally don't like dynamic typing at all.

We are discussing about a language used as first programming language. What's
good for an programmer that is programming since two years is sometimes not the
best for a newbie and vice versa too. Finding a good balance for newbies
between Pascal/Java-style boring and stupid static typing, full type inference
as in ML, and full dynamic typing as in Python, is not easy.

I strongly disagree. The first language they learn should *not* be
agnostic to case, so they learn that case matters (because it does in
most languages).

Most languages are strict in their case. So sooner or later a programmer must
learn to tell apart cases of keywords and variables. But the case of keywords
is _not_ essential to learn the basics of programming. There are so many things
to learn in the beginning. And Pascal has being used to successfully teach
generations of programmers. So while I respect your point of view, I think this
is something different teachers are allowed to disagree on :-)
Bye,
bearophile

For them spaces are nothing, they don't even see them, so for them
braces are probably better

This is the biggest thing that trips me up with Python. Something
indenting inward is pretty easy to see, but going outward is often
skipped by my eyes.
def foo():
# i see this change
# but here I don't register the change and think I'm still in foo()
I wonder if part of the confusion is from indented paragraphs
in normal English. The most difficult thing to see is two or more
indents changing at once though... counting groups of spaces is
weird.

Brains are not all the same. There is a _large_ variation in all brain
structures at all levels, between people. This determines significant
differences in what different people find easy or hard. But your brain is
probably normal too, so it's mostly a matter of self-training with Python
programming, you are probably able to learn to register that.
Bye,
bearophile

For them spaces are nothing, they don't even see them, so for them
braces are probably better

This is the biggest thing that trips me up with Python. Something
indenting inward is pretty easy to see, but going outward is often
skipped by my eyes.
def foo():
# i see this change
# but here I don't register the change and think I'm still in foo()
I wonder if part of the confusion is from indented paragraphs
in normal English. The most difficult thing to see is two or more
indents changing at once though... counting groups of spaces is
weird.

- I appreciate Python significant indentation a lot, but I've seen it cause
problems to some students.

What kind of problems? (related to tabs vs spaces?)

Tabs Vs spaces is not a big problem once you have told students to set up all
their editors to never emit a tab :-) So this is not the real problem.
Different people have very different brains, some people find easy certain
things and other people find easy other things. A good teacher must adapt
himself/herself/hirself to the brain of the different students. Significant
indentation has some good advantages, it reduces noise, it makes the semantics
of the code the same of what you see, etc. But some programming newbies just
aren't precise enough, they lose control and count of indentations, etc. For
them spaces are nothing, they don't even see them, so for them braces are
probably better, despite the increase in noise.

OTOH python teaches to indent your code properly which enhances
readability, so maybe it's a good thing to learn right from the beginning.
I've had students producing working code (Java and SQL) that was totally
unreadable because it wasn't indented properly.

- Dynamic typing is handy, but it makes it a bit harder to learn the
discipline of types.

Yeah, I personally don't like dynamic typing at all.

We are discussing about a language used as first programming language. What's
good for an programmer that is programming since two years is sometimes not the
best for a newbie and vice versa too. Finding a good balance for newbies
between Pascal/Java-style boring and stupid static typing, full type inference
as in ML, and full dynamic typing as in Python, is not easy.

I strongly disagree. The first language they learn should *not* be
agnostic to case, so they learn that case matters (because it does in
most languages).

Most languages are strict in their case. So sooner or later a programmer must
learn to tell apart cases of keywords and variables.

Exactly. So why teach it in a differently first and then tell "well, now
you're using a proper language and now you have to start caring about
case"? This just asks for subtle bugs because of spelling mistakes..
class Bar {
int p;
void setFoo(int P) { this.p = p; }
}
and stuff like that.

But the case of keywords is _not_ essential to learn the basics of
programming. There are so many things to learn in the beginning. And Pascal has
being used to successfully teach generations of programmers. So while I respect
your point of view, I think this is something different teachers are allowed to
disagree on :-)

It may not be essential. Neither is correct spelling; so the language
could be fuzzy about detecting keywords so "to { ... } wihle(...);"
could be accepted as well :-P
Also: What are "the basics or programming"? Isn't expressing what you
want in a precise way part of it? And caring about case is part of being
precise IMHO.

OTOH python teaches to indent your code properly which enhances
readability, so maybe it's a good thing to learn right from the beginning.
I've had students producing working code (Java and SQL) that was totally
unreadable because it wasn't indented properly.

Some students are precise, they puts all the full stops and commas in their
comments, and format code well. Other students seem unable to understand the
need for a proper code formatting. But both kinds of students must learn some
programming and do some practice at it. The teacher has to ask for a good code
formatting, but I have seen it's better to avoid an escalation of the
frustration of the less precise programmers, otherwise they may lose interest
in programming and sometimes even switch courses :-) They already hate the
interpreter/compiler for all those stupid error messages it gives them...

Exactly. So why teach it in a differently first and then tell "well, now
you're using a proper language and now you have to start caring about
case"?

Delphi is a proper language (better than C, by the way). The first language you
use doesn't need to be the same language you use 8 months later. Ignoring cases
first, and later asking for a more strict programming style is not bad, it's
exactly what lot of students used to do learning Pascal the first year and C
the second :-)

Have you programmed in Delphi/ObjectPascal for some weeks or more? Case-related
bugs are not common. I am not talking about removing case sensitivity from
C/Java, I am talking about a language wholly designed taking into account it is
case insensitive.

It may not be essential. Neither is correct spelling; so the language
could be fuzzy about detecting keywords so "to { ... } wihle(...);"
could be accepted as well :-P

People that don't know how to switch on a computer know that in their natural
language the word "the" means the same thing if you write it lowercase in the
middle of the phrase, or if you write it capitalized as "The" at the beginning
of a phrase. But even programming newbies (unless they have dyslexia, and some
new programmers _do_ have strong dyslexia, and the teacher must find a ways to
teach them too something) are able to see that "hte" is a word different from
"the". So this argument of yours is not good enough.
Bye,
bearophile

OTOH python teaches to indent your code properly which enhances
readability, so maybe it's a good thing to learn right from the beginning.
I've had students producing working code (Java and SQL) that was totally
unreadable because it wasn't indented properly.

Some students are precise, they puts all the full stops and commas in their
comments, and format code well. Other students seem unable to understand the
need for a proper code formatting. But both kinds of students must learn some
programming and do some practice at it. The teacher has to ask for a good code
formatting, but I have seen it's better to avoid an escalation of the
frustration of the less precise programmers, otherwise they may lose interest
in programming and sometimes even switch courses :-) They already hate the
interpreter/compiler for all those stupid error messages it gives them...

How do you do "less precise programming"? Just change your code until
the compiler stops emitting error messages and until the output of your
program looks "about right" for some sample input?
IMHO the sooner they learn to be precise the better - randomly changing
code until it compiles is no programming but a sign that the
"programmer" hasn't got a clue what he's doing.
Furthermore I'm not sure whether setting correct parentheses is easier
than correct indenting for these kind of students (or will they just add
parentheses until the compiler shuts up)?
(WTF am I really defending a scripting language?)

Exactly. So why teach it in a differently first and then tell "well, now
you're using a proper language and now you have to start caring about
case"?

Delphi is a proper language (better than C, by the way).

Maybe, doesn't change the fact that most other languages are case
sensitive. And as a Linux user (with case sensitive file systems) I
think people should get used to case sensitivity.

The first language you use doesn't need to be the same language you use 8
months later. Ignoring cases first, and later asking for a more strict
programming style is not bad, it's exactly what lot of students used to do
learning Pascal the first year and C the second :-)

Have you programmed in Delphi/ObjectPascal for some weeks or more?
Case-related bugs are not common. I am not talking about removing case
sensitivity from C/Java, I am talking about a language wholly designed taking
into account it is case insensitive.

I've "learned" Delphi in school (didn't learn that much in retrospect, I
wasn't taught about records, classes, pointers, ... but we always
clicked a nice GUI..) but didn't even know it was case insensitive.

It may not be essential. Neither is correct spelling; so the language
could be fuzzy about detecting keywords so "to { ... } wihle(...);"
could be accepted as well :-P

People that don't know how to switch on a computer know that in their natural
language the word "the" means the same thing if you write it lowercase in the
middle of the phrase, or if you write it capitalized as "The" at the beginning
of a phrase. But even programming newbies (unless they have dyslexia, and some
new programmers _do_ have strong dyslexia, and the teacher must find a ways to
teach them too something) are able to see that "hte" is a word different from
"the". So this argument of yours is not good enough.

I started writing what I hoped would turn into a fairly
complete book.

Thank you for doing this! :)

This book is intended to teach programming from the ground
up.

I have some experience in doing the same. Just like teaching in the
classroom, no matter what style or detail has been chosen, readers will
find the material anywhere from very easy to exteremly difficult. :)
One (draft of an) article on teaching programming that had struck a
chord with me has been
http://www.cs.mdx.ac.uk/research/PhDArea/saeed/paper1.pdf
They divide the students in three groups. They argue that the ones that
are successful in programming are the ones who can form consistent
models for unknown phenomena. (Not their exact words, but what I got out
of the paper.)

We all know D would make a very good first language

Agreed. Although there are so many high level concepts in the language,
starting to write simple programs is very easy. For example, one can go
a long way without even knowing that pointers exist. Additionally,
having to introduce the concept of a reference type earlier makes it
easy to explain pointers later on.

And I really want the user to go from first time "Python"
programmer to basic "C" programmer.

I think, that is a more accurate description than the one in Chapter 1:
"(expected starting experience of none)". I can imagine that some people
will find your book a little too fast. (And others will find it too
slow! :))

One approach that I think many will like is the Common Errors
sections which is meant to help people identify what the
compiler is saying when things go wrong.

I started writing what I hoped would turn into a fairly
complete book.

Thank you for doing this! :)

This book is intended to teach programming from the ground
up.

I have some experience in doing the same. Just like teaching in the
classroom, no matter what style or detail has been chosen, readers will
find the material anywhere from very easy to exteremly difficult. :)
One (draft of an) article on teaching programming that had struck a
chord with me has been
http://www.cs.mdx.ac.uk/research/PhDArea/saeed/paper1.pdf
They divide the students in three groups. They argue that the ones that
are successful in programming are the ones who can form consistent
models for unknown phenomena. (Not their exact words, but what I got out
of the paper.)

We all know D would make a very good first language

Agreed. Although there are so many high level concepts in the language,
starting to write simple programs is very easy. For example, one can go
a long way without even knowing that pointers exist. Additionally,
having to introduce the concept of a reference type earlier makes it
easy to explain pointers later on.

I think explaining pointers first (including "you have to dereference it
to get to the thing it's pointing at", to show the difference between
pointer and pointee) may be a better idea.
After that you can say "and objects of classes are reference types, they
behave like pointers but don't need all the ugly syntax"
And I think http://www.youtube.com/watch?v=i49_SNt4yfk is a great video
explaining pointers ;)

And I really want the user to go from first time "Python"
programmer to basic "C" programmer.

I think, that is a more accurate description than the one in Chapter 1:
"(expected starting experience of none)". I can imagine that some people
will find your book a little too fast. (And others will find it too
slow! :))

One approach that I think many will like is the Common Errors
sections which is meant to help people identify what the
compiler is saying when things go wrong.

Yes, funny. :) But as some of the comments show, there are bad practices
like not initializing the pointers. I wonder whether the person who
wrote the accompanying code has experience with pointers. ;)
Also, the fact that the pointee is allocated with 'new' is adding
confusion to the already confusing matter. Allocating by new is a
lifetime issue and has nothing to do with being a pointee. It also makes
one wonder whether the int should not be guarded by a smart pointer.
Ali

I started writing what I hoped would turn into a fairly
complete book.

Thank you for doing this! :)

This book is intended to teach programming from the ground
up.

I have some experience in doing the same. Just like teaching in the
classroom, no matter what style or detail has been chosen, readers will
find the material anywhere from very easy to exteremly difficult. :)
One (draft of an) article on teaching programming that had struck a
chord with me has been
http://www.cs.mdx.ac.uk/research/PhDArea/saeed/paper1.pdf
They divide the students in three groups. They argue that the ones that
are successful in programming are the ones who can form consistent
models for unknown phenomena. (Not their exact words, but what I got out
of the paper.)

We all know D would make a very good first language

Agreed. Although there are so many high level concepts in the language,
starting to write simple programs is very easy. For example, one can go
a long way without even knowing that pointers exist. Additionally,
having to introduce the concept of a reference type earlier makes it
easy to explain pointers later on.

I think explaining pointers first (including "you have to dereference it
to get to the thing it's pointing at", to show the difference between
pointer and pointee) may be a better idea.
After that you can say "and objects of classes are reference types, they
behave like pointers but don't need all the ugly syntax"

If you're going to start with pointers, then it might make sense to
start with MIXX, or something else that offers a simplified model of the
hardware. Otherwise I tend to consider pointers an advanced concept.
Starting with a model of the hardware isn't a bad approach, but it
doesn't seem to be currently popular, and it's a long distance from
where most of the students want to end up.
Another approach is Python -> Pyrex -> C, but if there's any good
tutorial matter along that path, I haven't seen it. The presumption
seems to be that you know C before you tackle Pyrex. (The next step
along the path would be to assembler, but few want to take that step.)
But unless you start with the hardware (or a model of it) then any
explanation of pointers is going to be ... difficult. I've seen the
cartoons in several flavors, and they don't really do the job. They
make it "easier" to understand pointers, but also to misunderstand them.
(And pointers are never a "good" idea. An efficient idea, perhaps,
and sometimes necessary for that reason. But they aren't "good". They
are dangerous and tend to lead to code that's not only difficult to
understand, and doesn't do what you expect. [I,e., easy to misunderstand.])

And I really want the user to go from first time "Python"
programmer to basic "C" programmer.

I think, that is a more accurate description than the one in Chapter 1:
"(expected starting experience of none)". I can imagine that some people
will find your book a little too fast. (And others will find it too
slow! :))

One approach that I think many will like is the Common Errors
sections which is meant to help people identify what the
compiler is saying when things go wrong.

I think the biggest confusion about pointers comes from its C syntax.
Otherwise the concept is pretty simple.
The best way to explain it is with a lot of short code samples and
maybe even some simple diagrams. Forget trying to explain pointers
with walls of text and pretty language.

I think the biggest confusion about pointers comes from its C syntax.
Otherwise the concept is pretty simple.

Yes and no. To those that "get it", it is simple and straightforward.
Experience shows that very few people actually "get it". Syntax is a
factor but not the only one. The very nature of the concept stumps some
people.

The best way to explain it is with a lot of short code samples and
maybe even some simple diagrams. Forget trying to explain pointers
with walls of text and pretty language.

Diagrams about boxes in which things can be held and arrows pointing
from one box to another are very definitely the tool for maximizing
understanding, along with lots of simple examples of things people can
try out. There is an almost "visceral" element here, people need lots
and lots of different, simple examples so that they can build a correct
mental model.
=20
--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road m: +44 7770 465 077 xmpp: russel russel.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder

Yes and no. To those that "get it", it is simple and straightforward.
Experience shows that very few people actually "get it". Syntax is a
factor but not the only one. The very nature of the concept stumps some
people.

I suspect that those people who never get it are people who fundamentally do
not
know how a von neuman architecture computer works. I came to C from writing
embedded systems in assembler language, and C was immediately obvious to me.

Yes and no. To those that "get it", it is simple and straightforward.
Experience shows that very few people actually "get it". Syntax is a
factor but not the only one. The very nature of the concept stumps som=

e

people.

=20
I suspect that those people who never get it are people who fundamentally=

do not=20

know how a von neuman architecture computer works. I came to C from writi=

ng=20

embedded systems in assembler language, and C was immediately obvious to =

me.
Or Harvard architecture for that matter :-)
I completely agree with the direction of you point but would put it
slightly more abstractly. In order to be able to use a programming
language effectively and efficiently you must have an operational
semantics for the language. This need not be the actual semantics of
the processor executing the code, it just has to be consistent with it
or else you are doomed to write broken code.
It is important for a programming language to have a short cognitive
translation distance between the syntax of the language and a high-level
operational semantics consistent with the machine semantics.
Sadly most programming languages are measured against compilation
metrics rather than cognitive ones, and whilst there are many factors
the same (regularity, general lack of exceptional cases, etc.) there are
some significant divergences (people can cope with exceptional cases
where compilers often cannot, cf. English!)
I find it a bit irritating that there isn't more collaboration between
programming language folk and cognitive science folk. Programming
language folk often comment on cognitive issues, generally in the
absence of any knowledge of psychology and cognitive science, and the
psychology of programming folk generally end up doing their experiments
with outdated languages and on groups of people designed to give useless
results.
Sadly programming language development by natural selection fails to
work due to commercial vested interest, and lack of a adventurous spirit
on the part of the majority of practicing programmers.
I am beginning to rant, I will stop.
--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road m: +44 7770 465 077 xmpp: russel russel.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder

Yes and no. To those that "get it", it is simple and straightforward.
Experience shows that very few people actually "get it". Syntax is a
factor but not the only one. The very nature of the concept stumps some
people.

I suspect that those people who never get it are people who fundamentally do
not
know how a von neuman architecture computer works. I came to C from writing
embedded systems in assembler language, and C was immediately obvious to me.

Or Harvard architecture for that matter :-)
I completely agree with the direction of you point but would put it
slightly more abstractly. In order to be able to use a programming
language effectively and efficiently you must have an operational
semantics for the language. This need not be the actual semantics of
the processor executing the code, it just has to be consistent with it
or else you are doomed to write broken code.

Interestingly, before I learned assembly I programmed in Basic and Fortran.
While my programs worked, I really had no idea how the underlying machine
worked. I was completely baffled by it.
When I learned to program a 6800 microprocessor, suddenly all the lights came
on.
While learning assembler isn't going to help much with, say, comprehending
monads, I venture to say that writing effective C programs without knowing
assembler is like trying to drive a race car without knowing how a car works.
You can probably get it around the track, but you have no hope of winning, or
even being competitive.
(Test pilot Chuck Yeager remarked in his autobiography how being intimately
familiar with how his airplane worked saved his life many times.)

If you're going to start with pointers, then it might make sense to
start with MIXX, or something else that offers a simplified model of the
hardware. Otherwise I tend to consider pointers an advanced concept.

Conceptually pointers are very easy to explain and understand. Hardware plays
very little role in understanding pointers. The major stumbling blocks for when
someone is taught pointers is all the terminology that comes from it and
subjects being discussed. Pass by value, pass by pointer, pass by reference,
dereference, pointer, address of, array, static array, null, pointer
arithmetic, array syntax.
I'm starting with basic module based programming, but I will have structs and
pointers introduced before classes. While many do not want to learn about
pointers and hardware, I'm believe I can make it less painful. I do need to add
more fluff before getting to them, and most importantly come up with a good
example solved by pointers that isn't covered by a ref parameter (one thing
I'll have to have more examples of instead of just using in a foreach loop).

Starting with a model of the hardware isn't a bad approach, but it
doesn't seem to be currently popular, and it's a long distance from
where most of the students want to end up.

Like I said, I don't think pointers and hardware go together. I think I'll
cover a good area for application developer and low level coder, the pointer
and ASM chapters can/will be easily skipped.

Another approach is Python -> Pyrex -> C, but if there's any good
tutorial matter along that path, I haven't seen it. The presumption
seems to be that you know C before you tackle Pyrex. (The next step
along the path would be to assembler, but few want to take that step.)

I'm wondering if you know what this thread is about, its about the path of: D
-> D -> D

But unless you start with the hardware (or a model of it) then any
explanation of pointers is going to be ... difficult. I've seen the
cartoons in several flavors, and they don't really do the job. They
make it "easier" to understand pointers, but also to misunderstand them.

I agree, analogies and other simplifications make for a very poor grasp of what
a pointer is. I intend to make much more use of my Common Errors section to
cover lots of pitfalls of pointers, and this is important to understanding them.

(And pointers are never a "good" idea. An efficient idea, perhaps,
and sometimes necessary for that reason. But they aren't "good". They
are dangerous and tend to lead to code that's not only difficult to
understand, and doesn't do what you expect. [I,e., easy to misunderstand.])

Pointers are rarely needed in D, but understanding them is very useful. I think
pointers make it easier to understand other safer concepts. I do not think
hardware/ASM make it easier to understand pointers/functions/modules/types.

I think at the end of the day feedback from beginners reading the book
or tutorial is the most valuable thing to have. With an online version
of a book you could add extra clarification for some topics if newbies
end up being confused or didn't grasp a concept in full. I rarely see
this happen with online material though. I guess people are just too
busy, maybe. :)

With an online version
of a book you could add extra clarification for some topics if newbies
end up being confused or didn't grasp a concept in full.

I do that all the time: typos reduced, sentences get clarified, more
information added as the author learns about them, etc. ;)

I rarely see
this happen with online material though. I guess people are just too
busy, maybe. :)

I still need to change the operator overloading section to use the new
syntax. But before that, I will remove the information about octal
literals. And even before that, I will finish and publish the
parallelization chapter, etc., etc. :)
Ali

On 05/21/2011 11:12 PM, Jesse Phillips wrote:
> This book is intended to teach programming from the ground
> up.
I have some experience in doing the same. Just like teaching in the
classroom, no matter what style or detail has been chosen, readers will
find the material anywhere from very easy to exteremly difficult. :)

I definitely don't expect to satisfy everyone and what I have leans on the
easy, fast style.
I've some experience tutoring, and generally get compliments, but I don't know
how well this translates to writing. But it is better than nothing.

> We all know D would make a very good first language
Agreed. Although there are so many high level concepts in the language,
starting to write simple programs is very easy. For example, one can go
a long way without even knowing that pointers exist. Additionally,
having to introduce the concept of a reference type earlier makes it
easy to explain pointers later on.

I don't think there is a right answer to this. I think classes can be harder to
explain and understand then basic pointers and structures.
One aspect which I'm trying to keep in this book is, leave nothing unexplained.
If I use it I don't want to just say "this is required, but don't worry about
why just yet." I did this with the main function, but I'm making an effort not
to make this common.
Classes have lots of things that can just be glossed over, which is fine, but
it makes it very hard to explain why they do what they do.

> And I really want the user to go from first time "Python"
> programmer to basic "C" programmer.
I think, that is a more accurate description than the one in Chapter 1:
"(expected starting experience of none)". I can imagine that some people
will find your book a little too fast. (And others will find it too
slow! :))

I didn't want to mention any languages, but I suppose someone looking to learn
a language will have heard of a few and have an idea of what that statement
would mean.

> One approach that I think many will like is the Common Errors
> sections which is meant to help people identify what the
> compiler is saying when things go wrong.
That is going to be very helpful.

Yes and at some point I'll look at pulling these out and having them all in a
single section and probably placed on Wiki4D.