Why is Perl losing ground?

[Aaron Sherman]

Yep. Larry, AFAICT, didn't intend Perl to be an "undisciplined" language.
He intended it to be a "bring your own discipline (BYOD)" language. And I
think that's because he realized that:

I'm not convinced that that much thought went into it. I think Perl is
the result of "oh crap, someone's actually using it!" Mind you, Larry
makes it look much easier than it is, so sometimes it can seem like
there's a plan....

With Perl 6 there is clearly a plan and several goals, but that's Perl
6.

1) Despite all the religious wars over which style of programming
discipline is the Right One, what really matters in the real world of
writing correct, scalable and maintainable programs is that you pick one
and stick to it.

True to an extent. That statement can, of course, be twisted into a
justification for some VERY poor choices.

2) (This one is probably going to raise some hackles) Many problems are not
technical problems and therefore one should not attempt to solve them by
technological means. In particular, programming discipline or the lack
thereof is a social problem, not a technical one, and therefore requires a
social solution rather than a technical solution.

I agree to a point. The key difference between you and I here is that
I think the language should have a set of tools for casting some of
those social conventions into code. The strict module is a simple
example of this. In Perl 6 there will likely be many more such
features for telling perl what constraints you wish to place on the
code. This can be quite beneficial too, as certain constraints will
make certain optimizations possible (one of the reasons that I
disagree slightly with some of Parrot's design goals).

 

[Aaron Sherman]

PHP out-performs Perl by a tremendous margin in a shared hosting
environment, which is where most sites are implemented. mod_perl
doesn't isolate the various users enough to be very safe in a shared
hosting environment, and you need mod_perl to get performance.

Many have replied, but I just want to point out one side point:
comparing PHP to mod_perl is like comparing Tomcat to Python. You
really need to look at equivalent tools. Mason, The Template Toolkit
or bricolage would be appropriate tools to compare to PHP as they
provide the template substitution and (to various degrees) the other
content services that one expects out of the box with PHP. mod_perl is
really just an interface to the Apache API.

THAT is why so many people go to PHP: it's easier to use than
mod_perl, and they don't understand that there are better (or at least
more abstract) Perl based tools available to them.

 

[G Klinedinst]

Exactly. There are far too many 'S&M' object languages, that are more
interested in forcing you into writing perfect OO than in actually
getting a job done. Perl's OO is the best I've come across: though
what I am comparing it to is C++ and Java. The fact that in Java you
have to have a class just to hold things like Math.sin just shouts
'bodge' to me: the world doesn't fit into your little box, so rather
than let people out of the box you bend the edges until things almost
fit.

Well, this war has been waging for years. You are on one side and I am
on the other. For OOP I believe it is in the interest of programmers
to shoehorn things into classes a little for the sake of uniformity
and simplicity. However you are far from alone being on the other side
of this.

print !($_ % 5) || !($_ % 7) || $_;

or

print ( $_ % 5 == 0 or $_ % 7 == 0 or $_ );

Or to solve something closer to the original problem:

print $_ % 5 ?
$_ % 7 ?
$_ :
"buzz" :
"fizz";

I find all three of those more readable than that mess of brackets and
studlyCaps.

Of course you do, however judging from you posts you are an expert at
Perl. A language which is aiming for broader acceptance also has to be
readable and understandable to the vast majority of coders out there.
In my opinion english and english-like names, as well as less cryptic
symbols makes other languages easier to read to people in the low to
medium skill category. Shortening the learning curve would certainly
help bring more people to Perl.

..I don't think so. Examples?

Sure, from an article you wrote:
----------------------------------------------------------------

$value =~ s/^\s*(.*?)\s*$/$1/;

----------------------------------------------------------------
Forgive me if I'm wrong but will all of you examples it certainly
looks like you are advocating Tore not use the functions he wrote, and
instead use regexps that are common to all of perl. If you are only
saying that these shouldn't be part of the Perl base, then I agree
with you and please forgive me, but it looks to me like you are
rewriting everything Tore wrote in regexps rather than function calls
with names that make sense to him. There is another example which I
can't find of someone saying basically "after removing excessively
long variable names here is what your code looks like...".

OK, yes, there's one *hell* of a lot of really badly written Perl out
there. Perl is a tool which treats the programmer as a responsible
adult, capable of making sensible decisions about the compromise
between readability and brevity, between getting the thing working now
and keeping it working later. All too many programmers abuse that
responsibility, but that doesn't make Perl a bad language, it makes
tham bad programmers.

This is covered in detail below in this thread, however I am in favor
of structured coding for the same reasons as Charlton is. Too many
people, to much chaos, wasting too much time trying to decipher what
should be done virtually the same in all cases across the board. Or
just wasting time trying to decide on coding guidelines in the first
place. Yucky.

BTW, I have no illusions that I am going to convert anyone here. All I
am hoping is that the Perl gods hear that some people say "There Are
Too Many Ways To Do It", which hurts readability.

-Greg

 

[Tassilo v. Parseval]

Also sprach G Klinedinst:

Sure, from an article you wrote:
----------------------------------------------------------------
----------------------------------------------------------------
Forgive me if I'm wrong but will all of you examples it certainly
looks like you are advocating Tore not use the functions he wrote, and
instead use regexps that are common to all of perl. If you are only
saying that these shouldn't be part of the Perl base, then I agree
with you and please forgive me, but it looks to me like you are
rewriting everything Tore wrote in regexps rather than function calls
with names that make sense to him. There is another example which I
can't find of someone saying basically "after removing excessively
long variable names here is what your code looks like...".

Whenever the topic of readability is discussed, sooner or later regexps
will be mentioned as the one big evil of unreadability. I would like to
point out that the concept of regular expressions is far older than
Perl. Originally they were a different notation for deterministic (or
indeterministic) finite automata and are able to describe the same
languages (namely regular languages, hence the name).

It has nothing to do with the programming languages. Regular expressions
look the same in every programming language (minus some extended
features that regular expression engines tend to offer; Perl has quite a
lot of them). Therefore I could argue that using simple regexps is
actually more readable than a function because anyone with an even
moderate background in computer science should be able to read them.

Unlike functions. Since function names differ wildly across programming
languages, the programmer will very likely have to look it up in the
docs.

Tassilo

 

[Ben Morrow]

Of course you do, however judging from you posts you are an expert at

^^^^^^
hardly

Perl. A language which is aiming for broader acceptance also has to be
readable and understandable to the vast majority of coders out there.

OK:

use English qw/-no_match_vars/;

print not ($ARG % 5) or not ($ARG % 7 ) or $ARG;

Yes, there is a Perlish trait of being rather functional about things:
making expressions rather than statements, e.g.
print <cond> ? $a : $b;
rather than
if (<cond>) { print $a } else { print $b }
, where possible, which I suppose is probably unfamiliar to people
coming from other (common first-) languages.

In my opinion english and english-like names, as well as less cryptic
symbols

At the risk of sounding more pedantic than is necessary , do you mean
'less-cryptic symbols' or 'fewer cryptic symbols'? If the former, then
yes you could say that Perl's array of $? vars (for instance) is
cryptic, but they are actually no harder to learn than an api; if the
latter, then I would argue that replacing them with named functions
would only alleviate the initial 'what the Hell is that???' shock, and
the api would still need to be learnt.

Sure, from an article you wrote:
----------------------------------------------------------------

Well, I'm not advocating *Tore* do one thing or the other: TMTOWTDI,
after all .

and instead use regexps that are common to all of perl. If you are
only saying that these shouldn't be part of the Perl base, then I
agree with you and please forgive me, but it looks to me like you are
rewriting everything Tore wrote in regexps rather than function calls
with names that make sense to him.

I was saying that such things should certainly not be core, and also
perhaps that I would never write them like that. I would also say that
my versions are more readable *to someone familiar with Perl*. A regex
like that is short enough to be comprehended as a single 'word': after
all, it's only got 4 'letter's in it (s/, ^, \s*, and //). I am
certainly would advocate, when one is writing a regex longer than that,
that it be broken into such immediately-comprehensible parts by use of
/x and interpolating variables.

There is another example which I
can't find of someone saying basically "after removing excessively
long variable names here is what your code looks like...".

I have an irresitable urge to insert this quote here, from
linux/Documentation/CodingStyle. True, it's about C, but Perl has a lot
of C heritage:

| C is a Spartan language, and so should your naming be. Unlike Modula-2
| and Pascal programmers, C programmers do not use cute names like
| ThisVariableIsATemporaryCounter. A C programmer would call that
| variable "tmp", which is much easier to write, and not the least more
| difficult to understand.

Yup, arguing from authority is the last recourse of the ignorant...

Or just wasting time trying to decide on coding guidelines in the
first place. Yucky.

Such time is never wasted. If it is true that such things are generally
the same between one project and the next, then the job of preparing
guidelines should be a relatively trivial modification of those already
at hand. If it isn't, then at some point you'll find a situation where
the canned 'guidelines' given you by your language-of-choice don't fit.

Ben

 

[Beable van Polasm]

I know people will say that Perl can be object oriented, but of course
it was an afterthought with Perl. Other languages were designed from
the ground up to make Objects easy to work with, and not allow a mix
of procedural and OO. As projects and applications get larger and more
complex people want to use OOP, so they pick a language which is
purely OO, and which implements it cleanly.

Have you tried using one of these modules: Class::Struct,
Class::MethodMaker, or Class::MakeMethods? Using one of them makes
writing OO Perl very easy, especially the last two modules (available
from CPAN). There are still a few niggly things, but who knows? Maybe
Perl6 will fix them.

 

[G Klinedinst]

Have you tried using one of these modules: Class::Struct,
Class::MethodMaker, or Class::MakeMethods? Using one of them makes
writing OO Perl very easy, especially the last two modules (available
from CPAN). There are still a few niggly things, but who knows? Maybe
Perl6 will fix them.

No, I haven't but thanks for the recommendation. I will take a look at
them and see if they can help me speed up my Perl OOP.

-Greg

 

[G Klinedinst]

At the risk of sounding more pedantic than is necessary , do you mean
'less-cryptic symbols' or 'fewer cryptic symbols'? If the former, then
yes you could say that Perl's array of $? vars (for instance) is
cryptic, but they are actually no harder to learn than an api; if the
latter, then I would argue that replacing them with named functions
would only alleviate the initial 'what the Hell is that???' shock, and
the api would still need to be learnt.

I meant the former, the number of variables is fine, it's just the
naming conventions are cryptic. Some sort of mnemonic naming
convention might help people learn.

I have an irresitable urge to insert this quote here, from
linux/Documentation/CodingStyle. True, it's about C, but Perl has a lot
of C heritage:

| C is a Spartan language, and so should your naming be. Unlike Modula-2
| and Pascal programmers, C programmers do not use cute names like
| ThisVariableIsATemporaryCounter. A C programmer would call that
| variable "tmp", which is much easier to write, and not the least more
| difficult to understand.

Most of the fancy naming conventions, such as Hungarian Notation are
in place to help people remember what is stored in the variable, which
is largely irrelevant in Perl(the $, @, or % tells you). As you point
out some people go way overboard with it, but the theory itself is
solid. Personally I like the capitalization of the words, because I
can't stand reading underscores.


-Greg

 

[G Klinedinst]

Whenever the topic of readability is discussed, sooner or later regexps
will be mentioned as the one big evil of unreadability. I would like to
point out that the concept of regular expressions is far older than
Perl. Originally they were a different notation for deterministic (or
indeterministic) finite automata and are able to describe the same
languages (namely regular languages, hence the name).

It has nothing to do with the programming languages. Regular expressions
look the same in every programming language (minus some extended
features that regular expression engines tend to offer; Perl has quite a
lot of them). Therefore I could argue that using simple regexps is
actually more readable than a function because anyone with an even
moderate background in computer science should be able to read them.

Unlike functions. Since function names differ wildly across programming
languages, the programmer will very likely have to look it up in the
docs.

Good point Tassilo. RegExp != Perl. I guess more specifically I was
refering to the tendency in Perl to use regexp throughout the code,
rather than relying on functions to handle mundane chores such as
searching for substrings, etc. Maybe with more practice I will be able
to read them a little faster too, because to me currently every one is
like a little hurdle I have to leap before I can keep on reading.

-Greg

 

[Ben Morrow]

I meant the former, the number of variables is fine, it's just the
naming conventions are cryptic. Some sort of mnemonic naming
convention might help people learn.

perldoc English

The fact that noone uses it, though, shows that my point still stands:
it's actually no *harder* to learn an api consisting of symbols than it
is one consisting of words, and learning the api is a step that must be
gone through regardless.

It also comes under Larry's mantra of 'different things should look
different': these variables are *really* *special*, so it's good that
they are instantly recognisable.

Most of the fancy naming conventions, such as Hungarian Notation are
in place to help people remember what is stored in the variable, which
is largely irrelevant in Perl(the $, @, or % tells you). As you point
out some people go way overboard with it, but the theory itself is
solid. Personally I like the capitalization of the words, because I
can't stand reading underscores.

Sorry, but to continue from the same document:

| Encoding the type of a function into the name (so-called Hungarian
| notation) is brain damaged - the compiler knows the types anyway and can
| check those, and it only confuses the programmer. No wonder MicroSoft
| makes buggy programs.

and furthermore, a variable is either local, in which case it is in a
small enough scope that there is no question about what it contains, or
global, in which case what it contains is an api issue just as much as
the parameters of functions.

Also, from perlstyle,pod:

| While short identifiers like $gotit are probably ok, use underscores to
| separate words. It is generally easier to read $var_names_like_this
| than $VarNamesLikeThis, especially for non-native speakers of English.
| It's also a simple rule that works consistently with
| VAR_NAMES_LIKE_THIS.

I would definitely agree with that: an underscore is a much clearer
separator of words than a change in case.

Ben

 

[Tassilo v. Parseval]

Also sprach G Klinedinst:

Good point Tassilo. RegExp != Perl. I guess more specifically I was
refering to the tendency in Perl to use regexp throughout the code,
rather than relying on functions to handle mundane chores such as
searching for substrings, etc. Maybe with more practice I will be able
to read them a little faster too, because to me currently every one is
like a little hurdle I have to leap before I can keep on reading.

It's a little declarative programming language of its own. Although
RegExp != Perl, Perl might have the tightest integration of regular
expressions of all contemporary languages I know. There's not really a
good way to avoid them when programming Perl.

However, the good news is that learning regexps is not a waste of time
as they show up in many places (when using a proper text editor, in the
shell, common UNIX utilities and in other programming languages). Once a
general understanding of how they work has been achieved, there is not
much that could beat them when it comes to readability. What they can do
with 20 characters might need 20 lines when avoiding them. And I always
prefer to read one line over many lines, even when this one line might
be quite complex.

Tassilo

 

[Sherm Pendley]

I meant the former, the number of variables is fine, it's just the
naming conventions are cryptic. Some sort of mnemonic naming
convention might help people learn.

If you 'use English;', most of the cryptic variables are given more friendly
aliases. For example:

$_ : $ARG
$? : $CHILD_ERROR
$! : $OS_ERROR
$@ : $EVAL_ERROR
$$ : $PROCESS_ID or $PID
$| : $OUTPUT_AUTOFLUSH

sherm--

 

[Uri Guttman]

SP> If you 'use English;', most of the cryptic variables are given
SP> more friendly aliases. For example:

friendly? i have never seen decent code written with english. learning
the common perl vars is easy. find a module on cpan which uses
english. there might be a couple but not many more.

SP> $_ : $ARG
SP> $? : $CHILD_ERROR
SP> $! : $OS_ERROR
SP> $@ : $EVAL_ERROR
SP> $$ : $PROCESS_ID or $PID
SP> $| : $OUTPUT_AUTOFLUSH

my eyes!!! i can't see!!!!

$i_will_switch_to_super_long_variable_names_too

uri

 

[David K. Wall]

If you 'use English;', most of the cryptic variables are given more
friendly aliases. For example:

They're already in mnemonic form.

$_ : $ARG

Fill in the blank. "Is this the right room for an argument?"

$? : $CHILD_ERROR

Children are a mystery.

$! : $OS_ERROR

What the hell was that?!

$@ : $EVAL_ERROR

D00d, it's an 3v@l 3rr30r. S#%$*&!!
^

$$ : $PROCESS_ID or $PID

That'll cost you.

$| : $OUTPUT_AUTOFLUSH

Flush that crap down the pipe.

 

[Sherm Pendley]

friendly?

It's subjective.

My post was aimed at countering the "$@ variables are too terse and cryptic"
argument by showing that more verbose alternatives are available. Someone
who makes such an argument might well consider the longer forms to be more
friendly.

sherm--

 

[Uri Guttman]

SP> It's subjective.

no it isn't. no perl hacker with even a little experience uses
English. like i said, find it being used on cpan.

SP> My post was aimed at countering the "$@ variables are too terse
SP> and cryptic" argument by showing that more verbose alternatives
SP> are available. Someone who makes such an argument might well
SP> consider the longer forms to be more friendly.

that module is not a proper response to it. the answer is they the
variables are not cryptic as you can learn them as you need too. larry
actually picke nmemonic chars for them as well. and perldoc perlvar is a
click away.

rtfm is the proper response. and if they want handholding all the time
choose basic.

uri

 

[Sherm Pendley]

SP> It's subjective.

no it isn't.

Sure it is. It's a matter of style and opinion, not one of substance. The
fact that many people share the same opinion doesn't make it any less
subjective.

larry actually picke nmemonic chars for them as well.

Larry also coined the term "TMTOWTDI", and chose to include the English
module in support of that philosophy. It would seem that Larry has a much
better understanding of the term "subjective opinion" than you do.

sherm--

 

[Sherm Pendley]

What the hell was that?!

I once used a database library where every error function was prefixed with
"wtf_". I didn't get it at first, but my reaction to the first error I ran
into brought immediate understanding. ;-)

Flush that crap down the pipe.

LOL! I've always thought of it as "piping hot output."

But I like your version better.

sherm--

 

[Uri Guttman]

SP> Uri Guttman wrote:
SP> It's subjective.
SP> Sure it is. It's a matter of style and opinion, not one of substance. The
SP> fact that many people share the same opinion doesn't make it any less
SP> subjective.

it is not subjective. no one uses it and no one recommends it
(regardless of the slowdown bug). it is there for show and not use.

SP> Larry also coined the term "TMTOWTDI", and chose to include the English
SP> module in support of that philosophy. It would seem that Larry has a much
SP> better understanding of the term "subjective opinion" than you do.

you quote larry like you know him which i don't think you do. he picked
the special chars with nmenonics in mind. he didn't expect english to be
needed or he would have made those names aliased by default. note that
they are in a separate module and not in the core language. perlvar
covers their names.

the worst thing is seeing english in use and it never seems to help at
all. users of it usually have way more problems with perl than just the
names of special vars. they need more help than english could provide.

and here is another little tidbit, perl is used internationally and note
how no one has ever come up with a french.pm or italian.pm? why not?
because having non-words for the special vars is more portable across
human languages. that alone should show you that english is a wasted
module.

uri

 

[Sherm Pendley]

it is not subjective. no one uses it and no one recommends it
(regardless of the slowdown bug). it is there for show and not use.

Pointing out the availability of an option is not the same as recommending
it. In fact, I don't use English in my own code.

The post I originally replied to was criticizing Perl for its terseness, and
implied that the short forms were the only ones available. That's simply
not true - the longer forms are an available and supported option.

It's important to distinguish what's acceptable to the community vs. what's
allowed by the language. The fact that the Perl *community* has mostly
chosen to use a very terse style is a matter of fashion; it has nothing to
do with what is allowed by the Perl *language*. (I realize I'm using the
term "language" rather loosely here, in that English.pm is part of the core
distribution, but not part of the core language...)

Having said that, I do agree that it's worth keeping community standards in
mind if you're writing code that will be shared with the community - "when
in Rome, do as the Romans do" and all that. And obviously, if your employer
has an established set of guidelines, you'll need to follow them.

On the other hand, what consenting adults do in the privacy of their own
code is another matter entirely. If they want to shout their variable
names, Perl will let them do that. It will even indulge their fetish to the
extent of shouting back at them, if that's what they want.

sherm--