A really bad idea.

[Russell E. Owen]

In article <3DD44152.69795B9F at alcyone.com>,
 Erik Max Francis <max at alcyone.com> wrote:

>"James J. Besemer" wrote:
>
>> I collect pocket reference guides, and FWIW, Python's is the largest!
>> 
>> Perl 5 (including libraries) is only 48 pages.
>> 
>> I have C/C++ pocket refs that work out to 8 pages for the language and
>> 8 pages for the libraries.
>
>I think what's making the difference here is the quality/depth of the
>reference guides, not the actual languages.  A "C/C++" reference that is
>a total of 16 pages simply not comparable to a Python reference that is
>124 pages.  C and C++ (two different languages, by the way) are not
>about 8 times simpler than Python.  Far from it, in fact.

I agree. I'd say that the ratio of power to pitfalls is one very good 
way to gauge a language. Consider C++ and Python in that light:

C++ has many nasty pitfalls. Sources of trouble include the lack of 
garbage collection, the use of pointers, a complex object implementation 
and strong typing (which plays hell with collection classes). Several 
entire books are devoted to subtle ways you can shoot yourself in the 
foot with C++ (I have Meyer's Effective C++ and More Effective C++ and 
found them very useful). It's so bad that I cringe whenever I use C++ 
classes (did I remember to disable copying and related methods, or 
support it specially in some way? are my destructors really solid? am I 
doing things the virtual way or not depending on future plans for 
inheritance?). 

Contrast that with Python. Python has most of the features of C++, 
including classes, collections, multiple inheritance, exception 
handling. Yet these features are much easier to use (admittedly at a 
small hit in power, but it's a tradeoff I heartily endorse) and Python 
has many fewer pitfalls. A book of cautions would be very short -- 
perhaps a worthy chapter in a Python reference manual, but no more.

With regards to Perl, I favor Python for some of its other virtues, 
including readability and self-consistency.

In my experience, the only language I've used that comes close to Python 
for power, ease of use and overall enjoyable programming is Smalltalk 
(which is more self-consistent, has better collection classes and a 
much, much better development environment, but of course also has its 
own weaknesses--including it's pretty hopeless for short scripts). Ruby 
looks very promising, but I've not learned it. The bits of Lisp I 
learned were promising. LabView is quite amazing in some ways.

So when you see me pontificating about perceived warts in Python, I do 
want to say I speak up because I love the language. Python is great and 
I'd like to see it evolve to ever greatness (and certainly not towards a 
morass of clutter and featuritis).

In trying to kill 3 birds with one stone, I also want to say something 
about division. As I understand it, the primary reason to change / so it 
never truncates is because if you are dividing two variables, you may 
not know in advance whether they will be floats or integers. The new way 
allows you to consistently get a given result. Note that this is 
entirely a nonissue in C/C++ because of its strong typing. I personally 
heartily endorse the new way of doing things and heartily thank Guido 
for taking this stand. Change is very painful, as is not doing things 
"the C way", so it's bound to cause anguish.

-- Russell