[Tutor] Losing the expressivenessofC'sfor-statement?/RESENDwithexample

[Stephen McInerney]

Hi Alan,

I appreciate your very thoughtful answer.
I had previously thought you were not taking the intent of my question 
seriously, it did seem to have strayed hopelessly offtopic (e.g. I knew all 
about Python's quicksort() already, but the generic question about for-loops 
very much stands).

We certainly don't want the Python equivalent of Pascal-migration 
abominations like:
>#define BEGIN { #define END }

but idiomatic translation of for-loops into Python is hard:
(e.g. list comprehensions vs basic iterator vs while loop vs generator vs 
special-purpose fn)
How can we address that reasonably and succinctly without polluting the doc 
with language-migration-specific details, that is a worthy question... I 
believe we can do a better job simply by grouping and highlighting related 
alternative concepts like I listed above. As to a generator returning 
tuples/sequences, I will look into how far that goes.

Also, I believe my generic comment about being forced to choose the 
efficient approach vs the most clear, legible or simple approach stands, and 
I will think up some examples.

I will collect my response and further thoughts and repost in a few days 
when I have more time...

Best,
Stephen



>From: "Alan Gauld" <alan.gauld at btinternet.com>
>To: tutor at python.org
>Subject: Re: [Tutor] Losing the 
>expressivenessofC'sfor-statement?/RESENDwithexample
>Date: Sat, 11 Aug 2007 02:12:18 +0100
>
>"Stephen McInerney" <spmcinerney at hotmail.com> wrote
>
> > I'm annoyed at how far offtopic and frankly rude the responses
>
>Don;t get annoyed at off topic posts, that's all part of the fun in
>a group like this which is aimed at teaching novices how to
>program and specifically how to program in Python. The wider
>issues are all part of the training.
>
>As to rudeness, this is a very polite group by most internet
>standards,
>but if anything I wrote upset you I apologise, it wasn't my intention.
>
> > I'm just going to submit my doc change request to Fred Drake
> > exactly as I was intending to before I sent the first mail.
>
>That's fine and Fred may well incorporate it. Personally I believe
>that
>would be a mistake as it sets a bad precedent. It may even encourage
>C programmers to try to convert their C coding style into Python,
>and that would be a big mistake - both for the individuals concerned
>and for the Python community.
>
> > I didn't get much decent opinion on my central question:
>
>You got a lot of very good opinion, namely that you are comparing
>apples and oranges. C's for loop is syntactic sugar for a while loop.
>Python's for loop is a foreach construct for iterating over a
>collection.
>Very different things, and impossible to compare sensibly.
>
> > "isn't this idiom more restrictive than C/C++/Java (aka the
> > rest of the universe),
>
>But your central premis that C/C++/Java form the "rest of the
>universe"
>is just plain wrong. There are many, many other languages in day to
>day use.
>Infoweek and Computing magazines regularly run surveys of their
>readers
>which show COBOL to be the most widely practiced language today (as
>indeed it has been for the last 30 years!) - looking at job ads
>doesn't take
>account of the fact that most COBOL jobs are with big corporations and
>are often jobs for life! I know several of our (5000 or so) in-house
>COBOL
>jockeys who have over 30 years service...)
>
> > don't you agree it's badly explained in the doc (there is no basic
> > advice to transform to while loop or else write generator), and the
> > doc
> > should have a simple change
>
>The docs explain how the python for loop works pretty well I think.
>They do not explain the differences between Python's for loop and C's
>for loop any more than they explain the differences between Pythons
>lambda and Lisp's version. Whether the docs should do that is a
>moot point that the maintainer (Fred) can decide.
>
> > Show any of the code we discussed to non-Python programmers
> > and they'll be lost.
>
>That I doubt, most of it was generic apart from the generator 'yield'
>construct. And anyone used to generators - Lisp, Ruby, Smalltalk
>programmers would all guess at its function pretty well intuitively.
>
> > follow-on question about generators returning a tuple
> > (e.g. walking a pointer, and incrementing a count, let alone
> > anything more complex)
>
>Sorry, I missed it. Can you ask again in a separate thread and we
>can take a look at it.
>
> > - quibbling the motivation for the quicksort example I gave was
> > clearly offtopic;
>
>No, it was an example of how, by considering the actual purpose
>of the code we can usually find a completely different solution to
>any such problem. There are very few scenarios that actually require
>that kind of low level algorithmic access in Python - algorithm
>design being one valid example!
>
> > the motivation was to give a legitimate example which clearly arises
> > commonly.
>
>And my point was that in Python it doesn't arise very commonly at all.
>There is nearly always an alternative style of solution, often
>avoiding for
>loops entirely.
>
> > In any case, when we talk about people migrating from other
> > languages,
> > C/C++/Java is ~60-95% of the audience, COBOL is irrelevant
>
>Going by the posts we see on this list the majority of the folks
>coming
>to python come from other scripting languages: PHP, Perl, Visual Basic
>or from shell scripting (DOS Batch, VMS DCL  or Unix shell) or from
>other high level languages like Rebol, Mathematica or Lisp. There are
>also many first timers since python is fast becoming the teaching
>language
>of choice in colleges and schools. We very rarely get questions from
>C/C++
>programmers and only a few from Java. We have had at least one COBOL
>programmer but I agree they aren't that common - mostly they are still
>hacking away in COBOL! Where they might come from is using Python
>as a replacement for their JCL scripts, and we have had a couple of
>those
>at least...
>
> > and PL/I is ancient history.
>
>But we can learn from history and the lesson of PL/1 was - don't try
>to
>create a language with all the features of every other language, it
>will
>be a monster! I know you weren't trying to change the for loop merely
>translate its style in the docs, but my point was that anyone looking
>for all their best loved featires from language X in language Y is
>doomed
>to failure.
>
> > - This is offtopic, but the C for-loop syntax is very syntactically
> > powerful, so when people perceive Python lacks it, they may baulk
> > at that.
>
>No arguments about its power, but anyone who gives up on a language
>because one favourite control structure is missing is foolish in the
>extreme.
>
> > We have to do a better job selling why Python is better.
>
>Its not better, just different. There are jobs that I would never try
>to do in Python and for some I would pick C every time. For others
>SQL or Prolog or even COBOL might be more appropriate.
>
> > The C for-loop syntax itself is not error-prone at all.
> > Unless you mean off-by-one errors etc., missing initializations, and
> > those
> > are mostly semantic not syntax-related.
>
>All I can say is that having seen several thousand C bugs pass
>through my maintenance team I can tell you that for loop errors
>are up there in the top 5 problem areas. Your list gives many but
>there are also problems with side-effects introduced because of C's
>assignment as an expression "feature". And if everyone rigorously
>lint'ed their C then I agree many would be caught but I can attest
>that
>many C programmers do not use lint - and indeed its not (readily)
>available on some platforms (eg embedded controllers etc).
>
> > >The C syntax is extremely odd to most programmers who haven't been
> > >trained in it but in more traditional languages like Lisp, Cobol,
> > >Fortran,
> > >Pascal, ADA, etc.
> > Those were already dated in 1980
>
>Well ADA didn't even exist in 1980. And new versions of COBOL and
>Fortran have been standardised in the last 10 years. Admittedly
>Borland Delphi is probably the last bastion of Pascal and Lisp
>has had a long but loyal following since the early 60's with CLOS
>standardised during the early 90's(?).
>
> > - almost everyone these days learns C/C++/Java(/C#)
>
>Those who go through University probably do, but many colleges
>and high schools teach VB or interpreted languages (like python).
>And scientists still get taught Fortran in many schools. And IS
>programmers are still universally taught COBOL because it is still
>the king of large scale data crunching.
>
> > I am an EE who started out in the 80s with garbage like BASIC,
> > Fortran, Pascal and assembly,
>
>Me too, (except we didn't do Fortran) but I didn't find them garbage
>(but I didn't like early BASICs its true), rather I found the
>different
>approaches interesting. I also learnt Smalltalk at Uni - an advantage
>for which I am immensly thankful since it opened my eyes to OOP
>long before it became generally popular. I came to C during a vacation
>job in 1985 and loved its conciseness and low level access, but I grew
>to hate things like casting, and the arcane pointer syntax etc.
>
> > we should at least make very basic accomodations for that
> > migration reality. Specifically, give the people a hint to use
> > while-loops and generators.
>
>The docs describe while loops and generators. What we don't
>want to encourage is C programmers coming to python and trying
>to mentally translate their C code into Python by translating for
>loops into while loops. That will nearly always be the wrong
>approach. (K&R makes a similar point about discouraging Pascal
>programmers from doing things like
>#define BEGIN {
>#define END }
>in C.)
>
> > >myList.sort()
> >
> > Alan - this was totally unnecessary and trashes the entire
> > (legitimate)
> > context of my question.
>
>Not so, it illustrates that the fundamental solution to your specific
>example was in looking for a native solution to the problem - sorting
>a collection. Using the built in functionality will nearly always be
>faster
>and more efficient than building your own. And there are very few
>cases where you need to build your own algorithms in python.
>
>And as I said above we can't compare the general case because
>C and python for loops are fundamentally different things.
>
>I guess what I'm trying to say is that it is pointless trying to get
>the
>documentation to provide pointers for any one language when there
>are so many others out there(*). The purpose of the languages is
>different, the syntax is different and so are the semantics of the
>constructs.
>
>(*) Interestingly my web tutor actually does take a comparative
>approach
>teaching 3 languages in parallel. (One of which, JavaScript, uses the
>C style for loop)  But this apparent contradiction in stance is in
>fact
>because I believe that the syntactic differences in languages are
>vastly overplayed. Learning programming happens at a much more
>fundamental level than at the language syntax.
>
>HTH,
>
>--
>Alan Gauld
>Author of the Learn to Program web site
>http://www.freenetpages.co.uk/hp/alan.gauld
>
>
>_______________________________________________
>Tutor maillist  -  Tutor at python.org
>http://mail.python.org/mailman/listinfo/tutor

_________________________________________________________________
A new home for Mom, no cleanup required. All starts here. 
http://www.reallivemoms.com?ocid=TXT_TAGHM&loc=us