[Tutor] Losing the expressiveness ofC'sfor-statement?/RESENDwith example

[Stephen McInerney]

Guys,

I'm annoyed at how far offtopic and frankly rude the responses to my email 
were,
and 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.
I didn't get much decent opinion on my central question:
"isn't this idiom more restrictive than C/C++/Java (aka the rest of the 
universe),
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
(add one or two lines with links is all that's needed)."
I made it clear that my motivation was that this is badly explained and is a 
real
hurdle to migration. Show any of the code we discussed to non-Python
programmers and they'll be lost. Nobody attempted to address the valid
follow-on question about generators returning a tuple (e.g. walking a 
pointer,
and incrementing a count, let alone anything more complex)

- quibbling the motivation for the quicksort example I gave was clearly 
offtopic;
I'm very well aware there are better Python implementions, that's 
irrelevant;
the motivation was to give a legitimate example which clearly arises 
commonly.

- nowhere did I ask for "the language to be changed". I made it clear this
was a question about how the *documentation* *describes* the
Python approach (very badly describes).
In any case, when we talk about people migrating from other languages,
C/C++/Java is ~60-95% of the audience, COBOL is irrelevant and PL/I is 
ancient history.

- 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. We have to
do a better job selling why Python is better.
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.
Anyway most of those can be caught by trivial linting and code reviews,
and the rest by automated checkers.


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

I couldn't disagree more strongly.
Those were already dated in 1980 - almost everyone these days learns 
C/C++/Java(/C#)
as their main programming language, unless they're mechanical engineers or
accounting programmers. Look at TIOBE Index to confirm that.

I am an EE who started out in the 80s with garbage like BASIC, Fortran, 
Pascal and assembly,
but when I discovered C in 1992 I almost wept that the for-loop syntax was 
so simple yet infinitely powerful.

>But C is a poor choice for more user centric problems.
I never said otherwise, but the reality we're operating in is that the 
common languages in use will always lag the leading edge by ~15-30 years. So 
we should at least make very basic accomodations for that migration reality. 
Specifically, give the people a hint to use while-loops and generators.

> > It's regrettable we have to choose between the clear and the
> > efficient, in this situation.
>
>The most clear and efficient is probably:
>
>myList.sort()

Alan - this was totally unnecessary and trashes the entire (legitimate) 
context of my question.

Regards,
Stephen


>From: "Alan Gauld" <alan.gauld at btinternet.com>
>To: tutor at python.org
>Subject: Re: [Tutor] Losing the expressiveness 
>ofC'sfor-statement?/RESENDwith example
>Date: Tue, 7 Aug 2007 15:24:34 +0100
>
>"Stephen McInerney" <spmcinerney at hotmail.com> wrote
>
> > I don't deny the superiority of the underlying language design,
> > I'm just pointing out the very real mindjolting effect of Python not
> > supporting the universal syntax.
>
>An interesting term. 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. It is also highly error prone and a
>source of many bugs in C programs (I know I spent several years
>running
>a C maintenance project and for loop side-effects were right up there
>with
>uninitialised variables and memory leaks in the common error lists!).
>
> > Java is closer to C than Python is.
>
>True, Java deliberately set out to be a simple subset of C++ so it
>has a similar syntax. Python is closer to Lisp than C is but nobody
>would suggest that C should change its semantics to suit the tastes
>of Lisp programmers who are converting. Languages are different and
>learning the new idioms both positives and negatives) is part of the
>process.
>
> > Don't you agree that the Python tutorial should say something simple
> > and accessible to beginners like: "For all for-loop constructs where
> > the
> > iteration can't be written as a simple range object,
>
>In fact the range version of a for loop is only one style and probably
>not the most common. You should iterate over a collection not a range
>in most cases:
>
>ie
>
>someList = [1,2,3,4,5]
>
>for item in someList:
>    print item
>
>and never
>
>for index in range(len(somelist)):
>     print somelist[index]   # bad bad bad!
>
>It is Pythons "foreach" effect that makes it so powerful.
>
> > I think the tutorial is lacking on this (should I email Fred Drake?)
>
>You could try it but that would imply that the tutorial should flag
>up where Python varies from the syntax of COBOL too - after all there
>are many more COBOL porogrammers than any other language!
>
>So explaining
>
>x = y + z
>
>we would need a note:
>
>Notice that Python uses a math symbol for addition instead
>of the more common COBOL usage
>
>ADD Y, Z TO X
>
>And explain to Smalltalk, ADA  and Pascal programmers that = is
>assignment instead of :=
>
>Where do you stop?
>
> > Instead of leaving C and Java people cold scratching their heads
> > about
> > why they think the language is hopelessly quirky and not
> > (syntactically)
> > fully-featured?
>
>A language is syntactically fully featured if it supports the 3
>elements
>of structured programming (sequences, loops and branches) , or even
>more starkly if it is Turing complete. No language should try to
>encompass
>all styntax structures of all languages (that way lies PL/1!)
>
> > One of our aims should be to write code which is at least
> > understandable to
> > programmers of other languages.
>
>Yes, but that doesn't mean a similar syntax, it means an easy
>comprehension of the syntax as written. ie one that reads as much
>as possible like a natural language - a test that C fails miserably!
>
> >>You don't give us any reason why you want to generate a set
> >>of numbers from 30,000 down to zero decreasing by half each
> >>time: 30,000, 15,000, 7500, 3750, etc
>
> > Yes I did: it occurs in a quicksort as we halve the stepsize each
> > time,
> > on an array of size 60000.
>
>OK so use Pythons built in sort method. It uses quick sort I believe.
>But if it doesn't still use it and see if its fast enough. If it isn't
>consider
>refactoring your data structures to improve it. If that doesn't work
>then,
>as a last resort, consider writing your own sort function. When using
>high level languages leverage the language.
>
> > Can you please give me your answer on this? We have to transform it
> > to
> > a while-loop? (or write a custom iterator?)
> > It would nice to compare the most straightforward solution
> > (while-loop?)
>
>The most straightforward solution is to use the standard sort
>function.
>
> > the fastest solution, the last-memory solution and the most elegant
> > solution.
>
>Yes it's almost certainly all of those.
>
> >>def half(n):
> >>     while int(n) > 0:
> >>        n = n/2
> >>        yield n
> >>
> >>for x in half(300): print x,
> >
> > It's ok but it's visually clunky. while-loop wins for clarity.
>
>I disagree, the while lop is a distraction from what you are trying to
>achieve,
>which is use a specific list on numbers to performs some action, in
>your
>case a sort. The more you can hide the generation of the numbers the
>clearer your code becomes. (PS I agree the name "half" is not great
>but it was short in the interpreter! :-)
>
> > lambda would also be too quirky.
>
>lambda is no good here because Python's lambda only allows a
>single expression not loops - I originally thought a lambda might
>work.
>(The limitations of Python's lambda are another copmmon complaint for
>programmers moving from languages which better support functional
>programming, but that still doesn't mean Python should change its
>lambda to match)
>
> > I know the generator is more runtime-efficient.
>
>You know more than me in that case, I didn't even think about that, I
>simply
>tried to solve the problem. If run time efficiency is that critical
>Python is probably
>not the right language anyway - but only if you try it, and measure
>it, and
>know that run time efficiency is an issue. Python is not trying to get
>you close to the machine, quite the opposite, its trying to get you
>closer
>to the problem you are trying to solve. C is designed to get you close
>to
>the machnie, that's why its the right choice for writing device
>drivers etc.
>But C is a poor choice for more user centric problems.
>
> > It's regrettable we have to choose between the clear and the
> > efficient, in
> > this situation.
>
>The most clear and efficient is probably:
>
>myList.sort()
>
>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

_________________________________________________________________
More photos, more messages, more storage—get 2GB with Windows Live Hotmail. 
http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_2G_0507