www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Learning With D

reply Jesse Phillips <jessekphillips+D gmail.com> writes:
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.pdf
http://nascent.freeshell.org/programming/D/LearningWithD.tex
May 21 2011
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Jesse Phillips:


 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
May 22 2011
next sibling parent reply Emil Madsen <sovende gmail.com> writes:
On 22 May 2011 22:26, bearophile <bearophileHUGS lycos.com> wrote:


 Jesse Phillips:


 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


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
May 22 2011
parent bearophile <bearophileHUGS lycos.com> writes:
Emil Madsen:


 I honestly think, it would make D more attractive as a first language to
 learn, if it had these 'pedagogical' teaching tools.


This is of course true. And those tools are useful for generic newbies too.

Bye,
bearophile
May 23 2011
prev sibling parent reply Russel Winder <russel russel.org.uk> writes:
On Sun, 2011-05-22 at 16:26 -0400, bearophile wrote:
[ . . . ]

 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
May 22 2011
parent reply bearophile <bearophileHUGS lycos.com> writes:
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
May 23 2011
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
You can tell how much tired I am from the number of grammar mistakes -.-

Sorry,
bearophile
May 23 2011
prev sibling parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 23.05.2011 20:51, schrieb bearophile:

 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.


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
May 23 2011
parent reply bearophile <bearophileHUGS lycos.com> writes:
Daniel Gibson:


 - 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
May 23 2011
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
bearophile wrote:

 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 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.
May 23 2011
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Adam D. Ruppe:





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
May 23 2011
prev sibling parent Daniel Gibson <metalcaedes gmail.com> writes:
Am 23.05.2011 22:51, schrieb Adam D. Ruppe:

 bearophile wrote:

 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 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.


Scintilla based editors (like SciTE and Geany) have indentation guides,
see
http://www.joeflash.ca/blog/2009/03/indentation-guides-in-flex-builder.html
for a screenshot (that's not my page, I found this via google).
That should help.

Cheers,
- Daniel
May 23 2011
prev sibling parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 23.05.2011 21:53, schrieb bearophile:

 Daniel Gibson:
 

 - 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.


 Bye,
 bearophile


Cheers,
- Daniel
May 23 2011
parent reply bearophile <bearophileHUGS lycos.com> writes:
Daniel Gibson:


 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 :-)



 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.


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
May 23 2011
parent Daniel Gibson <metalcaedes gmail.com> writes:
Am 24.05.2011 01:59, schrieb bearophile:

 Daniel Gibson:
 

 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 :-)
 


And learning Pascal in the first and C in the second year is good?


 

 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.


 
 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.
 


Even programming newbies can easily learn that "The" != "the".


 Bye,
 bearophile
May 23 2011
prev sibling parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 05/21/2011 11:12 PM, Jesse Phillips wrote:


 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.


That is going to be very helpful.

Thank you,
Ali
May 22 2011
next sibling parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 23.05.2011 01:29, schrieb Ali Çehreli:

 On 05/21/2011 11:12 PM, Jesse Phillips wrote:
 

 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.


 
 That is going to be very helpful.
 
 Thank you,
 Ali
May 22 2011
next sibling parent =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 05/22/2011 04:36 PM, Daniel Gibson wrote:


 And I think http://www.youtube.com/watch?v=i49_SNt4yfk is a great video
 explaining pointers ;)


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
May 22 2011
prev sibling parent reply Charles Hixson <charleshixsn earthlink.net> writes:
On 05/22/2011 04:36 PM, Daniel Gibson wrote:

 Am 23.05.2011 01:29, schrieb Ali Çehreli:

 On 05/21/2011 11:12 PM, Jesse Phillips wrote:


 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 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.


 That is going to be very helpful.

 Thank you,
 Ali
May 23 2011
next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
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.
May 23 2011
prev sibling next sibling parent reply Russel Winder <russel russel.org.uk> writes:
On Mon, 2011-05-23 at 20:00 +0200, Andrej Mitrovic wrote:

 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
May 23 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/23/2011 11:30 AM, Russel Winder wrote:

 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.
May 24 2011
parent reply Russel Winder <russel russel.org.uk> writes:
On Tue, 2011-05-24 at 14:56 -0700, Walter Bright wrote:

 On 5/23/2011 11:30 AM, Russel Winder wrote:

 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
May 25 2011
parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/25/2011 12:04 AM, Russel Winder wrote:

 On Tue, 2011-05-24 at 14:56 -0700, Walter Bright wrote:

 On 5/23/2011 11:30 AM, Russel Winder wrote:

 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.)
May 25 2011
prev sibling parent reply Jesse Phillips <jessekphillips+D gmail.com> writes:
Charles Hixson Wrote:


 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.
May 23 2011
parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
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. :)
May 23 2011
parent =?ISO-8859-1?Q?Ali_=C7ehreli?= <acehreli yahoo.com> writes:
On 05/23/2011 01:39 PM, Andrej Mitrovic wrote:


 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
May 23 2011
prev sibling parent Jesse Phillips <jessekphillips+D gmail.com> writes:
Ali Çehreli Wrote:


 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.


 Thank you,
 Ali


Thank you
May 23 2011