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 Russel Winder <russel russel.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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

 # but here I don't register the change and think I'm still in foo()

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

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 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 next 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 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 =?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 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 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 next 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
prev sibling 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 Russel Winder <russel russel.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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
prev sibling next sibling parent 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
prev sibling parent Russel Winder <russel russel.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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=


 people.

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

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

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

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
prev sibling parent Emil Madsen <sovende gmail.com> writes:
--bcaec51dd19ff1af0804a3e6f5e2
Content-Type: text/plain; charset=ISO-8859-1

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

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 --bcaec51dd19ff1af0804a3e6f5e2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 22 May 2011 22:26, bearophile <span dir=3D"lt= r">&lt;<a href=3D"mailto:bearophileHUGS lycos.com">bearophileHUGS lycos.com= </a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin= :0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> Jesse Phillips:<br> <div class=3D"im"><br> &gt; We all know D would make a very good first language, and I want to pro= vide some material that makes this possible.&lt;<br> <br> </div>This is a very interesting experiment, thank you for writing it.<br> <br> 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, proba= bly no one uses it, there are no libs and ecosystem for it, so it keeps bei= ng a mostly useless and buggy toy. I don&#39;t see many ways out of this si= tuation.<br> <br> Bye,<br> <font color=3D"#888888">bearophile<br> </font></blockquote></div><br>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.<div> <br></div><div>I honestly think, it would make D more attractive as a first= language to learn, if it had these &#39;pedagogical&#39; teaching tools.= =A0<br clear=3D"all"><br>-- <br>// Yours sincerely<br>// Emil &#39;Skeen&#3= 9; Madsen<br> </div> --bcaec51dd19ff1af0804a3e6f5e2--
May 22 2011