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

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.

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

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

You can tell how much tired I am from the number of grammar mistakes -.-

Sorry,
bearophile

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

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

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.

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

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.

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