[Edu-sig] Why Python?

[David MacQuigg]

kirby urner wrote:
>> On Tue, Apr 13, 2010 at 10:30:49AM -0700, David MacQuigg wrote:
>>     
>
>>> 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.
>>>       
>
> There's a school of thought out there that says operating systems are
> supposed to handle concurrency pretty well.  Some designs boot
> multiple Pythons as multiple processes and let the OS take care of
> concurrency issues.  Why reinvent the wheel and rely on internal
> threading?  Instead of multiple threads within Python, make each
> Python its own thread.
>
> These concurrently running Pythons are then trained to communicate in
> a loosely coupled fashion by reading and writing to centralized SQL
> tables, which double as audit trails.
>
> If a process dies, there might need to kill a process (zombie snake
> problem), and maybe the controlling process (like air traffic control)
> launches a new one -- depends on many factors.
>   

As long as the coupling is loose, this kind of "concurrency" is easily 
handled by Python (either with threads, or separate processes).  The 
more challenging concurrency problems involve tight coupling, tighter 
than can be achieved with inter-process communications.   Think of a 
large system of equations, with 1000 outputs depending on 1000 input 
variables.

The challenge is in partitioning that problem into smaller problems that 
can be solved on separate processors, with manageable requirements 
relating to interprocess communication.  Strategies tend to be 
domain-specific.  If the domain is circuit design, the equations follow 
the modularity of the design, e.g. a collection of subcircuits, each 
with only one input and one output.  That strategy won't work in other 
domains, so we have no partition() function that will do it 
automatically, and (in my opinion) not much chance that some new 
language will come to the rescue.  For problems that really need 
partitioning, we need programmers that understand the problem domain.

The question for teachers using Python is - Will there be some future 
"concurrency" language that is:
1) So different that its features can't be unobtrusively merged into 
Python (not burdening those who don't need it).
2) So easy that it will replace Python as a general-purpose language, 
even for those 99% that don't need concurrency.

I'll keep an open mind.  Meanwhile, I've got to make a choice for 
PyKata.  We need to be ready for next semester.