OO misconceptions

[Tim Hammerquist]

Me parece que Alex Martelli <aleaxit at yahoo.com> dijo:
> "Tim Hammerquist" <tim at vegeta.ath.cx> wrote in message
> > 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.

A person's aptitude for learning a given concept is largely affected by
the person's willingness.  This is demonstrated by hundreds that
frequent programming newsgroups (all of them), as well as by millions of
high school students nationwide (in the US).  "Willingness" is not
something that can be rationalized into existence by talking, reasoning,
or even yelling. (Have you ever dealt with teenagers? Then you
understand! =)  Doing a "study" would require a quantification of an
abstract thing such as "willingness", "open-mindedness", etc; I leave
this for marketing and advocacy people.

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

Yes.

> Would it
> lead you to conclude that "Fortran is preferable to Perl for
> certain tasks regarding extraction and reporting of lines
> from textfiles"?

Umm, no.  Why?  Would you like to take anything else I say out of
context?  My point was made. You understood what I was saying, and now
you search for loopholes in my words.  Why?

BTW: very subtle use of words: "extraction" and "reporting"; however:

$ perldoc -q '"perl'"

       [snip] ... perl isn't really an
       acronym, apocryphal folklore and post-facto expansions
       notwithstanding.

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

Or did you actually not understand what I said?  "Ability to use" in the
sense that, say, if a Pythonista can't get past the curse-characters in
a Perl script, they're not very "able" to "use" Perl, are they?
Therefore, they will be much more productive using Python than they will
with Perl.

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

Hence the statement below.  I'm not content with my current knowledge of
Python, therefore: I am here in cl.py and learn more about
idioms, new developments, standard modules, etc.

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

I meant Java's tendency (as C/C++) toward syntax errors.  Java's
execution speed is a thread I have no time 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:-).

Two major tripwires to Perl: context, varied control structures with
implied meanings.  Perl syntax is not near as clear-cut and
self-explanatory as Python's, and most in this NG consider this a plus
for Python.  But if understanding these concepts speeds development time
for someone using Perl, doesn't this support your argument?  Given
proper indentation and half-decent var names, I find most documentation
of Perl code unnecessary.

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

Ah, but I grasped the concepts and said, "Ooh!  So I can do this...and
this... and this...", etc.  It was beautiful!

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

Advocacy has never been my calling.  And while I may not love the way
some people mention Perl, I don't have to.  My desire to learn more
about Python outweighs the cons.  Nor must I convince you that Perl's
existence is justified.  It's not my job to teach you about Perl. I'm
sorry you didn't get the level-headed discussion you said you wanted,
but honestly, did you ever think it would happen?

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

Every NT host so far has had Perl installed, hence my website in
ASP PerlScript.  

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

Abigail on clpm helps develop Perl. She can probably answer your
questions much better than I.  I never asked for a debate about
Python vs. Perl.  Any actions misinterpreted as such are strictly
coincidental. (Although I have enjoyed some of your retorts.)

Cheers.
-- 
640K ought to be enough for anybody.
	-- Bill Gates (circa 1981)