

Why Perl? - Mithaldu
http://bits.shutterstock.com/?p=63

======
buster
This is my view on Perl after coding occasionally with it for 2-3 years. For
the last 6+ months i've been coding Perl 8 hours per day. In general i'd
consider myself at least average in those languages (meaning this list
includes my favorite language(s) and ones that i came across for projects and
never looked back): C, C++, Java, Javascript, Python, Groovy, Visual Basic,
C#, PHP.

To be honest i don't agree at all (actually i'm all for letting Perl die
except for little scripts less then 100 loc):

Perl Programmers love their language:

Me (and colleagues) had to use Perl for some projects and i can't say i love
the language at all. I understand it, i can write it and i am constantly
underwhelmed, disappointed and sometimes disgusted. The point is that Perl is
sort of a zombie in many businesses and runs often enough that it can't be
ignored and often enough has to be maintained.

True Freedom:

Probably yes, but "and often can find the core developers in charge of some
code" really doesn't apply anymore.. i browsed a lot through CPAN and a huge
part of modules hasn't been touched for years (i can't count how many modules
i've seen from 2001).

Great Community:

I certainly wouldn't bash a whole community, it sure may be great, but when
searching online you get the feeling it died years ago (most posts are
ooooold). perlmonks.org is often a good resource, but beyond that... the IRC
channels i know are more idle then other languages (by far).

CPAN:

True, a big selling point for Perl is the huge amount of libraries on CPAN.
But it's really untrue to say "there is nothing like it" (PIP for example)..
Same point as above, a big amount of CPAN seems to be not maintained anymore,
there are many modules with unsolved bugs.. just a few examples of widely used
modules that haven't been updated for years and have open bugs:

    
    
      Config::Simple https://rt.cpan.org/Public/Dist/Display.html?Name=Config-Simple
      XML::Simple https://rt.cpan.org/Public/Dist/Display.html?Name=XML-Simple 
      HTML::Parser https://rt.cpan.org/Public/Dist/Display.html?Name=HTML-Parser (atleast active)
    

And i just went through search.cpan.org hit some "buzzwords" and checked the
results, there is a BIG amount of modules nobody looked at for years. I'm not
saying that there is no development at all, but often enough i think "mhh,
should i even use this module? Nobody seems to care about this anymore".
Certainly the most important libraries are actively maintained for sure, no
doubt about that!

Awesome Tools:

Yes sure.. Moose is a good example of what's wrong.. it's trying to bring
object system to a language that wasn't even remotely designed to support
modern language features. Not to bash Moose, i like Moose, it's good! But it
tries to solve a problem that shouldn't be there in the first place.

Another creepy example:

Want to have exceptions in Perl? Turns out the language doesn't have them..
There are modules.. all of them do some black magic trying to emulate this.
The number one google hit (Error.pm) even states "Using the "Error" module is
no longer recommended due to the black-magical nature of its syntactic sugar,
which often tends to break.". And this is not some fancy 2011 language
feature, it still isn't built in! What's also not built in? Perl thinks it's
ok when you read an uninitialized variable. Want the script to terminate when
this happens? You'll have to implement and change signal handlers and take
care of it yourself when other modules try the same... ugh.. Want to know if
an element is in an array? There are some hideous for loops you could do, but
nothing like "if X in Y".. best thing: Most recommended way to do this is to
convert your array to a hash/dictionary and check for the key.. that's basic
array handling.. I could go on with this list for weeks but i fear this is
already too long of a text..

Jobs:

Yes, where i live it doesn't matter. As IT guy it's unbelievable easy to get a
job, that has nothing to do with the language. At least where i live.

My criticism on Perl:

\- Perl lacks basic language features of a modern language (Exceptions, Array
Handling, Error Handling, Unicode Support is horrible and so much more)

\- In general Perl code from different programmers looks very different,
because basic things can be done equally "well". This and a hideous syntax
leads to really hard to read code unless you know every way a Perl program can
be written (and i'm sure not even Larry Wall knows that)

My fun fact on Perl:

\- Did you know that Parrot (the Perl6 VM) won't have a Perl5 interpreter
because it's next to impossible to craft a 100% perl5 compatible parser.. at
least they gave up early.

I've had the highest WTF-count while reviewing other peoples code by far(i may
at one day put my prime example on thedailywtf.com).

Now this will get me a massive downvote, but this is my Perl experience. I can
only beg people:

When your script/tool exceeds 100 lines of code, don't use Perl! Atleast not
if there is the remote possibility of another human being having to understand
or maintain it. Please!

[edited for some paragraphs, but well... not as readable as i'd like it to be,
sorry!]

~~~
tzs
> Perl lacks basic language features of a modern language (Exceptions, Array
> Handling, Error Handling, Unicode Support is horrible and so much more)

Perl has more extensive Unicode support than Javascript, PHP, Go, Ruby,
Python, or Java. That alone disqualifies it from being "horrible". See
<http://98.245.80.27/tcpc/OSCON2011/gbu.pdf>

> Want to have exceptions in Perl? Turns out the language doesn't have them..
> There are modules.. all of them do some black magic trying to emulate this.
> The number one google hit (Error.pm) even states "Using the "Error" module
> is no longer recommended due to the black-magical nature of its syntactic
> sugar, which often tends to break.". And this is not some fancy 2011
> language feature, it still isn't built in!

Exceptions are built in:

    
    
        eval {
           ....code...
           die("foo");  # throw exception
        }
        if ( $@ ) {
           ....this is exception handler...
        }
    

The modules of which you speak aren't there to try to add exception handling.
What they are trying to do is make it look like the exception handling from
other languages (e.g., adding new keywords, changing the way scoping works,
and such to match some other language).

> Want to know if an element is in an array? There are some hideous for loops
> you could do, but nothing like "if X in Y".. best thing: Most recommended
> way to do this is to convert your array to a hash/dictionary and check for
> the key.. that's basic array handling.

Yes, Perl assumes that you did not sleep through "Introduction to Data
Structures". If the operation of "find out of collection X contains element Y"
is one that you need to do often and/or need to be more efficient than linear
search, you should not be using an array.

~~~
buster
I'd like to reply to your Unicode link with another link:

[http://stackoverflow.com/questions/6162484/why-does-
modern-p...](http://stackoverflow.com/questions/6162484/why-does-modern-perl-
avoid-utf-8-by-default/6163129#6163129)

>Exceptions are built in:

Exceptions are built in? Ok, someone decided that this strangely named
construct can also be used to emulate exceptions to a minimal degree (finally
statement where? does it support "bubbling up" the exceptions over different
modules? What if a module redefines signal handlers? I'm also not sure how the
error message can be handed over multiple exceptions or how to catch different
types of exeptions.. can probably be done but only by bloating up the code
unnecessarily). The man page of eval shows a lot of issues and broken cases.
This is the preferred way to do exceptions? Really?

Interesting link on your use of "if ($@)":
<https://www.socialtext.net/perl5/exception_handling> It looks like it's not a
good idea to do that, because it's a global variable (which in itself shows
bad design decisions in the language itself, IMHO).

Finally, why are there myriads of Exception modules and Error handling modules
and die/croak/carp modules, if it's already working so good in the base
language? All of them try to solve problems in the base language (most of them
even state that they exist because of quirks and problems in Perl on their man
page). I never came across the need of looking for a replacement for those in
another language...

> Yes, Perl assumes that you did not sleep through "Introduction to Data
> Structures". If the operation of "find out of collection X contains element
> Y" is one that you need to do often and/or need to be more efficient than
> linear search, you should not be using an array.

If i would care that much about speed i would expect the language to have an
efficient C/asm implementation and not rely on millions of programmers to do
it right. It's no magic, it's expected to just be there, by me. Plus, not
everyone that uses Perl is a good programer and this encourages bad behavior
and hideous code which could just be avoided. Besides, i write lots of network
heavy code. I could run multiple seti@home instances in parallel and not slow
the script down. Tbh, i don't care about the speed of this operation. I far
more care about convenience. It's not convenient for me to have to read and
debug array search operations of other people because they didn't get it
right.

One example: I was debugging a clients script and somehow for very few
elements out of millions the script failed. Reason: He used regex to
compare/search for elements which broke when the element contained a dot,
which translated to the regex special character. It was easy to fix but it was
a pain in the ass to find.

Another example: I had to review and maintain code at a client (mind you this
is a Dr. and shouldn't be that stupid. Nowadays i think he shouldn't even
program ever again but this is a real case!): He obviously wasn't able to
figure this out a nice way and wrote a lot of code to put single elements into
a string and separate each element by a predefined string (#### in this case).
Afterwards he was using regex with #### and ######## and added and removed
those limiters and what not. It was a horrible day for me to read this and
took hours to even figure out what he tries to achieve. Imo, this person
shouldn't touch an editor ever again, but the point here is: I bet you 100$
that he wouldn't have done this in Java or Python or Ruby or whatever, just
because it's easy to do in those languages.

Another point is: Very often i came across the recommendation to convert the
array to a hash and then check for the key. What recommendation is that? When
i have a data structure that is best represented as array, convert it for a
simple operation? ugh...

~~~
Mithaldu

      > I'd like to reply to your Unicode link with another link:
      >
      > http://stackoverflow.com/questions/6162484/why-does-modern-perl-avoid-utf-8-by-default/6163129#6163129
    

To which i have to say that both the Great Unicode Shootout as well as that
answer are written by the same person. The point being: Yes, Perl's Unicode
support is not perfect. But honestly? It's still the best you can get out
there.

    
    
      > >Exceptions are built in:
      > 
      > Exceptions are built in?
    

The both of you are conflating two things here:

\- Exception flow control \- Exception objects

The former is in fact implemented in Perl core via eval { literal code block
}. In earlier versions of Perl there were issues where DESTROY blocks, called
on object destruction, were able to clobber $@, i.e. the error message. Thus
Try::Tiny has become the preferred method of doing exception flow control:

    
    
      my $x;
      try {
          die 'foo';
      }
      catch {
          warn "Got a die: $_";
      } 
      finally {
          $x = 'bar';
      };
    

Mind, that issue has been fixed in 5.14 (
[http://perldoc.perl.org/perl5140delta.html#Exception-
Handlin...](http://perldoc.perl.org/perl5140delta.html#Exception-Handling) ),
so if you're above that, you can safely use eval for your exception flow
control.

    
    
      > does it support "bubbling up" the exceptions over different modules?
    

Yes, evals can be nested.

    
    
      > What if a module redefines signal handlers?
    

If it does it via local it won't even concern you. If it does it plainly
you're in a bit of a bind, but in practice this kind of thing happens
exceedingly rarely on CPAN outside of self-contained applications or
testing/installing code.

    
    
      > I'm also not sure how the error message can be handed
      > over multiple exceptions
    

You die with an array reference containing the interesting exceptions.

    
    
      > or how to catch different types of exeptions.
    

If you know what kind of exception you expect, you write code that
interrogates the scalar for that. For example, if you're expecting an object
of a certain type:

handle_exception( $_ ) if blessed( $_ ) and $_->isa('Exception::Parse');

    
    
      > Finally, why are there myriads of Exception modules and
      > Error handling modules and die/croak/carp modules
    

Because we're collectively still trying to decide how to best handle
exceptions.

    
    
      > I never came across the need of looking for a 
      > replacement for those in another language...
    

In other languages you get a solution plopped in front of you and have to
accept it because you cannot even implement your own exception handling. If
they got it right, great. If they didn't ... welp.

Anyhow, that was only the first part. The second part is Exception Objects,
which is where a lot of the various CPAN modules come in. Since Perl does not
provide a native exception object, you can return literally anything you wish
and many people experimented to see which kind of exception object they
wanted. The concensus for this has landed on Exception::Class.

    
    
      > Another point is: Very often i came across the 
      > recommendation to convert the array to a hash and then 
      > check for the key. What recommendation is that? When i
      > have a data structure that is best represented as
      > array, convert it for a simple operation? ugh...
    

Those recommendations are bullshit and that's where you're right. However the
fact that you think Perl does not have tools to search through arrays shows a
glaring gap in your knowledge. As i mentioned in another comment, Perl has
excellent facilities for searching through arrays:

    
    
      > `my @hits = grep { $_ eq 'dogfood' } @array;`
      > 
      > Alternatively:
      > 
      > `use List::Util 'first'; my $has_dogfood = first { $_ eq 'dogfood' } @array;`
      > 
      > And this is in core.

~~~
buster
Thanks for your answer.

I'm very aware how to search an array in Perl. I really concentrated to much
on searching in my text, whereas the critic should have been for array
handling in general which i find far more inferior to other languages. From my
other comment:

Example: Looking for an element and deleting it? (Taken from perlmonks.org)

    
    
      my @array = qw( your array here );
      my $search_for = "here";
      my( $index )= grep { $array[$_] eq $search_for } 0..$#array;
      splice @array, $index, 1
    

I'm sorry, but this is hideous, really. Just to show you an example of what
"modern" languages can do:

    
    
      array = ["a", "b", "c", "d"]
      search = "b"
      array.remove(search)
      print array
         ['a', 'c', 'd']
    

They may have nearly the same amount of loc but imo the second one is by far
more readable and not as error prone to typos or simple bugs as the Perl one.

~~~
Mithaldu
I guess i'll have to repost this here. :)

The correct answer should've been:

    
    
       @list = grep { $_ ne 'dogfood' } @list;

------
DanielShir
One of the main points that caught my eye while reading this was the fact that
the author mentioned that Perl programmers love their language.

As a Perl hacker, I couldn't agree more, and that's the main point I guess.
Sure, CPAN is awesome (there is even a module for controlling USB rocket
launchers - [http://search.cpan.org/~pen/Device-USB-MissileLauncher-
Rocke...](http://search.cpan.org/~pen/Device-USB-MissileLauncher-
RocketBaby-1.01/lib/Device/USB/MissileLauncher/RocketBaby.pm)) and everything
is open source, but the thing I love most about Perl is the fact that thought
is translated into code very quickly and naturally. Something just clicks and
feels right.

I suppose that's why despite being fluent in several languages, I always come
back to it.

~~~
ominous_prime
I think this issue is where a lot of the schism comes from - not everyone's
thoughts translate well into perl.

I've tried to "get" perl a few times, and I also get tasked with maintaining
legacy perl code from time to time. Perl is the only language I can't readily
use without a few books and perldoc.perl.org handy. It just doesn't fit my
brain - yet I can jump around in other languages with little trouble.

Maybe it's just me, but I imagine that there's others that have a similar
dissonance with the language.

~~~
Mithaldu
Sometimes it takes a while to click. I abhorred `map` for the longest time,
but nowadays i use it everywhere; since i read the SICP and suddenly grokked
them.

------
geebee
It can be very revealing how people feel about a programming language after
they stop using it for new projects. Some people can't quite give it up,
others fondly send flowers once a year, and some people piss on the grave.

I do think people often wind themselves up when they're breaking up with
something - could be a personal relationship, a hobby, a programming language
- anything that required a lot of devotion. I think we do this to justify the
decision and overcome the dissonance we feel (ie., we overstate the problems
we have experienced as a way of overcoming the pain of leaving), so it's
especially impressive when people still look back on a programming language
with affection. Perl seems to be one of those languages.

Java gets a lot of scorn from people who once used it and have moved on. I
personally look back on the days of servlets, jsp, and jdbc fairly positively
- I do remember sometimes looking at the screen and realizing that my fingers
were going to spend a few days typing something that I'd already thought out,
but it all made sense and I felt like I could do anything. I didn't start
hating java until configuration hell arrived. Then, I wanted out.

------
TheRevoltingX
Hear hear, Perl developer here. I've used C/C++/ObjC/Java/Erlang and I just
love Perl for gluing it all together.

I must admit my stack is outdated, I still use CGI::Application, though I love
Moose. I haven't kept us since catalyst, etc started to appear.
CGI::Application works really well for me.

The other day I implemented push notification and geolocation bases
functionality for a client in a couple of days.

To them it looks like magic, but to me it's just awesome that there are
libraries in cpan to do just about everything making it a real time saver.

------
16s
The thing I admire most about Perl is that the libraries written for it tend
to be more complete than what I've seen in other, similar languages. I think
this is due to its age. This may not seem important, but when you need a
complete implementation of something you'll likely find it in a Perl library
before you will in a Python or Ruby library... just my experience.

~~~
abuzzooz
Age is not the real reason. Perl was first released in 1987, while Python was
released in 1991, Tcl in 1990, and Ruby in 1995.

I believe that Perl's success is due to the fact that it was written to
scratch an itch. Larry Wall didn't care much about making a pretty language.
He cared about creating a useful language. To this end, it was picked up
quickly by Unix junkies everywhere.

The other big issue, that's often overlooked, is the Perl community itself.
People working on Perl are really passionate about it. Spend some time reading
the perl5-porters (p5p) archives, and you'll see for yourself.

~~~
jamesbritt
_Larry Wall didn't care much about making a pretty language._

This suggests that Larry Wall was happy to create a kludgey language for the
sake of just getting things done.

I don't have any references around to back this up, but given Wall's
background in linguistics, and his demonstrated interest in language features,
I have to believe he was interested in creating a coherent, thoughtful, as
well as practical, language.

Perhaps you nor I find the results pretty per se, but the language does have
its own aesthetic which apparently many find to have a kind of beauty.

~~~
kamaal
>> _This suggests that Larry Wall was happy to create a kludgey language for
the sake of just getting things done._

Don't really know what to reply to this. Is this your speculation, or do you
have a citation to back this up. Have you had some programming experience in
Perl?

Perl is the only programming language(the other tool is emacs) I have learn't
so far which gives exponential gains in productivity with a linear learning
curve.

No other scripting language remotely comes closer to Perl practicality and
pragmatism in the real world. Python and Ruby aren't even closer.

All beauty and other merely-for-talk stuff aside, For serious applications
nothing is beating C++/Java in the larger scenario. And Python and Ruby never
came to match Perl's glory.

Python's glory is fading pretty quickly. The web crowd is going to the _next
cool framework_. Ruby tends to be pretty famous these days.

Perl is truly among those _first things done right_ tools. Nothing will ever
replace C, Lisp, Perl, Unix, Emacs kind of tools completely. Because whatever
tries to replace them, ultimately ends up looking up very similar to them.

~~~
jamesbritt
_Is this your speculation, or do you have a citation to back this up._

As I wrote, "I don't have any references around to back this up."

I used Perl for a few years about 10 years ago; was quite the perl evangelist
at that job. Then I found Ruby, which won my heart. But I have a pick-cover
copy of the book _perl_ (yes, all lower case). And I've read the whole thing
and liked Wall's jokes. :)

 _Python's glory is fading pretty quickly. The web crowd is going to the next
cool framework. Ruby tends to be pretty famous these days._

Pure trolling.

 _Because whatever tries to replace them, ultimately ends up looking up very
similar to them._

That's an amazing assertion for which I would like to see proof. FWIW, I don't
think Haskell looks like any of those, a passing resemblance to Lisp
notwithstanding.

Perl, et al may have been done right, but it's myopic to think they are some
sort of end point of perfection, if only because we don't know all the things
we want to do, so we don't know all the things we need to have, "done right"
or otherwise.

"There are more things in heaven and earth, Horatio, Than are dreamt of in
your philosophy."

~~~
chromatic
_Perl, et al may have been done right, but it's myopic to think they are some
sort of end point of perfection..._

I'm not sure anyone will argue that seriously.

 _That's an amazing assertion for which I would like to see proof._

It's probably not true for Perl 5's concurrency and parallelism features, such
as they are. (You get fork() and POSIX-style shared memory with IPC or a queue
or RPC or whatever, and you like it.)

It's probably true for access to POSIX and other standards. (I can't remember
the article here several months ago about how to write fast network code, but
it's essentially "Embrace what Unix and Unix-like systems give you." It's not
the article about the Varnish architecture.)

It's almost definitely true for module repositories, where it's not enough to
track dependencies and mirror downloadable code bundles. Testing, change
management, dependency resolution tracking, and documentation formats and
presentation systems are essential. Not even CTAN gets it as right as CPAN.

------
draegtun
The author originally posted this article on his blog a few days before this
one. If you ignore the _trolling_ then there are some interesting comments on
what Perl offers today: [http://jjnapiorkowski.typepad.com/modern-
perl/2011/10/why-pe...](http://jjnapiorkowski.typepad.com/modern-
perl/2011/10/why-perl.html)

~~~
pasbesoin
Thanks. That one also doesn't require JS ("Why not JS"?).

(Call me old-fashioned)

------
superasn
Perl is also an awesome language for web automation and testing, esp with
WWW:Mechanize and LWP.

Also the kind of freedom or strictness Perl offers to users is just unique.
It's like slider on top. Building a website or project? then use strict, and
warnings and objects. Want to write a quick and dirty csv parser? well just
paste your code in the command line. How cool is that!

------
mmaunder
I program in a variety of languages and Perl has formed a big part of that
during the last 12 years. The one thing that all other languages seem to lack
is the native support for regex that Perl has. Perl also seems to give the
best regex performance of any language. Regex is the swiss army knife of text
processing, which is most of what we do when building web apps. I'd like to
see all major web languages support regex natively like perl does including
things like:

$str =~ s/([a-z])/$myFunc->($1)/ge;

------
windsurfer
A few years ago I did a lot of Perl work. Since I do interactive multimedia, I
wanted to try my hand at game programming (Frozen Bubble is written in Perl,
it couldn't be that hard, right?). At the time, however, the only graphics
libraries were extremely limited, which forced me to work in different
languages.

Recently, a new awesome SDL library has been created: <http://sdl.perl.org/>
that actually supports drawing lines on the screen! It's really tempting to
make some perl games again.

Right now I'm using the Effect Engine which has a perl backend. It's
wonderfully written and straightforward. Many of the "simple" things it does
would have been a lot more complicated had they been written using other
popular languages. The library support also means that extending anything is
easy as pie.

~~~
agentultra
I made a few patches for SDL::Perl and I'm a fan. I also helped do some of the
porting work on Frozen Bubble and Pangzero to the new APIs. It was pretty fun.

Perl isn't easy to learn because it's difficult to become familiar with it.
However, I found it enjoyable to work with. It's certainly a little quirky but
for a dynamic language it is also quite malleable. My example is Moose: Perl
didn't ship with an OO system but is flexible enough that Perl6's object model
could be back ported. Don't like Moose? There are others. Or you could just
use straight blessed hashes (which Python, Ruby, and others just put syntactic
sugar around).

For a dynamic language it's pretty nice. But I don't think it's going to be
winning many converts these days. The tower of babel had fallen long ago and
people are starting to pick up the pieces again. Languages that stray too far
from the squishy middle of collective wisdom, I fear, are likely to relegate
themselves to history.

That being said, Perl does have an excellent community. And I really like
reading Perl books. They're really fun where too many are either dry or over-
compensating in quirkiness. Perhaps its those unixy origins that still pull me
to it.

------
gatlin
I've said it before and I'll say it again: other imperative scripting
languages feel like incomplete subsets of Perl. And the community is
fantastic.

~~~
TylerE
This is the language that doesn't have proper function arguments, exceptions,
objects, etc, and you're calling OTHER languages a subset? Sorry, I just don't
see it. What exactly is so awesome in Perl that isn't easily done in
Python/Ruby/Scala/D/Haskell?

~~~
gatlin
> proper function arguments
    
    
      my ($a, $b, $c) = @_; # this works
    

Or I can do things like

    
    
      my ($first, @rest) = @_;
    

giving me features which require all manner of annoying syntax in Python.

> exceptions

[http://search.cpan.org/~nilsonsfj/Error-
TryCatch-0.07/lib/Er...](http://search.cpan.org/~nilsonsfj/Error-
TryCatch-0.07/lib/Error/TryCatch.pm)

or just eval and see what the output is.

> objects

 _Edit: I was being an asshole_ Perl has a decent object system out of the box
and Moose for those times when you want type constraints.

    
    
      package MyClass;
      use base 'Parent';
      
      sub new { my $class = shift; bless { prop1 => undef },   $class; }
      
      package main;
    
      my $obj = new MyClass;
    

> etc

Lexical scoping, anonymous coderefs that can be passed as data, modifiable
syntax, reference semantics, and the regex engine I see other languages
comparing theirs too.

~~~
kbd
> giving me features which require all manner of annoying syntax in Python
    
    
        def foo(first, *rest):
    

vs

    
    
        sub foo{
            my ($first, @rest) = @_;
    
    ?

~~~
gatlin

      >>> def foo(first, *rest):
      ...  print first
      ...  print rest
      
      >>> foo([1,2,3])
      [1,2,3]
      ()
    

__*

    
    
      sub foo {
        my ($first,@rest) = @_;
        print $first . "\n"; 
        print @rest;
      }
    
      foo (1,2,3);
    
      1
      23
    

__*

It's probably my Python deficiency. My claim that Python's syntax was going to
be uglier is probably wrong, but I think the claim that Perl's is appreciably
worse is also wrong. We can all get along!

~~~
TylerE
Not sure I follow you. Your python example is very explicitly passing a
_single_ arguement, a list of three items. If you call it the same way you
call the perl code, you'd have the same result.

------
brider
Honestly, I am completely unsure why we are discussing this article, or why it
showed up in a place like HN. It is clearly based on shutterstock's agenda in
acquiring perl developers.

I coded perl full-time for a year, straight up, for 10+ hours a day -- using
it as the glue to hold a rudimentary distributed system together.

To show that I myself am not biased, I will admit Perl has a lot of nice
things, but it also has a lot of undesirable things. This article only
concentrates on the former (and doesn't even focus on what could arguably be
the _right_ nice things to speak of).

------
chrismealy
Perl was the first language I loved, and I'll always love it, but I'm sticking
with ruby. No more my $self = shift

~~~
DanielRibeiro
Also, Ruby's lack of @ $ % is great. And the fact that it has a single object
model, not falling to the Paradox of Choice[1] makes it a great alternative to
Perl.

And what is best: I've never seen anyone that loved Perl not enjoy Ruby. They
both have very similar ideologies, but Ruby stands on the shoulders of Perl,
Smalltalk and Lisp. Therefore it could see farther.

[1]
[http://en.wikipedia.org/wiki/The_Paradox_of_Choice:_Why_More...](http://en.wikipedia.org/wiki/The_Paradox_of_Choice:_Why_More_Is_Less)

~~~
rcfox
"In Ruby, ordinary variables lack sigils, but "$" is prefixed to global
variables, "@" is prefixed to instance variables, and "@@" is prefixed to
class variables."[0]

Okay, I don't know Ruby well enough to know if these are commonly used
features, but the statement that there are no sigils is false.

[0]
[http://en.wikipedia.org/wiki/Sigil_(computer_programming)#La...](http://en.wikipedia.org/wiki/Sigil_\(computer_programming\)#Language_comparison)

~~~
prophetjohn
Ruby even uses some predefined globals (eg $_) that are pretty much straight
out of Perl.

[http://www.tutorialspoint.com/ruby/ruby_predefined_variables...](http://www.tutorialspoint.com/ruby/ruby_predefined_variables.htm)

~~~
jamesbritt
_Ruby even uses some predefined globals (eg $_) that are pretty much straight
out of Perl._

They exist, and while I'm a fan of $: over $LOAD_PATH I don't think I've even
seen $_ used in the wild.

~~~
prophetjohn
I don't really have the perspective to comment on how common they are, but
they do exist. Ruby is full of little things like this, which one of the
things I simultaneously love and hate about Ruby

------
rhizome31
This is really just a checklist that can be applied to any language. So yes,
why not Perl after all...

~~~
kablamo
There are lots of great languages. I think we can learn from each other. Perl
has a lot of problems but also a lot of strengths. CPAN is one of its
strengths.

Compare CPAN: <https://metacpan.org/module/Moose::Manual>

Then compare with other repositories from other languages:
[http://stackoverflow.com/questions/1693529/list-of-top-
repos...](http://stackoverflow.com/questions/1693529/list-of-top-repositories-
by-programming-language)

CPAN does

* Documentation

* Historical versions of libraries

* Search

* Source code

* Integrated bug tracker

* Integrated review system

* Links to repositories

* Integrated automated tests regularly run against hundreds of machines/operating systems/perl versions.

~~~
draegtun
And also there is:

* CPAN Forum - <http://cpanforum.com/>

* Annotated CPAN - <http://www.annocpan.org/>

* Discussion/review on pre CPAN modules - <http://prepan.org/>

------
_delirium
Perl is my first choice go-to language, but I'm not finding the CPAN advantage
as big as it used to be. Increasingly I'm having to use languages I don't
prefer (not out of any hostility, just not as comfortable in them) because
they have libraries that CPAN either doesn't include, or doesn't include with
the same polish/functionality. For example, there doesn't seem to be anything
in the Perl world as good as the Python Imaging Library (PIL); PerlMagick is
featureful but not very fun to use. The data-visualization libraries are also
way behind Python's matplotlib. NLP is a closer call, but overall I find NLTK
better integrated and maintained than the stuff in CPAN, though CPAN _does_
have modules for most things you might want to do. I'm currently using Perl
for some simple GIS stuff, and the GIS packages also are pretty hit-or-miss.

Admittedly I might just not be good at finding the _right_ packages. Python
seems to have more of a culture of headline projects, which register their own
domain names, like NLTK, PIL, numpy, etc., while Perl mostly has a big pile of
CPAN modules, which range from excellent and actively maintained, to a script
someone once wrote that's incomplete and hasn't been touched in 12 years.

~~~
phaylon
Have you tried Imager[1]? It's what I'd recommend these days, but I don't have
experience with image manipulation in any other language so I can't compare.

I agree that there need to be better ways to find modules. I have high hopes
for MetaCPAN in this regard.

[1] <https://metacpan.org/release/Imager>

------
Duff
My perspective on Perl is that it's like a Dremel tool.

If you've ever had a household project that requires a tool you don't have or
skill you don't know, you can usually take your Dremel out, dig through the
gift pack of attachments that you received for Christmas, and find a way to do
what you need to do.

Will the results be pretty? No. Is it the best way to get the job done?
Probably not -- but it's good enough.

Perl's great because it has the power to do lots of things, quickly, and
without alot of drama. It's dangerous because it's just good enough to keep
some hastily written program around too long. Many "black box" processes
written in unintelligible Perl by persons unknown haunt data centers all over
the globe.

I enjoyed the time I spent with Perl immensely. But I spent it as a individual
sysadmin/DBA turned developer integrating lots of complex systems on multiple
platforms a decade ago. (For better or for worse, some of those apps are still
working!) For a team of programmers in 2011, there are probably tools out
there that will do the job better for the same price.

~~~
JadeNB
> My perspective on Perl is that it's like a Dremel tool.

Or, perhaps less literally, like a Swiss-Army chainsaw.
<http://catb.org/jargon/html/S/Swiss-Army-chainsaw.html>

~~~
Duff
That's great... I somehow never ran into that before. Thanks!

------
bitcracker
Anyone using Perl 6?

What is your experience? Is it mature enough for serious use or should we stay
with Perl 5?

This article <http://perlgeek.de/en/article/5-to-6> shows a glimps of the
features of Perl 6.

~~~
chromatic
_Is it mature enough for serious use or should we stay with Perl 5?_

Stay with Perl 5.

------
greenName
The great downfall of Perl is that it's slow:
[http://shootout.alioth.debian.org/u64/which-programming-
lang...](http://shootout.alioth.debian.org/u64/which-programming-languages-
are-fastest.php)

60X slower than C. 30X slower than Java

If sed/awk/grep/sort/tr is not up the task, sure, try Perl for those one offs.
For serious computation? Fuggedit.

~~~
bitcracker
> The great downfall of Perl is that it's slow:

What about Perl6 and LLVM?

My personal experience with Perl5:

\- It has incomparable expressiveness. Only APL is more expressive. But more
expressiveness makes source code less readable.

\- Perl's regexp engine is the best - no doubt about it.

\- I would never use Perl for big projects. Its odd syntax ($, sometimes %,...
before variable names etc.) is terrible for long term maintainability.

~~~
chromatic
_What about [Perl 6] and LLVM?_

No Perl 6 implementation is mature enough to use for practical purposes.

LLVM probably won't help Perl 5, because Perl 5 lacks sufficient type
information, and because LLVM's design really seems to want static languages.
See also the JVM and the CLR.

 _Its odd syntax ... is terrible for long term maintainability._

I would never attempt to maintain code written in a language I don't know.

~~~
bitcracker
> I would never attempt to maintain code written in a language I don't know.

I know Perl 5 well enough but will my successors also? Is Perl still rising? I
don't think so.

~~~
chromatic
_I know Perl 5 well enough but will my successors also?_

That sounds like a hiring and training question.

~~~
bitcracker
> That sounds like a hiring and training question.

Yes, Fortran, APL and Ada had the same questions.

~~~
chromatic
If only they had a CPAN growth rate to measure.

~~~
greenName
"compilable perl" has been "on the horizon" for 15 years. I suggest you not
measure it by that rate.

~~~
chromatic
I don't know what "compilable Perl" has to do with the CPAN. "Compilation"
suggests some sort of execution and distribution strategy, while the CPAN is
an archive of resuable code and the surrounding ecosystem of dependency
management, documentation, bug tracking, history, annotation, and
comprehensive testing around it.

I'm suggesting that if you measure the amount of code submitted to the CPAN,
the number of authors, the frequency of updates, and the freshness of
versions, you'll see that Perl 5 is far from stagnant.

~~~
bitcracker
> you'll see that Perl 5 is far from stagnant.

You mean _CPAN_ is far from stagnant. CPAN is nice, yes, but I don't think
CPAN alone is enough to invite newcomers to Perl.

Perl 5 itself is stagnant. New features are not developed in Perl 5 but Perl
6. Perl 6 ist still not mature after several years of development. I tried it
on Parrot yesterday, it ran way slower than Perl 5. Who ever would use it when
even the Perl advocates don't recommend it? Perl 6 looked so promising. I am
disappointed.

~~~
Mithaldu
> Perl 5 itself is stagnant.

I'm sorry to say, but you're merely showing that you're not aware of core
development of Perl. Not a mistake of your's, mind, marketing of perl core dev
is terrible and i need to start fixing that, but there's a lot going on:

<https://github.com/stevan/p5-mop>
<http://perl5.git.perl.org/perl.git/shortlog>
<http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/>
<http://perldoc.perl.org/index-history.html>

~~~
bitcracker
> marketing of perl core dev is terrible

A link "Current Developments" in perl.org would be helpful. Thanks for the
links but I'm not interested in minor changes of Perl 5 (Unicode etc.). I was
very interested in the new features of Perl 6.

No matter, I lost my patience and left Perl years before and returned into the
Lisp and Scheme world where I was before. Sometimes I still use Perl 5 but
merely for small scripts.

Perl 6 got stuck in Parrot while Lisp enjoys a revival in Clojure, Qi/Shen and
Racket Scheme which are all usable and under heavy development.

The new Lisp versions support multiprocessors and compile to JVM, Javascript
(V8), Lisp, Scheme or C. Lisp and Scheme macros are still superior. In Qi/Shen
I can even write attribute grammars in BNF style. I can compile my source to
standalone native EXE files which are really fast. For that reason I prefer
Scheme and Lisp over Python and Ruby. I don't need Perl 6 anyymore!

~~~
Mithaldu
I linked you to a repo where a meta object protocol for the perl core is being
developed and you say you aren't interested in minor changes?

Shine on you crazy diamond! :D

~~~
bitcracker
If you think that MOP for Perl is something big then I'm not surprised that
Perl doesn't make real progress anymore.

------
101000101
So if I compile a busybox-like crunched binary with a variety of "do one thing
well" UNIX utilities, including sh itself, and then I write a shell function
that only calls this single binary it its various incantations and uses pipes
and temporary files residing on tmpfs or mfs (instead of reading entire files
into memory the way perl does), and this binary used like this can do all that
Perl can do, why should I use Perl?

That's my question.

~~~
chromatic
* [If] ... this binary used like this can do all that Perl can do...*

If you can do that, great! Do it. That's a big job though, and it's not worth
my time even to consider how much work it is. That's why I don't bother.

~~~
101000101
It's actually a very small job.

The hard part I guess is learning to do things with the shell and UNIX
utilities instead of Perl. And simplifying what you do and how you do it.

If you choose to do complex things and do them in complex ways, or you can
only see complex solutions where simple solutions exist, I guess a module-
powered scripting language like Perl becomes irresistable and using the UNIX
base utilities becomes a prohibitively painful exercise.

I want to learn Perl. But I just cannot find the motivation because I never
need more than what UNIX gives me.

~~~
Mithaldu
You wrote a website with only the shell and unix utilities?

~~~
101000101
I write small, simple shell functions using a single busybox-like binary that
do the same things as Perl modules. I store the shell functions in a local
repository and load/unload them as needed. I make "programs" by combining
different functions.

------
pitchblack
There’s nothing that can’t be said about any other scripting language from
their respective fans.

------
lawnchair_larry
Perl is easily the worst language I have ever had to use. I just can't stand
it. Maybe perl 6 changed everything, but I thought perl 5 was such a terrible
hack.

------
insertnickname
Perl blah Perl Perl Perl? Perl! Also, did I mention Perl?

