Python vs. PHP (& Java?)

[rturpin at my-deja.com]

"Kemp Randy-W18971" <Randy.L.Kemp at motorola.com> writes:
>> Can we nip language comparisons in the bud?

In comp.lang.*? I doubt it.

In article <mailman.978018791.20357.python-list at python.org>,
  "Alex Martelli" <aleaxit at yahoo.com> wrote:
> In each case, there are some _facts_ that can be pointed
> out, ..

Yep.

And some of these facts point to the danger of reasoning
from natural to programming languages. People use natural
language for human communication. And in almost all
practical contexts, small competencies bring signficant
benefit. If you can ask where the bathroom is in Japanese,
the waiter, recognizing your deficiency in that tongue,
but pleased that you made the attempt, will point the
way. This keeps you from having to translate the Japanese
equivalent of "behind the screen with the crouching tiger."
Which is good, because your back teeth are afloat, and the
only part your limited Japanese knows is "behind."

In contrast, texts in computer languages are more studied
as artifacts. "How did this work?" "Why did it stop
working?" "What did the original authors intend?" They,
the rascals, are no longer around to explain, take credit,
or defend their honor. This kind of comprehension requires
a high level of competency in the language. Knowing
one-tenth of Perl is not enough to understand most Perl
scripts.

Computer languages have more precisely defined semantics
than natural languages. The niggling details are important,
such as what "[[0]*10]*3" means. Natural languages are
more fluid, and it is the nuances of the tacit, multiple
meaning, and almost ambiguous that are important in their
competence.

For these reasons, I am a great believer in small computer
languages, ones that can be explained well in a book no
thicker than my pinkie. The use of extentions should be
recognizable, so that when you come across something you
don't know, you know *what* to look up and where to find
it. "One way to do everything" IS better than "many ways
to do anything."

Of course, being small has its hazards, if core features
are omitted. That's why I am fond of saying that a language's
productivity is proportional to its expressive power, and
inversely proportional to its complexity. (Not that these are
the only considerations.) That is why I am happy to see
Guido resist the temptation to continually add new bells and
whistles.

People tend to focus on the benefit of expressive power,
while overlooking the problem of complexity. C, Lisp, and
Python are examples of languages that pack a lot of
expressive power into simple packages with a small set of
orthogonal concepts. C++, trying to build OO on top of C
while retaining maximal compile time efficiency, grew
bigger than its expressive power requires. But that set
of goals is hard to achieve, and to its credit, C++ does
this. Perl is overly complex for what it does. I think
this was due to its syncretic history, rather than the
scope of what it achieves. Like Alex, I can't imagine any
task that, from a pure language viewpoint, is better done
in Perl than in Python. Practical constraints, such as
a company's preferred language, or which language someone
already knows, could determine otherwise.

Russell


Sent via Deja.com
http://www.deja.com/