[Edu-sig] Why Python?

[David MacQuigg]

Mark Engelberg wrote:
>>> It's interesting to speculate whether there
>>> will ever be another major improvement in programming, a step beyond
>>> Python, or if Python will simply incorporate any good ideas that come
>>> along (as it did with our @ syntax).  I would bet on the latter.
>>>       
>
> Python has served me well for many years, but it is pretty poor at
> handling concurrency, which is widely considered to be the hot issue
> that future languages will need to solve.  I am skeptical that Python
> will be able to absorb these improvements into its existing
> infrastructure.  I would almost certainly bet that Python will be
> superseded by superior languages, although possibly it has another 10
> or so more years of popularity to look forward to.
>   

Good observation.  I wasn't thinking of parallel computing at all.  I 
can see a need for something very different in this realm.  I'll stick 
with my original bet, however, if we limit our consideration to 
"mainstream" languages.  I will bet that languages like Fortress, 
designed to deal with concurrency, will be used only by specialists, and 
that the majority just needing to process payroll records or program a 
website, will stick with whatever evolves from Python.

Parallel programming is motivated by a need for speed.  Already Python 
is fast enough for 99% of what we do, and that is without even taking 
the next logical step, merging C into Python in a way that puts no extra 
burden on those that don't need it.  Add to that some extensions to 
Python that will make available at least the simplest techniques for 
parallel computing, and I'll bet the 99% majority will remain well served.

That's not to say the 1% is unimportant.  Here we will find brilliant 
programmers working on sophisticated techniques to break large problems 
into pieces that can be executed concurrently by hundreds of 
processors.  Each problem is very different, and we may find programs 
for circuit simulation using very different techniques than programs for 
weather prediction.  These programs will be run in an environment 
controlled by Python.  The circuit designer or atmospheric scientist 
will not be concerned about the details of concurrency, as long as the 
result is fast and accurate.

> Some food for thought:
> http://research.sun.com/projects/plrg/Publications/ICFPAugust2009Steele.pdf
>   

Excellent presentation of parallel programming.

> The "Let's Add a Bunch of Numbers" slide is a great example of how
> Python's style naturally encourages us to write code in exactly the
> worst possible way from a concurrency standpoint.
> Translating the slide to Python:
> total = 0
> for i in range(1000000):
>      total = total+i
> return total
>
> Programmers will eventually need to unlearn this kind of
> process-one-at-a-time linear thinking.  We will need programming
> languages with lots of built-in rich tree-like structures, and a way
> for specifying computations in a way that can be easily parallelized.
>  Lots of great experimentation is happening in this area -- it's only
> a matter of time before the next language revolution.
>   

The example above could be written in Fortress (or whatever is the new 
parallel language), and presented to the Python programmer as a simple 
function sum(X), replacing what is now written in C.  The Python 
programmer need not even be aware of the upgrade.  All he might notice 
is that summing a list of 10 million floats no longer takes 4 seconds, 
but appears to happen instantly.

> In the meantime, I think that a strong emphasis on topics like trees,
> recursion, immutable data structures, and divide-and-conquer
> algorithms is a great way to future-proof our students and prepare
> them for the "next big thing".
>   

These are good topics for future professional programmers who might be 
in that elite 1%.  I don't think other technical professionals will need 
to understand parallel programming, any more than they need to 
understand how modern pipeline processors execute instructions faster 
than if they were finishing one before starting the next.

All bets are off if Wintel continues to successfully defend its version 
of Moore's law.  Then we will need all those multicore processors just 
to balance our checkbooks.  :>)

-- Dave

************************************************************     *
* David MacQuigg, PhD    email: macquigg at ece.arizona.edu   *  *
* Research Associate                phone: USA 520-721-4583   *  *  *
* ECE Department, University of Arizona                       *  *  *
*                                 9320 East Mikelyn Lane       * * *
* http://purl.net/macquigg        Tucson, Arizona 85710          *
************************************************************     *