Not a flame war--curious about Python vs. Tcl

[Cameron Laird]

In article <cm6bg2$s5l$1 at gnus01.u.washington.edu>,
Aric Bills <aricb at u.wwashingtonn.edu> wrote:
			.
			.
			.
>> I can make a case that Python's the best language available
>> for large-team projects--certainly better than Java and C++,
>> and arguably on a par with Smalltalk.
>
>Cameron, can you elaborate on this (or point to resources that do)?  As a
>person who's never worked on a large-team project, I'm curious to know what
>kinds of features facilitate or get in the way of productivity in such an
>environment.
>
>

Good question.  It deserves a better answer than one I can
express in the time I'm willing to give this week.  I'll
summarize, though:

First, C++ is part of the problem, NOT part of the solution.
While I like C++, and often use it, I consider it a disaster
for teams.  It requires too much discipline, and, in group
work, inevitably leads to breakdowns and recriminations (if
only in memory management; look for "memory management" in
<URL: http://www.joelonsoftware.com/articles/APIWar.html >).

Next, Python thumps Java on readability and maintainability.
While I don't yet know how to make an iron-clad objective
case for this briefly, I'm utterly convinced that Python
programs are significantly easier to read "six months later".
This matters:  much of teamwork is dealing with source code
that one doesn't understand.  Traditionalists promote Java
as a statically-typed language, but this is just a distrac-
tion; Python's more graceful expressiveness leads to 
relatively more focus on correct algorithms and unit tests,
while Java is relatively mired in syntax.  Programming in
Java feels too often like dealing with Java, whereas Python
is a leader in letting developers think they're dealing with
the application.

Finally, at least for now, don't underestimate the extent to
which Java (like C++, but not Smalltalk) is just too *heavy*.
Even in modern computing environments with apparently slick
IDEs backed by gobs of CPU cycles and main memory, big Java
projects can bog down in the basic edit-compile-execute cycle.
They're just a drag, despite all the traditional rhetoric 
about Java's status as "enterprise-class".  Python line counts
are typically around half those of corresponding Java projects,
and, even at comparable levels, Python always gives a much
better impression of manageability.  You write a small Python
fragment, you execute it immediately; it feels good.  While
there are pitfalls in module searching which can slow big
applications, at their worst they don't cause the delays that
the Java world commonly accepts.

I hope to return and say more about this within the week.