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

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

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

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

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

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.

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.

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

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