

In defense of Perl. - wheels
http://blog.directededge.com/2008/08/03/in-defense-of-perl/

======
mechanical_fish
You may have given up on Ruby too soon. I'd encourage you to try again. What
book were you using?

The fact that you called it "Ruby on Rails" does not inspire confidence. Rails
is a complex Ruby framework, and a lot of Rails code actually consists of
calls to a Ruby-based DSL for the Web. It's hard to appreciate the kinship
between Ruby and Perl, or Ruby's usefulness for Perl-like tasks, when you
approach the language from that high-level angle. Try _Programming Ruby_ or
_The Ruby Way_ \-- or, heck, try _Why's _Poignant Guide to Ruby with Cartoon
Foxes_ , which is how I learned, though its unique style is not for everyone.

Ruby was built by a Perl fan; it was _named_ in honor of Perl, and I find that
most of the glue-code tasks that were easy in Perl are even easier in Ruby.

I will certainly _use_ Perl in the future -- one good thing about the
language's awesome documentation culture, and its excellent automated build
tools, is that they let you use Perl code without having to read any of it.
But I don't read or write Perl anymore unless I really have to -- just as,
back in 1999, I didn't use sed or awk and avoided writing shell scripts,
because I had Perl.

~~~
davidw
I initially looked at Ruby a number of years ago, and didn't really care for
the syntax either. Rails made me take a second look, and while I'm not sure I
consider it a thing of beauty, it is eminently practical, and a pretty good
compromise between Perl's minimalist style that lets you get lots done - and
then forget what the heck it does, and Java's blah blah blah verbosity. Also,
Ruby gems are handy - maybe not quite to the level of CPAN, but they're pretty
good.

~~~
kingkongrevenge
I don't know Rails at all but I'll go out on a limb suggest Perl's Catalyst is
probably just as good.

~~~
jm4
Prefacing a one-liner like this with "I don't know Rails..." is just begging
to be downmodded, but damn... -3? This is a rough crowd.

I only have cursory experience with Rails and Catalyst, but the first thing I
noticed is that Rails is much friendlier to Ruby novices than Catalyst is to
Perl novices. Still, Catalyst is pretty nice if you're a Perl developer
looking for a Rails-like framework.

------
shimon
I love Perl, but its essential problem at this point is that it's lost
momentum. After over 7 years of waiting for Perl 6, a huge gulf has developed
between the people who can influence language development and new users. In
this time, other language communities have taken great steps to attract new
users, and in many cases they've been pulling in more former Perl hackers than
converted Java/C++/etc folks. In web apps, Rails and Django are king for a
reason; they're excellent libraries that are well-documented and easy to
choose because of broad support in the language's community. Perl's Catalyst
is workable (I've used it) but is tricky to install and configure, has
inferior docs, and a thinner set of libraries. And it isn't what all your
friends are doing.

It might be narrowminded to blame Perl 6's schedule slippage (and the general
shakeup in Perl leadership and Larry Wall's struggle with cancer) for the
broader community decline. But there was a time when, say in web apps, Perl
was the default choice. That default started to change when some smart hackers
wrote some terrific libraries in Ruby and Python, and broad segments of the
hacker world started to agree on roughly what features they expected in a web
framework. I'm not sure why those hackers didn't choose Perl, but if I had to
pick exactly one thing, it would be Perl's awkward handling of references, a
skill that might have been easily picked up by C hackers but seems exceedingly
arcane to those reared on Java.

~~~
jrockway
_I love Perl, but its essential problem at this point is that it's lost
momentum._

No, that's just false. In the last year, we've gotten a new major release of
Perl, with many, many new features. (See the perl510delta man page for
details.) On the CPAN, we've seen 1000s of new libraries released. We have a
new object system, called Moose, which is probably one of the best object
systems of any language. The Perl conferences have been seeing record
attendance.

Basically, Perl is stronger than ever. We just spend our time programming
instead of talking about ourselves incessantly, declaring other languages
dead, winning awards for being 'the most attractive hacker', or covering up
security holes.

~~~
shimon
Interesting points. It could well be my professional frame of reference that's
shifting. Maybe a historical analysis of job listings would give a less biased
take?

------
softbuilder
I have a similar history. I wrote my first web app in 96, in C on SunOS. Since
then I've worked on all different types of platforms and at last count had
used 13 different programming languages in that period.

I recently went through a re-eval of what tech I wanted to be working with and
ended up with Python. I tried to return to Perl but couldn't do it. Mainly it
is because I'm back working on web projects and Perl's web frameworks aren't
so nice. People worship CPAN, but I've never found it any more useful than SF
or Googe Code. That is to say, useful yes, but amazing or worthy of awe? Not
hardly.

I will say though that Perl was pretty much the only language that made me
smile and I eagerly await Perl 6.

------
mhartl
_Most people talking about Perl are quick to groan about its ugliness. I’ll
first note, most of them don’t know Perl..._

OK, I'll bite. I know Perl. Perl is versatile. Perl is powerful. But Perl is
_Ugly_ with a capital 'u'. Give me Python or Ruby any day.

~~~
SwellJoe
Most folks who say Perl is ugly are talking about one of two things (or both):
Sigils or Regular Expressions.

Regular Expressions have turned out to be so useful that they've been slurped
into every modern language (and using the Perl interpretation of regex to
boot), so it's pretty much a null statement to say that Perl is ugly because
of regular expressions...because it means every language is ugly. This is
usually what people mean when they call Perl executable line noise...but is it
really the fault of Perl that folks write regexes that are longer and more
complex than is readable? Perl just happens to be a culture that is steeped in
UNIX history, and sometimes we reach for a regex before other more readable
tools...it's a failing of the developer, rather than the language. I find
regexes in Python quite ugly, myself, since they're in the ghetto of a library
rather than a first class part of the language. In Perl, you can take a
reference to a regex, or turn it into an object, and of course, you can use
regexes extremely concisely and in one-liners and quick throwaway scripts. I
consider this a worthwhile tradeoff.

Sigils, on the other hand, are core to the language and Perl uses them more
heavily than almost any other modern language (PHP and Ruby both use them to
some degree, but nowhere near the degree of Perl), so if it's not the sort of
thing you like, then Perl is not the sort of thing you'll like. This one, at
least is a point of real difference.

I don't find sigils particularly offensive or particularly nice; I'm pretty
much indifferent to them. Though I am happy to know that the inconstant sigils
of Perl 5 are going away in Perl 6, as they've been a source of confusion for
me on many an occasion (though less so when I'm working with Perl a lot--I
haven't written a bug in weeks due to that particular quirk, and I don't think
I've ever written one that the compiler didn't catch immediately). References
are also problematic, and will also be made prettier in Perl 6 (in particular,
function references are automagic when it is apparent that's what you want to
happen).

My first dynamic language (if I don't count tinkering with ARexx on my Amiga
when I was a kid...and I don't) was Perl, and I worked with it for several
years. Then I went to work in a Python shop, luckily with some of the best
Python developers in the world working on some of the most interesting Python
code going (if you use Python, you use some code written by several of the
folks I was working with), and I really enjoyed working in Python and found it
"cleaner" than the Perl I was accustomed to.

After a few years with Python, I found myself working with Perl again...and I
set myself the task of learning it a bit more systematically then I had the
first time around. Turns out, Perl is a quite pretty language...and I like it
better than Python. Both are very fine languages, but Perl suits me better. I
was merely judging some extremely nice Python written by masters of the
language vs. random snippets of Perl found on the Internet, and unsurprisingly
Perl fared poorly in the comparison.

Ruby, on the other hand...I might actually find it prettier than Perl--it has
a lot of the things I love about Perl, and very few of its rough edges. Though
I'm not fond of the seeming standard usage of "end" for blocks. You guys know
you don't have to use those, right? I mean, it's not Pascal. You can use curly
braces, and it'll work just fine...and bouncing on % works. I'm also not fond
of the occasional verbosity of Ruby that seems to be a function of its
"everything is an object" philosophy.

Anyway, beauty is in the eye of the beholder...and conciseness is one of my
primary "beautiful" qualities. And, if Perl is anything, it is concise (at
least, it _can_ be, and for almost any task).

~~~
trominos
The ugliest parts of Perl (in my admittedly not-exceptionally-well-informed
opinion) are dereferencing variables and automatic list flattening.

I honestly don't know what kind of crazy design process could possibly lead to
the way Perl handles nested lists. $a[0]->[0]? @{$a[0]}?

Why? God?

~~~
shimon
I agree that this approach is deranged. It all stems from the decision to
distinguish between values and references. That decision comes from the
available hardware and typical programming background at the time of Perl 5's
development (early 90s). At that time computers weren't abundantly fast for
most programming goals, and storing all variables as references (or objects)
was a pretty serious "extreme OO" position. Plus, anyone who called himself a
hacker would have to be competent with pointers in C, and Perl references were
substantially easier than that. So Perl layered on ways to reference and
dereference values, and @{$array->[1]{"foo"}} was born.

~~~
Agathos
When Perl references start making as much sense as C pointers it will be a
considerable improvement.

~~~
SwellJoe
You really believe that? I simply can't believe anyone would find working with
complex data structures in C easier than in Perl. It just doesn't make sense,
but obviously a few people agree with you. Have you actually worked in Perl
(and C)?

~~~
Agathos
C pointers make sense to me because they represent what's going on in the
machine. The syntax and the rules behind it are simple enough that they click,
for me.

Perl references seem to carry a lot of historical baggage that leads to the
expressions mentioned elsewhere in this thread. The rules behind them always
seemed arbitrary and I have never felt like I had a grip on them.

Now that said, I'm still more likely to blow my foot off with C than with
Perl, thanks to the do-it-yourself memory management. But at least when it
happens it's for the right reasons.

~~~
SwellJoe
_Now that said, I'm still more likely to blow my foot off with C than with
Perl, thanks to the do-it-yourself memory management. But at least when it
happens it's for the right reasons._

You're my hero, and I mean that.

I'm glad we cleared that up, and I'll readily agree that complex data
structures via references is among the most glaring warts in Perl. It's
obviously more complicated and error-prone than it ought to be, and moreso
than other similar languages.

I've got this theory that the thing that people talk about most in any
language or technology is the thing that is actually most broken about the
language. People talk a lot about references in Perl, and I know they're
broken by design. Similarly, I've got my suspicions about monads in Haskell,
since people spend so much time trying to explain them...seems like there must
be some fire under all that smoke. But I could be just imagining it, and I
think I probably need to spend a lot more time with Haskell before I can
accurately detect bogosities.

------
charlesju
I agree that Perl's CPAN is probably the most awesome thing invented since
slice bread. If you want to hack together something really quick, like PHP,
Perl is awesome.

But the beauty of Ruby on Rails is abstraction. It takes a while getting used
to the code and the framework, but that time invested is paid off in
productivity. Ruby on Rails is really on a whole new playing field. Complete
object orientation, a fully developed framework to deploy and TEST with a
single command in the terminal, MVC, it is just ... heavnly. To be honest, any
language can build the Rails framework. Ruby isn't necessarily too unique in
that sense. What does make it unique is having an evangelical preacher for its
framework, David "oh so sexy" Hansson, and a kind and awesome community.

You should give it another shot, if you're a web developer, it'll make your
life a million times easier.

~~~
jamongkad
I think alot of major frameworks written in other languages have all if not
most of the features Rails has. Django, Pylons, CakePHP, CodeIgniter,
Catalyst, and Mason are to name a few.

Rails to make your life easier? well that's true if your creating web apps
that fit into RoR's philosophy. To quote a member of HN "Coloring outside the
lines is not allowed".

I do agree with you on one thing though, I believe the massive boost in Ruby's
popularity is the great marketing campaign behind it.

~~~
gunderson
That's it, we're all just victims of some catchy jingle.

~~~
jamongkad
In a manner of speaking yes, just take a look at the massive spike in
mindshare Rails has garnered since it's release. Let's take into consideration
the passive influence it also has on framework developers as well.

Nearly every mainstream framework we know has at least been influence by RoR.

~~~
gunderson
True, but that's not because people can't get the annoying ideas out of their
head, it's because of the legitimate innovation that Rails brought into the
mainstream.

------
jrockway
It looks like a lot of people are missing the point of the original article,
so I wrote a long-winded reply here:

[http://blog.jrock.us/articles/You%20are%20missing%20the%20po...](http://blog.jrock.us/articles/You%20are%20missing%20the%20point%20of%20Perl.pod)

------
omouse
In defense of <insert religion here>. A programming language is a tool and
some tools are better than others. There's no need to _defend_ them.

~~~
wheels
Well, it depends on why it's being attacked. My feeling is that Perl is an
under-appreciated tool because it's not cool to like Perl. In the post I don't
really try to defend Perl's actual flaws, which are many, but to point out to
an audience that presumably mostly doesn't know Perl, that it can be really
useful for some sorts of tasks.

~~~
stcredzero
Any given language is under appreciated by that subset of programmers that
mistakes their own ignorance for the language's shortcomings.

------
rplevy
I’m a Perl developer and a big fan of Lisp. However, it should be well known
by now that Common Lisp is the only dynamic language that beats C in
performance. It also defeats Python and Ruby in productivity and joy. And the
code is beautiful and clear to read. It used to be that there weren’t any good
routes to using Lisp for the web, and it didn’t used to be fast either, but
now both of those obstacles have been overcome. Ruby is unstable and keeps
changing, making previous code unusable. Anyway Ruby is just a lame hack
impersonation of a Lisp. Everyone should skip the trends and use Lisp. If for
whatever reason Lisp is not an option, Perl is the alternative that’s been
around a long time and is going to keep growing. It has CPAN. End of story!

------
dhotson
Obligatory xkcd comic: <http://xkcd.com/224/>

------
mr_excellent
> I’m also not advocating doing large projects in Perl.

Actually, you can nowadays. With Perl 5, use strict, use warnings, use Moose,
write tests, and have a look at modern Perl best practices.

And, of course, Perl 6 should be quite well-equipped for handling large
projects right out of the box, ... once that box gets here. :)

------
greyman
"Fast hacks, fast, quickly." From my perspective and style of working, I would
call this a temptation, not an advantage. ;-)

------
pmorici
The thing I hate most is all the special global variables you can set that
effect the behavior of various functions.

~~~
jrockway
These are indeed bad, and nobody uses these features anymore. (They are
important to have around for library authors, but you will probably never need
them in "user code".)

Sometimes it's acceptable to use them in a very small scope:

    
    
      my $entire_file = do { local $/; <$filehandle> };
    

This is much easier to read than something like:

    
    
      my $entire_file = readline $filehandle, -line_separator => '';

~~~
tobidope
This is why I stopped using Perl. I think this

    
    
      entire_file = open('file').read()
    

is how it should look like. You can comprehend it without knowing the
language.

~~~
jrockway
The only reason why you find the Perl hard to read is because you don't know
Perl. I find Spanish hard to read. Why? Because I don't know the language.
That doesn't mean that there's anything wrong with Spanish as a language,
though, it just means I don't know it.

~~~
YuriNiyazov
Two points:

1) He said - "you can comprehend it without knowing the language" and you
responded with "well, of course you can't read it - you don't know it!". The
argument is specifically about being able to read a language without knowing
what % ! and $ stand for.

2) Equating a programming language to a human language as if proficiency or
deficiency in the first implies something about the second is really a bad
idea. Human languages evolve naturally without a designer who can make a
language less or more readable. For a programming language, there is always a
designer, and readability by a person "unskilled in the art" is a major
category by which the language is judged.

