develooper Front page | perl.perl5.porters | Postings from May 2000

RE: Thoughts on maintaining perl

Thread Previous | Thread Next
From:
Horsley Tom
Date:
May 26, 2000 04:37
Subject:
RE: Thoughts on maintaining perl
Message ID:
2073F4E25299D311BC6200805F0D910740B6B2@exchange.ccur.com
> >Suddenly I have to stop and learn new language
> >constructs, then I have to try and pop the stack
> 
> The number of language constructs is both finite and small in
> comparison to the combinatoric expressions thereof.  I don't
> understand this assertion.  What is really the problem?  Someone
> used a Module that you weren't familiar with?

Finite? Yes. Small? I wouldn't call it that, not compared to
other languages. There are bazillions of special cases
in perl, and if you don't actually have them all
memorized and cached for easy access, you can easily
read a line of code and not even realize it is using
one of the special cases.

Things like implicit defined(), implicit $_ or @_
or @ARGS, different meanings for random sets of
functions in scalar context, for that matter, just
recognizing if you are in "scalar context" or not.
Compare this to C - it basically only has one weird
special case with pointers and arrays sorta being
the same sometimes except when they aren't.

These are all things that usually make perl easier
to write, but they definitely don't make it easier to
read. The learning curve to get them all into your
awareness so you can do effective maintenance on perl
is steeper for perl than many other languages (PL/1
is probably worse - you can't even do arithmetic
in PL/1 without a degree in number theory :-).

I hasten to add that I don't think any of this makes
perl inappropriate for "production use". I think the
huge advantages perl has for development more than
offset the extra time it takes in maintenance, but
I think it is harder to maintain.

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About