OO misconceptions

[Tim Hammerquist]

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.  For this reason, for a given application, I might reach for
Perl before Python because I have more experience with it.  However, I
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!)

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

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
apply to choice of language as well.  To quote a book I read: "Be quick
to see where religious people are right. Make use of what they have to
offer."  And who _isn't_ religious in a programming language war?  ;)

> It seems to me that the niches of applicability for Python and
> Perl are totally overlapping: I cannot think of application
> areas where Perl would be preferable, except, I guess, if there
> were deployment constraints, such as those above-quoted or
> similar ones (e.g., say you're allowed to use mod_perl but NOT
> mod_python & similar Apache mods, then it might be unfeasible to
> do certain things in Python; or, similarly, if there was some
> crucial module already existing for Perl and it was unfeasible
> to port it for Python).  Similarly, I cannot think of application
> areas where Python could make sense but Perl wouldn't, except,
> again, for possible deployment constraints (need to use Jython,
> or Numeric, etc etc).  So what are those "application areas where
> Perl is clearly preferable to Python", and vice versa, that make
> it worthwhile to use both languages for new development (not just
> maintenance of legacy stuff that one prefers not to port)?  Are
> you just referring to deployment constraints ("I'm not allowed to
> use mod_python but mod_perl IS allowed", &c) or is there something
> deeper that I'm missing?

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

-- 
Things need not have happened to be true.  Tales and dreams are the shadow
truths that will endure when mere facts are dust and ashes, and forgot.
    -- Morpheus, The Sandman