not safe at all

[Tim Daneliuk]

Dennis Roark wrote:
> 
<SNIP>

> 
> Python is an attractive language.  But for a large program I
> would still rather be forced to declare the name of a
> variable (and its type) rather than risk misspelling or
> misuse 500 lines later in the program.  My original note was
> not intended to be an indictment of Python, but only to
> bring up some reasons that for me make more strongly typed
> languages like C++ or Object Pascal better at coding very
> large projects.
> 

Umm, the world's largest systems are not written in C++ or even C.
I spent almost 10 years at UAL's Apollo Reservation system which was
the largest commercial transaction system in the world (probably still
is number one or two).  All the core system was written in *assembler*
running an OS that had no memory protection.  Yup, a bad application
segment could take down the whole business.  Why?  For SPEEEEEEED.

I have programmed extensively in C, assembler, BASIC, PL/M and a some
in C++, Forth, Pascal, AWK, Perl, Java...  For my money, I have *never*
seen a language more suited for rapid applications development - even
pretty good sized applications - that strongly encourages the programmer
to write clean, easy to read code, than *Python* - this after only a
month or two of fiddling with it.

The academic debates about early- vs. late binding, static- vs. dynamic
typing, procedural- vs. object, and so on mean very little in practice,
in my experience.  The thing that is never taught in language design
and compiler classes is that what matters to the programmer is
*safe and readable ***SYNTAX*** with predictable semantics*.  The rest
of it is of interest only to language implementors and designers.

Furthermore, bear in mind that code "portability" is no where near as 
important in the commercial sector as it is in academics.  Commercial
applications are typically the largest around.  They are purpose built
to do things which distinguish their company from the pack and create
unique value-add.  It is rarely important to be able to move code
around at will.  What *is* important is code *reliability*, *cost of
ownership*, *readability*, and portability of *programmer's skills*.

In this light, C++ is an abomination.  It was a really good research
exercise which demonstrated just how flexible the whole Unix paradigm
really is for making things extensible, but as a production language
is it clumsy, ugly, hard to read, and full of subtle semantic traps.

In the past few years I have been a technology executive in a variety
of companies.  In every case, unless there is no other way out, I have
stopped the use of C++.  I'd rather see people coding in perl, awk, or now,
python by a bunch.  The cost of maintaining and owning C++ is demonstrably
higher than any of the alternatives.  It is a systems programming language
in OO drag and has the worst of all possible worlds - the ease of shooting
your foot off that a systems language has, the complexity of OO, and
syntactic obscurity that does little more than preserve the Programming
High Priesthood.  It is thankfully dying a slow death precisely because
there are much better choices.

Applications programmers need to do different things in different ways
than Systems programmers.  No language can serve both well, in my experience.
IMHO, that's why C++ failed - it tried to be all things to all programmers
and ended up being a convoluted mess. 

------------------------------------------------------------------------------
Tim Daneliuk
tundra at tundraware.com