[Edu-sig] Why Python?

[kirby urner]

On Tue, Apr 13, 2010 at 11:02 AM,  <chris at seberino.org> wrote:
> On Tue, Apr 13, 2010 at 10:30:49AM -0700, David MacQuigg wrote:
>> 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.
>
> I agree.  When speed isn't important, there is no reason to welcome the added
> complexity of concurrent programming.
>

Lets not exaggerate the current standing of Python within industry.

The technicons in places like Indonesia still mostly don't teach it,
pretty new in the Philippines etc..

Singapore / Pycon may turn some heads, but a lot of production work is
done in other languages besides Python, such as Java, VB, Perl and so
forth, and this is as it should be.  Mathematica is one of the most
prevalent languages and I don't see Python eclipsing it (or vice
versa).

J has its niche in the financial sector they tell me, an arena in
which Python has only just emerged as a contender thanks to its now
sporting a decimal type written by Facundo Batista and implemented by
Facundo Batista, Eric Price, Raymond Hettinger, Aahz, and Tim Peters.

All I'm saying is that Python is not now and never has been the King
of Languages, nor is it my impression that it's bucking for that role
(it's not my impression that geekdom even has such a job opening).

Python "plays well with others" which means it expects to have others
to play with, many others, including concurrently.

New languages are and will be coming down the pipe, like Go most
recently (a candidate implementation language?) and Python's
capabilities will change depending on what it's written in.

PyPy allows what by today's standards could be considered freakish
behaviors, more normal to those frequenting exotic circles -- like
Cirque du Soleil (currently with tents here in Portland).  Fresh ideas
for language features will likely keep coming from that test bed.

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

I'm thinking of a buzzbot I know about, by Portland Energy Strategies
(Patrick Barton et al).  I've posted about it before over recent
months.

Also, think about Twisted, the basis for vast multi-user games.

You might think Python couldn't hold its own in such a server
intensive interactive environment, but here the approach is to take
maximum advantage of asynchronous architecture.

That being said, I'm not suggesting only Python is ever used.  The
whole idea of a "glue language" is you have other things to glue.

I don't think Python's global interpreter lock is always the big
bugaboo some people consider it to be.  Concurrency has many meanings,
and is an issue computer science has been tackling regardless of the
number of chips.  What's true about Python is it's designed to shield
programmers from wanting or needing to know much about machine
architecture.

You have sockets, ports, tcp/ip, various pickling and packaging
protocols (like json), but you're not thinking in terms of chips or
individual registers on those chips.

Does this mean I think Python has a realistic chance of completely
replacing Erlang as a cell phone language?  No.  Why would anyone
wanna replace Erlang?  They should be teaching that at New Mexico
Tech, no?

Promela anyone?
http://en.wikipedia.org/wiki/Promela

> Interesting observation.  Python would still be useful in a world with
> concurrent tools as a glue language at worst.

In my view, the information services have a challenge to keep training
a few students in esoteric so-called "dead" languages.

Their "deadness" mainly involves their not evolving any more, yet they
may have significant workaday responsibilities and continued
maintenance of their applications remains paying work for many people.

FoxPro, MUMPS, COBOL some would say Smalltalk, APL -- these are "dead
languages" in the sense of being frozen APIs.  Ada, Perl 5.x, Logo,
Algol... all dead, and yet we could still use some help with projects
implemented therein.

I remember working with Bernie Gunn on his Pascal stuff.  Even if the
goal is to migrate to Python (or maybe Java, or both), you still need
a working knowledge of the source language to move to the target
language.  Bernie the geochemist in New Zealand.
http://www.geokem.com/

I'm thinking the approach taken by the classics and antiquities
departments will come into play.

How do we get students interested in Sumerian?  I spell SuMerian with
a capital M sometimes (like camelcase) to remind myself of this
challenge.

M stands for the M-language or MUMPS, a paradigm "dead language" still
in use to this day, a good example of the kind of esoteric dead
language that only a dwindling number will know.  UC Davis still
teaches M I'm pretty sure.  Anyone know?
http://www.vmth.ucdavis.edu/m/m_faq1.htm

The work / study programs of the future will need curricula that
continue to produce competent programmers in these various languages.
A popular combination will probably be:  learn one or two "hot" or
"avant-garde" languages (whatever is in vogue, say Haskell), one
workaday "old faithful" too maybe (like Java), and then one esoteric
retro language that still nets you interesting clients and gigs from
time to time.  That could be Fortran, Pascal, even VBA.

Then of course there are still the assembly languages, special to each
chip.  The Art of Computer Programming keeps the focus more to that
level, where thinking about registers *is* important.

Python is about to join the ranks of the dead at least temporarily,
thanks to this recent PEP mandating a feature freeze, giving the
librarians and 3rd party package developers a chance to catch up.

I think this decision wins high marks for Python as a mature
development community.

Now that the major leap to 3.x has been made, people are willing to
step back and wait for more of the assets to get over the hump.

Kirby


> _______________________________________________
> Edu-sig mailing list
> Edu-sig at python.org
> http://mail.python.org/mailman/listinfo/edu-sig
>