Python advocacy

[Paul Prescod]

Brett g Porter wrote:
> 
> ...
>
> "Tape recorders are better than pianos because it's too darn hard to become
> a good piano player. It divides the world into 'musicians' and
> 'non-musicians'.  The piano suffers from an overemphasis on being backwardly
> compatible with the clavichord."

The argument is totally different because a piano *does something
different* from a tape recorder. Here goes my rant:

Ten years ago many argued that C++ was too damn complex. The industry
was told that this was necessary for large, complex systems. So we put
in the effort and became proficient in all of that pure virtual array
destructor crap. Garbage collection? That could never fly in a language
for mission critical applications! Then along comes Java. It has 30% of
the weirdo complexity and yet the same people are now building the same
big, complex systems in Java. Billion dollar valuations are being built
on top of Java code. 

One of the exciting (and frightening) things about Java is that Sun says
it can be used for everything. Embedded systems and million dollar
payroll systems alike. Telecoms and multimedia. The Full Monty. That's
frightening because it isn't my favorite language.

It is exciting because it breaks the historic pattern where language
designers excuse flaws in their language by saying "go use some other
language that's more suited to that." That kind of thinking gave us
"shell scripting" languages, TCL and other monstrosities. No language
can ever be perfect but language communities can address the limitations
of their language as limitations instead of labelling them as
"features".

I've actually been told that it is a feature of TCL that it is
inefficient because that helps you to know when to switch to C. TCL is
hard to scale because it is poorly designed, not because TCL people,
given an honest choice, would choose it be that way. Unfortunately we
are seldom presented with an honest choice. Things are the way they are
and we presume that there are fundamental reasons for that. 

Then a language like Python comes along which subsumes the abilities of
(at least) TCL, Perl, Visual Basic and ten thousand macro languages. It
is my assertion that there are no large, complex problems that can be
solved more easily in any of those languages than in Python with a
suitable library and (in the case of VB) development environment.
Obviously the smaller the problem, the more likely it is to be solved in
one line by one language or another. But our software engineering
backlog is not made up of one-line problems so they should not be
choosing our programming languages for us. Yes, you can use sh and VBA
for tiny little programs but isn't it just one damn more thing to learn?
Is it worth learning another language to reduce a 10 line program into
1?

Given that Python offers us an opportunity to avoid the code
fragmentation caused by all of these little fragmented language
communities (Perl for text processing, TCL for Unix GUIs, VB for Windows
GUIs, other Basic variants for macros), it is only natural to ask if it
can also swallow the huge category of tasks being done with Java (we'll
leave C and FORTRAN alone for now...). If Sun succeeds in making Java
popular for everything from embedded computing to supercomputing then
there will be only one language for Python to replace. Bring it on!

Well, a Java evangelist would tell us two things, which may both turn
out to be myths:

 1. that the one complex feature we still cannot profitably strip out is
type safety -- if we strip that out we won't be able to build big,
complex systems (sound familiar?) or at least efficient systems

 2. that there is no good way to introduce this feature into an
erstwhile dynamically typed language

I am told by those in the know that Common Lisp disproves both of these
assertions. You can get fast code and complex systems from a language
with an optional "add-later" type declaration system. In fact, people
write large, complex systems in competely dynamic Lisps, Smalltalks and
low and behold, Python. The people writing the largest systems seem the
least inclined to argue that the lack of a static type system is
limiting them.

It is debatably the case that static type checking systems help people
to write code that scales to large systems. It is indisputably clear
that it can help the readability of the code. It is relatively clear
that it also helps the performance without massively complicating the
implementation. That's why Python is likely to eventually grow a static
type system. Then we can shove another sock in mouth of the apologists
for languages that are not good at one thing or another.

Can there be one language that does everything? Everything? Possibly
not, but it is better to presume so and fight to get there than to
presume not and live with languages that force us to shift from one to
the next because of designed-in limitations.

A cure for cancer in our lifetimes? Certainly not if we start with the
presumption that it cannot be done.
 
> Obviously, Paul is entitled to his view that the cost of proficiency in C++
> is too high. As a proficient C++ programmer, I have to disagree. I  can't
> imagine writing industrial-strength apps solely in Python (and I do mean
> industrial -- I've got applications running in steel mills).

To be honest with you, if I was required to write an application that
was going to run in a steel mill, and I was not constrained by memory or
CPU (which you often would be) then I would choose a dynamically typed
language with automatic memory management and pointer safety over a
statically typed language without, any day. Tbe safe I would probably
use a language like Java or Eiffel with both, just to be safe.
Seriously, where reliability is an issue, C++ would be at the bottom of
my list. Dr. Watson's frequent appearance on Windows NT desktops is a
testament to C++'s reliability.
 
> I agree with all the slams against Perl, though. KILL!! KILL!!

The-enemy-of-my-enemy-ly 'yrs Paul
-- 
 Paul Prescod  - ISOGEN Consulting Engineer speaking for himself
"We still do not know why mathematics is true and whether it is
certain. But we know what we do not know in an immeasurably richer way
than we did. And learning this has been a remarkable achievement,
among the greatest and least known of the modern era." 
        - from "Advent of the Algorithm" David Berlinski
	http://www.opengroup.com/mabooks/015/0151003386.shtml