Python vs. Perl, which is better to learn?

[Alex Martelli]

thp at cs.ucr.edu wrote:

> In comp.lang.misc Peter da Silva <peter at abbnm.com> wrote:
> [...]
> : C++ is horribly complex because the original design was a more or less
> : pragmatic scheme to support object oriented programming in a non-object-
> : oriented language.
> 
> So, exactly which parts do you consider to be superfluous?

>From the point of view of somebody setting out to write new programs in
C++, the "superfluous" parts are mostly those that exist for reasons of
backwards compatibility.  For example, class and struct are two keywords
which are exact synonyms except for a different default visibility until the
first private/protected/public keyword in the class body -- this should make
it obvious that there is redundancy here.  Sometimes the need for backwards
compatibility bytes even within C++ itself, since it developed slowly and
gradually, never shedding excess baggage to avoid breaking existing 
programs: for example, Stroustrup, in his excellent book about the Design
and Evolution of C++, points out that he was convinced to put 'protected' 
in the language by clever arguments rather than actual experience, and
in the light of experience he'd have liked to take it out as excess baggage
(more complication than its functionality is worth), but didn't feel he 
could, since existing programs were using it by the time he convinced
himself the language would be better off without it.

Do read the "D&E" book -- it's refreshingly honest about how much stuff
Stroustrup himself feels could have been better but for the backwards
compatibility constraints he chose to impose (no doubt those constraints
did help the language's acceptance *a lot* -- but the resulting language,
by the feeling of the designer himself, is nowhere as good as it might have
been had a 'greenfield' design been feasible).

My own feeling is that C++ is probably as good as it could be made
considering the many constraints on it -- pity that those constraints
never included "and simple enough for human beings to use well" (or
maybe if that had been added the whole set would have become an
overconstrained system, with no solution feasible:-).

Note that all languages that have been around a while suffer under
similar issues -- break some existing programs, or keep piling up
cruft as old mechanisms must stay while new ones go in?  C++'s
version of the dilemma is only magnified by its ambitious goals -- "one
language to bind them all", from the lowest-level programming task
to high levels of abstraction, AND potentially-top performance ("pay
only for features you really use") AND compatibility (more or less) with
ANSI/ISO C as well.


Alex (Brainbench MVP for C++)