Why is Perl losing ground?

[Bart Lateur]

Are you aware that C isn't replaceable when it comes to platform
portability?

C isn't portable, that's just an illusion.

<http://www.kuro5hin.org/story/2004/2/7/144019/8872>

There's a header "Portability?!", but no anchor.

 

[Tore Aursand]

It means that if you mess things up in one client's setup, it'll affect
everybody.

No, it doesn't. mod_perl settings can be set differently for different
users. It can be set differently for different directories/locations, and
it can be - of course - set differently for different virtual hosts.

This has, however, something to do with the Apache configuration, and has
nothing to do with Perl as a programming language.

 

[Randal L. Schwartz]

Ben> PHP is great for what it was designed for: a simple way to put a small
Ben> amount of scripting into a basically static HTML page. It's been
Ben> stretched *waay* beyond that now, though, and needs the same sort of
Ben> major rewrite/rethink that happened perl4->perl5. (FWIW I have heard
Ben> from friends who actually use the language that the PHP folks are
Ben> doing something along these lines now).

That would be consistent with my claim that PHP simply trails Perl
by five years in all manners of speaking, but badly.

Or, as I've said on more than one occasion:

PHP - training wheels without the bicycle

Now that we have Apache::Template (and EmbPerl before that), there's
really no reason to learn PHP, except when that's the only choice you
have for other defining reasons.

print "Just another Perl hacker,"

 

[thumb_42]

mod_php is usable in a shard hosting environment. mod_perl
essentially is not; at least that seems to be the consensus of most of
the places selling shared hosting, and reading about it, it does seem
that you don't have adequate isolation between virtual users in
mod_perl.

I agree with you.

I think enough people have had issues with mod_perl to say that mod_perl is
a highly specific application of perl. I gave up on it years ago, maybe it's
improved since then, but when I used it I had many issues, one was
impossible to track down, (Berkely DBM causing the web server to
periodically segfault). Others involved memory leaks surrounding DBI..

Yes, maybe these problems were caused by something I did, or something
burried deep within some module some place that I was using, probably
nothing to do with mod_perl.. either way, those issues don't creep in with
PHP or java. (well, actually they do with java but those are mostly threading
issues that are relatively easy to avoid with care.)

Perl advocates can try and argue this is not the case, but it won't help.
Perl *is* loosing webspace ground to PHP in the webspace, that is reality as
we know it today.


Jamie

 

[Ian Cass]

David Dyer-Bennet <[email protected]> wrote:

Perl advocates can try and argue this is not the case, but it won't
help. Perl *is* loosing webspace ground to PHP in the webspace, that
is reality as we know it today.

Which is a *big* shame. I'd choose www.apache-asp.org over PHP any day of
the week.

 

[Matija Papec]

X-Ftn-To: Bart Lateur

C isn't portable, that's just an illusion.

You're right, but note that I wrote platform[1] portability, not C
portability.

[1] such as OS, server, interpreter

 

[Martien Verbruggen]

C isn't portable, that's just an illusion.

<http://www.kuro5hin.org/story/2004/2/7/144019/8872>

There's a header "Portability?!", but no anchor.

That article is severely biased, and wrong in many places. Well
written C is very portable.

It is true that it is easy to write non-portable code in something
resembling C (mainly by using non-portable libraries, system calls and
other APIs), but that does not make C unportable.

Martien

 

[Tassilo v. Parseval]

Also sprach Martien Verbruggen:

That article is severely biased, and wrong in many places. Well
written C is very portable.

Also, at several points the author expresses his dislike for the
preprocessor. Of course, if he ignores an important part of the language
I am not surprised that he complains about lack of portability. The
preprocessor is the most important means to circumvent
portability-issues. If he doesn't like it, he shouldn't complain.

Tassilo

 

[Randal L. Schwartz]

Chris> OSX's window manager/GUI is written in ObjC, but the base operating
Chris> system is FreeBSD, and it's written in C.

No, the base OS userland stuff (non-kernel) was populated primarily
from a snapshot of FreeBSD back when OSX was essentially NeXT. The
Kernel never came from FreeBSD, but was written from scratch from the
ground up.

 

[Charlton Wilbur]

S> Incidentally, programmers, particularly those early in their
S> careers, this is exactly why you can't learn "a language or
S> two" and expect them to serve your needs for a whole
S> career. You always have to be looking at "what's next". Wise
S> Perl programmers would be looking and maybe even starting to
S> use Python and Ruby now. I've been an industry developer now
S> for over 20 years, and if a language serves my employer's needs
S> for 5 years thats a long life!

Do your employer's needs change that often? For the problem domain
that gave rise to C, C is still among the top three languages in
existence. The same can be said for FORTRAN, Perl, Forth, and LISP.

Of course, if you're looking for a magic-bullet solution, or your
employer reads and believes buzzword-compliant glossy magazines -- but
then, you're talking trendiness and marketing, not technical solutions
to specific problems.

Charlton

 

[Charlton Wilbur]

twit> Perl was originally a simple scripting and programming
twit> language. In the past several years these factors have
twit> contributed to its impending decline:

Do you have hard evidence of a decline, or are you simply fearmongering?

Charlton

 

[Charlton Wilbur]

RLS> Now that we have Apache::Template (and EmbPerl before that),
RLS> there's really no reason to learn PHP, except when that's the
RLS> only choice you have for other defining reasons.

No *good* reason. But I can think of a couple reasons that PHP is
still around.

* mod_perl is configuration-intensive. I'm convinced that this is why
most cut-rate web hosts don't offer it: the cost of supporting the
few morons who can't figure out how to configure it (and who expect
to get hours of free support for their $9.95 a month) would devour
their profits rapidly. With PHP, you can say "We support PHP
version foo with these standard modules," and that's that.

* Apache::Template, HTML::Template, EmbPerl, ePerl - all require
building software or installing modules. Users are too ignorant to
do this; sysadmins don't like it when it happens. PHP lets you
avoid that.

So for someone who's developing a tiny web site to be hosted on a
cut-rate shared-hosting service -- sure, PHP is a sensible choice, and
going with anything else will cause you an uphill battle, which you'll
lose because the risk that you'll need help with the mod_perl
configuration is great enough that the hosting company will drop you
as a customer rather than lose money keeping you as a customer. But
for a site that's large enough to be hosted on a colocated server, or
for a site that's developed in-house, there's just no advantage to
using PHP over Perl, and several disadvantages.

I had a long email exchange with my web hosting company before I
signed on with them, because I wanted to use HTML::Mason, mod_perl,
and Postgres. They said they'd be happy to do that, provided I got
one of the higher-end hosting accounts that had shell access; I could
build whatever flavor of apache I wanted, whatever database I wanted,
and they'd bless it by making my virtual host a proxy for that web
server. This seemed like a reasonable situation (especially as I
didn't need a separate colocated server, and I especially didn't need
to pay what one would have cost, back when I initially worked out this
arrangement.)

Charlton

 

[G Klinedinst]

As a programmer who is addicted to Perl, I am curious as to why Perl is
losing ground to another bunch of languages, namely: Python, PHP and
Ruby. I'd like to hear your opinions. Is Perl just not "trendy" anymore?
Does it still scare programmers who haven't used it? Or do the other
languages have any major advantages over Perl? I haven't worked in these
other languages, so I'm not qualified to have much of an opinion here.
What do you think?

- Dom

I think people are fond of PHP for web stuff due to the inline coding
you can do, which is similar to ASP on a MS platform. To a MS web
programmer writing a cgi program which spits out HTML code is wierd.
Don't know about Python or Ruby, but I am very interested in learning
both.

In general, I think that Perl is slightly less popular now(judging
from internet job postings) than it was a few years ago for two main
reasons: A) a general trend toward OOP and B) simpler syntax in other
languages.

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.

People also get turned away by Perls syntax. Readability is the key. A
language which allows something like this:

x!($_%7)||$_,$/;z($_+1);

is going to be harder to read than a language which uses this:

print((isFactor( 5, inputString ) || isFactor( 7, inputString ) ||
inputString));

I know those are not the same thing exaclty and wouldn't come close to
compiling, I just don't have time to write them both completely. The
point is that in Perl, brevity has taken the place of readability.
This GREAT for one-liners, etc but for anything which you have to read
it later, it slows development to a crawl. Even on this newsgroup, if
you try to write readable code, people tell you your variables are too
long, you are using too many methods, etc.

I recently replaced a script on a server at work written by someone in
Perl about two years ago. There was no documentation, and it took me a
few hours to read thru it just to see WTF it did. In fact it took me
less time to re-write it's replacement in Perl than it did to read it
and understand it in the first place. As as aside, the reason I had to
read it in such detail is because no one could remember what exactly
it did. The Perl motto on the Camel book says "There's more than one
way to do it." While the freedom to choose is certainly an advantage
when talking about government, or deoderant, or what to have for
dinner, I think it hurts a programming language in the long run
because it hurts readability. Just my $.02, coming from someone who
spent 5 years in school getting readability and documentation hammered
into me so take it for what it's worth.

That being said, I am going back to program some more Perl, but
luckily it's a small program.

-Greg

 

[Ben Morrow]

In general, I think that Perl is slightly less popular now(judging
from internet job postings) than it was a few years ago for two main
reasons: A) a general trend toward OOP and B) simpler syntax in other
languages.

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.

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.

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.

OK, I have no experience with Large Projects, but I am given to
understand that it's much easier if people stick to Doing Things
Properly. Fine: have coding standards. Fire anyone who doesn't stick
to them. If you want people to write OO Perl, and not break the
encapsulation, then tell them that. It's perfectly possible to write
pure OO in Perl, it's just that it's *also* possible not
to. TMTOWTDI.

People also get turned away by Perls syntax. Readability is the key. A
language which allows something like this:

x!($_%7)||$_,$/;z($_+1);

is going to be harder to read than a language which uses this:

print((isFactor( 5, inputString ) || isFactor( 7, inputString ) ||
inputString));

Leaving aside the fact that the first is golf, and thus deliberately
obfusticated, I find Perl's punctuation makes things much *easier* to
read. To re-write your Perl example to do what the other did:

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.

I know those are not the same thing exaclty and wouldn't come close to
compiling, I just don't have time to write them both completely. The
point is that in Perl, brevity has taken the place of readability.
Wrong.

This GREAT for one-liners, etc but for anything which you have to read
it later, it slows development to a crawl. Even on this newsgroup, if
you try to write readable code, people tell you your variables are too
long, you are using too many methods, etc.

...I don't think so. Examples?

I recently replaced a script on a server at work written by someone in
Perl about two years ago. There was no documentation, and it took me a
few hours to read thru it just to see WTF it did.

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.

The Perl motto on the Camel book says "There's more than one

way to do it." While the freedom to choose is certainly an advantage
when talking about government, or deoderant, or what to have for
dinner, I think it hurts a programming language in the long run
because it hurts readability.

It doesn't. It *helps* readability, because you can choose the WTDI
that is most readable in the circumstances. Again, often people don't;
but that's their fault, not Perl's.

Ben

 

[Bart Lateur]

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.

Which reminds me... The motto for Perl is TIMTOWTDI, there's more than
one road to Rome, which some people think is a bad thing, because other
languages enforce the One True Way to do something. So Perl gives you
the freedom, while the other languages don't. *shrug*

But where this really begins to matter, is when trying to do something
the language was *not * designed for. In Perl, because of the freedom,
there will most likely turn out to be an acceptable way to write it --
even though with fewer choices available than for the more common
problems. But those other languages simply won't allow you to write the
code. Period.

Sorry, I can't think of a proper example right now. Heh, think of this
as an purely abstract and unproven idea, then.

 

[Unknown Poster]

Ben Morrow wrote:


Which reminds me... The motto for Perl is TIMTOWTDI, there's more than
one road to Rome, which some people think is a bad thing, because other
languages enforce the One True Way to do something. So Perl gives you
the freedom, while the other languages don't. *shrug*

Just look at chapter 12 of Programming Perl.

TIMTOWTDI simply ain't gonna work with object oriented analysis, design,
and programming.

The large software projects that will be developed through a complete OO
process can't be done 20% the way Bob likes it, 25% Ann likes it,
15% Raoul likes it, and 40% the only way the project manager knows
how to do it.

 

[Ben Morrow]

Just look at chapter 12 of Programming Perl.

TIMTOWTDI simply ain't gonna work with object oriented analysis, design,
and programming.

The large software projects that will be developed through a complete OO
process can't be done 20% the way Bob likes it, 25% Ann likes it,
15% Raoul likes it, and 40% the only way the project manager knows
how to do it.

Right... so for such a project, you write a set of coding guidelines
that standardises how it's going to be done. And everyone follows
them. Where's the problem?

Ben

 

[Eric Bohlman]

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.

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:

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.

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. Trying to design a
language to make it impossible to use bad programming technique is trying
to solve a social problem by forcing people to change to fit the
technology. That seldom works in the Real World; when people don't "buy
into" a particular methodology, they find ways of getting around it. The
solution is to get the buy-in. (Note, though, that if the design of a
language makes it difficult or impossible to apply good programming
techniques, *that* is a technical problem which can only be solved by
changing the tool. I don't think that's applicable to Perl, though.)

Gerald Weinberg's classic _The Psychology of Computer Programming_ has much
to say about such matters.

 

[Eric Bohlman]

Right... so for such a project, you write a set of coding guidelines
that standardises how it's going to be done. And everyone follows
them. Where's the problem?

Exactly. Their success doesn't depend on Jason, Michelle, Roberto and
*their* project manager, all in some entirely different organization, doing
things the same way they do it. Yet trying to enforce programming
discipline through language design has that effect. TMTOWTDI doesn't imply
that *all* WTDIs are equally good in every situation. It simply recognizes
that which WTDI is the best one will vary from situation to situation, and
gives those who WBDI the freedom to choose it.

 

[Charlton Wilbur]

BM> Right... so for such a project, you write a set of coding
BM> guidelines that standardises how it's going to be done. And
BM> everyone follows them. Where's the problem?

In theory, this works. In practice, the project manager won't write
code, and hasn't written more than 3 lines of code at a time since his
COBOL days, and will dig in his heels about writing coding guidelines
because he doesn't see the point. Bob is more interested in reading
Slashdot, and so will adhere to any coding guidelines to the letter in
order to have more Slashdot time, but his code is unreadable even
though technically correct. Ann would rather be working in Java
anyway, and is trying to write Java in Perl. Raoul considers himself
the best coder in the world, and refuses to allow coding guidelines to
hamper his self-expression, and since the project manager doesn't
really see the point in coding guidelines in the first place, he gets
away with it.

Coding guidelines are only as good as the people who produce them and
the people who enforce them. The Perl approach allows well-managed
and good programmers to get a great deal of work done, whether working
alone or in groups; the bondage-and-discipline approach allows a
poorly-managed team of mediocre programmers to get any work done at
all -- and even then it's a crapshoot.

(My own preference, having worked with both, is for the well-managed
team of good programmers; but that's not the way the statistics fall
out in most companies.)

Charlton