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

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

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

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
> 

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

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

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.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 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

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

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

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.