Learning With D

[Jesse Phillips]

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.