SPUG: Does Perl Scale? (Was: Evolution of Perl)

Ken McGlothlen mcglk at artlogix.com
Sat Aug 11 13:22:56 CDT 2001


"Richard Anderson" <Richard.Anderson at raycosoft.com> writes:

| Much as I like Perl, weakly-typed, free-form languages like Perl are not as
| appropriate for large projects as C++ and Java are.  Since Perl doesn't have
| any way of enforcing compliance with subroutine interfaces for OO calls, it
| can be difficult to track down bugs in large systems.  It's easy to say that
| programmers shouldn't create bugs, but using a strongly-typed language can
| produce a better product.
| 
| More importantly, C++ and Java programmers tend to be more rigorous than
| Perl programmers.  Damian's talk is a good illustration of some of the
| warped programming styles that Perl can seduce programmers into.

Okay, hold it right there.

Back when I was a Pascal fan (1981-6), I used to say the same sort of thing
about C programmers.  Pascal was a nice, high-level, strongly typed language,
whereas C (at the time, K&R C---ANSI C was on the far horizon) allowed you to
break typing, screw with function calls, etc., etc., etc.  Moreover, most of
the C code I'd seen to date was obscure---I would even say "badly written" from
a maintenance viewpoint, whereas my Pascal programs were graceful, well written
and comprehensible.

I mentioned this to my teacher one day, and he said, "It's time to let you in
on an old adage:  `You can write FORTRAN in any language.'"

And he was right.  I went back, grabbed one of those badly-written C programs,
translated it into something better written, and started seeing the beauty of
the language.  I even started wishing I had access to a Unix system (though
when I got there, it gave me the willies---nothing like my good ol' relatively
comprehensible VMS systems, mostly because of the influence of the C language).

Once I did get hold of my own Unix account, though, and got past the
obscureness of the commands (RENAME became mv, COPY became cp, HELP became man,
ASSIGN became either setenv, or a two-step involving export, etc., etc., etc.),
I became a C junkie.  What a great language.  It was more flexible than Pascal,
more capable, more lyrical if you will, and you could write code just as
rigorously if you wanted.  (Same with Unix vs VMS, actually.)

In short, it became an appropriate language.

I was introduced to Perl in 1986, but didn't start using it until the following
year.  Even then, I was reluctant to use it---it wasn't as common as sh, and it
had some quirks to boot:  implicit variables, nonstandard regular expressions,
all those weird little prefixes.  Reminded me of some bastard child of awk and
BASIC, really.  But it eventually grew on me, and when I became a genyuine
sysadmin, with the capability of making sure it was on any system I ran, Perl
became my scripting language of choice.  But I never would have used it for
large projects.

But system speeds and Perl 5 have changed my view on even that.

Now Perl is object-oriented.  That's a tough thing to bolt onto a procedural
language.  The only *native* object-oriented language I've seen that did it
really well (IMHO, of course) was SmallTalk-80:  simple paradigm, simple
grammar, in short, a really naturally object-oriented language.  C++ is, by
comparison, awful.  It has an ambiguous grammar, overloading operators can
quickly lead to chaos, and using the >> and << operators for I/O is a travesty
against man and God/Allah/ The Great Spirit/Zeus/Sparky/what-have-you.  A much
better solution was Objective C, which melded SmallTalk with C to produce a
true object-oriented language *without* those problems, but adoption was (and
remains) slow, except on MacOS X (formerly NeXTstep).  Java takes out some of
the worst elements in C++, but what's left isn't particularly graceful.

Perl's object-orientedness isn't particularly graceful, either, admittedly.  On
the other hand, it's less inherently obfuscative than C++, and if you code
properly, the code can be just as robust.  Admittedly, it's not as fast as
compiled code, but that's becoming less of a problem, too---for critical parts
of loops, you can always resort to Inline, or be relatively clever with your
data structures and use the array functions properly.

| Obfuscated programming can be done in Java and C++ too, but the implicit OO
| structure of these languages discourages it.

No amount of structure will discourage obfuscation if that's how the programmer
writes.  Even Ada, possibly the most strongly typed, most anal-retentive
language that was ever invented, could be obfuscated with a few easy steps.  To
take a Pascal example:

        function kumquat (booger : integer) : integer; var fairies, rutabaga :
        integer; begin rutabaga := 1; kumquat := booger; if kumquat = rutabaga
        then kumquat := rutabaga else begin kumquat := kumquat(kumquat -
        rutabaga) end end

Not immediately obvious that it's just our old friend the recursive factorial
function, is it?  Badly written, I admit, but it serves the purpose.

I guarantee you as well that I can write a good ol' run-of-the-mill procedural
program in C++ or even Java, no sweat, *and* make it just as incomprehensible.
Perl no more "encourages" bad code than any other language does.  It's up to
the programmer to make it solid.

| Perl uses some non-standard OOP features that make it a bit awkward for OOP,
| like being able to dynamically change your superclass at runtime and failing
| to implicitly call a superclass's constructor.

Every object-oriented language uses "non-standard features," except SmallTalk
and a few other obscure ones.  None of those are in general use, unfortunately.
(Doing large projects in SmallTalk would be *cool*.)  So I don't buy that Perl
is more confusing or more prone to confusion than Java or C++.  In some ways,
it's less.

| Python and Ruby are superior to Perl as object-oriented languages since they
| were originally designed as OO languages rather than Bourne shell / awk / C
| derivatives as Perl was.

I don't have much experience with Ruby yet.  Python has an admittedly stricter
approach to object-orientedness, but it had the *advantage* of not needing so
much backwards compatibility, and not needing to support the rather difficult
core code that Perl has at the moment.  On the other hand, having kept up with
the Apocalypses, I think Perl 6 is going to be one heck of a kick-ass language.
Stronger typing (if you want it), better object-orientedness (if you want it),
and better consistency.  Given what's coming down the pipe, it's hard to work
up much enthusiasm for Python.

| It has strengths and weaknesses that make it appropriate for some situations
| and not appropriate for others.

Perl is a high-level language, just as appropriate for high-level projects as
any other high-level language.  About the only thing I wouldn't write in it is
device drivers, code that absolutely requires speed, or something else
disturbingly low-level.  But I wouldn't use C++ for those, either.  The one
thing I really wish Perl had going for it is a really good cross-platform GUI
library.  Alas.  :)

| Even a lame platform like VB on Windows has its uses.

I dunno.  VB has become sort of the modern-day COBOL.  :)

 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
     POST TO: spug-list at pm.org       PROBLEMS: owner-spug-list at pm.org
      Subscriptions; Email to majordomo at pm.org:  ACTION  LIST  EMAIL
  Replace ACTION by subscribe or unsubscribe, EMAIL by your Email-address
 For daily traffic, use spug-list for LIST ;  for weekly, spug-list-digest
  Seattle Perl Users Group (SPUG) Home Page: http://www.halcyon.com/spug/





More information about the spug-list mailing list