OO misconceptions

[Alex Martelli]

"Tim Hammerquist" <tim at vegeta.ath.cx> wrote in message
news:slrn9l9k6t.va1.tim at vegeta.ath.cx...
> Me parece que Alex Martelli <aleaxit at yahoo.com> dijo:
> > I wasn't part of this discussion, but since, for once, there
> > does seem to be a chance for a fair-headed, non-flaming
> > comparison, I'd be loath to see it fizzle out with an "agree
> > to disagree" when no technical issues have been discussed
> > (it seems to me).
>
> I cling to the philosophy that there is no "better" language and that a
> programmer's ability to _use_ it is more important than benchmarks or
> syntax.

It can be -- while I know of no studies directly targeting this,
Prechelt's results do confirm that variations between programmers
using the same language are at least as large as variations
between median values of metrics for different languages.

However, as long as we're talking about plausible as opposed to
proven results, it seems to me that it's quite likely that this
situation is *temporary*.  Consider a programmer who knows
Fortran quite well, and Perl not at all.  She needs to print
all lines in several files that meet certain criteria.  It is
quite possible that she can hack a Fortran program for the
purpose in less time than it would take her to learn enough
Perl for the purpose.  If this is the last time in her life
that she needs such a task performed, it would thus be quite
cost-effective for her not to learn Perl at all.

But does this line of argument make sense to you?  Would it
lead you to conclude that "Fortran is preferable to Perl for
certain tasks regarding extraction and reporting of lines
from textfiles"?  That would look to me like a wrong-headed
way to frame the situation.  It's quite unlikely that a task
in a sufficiently wide class, such as this one, presents
itself for the first and last time in a programmer's career
(*possible*, since the programmer MIGHT die tonight: but,
NOT *likely*).  Most likely other tasks in similar fields
will appear again and again.  The programmer who devoted the
reasonable amount of effort to keeping her own skills up to
date (and ancillary deployment efforts, e.g., downloading and
installing a Perl interpreter on a machine that used to have
only a Fortran compiler installed) will therefore, most likely,
soon be better off than the one who sticks to the tools she
is already highly productive with -- *IF* the new tools do
indeed present an intrinsic advantage over the already-known
alternatives.


> For this reason, for a given application, I might reach for
> Perl before Python because I have more experience with it.  However, I

Assuming for the sake of argument that the general class of
application is one where Python has intrinsic advantage (as
opposed to one where the two P languages are more or less
equal, or one where Perl has advantage), this might be short-
term sensible but long-term inferior, as above sketched.  I.e.,
you may get your current task done faster, but over a longer
period of time still enjoy lower overall productivity.

Which is why I believe it's potentially more interesting to
unearth the 'general classes of applications' where the
intrinsic advantages and disadvantages lie.  I suspect many
important application categories will show, roughly, a draw,
assuming highly developed knowledge of both languages by
the same programmer -- at least, this is surely what Prechelt's
results suggest (hard to find ANY statistically significant
difference between Perl and Python in those tests).  But this
is like trying to compare two restaurants by listing the huge
list of things they have in common; for _comparison_ purposes,
finding out that Chez Albert has vastly better Yorkshire Pudding
while Da Bodillo shines in deep-fried Camembert dishes is more
meaningful, no matter how marginal such culinary details may
be in the overall picture of running a good restaurant.

> am not content with "just getting by" in a language if I have an
> opportunity to learn more (as long as it doesn't piss me off with every
> :w<CR>:!javac %<CR> ... but I won't mention any names ... oops!)

A *FAST* Java compiler would surely do wonders for that
language's approachability, but that's another issue:-).


> > Declaring my bias: I am "violently anti-Perl" myself, mostly
> > because I wrote a *LOT* of Perl code (and helped others write
> > it, and maintain it, and maintained a lot myself, etc, etc).
> > If Python wasn't around, I'd probably still be doing so (and
> > hating it) for lack of viable alternatives.  Since discovering
> > Python, I moved to Python all code I had in Perl.  When asked
> > for help, advice, &c, about maintaining Perl, studying Perl,
> > &c, my invariable answer today is "do it in Python instead".
>
> I respect your honesty.
> Granted, Perl had the longest and steepest learning curve since C++ for

Personally, I found Perl the only language with an even steeper
and longer learning curve than C++ -- which, I guess, is part of
why I'm a C++ Brainbench MVP but definitely *NOT* a Perl one:-).

But it's more of an issue of "what are the alternatives".  I still
don't know of any real alternative to C++ for *its* strengths --
and believe me, I *HAVE* looked -- just consider two daily tasks
for me, writing small, fast components that directly interface to
system libraries for use as COM servers and as Python extensions:
with C++, ATL gives me COM serving, Boost Python gives me Python
extensions, the rest of Boost and the C++ Standard Library and
lots of other free libraries give me lots of wonderful reusable
stuff -- and even mediocre C++ compilers such as Microsoft's give
me great performance.  Eiffel, O'Caml, Dylan, Modula-3 -- and
many others -- tried them all, liked some things, disliked others,
but where's all of this indispensable infrastructure, for free,
at my fingertips...?

While, for Perl, I *HAVE* found an alternative, at long last... if
and when I ever find an equally "dominating" alternative to C++ I
may have a similarly-violent reaction to it:-).


> me.  But after grasping the concept of "context" and learning to use
> Perl's m// and s/// operators to my advantage, I find I can just
> accomplish more faster than with most other languages, even (so far)

I was in the same situation 2 years ago, to the day.  Which is
why I used Perl, even while detesting it -- for many tasks I was
more productive with it than with any other language.  (I never
detested C++ as deeply as I resented Perl -- the design strategy
for C++, while crazily ambitious in all it wanted to accomplish,
never struck me as wrong-headed as much as the _deliberate_ choice
to have as many redundant ways to express the same thing as could
fit in a single, poor, over-bloated interpreter program).

> with Python.  Having come from GW-BASIC, I had slightly less trouble
> grasping the whole "curse characters" bit. <wink>

Having come from APL, then APL2, I had and still have a deep
appreciation for what abundant use of special characters can
do for you.  That's not the real, deep problem for me (and I'm
less interested in syntax-sugar aspects than 99% of all
programmers, I think).  Rather, it's the over-abundance of
purported-to-be-"convenient" irregular special-cases that
still has me gnashing my teeth in dim memory (I've forgotten
as much as humanly possible about the subject over the last
two years -- a common after-shock victim reaction, I'm told).


> BTW: I have benchmarks (I think fair ones) where regex parsing is faster
> than string parsing.  I've taken pains to optimize the string parsing
> function.  I think my point is, whether advocate of regex's or
> string-parsing, be willing to see the other's strengths. This might

Regular Expressions are one of those subjects where I *wish*
there were better solutions, but I'm resigned to there not being
any (not sufficiently general ones, etc) -- so I do the best I
can in terms of using, teaching, and so on.  But when examining
a specific case where parsing is needed of course I'm aware of
various specific cases where other approaches dominate RE's.

Which is why I'd like to be shown the *specific* cases where Perl
dominates Python.  Knowing of a few, net of transient effects
such as a given programmer knowing one and not the other or
other deployment issues, would help reconcile me with Perl's
existence:-).

I can easily see such specific cases where the languages' niches
are far enough from each other.  If I have a class of problems
where logical-programming and backtracking can be used to very
good effect, for example, it seems quite reasonable to me that
Prolog (or Mercury or Mozart or ...) may be strongly preferable
for such problems to languages that are deeply imperative at
their core (Perl or Python or C++ or whatever).  It's when the
niches are very close, that problems seeing the specific areas
where one language or the other is preferable loom larger.

And I'm not particularly interested in deployment issues, e.g.
"Javascript is better because it runs client-side portably" --
that's just because of Netscape's quondam silly decision to
invent Yet Another Scripting Language for inclusion in their
product; Javascript, *qua* language, doesn't appear to me to
have anything to justify its existence (in fact I detest it
even more than I detest Perl -- at least Perl is powerful, for
all of its complication and awkwardness, while Javascript
manages to have the complexity and "ad-hocness" WITHOUT a
significant amount of power to show for them...!-).


> In web developing, where I can't necessarily convince my clients to use
> a host that provides the tools I'd most like to use, Perl is more
> readily available than Python, and especially more so than

Apparently your clients aren't wedded to NT...?  Because in that
case you might get VBScript as your sum total of readily available
tools... either Perl or Python requiring a download-and-install
(worst case for most boxes, today, surely).

> mod_p(erl|ython).  Python seems to be catching on in a big way, though,
> especially with it's standard inclusion in many linux distros.  But when
> I can't get the tools I'd like, Perl/Python's overlapping applicability
> is really a blessing, no?  Either that's there, I know I can do what I
> need to do.  <wink>

Sure, and if you get proficient in VBScript, you're even more
likely to be able to do the job.

But meanwhile, I still haven't learned anything about the general
application areas where Perl is alleged to enjoy intrinsic
advantages over Python -- the purpose of this thread from my
personal viewpoint... if somebody knowledgeable in both languages
such as you are can't help me ascertain this, who might?


Alex