Python vs. PHP (& Java?)

[Alex Martelli]

<rturpin at my-deja.com> wrote in message news:92fv4a$l2l$1 at nnrp1.deja.com...
    [snip]
> 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.

Are you implying that this _doesn't_ happen a lot for
many written texts in natural languages...?  Literary
analysis is all about such work, after all -- and courts
and lawyers do a lot of that on laws and constitution
articles.

> Knowing one-tenth of Perl is not enough to understand
> most Perl scripts.

Of course not, but, it IS enough to _write_ a lot of somewhat
useful scripts -- I doubt most casual Perl users are above 10%
in their knowledge and understanding of that extremely rich,
complex, and idiosyncratic programming language.  Yet, use
it they do -- and they get some useful work done thereby (as
well, no doubt, as their share of headaches).

The parallel with your anecdote about asking for the toilet's
whereabouts in Japanese is pretty telling, I think:-).

Of course, it's all a matter of degrees -- of shades of grays,
rather than of blacks and whites only!  So, what else is new?

Nothing "is EXACTLY like" anything else (Korzibsky would
insist on such firm avoidance of "the IS of identity", but, as
he doesn't seem to be following this newsgroup regularly,
I'll have to play his role, I guess).  There are always some
distinctions to draw, as well as, often, some similarities,
parallels, or analogies, to notice and meditate upon.

So, when somebody proposes an analogy which most might
consider inappropriate (and parallels between natural and
programming languages are a frequent case), I try to play
the game -- arguing my corner (if I have one -- else, I
just pick one that seems like it might be fun, or of some
challenge, just like one did back in debating-matches:-),
in part, by embroiding on those parallels.  Why is a raven
like a writing desk?  Well, both might be well modeled in
Python, Poe wrote upon both, and, of course, there IS a
'b' in 'both'.


Seriously, for a sec -- I understand, and, of course, agree,
with most of what you're saying.  In actuality, the closest
real and applicable parallel between programming and
natural languages may be based on what they DO have in
common: the human mind.  Learning a new language, in
either sense of the word, can always be a broadening
experience for that peculiar, quirky, interesting organ --
one different from your current knowledge-set even more
so, for the usual 'triangulation best done from distant
basepoints' reasons.  It's a paradigm issue -- I know
(from your excellent diagnostic-manual on quack theories)
that you have a healthy and well-justified dislike for this
word, but here, for once, it IS used appropriately:-).

*Using* a language is subject to different constraint and
uses than *learning* it, of course... and, most often, it's
what one is debating about *programming* languages.


> 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.

In other words, (natural) languages are NOT formulas, because
human _thoughts_ aren't -- they're biological phenomena, not
mathematical abstractions; the key intuition that distinguishes
the mature works of Wittgenstein from his youthful Tractatus.
Yes.

Go further, though: 'mathematical' languages are *bridges*,
between human minds and thoughts on one side, and abstract
symbol-processing engines/environments/settings (real or not
as the case may be) on the other side.  When using them, it's
not *fully* the case any more that "whatever we're talking
about, we're talking about the natural history of human beings",
to restate the key mature-Wittgenstein's insight in his own
words; but, surely, it's still *partly* the case, in as much as
human minds are involved in creating, shaping, using them.

It's from their bridge-nature, I think, that key characteristics
of 'mathematical languages' follow.


> 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."

Right -- *because* there are still human beings involved,
though, *as well* as "theoretically less-quirky" symbolic
processing systems on the other side.  Our mind's ability
to grasp and manipulate symbolic abstraction has limits
(ones which an evolutionary psychologist would have good
'just-so stories' ready to explain, but let's not anger S. J.
Gould needlessly by repeating them, shall we).  Simplicity's
power comes from that.

The complexity of natural language springs in good part from
the _adaptive_ characteristics (pace Gould...) of ambiguity in its
use; words serve to hide, as much as they serve to show.

Ambiguity and misunderstanding play no similarly adaptive
roles when we're interacting with an abstract symbol processing
environment (although, even there, human biological traits
are never fully absent -- using a needlessly complicated and
tricky tool may be a way to 'show off', much like a tail so
long, heavy, and showy, that it makes running away from
predators much harder, may be for a male peacock.  "See
what big brains I have, *I* can handle this horridly complex
language even when there's no real need to, *I* am the alpha
male here!", in other words).  "Hiding", as in "information
hiding", is a tool for further _simplification_ here -- one form
of abstracting away what we don't have to keep in mind right
now, so as to minimize the clutter in our thought.


> 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.

*Full* agreement here.  "Perfection is reached, not when
there is no longer anything to add, but when there is no
longer anything to take away", in other words (not mine,
of course; but, still, from yet another one of my favourites
among this century's thinkers:-).

Actually, pragmatic issues _augment_ the relative weight
of language simplicity, so I'd revise your formula to
something closer to expressive-power divided by
complexity _squared_.  A simpler language, as well as
helping in terms of not cluttering its user's mind with
more complexity than absolutely necessary, is also liable
to have simpler *implementations* -- and a simpler
language-processor (compiler, interpreter, whatever),
all other things being equal, will be more robust, easier
to port, faster, more adaptable to new environments.  All
big potential pluses in pragmatic terms.

Alternatively, of course, great complexity in implementation
MIGHT be spent towards such targets as optimization, as
you were interestingly arguing Python should be doing now.
But, even if a strongly-optimizing language processor,
being more fragile, exists more precariously, it IS still good
to have a simple, clear, transparent "reference implementation"
to fall back to...


> 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

..._and_ potential for top-notch *run*-time efficiency, too...

> bigger than its expressive power requires. But that set
> of goals is hard to achieve, and to its credit, C++ does
> this.

Again full agreement, and it's hard to find somebody whose
thoughts on these specific issues match mine as well as yours
do (of course, I'd have taken twice as many words to say the
same things less effectively, but, that's just me:-).  People
who appreciate simplicity for all the right reasons often fail
to grasp that C++ is probably pretty close to the best design
*that matches all of its design-goals* -- which, of course, is
not to say that one can't criticize it!, if nothing else because
its complexity proves how overly ambitious all of those goals
were when pursued at once:-).

> 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.

Not sure about that.  Its design goals DID apparently include
rich, exhuberant, redundant abundance -- it seems to have
matched them closely.  Again, of course, just like for C++,
one can then reflect on the appropriateness of those design
targets, by reasoning backwards from the design that meets
them (again, I guess, meets them pretty well).


> 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.

Right -- I guess I shouldn't have used "somebody with a
loaded gun at my head" as the _typical_ constraint making
Perl usage pragmatically preferable.  Chalk it up to typical
Latin exhuberance... it *is* a constraint that would be pretty
convincing to me.  Faced with other, less-strict constraints
(easy to find free/cheap web-hosts offering Perl for user
written CGI's -- hard for Python -- just for example), I've
chosen to postpone putting up a CGI-enriched personal
website (actually, I don't really have a personal website
at the moment, as magenta took my old one down and I
haven't found another satisfactory host yet); as for the
preferences of companies, with the kind of job market for
programmers that has prevailed over the last 2-3 years,
I'm not sure how much weight I would give to keeping a
job with a company so benighted as to prefer Perl.  Darn,
here I am, exhuberating yet again -- gotta watch it!-)


Alex