Python vs. Perl, which is better to learn?

[Alex Martelli]

Isaac To wrote:

>>>>>> "Alex" == Alex Martelli <aleax at aleax.it> writes:
> 
>     Alex> For example, class and struct are two keywords which are exact
>     Alex> synonyms except for a different default visibility until the
>     first Alex> private/protected/public keyword in the class body -- this
>     should Alex> make it obvious that there is redundancy here.
> 
> Then two comment styles (or actually, 3) is redundent?  How much more

Sure, completely redundant, obviously.

> difficult to learn one more alias?  Just like multiple comment style, they
> serve to communicate programmers' intent:

Multiple comment styles serve no "programmers' intent communication purpose"
since different programmers will mix them according to different guidelines
(or none).  If you want to make your own in-rules for how to delineate such
distinctions, there is still no added value in the language allowing you N
different ways to comment (just say, e.g., that a comment starts with /*A
if it's Alerting the reader of something, /*U if it's giving an URL to a
relevant article, etc, etc -- up to you, really).

> to differentiate those types
> that are encapsulated and those that aren't.

Again, the language draws no such distinction, and you're free to add your
own in-house rules, but again, if you do, you gain no extra value due to
the language's redundancy (much more productively you could specify that
either 'private' or 'public' get specified *FIRST THING* in the class or
struct: explicit is better than implicit).

The line of reasoning you're trying to follow, that it's good for a
language to specify two or more essentially identical ways to do the
same thing, is just silly.  Why don't you have both 'int' and 'integer'
builtin types then?  You could use them "to differentiate" e.g. those
integers that count things from those which are just used for internal
tagging or iteration purposes.  Why not have a keyword 'loop' which is
a complete synonym of 'while' -- you could use it "to communicate
programmers' intent", e.g. 'while' for loops meant to run normally
just a few times and 'loop' for those meant to run normally a lot of
times.  And so on, and so forth.

It's just silly.  It's not a language's business to add complication
for no real purpose to let people develop in-house conventions about
how to use redundant equivalent constructs, conventionally and
artificially, in halfbaked attempts to "communicate intent".  The ideal
(unreachable, of course, at least as long as some additions are
commutative and so a+b and b+a give the same result) should be to
supply ONE good way to perform a task.  ONE.  Not zero.  Not two.  Get it?


>     Alex> since existing programs were using it by the time he convinced
>     Alex> himself the language would be better off without it.
> 
> If a feature is "just for existing programs", new programmers usually are
> free not to learn it.  I see many who never learnt about C-style casts,
> function pointers, etc.

I've seen a few C++ programmers who tried that, and failed miserably
any time they tried to study a C++ based book (e.g. about numerical
computing, or data structures, or any specific technology such as COM,
interface to some kind of database, networks, etc), because nobody had
told the books' authors to avoid the language constructs those programmers
had not learned.  The same programmers were totally unable to maintain
existing code, use any existing library, and so on -- pretty useless.

Problem is that features in a language are NOT intrinsically flagged as
"just for existing programs" (except perhaps if you use some deprecation
idea such as Java's, which may be seen as a painful but necessary way
to take stuff *OUT* gradually).  Libraries, books, other programmers,
etc, will thus keep using those features.  To all intent and purposes,
the features ARE in the language, and thus bloat it -- and to be an
effective user of the language, you cannot avoid learning all about
them (or else you'll keep tripping on your feet over and over again).


>     Alex> My own feeling is that C++ is probably as good as it could be
>     made Alex> considering the many constraints on it -- pity that those
>     Alex> constraints never included "and simple enough for human beings
>     to Alex> use well"
> 
> It's not currently?  I beg to differ.  I see the only real thing currently

My opinion is substantiated by many years of working as senior software
consultant for an excellent software-development firm employing hundreds of
very good programmers.  A key part of my job was teaching those very good
programmers to use our chosen technologies effectively.  Now, these guys and
gals were mostly expert in specific disciplines -- some about relational
databases, some about three-dimensional constraints-based geometrical
modeling, some about effective user interfaces, and so on, and so forth.

Yet, they were all constrained to use C++ (a lamentable decision).  I have
seen the kinds of errors and misunderstandings generated by the language's
sheer, huge complexity, and how it ate into people's productivity.  Even
the "real experts", me included, were never *100%* perfect in their grasp
of the language's subtleties -- imagine somebody who has LOTS of other 
things to keep in mind, and is working on the leading edge of computational
geometry innovating a geometrical kernel with some new and brilliant idea,
why should HE (or she) be bothered to deal with a hugely complex language
*in addition*?

I might be biased from the fact that, of course, I was mostly called in
for fire-fighting when some problem turned out to be too hard to deal
with for the programmers directly involved.  But the same 'bias' if any
held for languages we used before C++ (Fortran and C) and ones we tried
out experimentally later (Java, Visual Basic -- even Perl, but the story
there is different).  I know the few crucial issues that are error-prone
in each of Fortran, C, Java, and VB6, for very good programmers whose
expertise and interest is in other fields than 'programming languages',
and they're quite easy to explain to those programmers so they can later
avoid erring again.  With C++, there's no such "small kernel of error
causing things" easily avoided.  The whole picture is *just too complex*.

I kept reasonably accurate measurement of our experiments with Java,
most particularly about my own productivity.  That rose about 20% when
using Java rather than C++, even though I was highly experienced at
C++ (Brainbench MVP for C++, well within the top 1%, etc, etc), and at
the time was little more than a beginner with Java.  For other people
(measurements less careful/accurate) I estimated performance gains of
30% to 40% (lesser grasp of Java, but of C++ as well, and the imperfect
grasp bytes MUCH harder with C++ -- even though they might typically
have been using C++ in production for two years, Java for two months).

We didn't switch because those productivity gains were insufficient to
cover all the technology risks of Java (we're talking about 1996 and
the choice was probably right -- one of our competitors last year made
a big publicity splash about having *reverted* one of their core
products, once coded in C++ and later redone in Java, back to C++:-).
But, I still found the numbers impressive -- not so much a plus of Java,
as a minus of C++.  It's *just too complex*.

> causing trouble is the lack of of good standard library.  Not just to deal

That absolutely wasn't an issue at that firm, since we had our own
libraries for all typical tasks you mention (DB interfacing, GUIs,
networking, etc) or standardized on good existing ones.  (e.g., the
C++'s standard libraries for containers, with additions from such
sources as SGI's STL, later Boost, etc).  Indeed, much of my own
Java work was ensuring we could interoperate with those existing
libraries of ours from Java code (that's where I learned to hate JNI --
wish Swig had been available for Java then, but that's another story).

Nor would it be an issue for a firm starting greenfield development
now -- they might well choose (e.g.) Qt 3, and be extremely happy
with it.  No, it's a language issue far more than a library one.

If C++ should next standardize the *interfaces* to such things as
DB interfacing, this will surely be a good thing, and adopting just
about all of Boost wholesale into the standard would also be nice.
But it would not cure the language's inherent, too-high complexity.


> But of course, this is a Python forum, so I'll stop advocating another
> language.

There's absolutely no problem with that.  Most large, real-world Python
applications, after all, need some extensions, which are most often
developed in either C or C++.  Not too long ago, I was convinced that
C++ was preferable -- after all, one could use CXX or Boost (or maybe
even sip, though I admit I never really learned THAT one) and reduce
the boilerplate needed for pure-C interfacing.  I'm not so sure any
longer.  If the developer and every future maintainer knows C++ inside
out (it won't be 100%, I bet -- but 99.44% might suffice), then maybe
the reasoning still holds.  But if the interface needs to be developed
or maintained by somebody whose grasp of C++ is more typical (90% down
to inexistent), is it worth learning C++ for the purpose?  Probably
not, is my current working hypothesis (still quite revisable, of course).

The moderate bother of having to deal with the C API directly is less
than the substantial bother of having to learn and deal with C++'s
complexity.  Maybe Weave or something along those lines is even better
then -- you can code plain C and have the interfacing boilerplate be
codegenerated for you.  Swig offers similar possibilities, of course.
I'm not doing any substantial extensions right now, but surely they'll
come up again in the future, so debates on these issues can hardly be
a waste of time and energy -- all the more so, for readers who are
right now actively contemplating such decisions, of course!


Alex