Python vs. PHP (& Java?)

[Alex Martelli]

<rturpin at my-deja.com> wrote in message news:92iie9$lg3$1 at nnrp1.deja.com...
    [snip]
> Turpin:
> >> Knowing one-tenth of Perl is not enough to understand
> >> most Perl scripts.
>
> Martell:
> > Of course not, but, it IS enough to _write_ a lot of
> > somewhat useful scripts ..
>
> Your use of a computer language is fairly limited if
> you can only WRITE it. Software engineering requires
> the ability to READ. And not just what you once wrote,
> but what others have written, including others who have
> been using it for years and know all the idioms and
> tricks. Even though they are long gone. This is why

Russell, are we talking software engineering, or are we
talking Perl?  You're making me dizzy with these continuous
switches between these completely unrelated subjects.

I'm not saying that Perl is a write-only language, not for
ALL, but I do maintain it is for many of its 'millions' of
'casual' users -- the ones who keep posting to c.l.perl
groups about how to do perl-unrelated CGI tasks even
though they DO get flamed to a crisp each & every time.

Such users (I claim, without rigorous empirical studies to
back me up, but, a LOT of anecdotal evidence:-) master
10% or less of the total language.  There being an average
of 7.2 ways to get any given task done, that fraction still
lets them do over half of what could be done in all, which
ain't bad, though they DO get headaches.

They don't claim to be software engineers any more than
typical foreign speakers of English claim to be scholars
in that demanding field.  They just get by... but they DO.
Mostly.


> an after dinner conversation. The interesting and hard
> productivity question is not how long it takes a
> beginner to complete a task, but how much effort it
> requires a group of professionals to maintain a sizable
> product, over its lifecycle. (This isn't meant as
> criticism of  those who want to use Python for teaching
> or personal use. It is a very good language for both
> purposes. But my interest and most of my comments are
> from the viewpoint of professional use.)

So, both questions are interesting, given that both users
(beginners and professionals) are in the language's target
market.  There need not be as much contrast as one
might think between their interests, I believe.

> simultaneously. A rich language that admits multiple
> meaning and implication is very useful. If you want to
> look for adaptation, sexual selection may have more to do
> with this than natural selection. A silver tongue will
> not save you from the lion or bag the deer, but it will
> win a heart.

Sexual selection, particularly female-choice, IS very much
a part of natural selection -- why male peacocks have
absurdly long and rich tails, etc.  "Survival" of the fittest
is the least of it -- *reproduction* is the name of the
natural selection game, and survival only adaptive in as
much as it serves reproductive purposes.

(Though in our specific cases, I'm convinced memes took
over most control a long time ago, but that's _another_
debate:-0).


> > 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.
>
> Yep. Keep in mind that only the implementation team has to

Plural, please.  Think how many C++ compilers there are, or
where, on the market.  Or, for Python: CPython, Jython, .NET,
Vyper, Stackless, other possible variants; also, the reference
implementation's clarity and simplicity encourages others who
are 'at the margins' of "the implementation team" (e..g, me)
to get gradually more involved.

> tackle the complexity of optimization, whereas the world has
> to tackle the complexity of language and semantics.

But complexity of language/semantics influences complexity
of optimization; and since the latter brings optimizer bugs, it
can affect all users (of a given implementation).  So it's not
as cut-and-dry as all that.

> > .. (from your excellent diagnostic-manual on quack
> > theories) ..
>
> It's amazing how one post in sci.med fifteen years ago has
> taken on a life of its own. I would rather you criticize
> my recent proposal for caching attribute and method
> references.

I won't, because it seems quite reasonable to me, and I'm
trying to puzzle over criticisms made by people who understand
the internals far better than I do.  Also, I do NOT understand
exactly where the time is going -- instrumented runs are
telling me that quite clearly.  E.g., on list comprehensions: I
*thought* tweaking allocation would help a lot; Tim Peters
reminded me of a thread back in August, in which I had entered
though I didn't recall that, which must have been what gave
me the idea, since somebody reported a simple patch with
huge benefits; but, having applied that patch, I cannot for
the life of me reproduce the claimed performance pluses.  So,
I'm busy trying to revise my mental performance model of
Python -- which makes my generic ideas about "caching's
always nice" not a very sharp contribution at this time.


> BTW, didn't we meet once?

Yes, we did.  Well before I met Python, actually.


Alex