Learning With D

[Charles Hixson]

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