
Perl Already Won - anaolykarpov
http://programming.tudorconstantin.com/2015/01/perl-already-won.html
======
DougHaber
I have written a lot of Perl code over the years, and I also hold the uncommon
opinion that it is a great language, and often a far better choice than other
similar languages for a lot of tasks. I agree with the author of this article
that most people who criticize it are extremely ignorant about it.

The most common complaints about Perl tend to be about the code of people who
don't know how to write Perl. Since when is it reasonable to judge a language
on how the amateurs use it, instead of the professionals?

Perl does have its warts, but no language is an exception to that. When you
learn to use a language well, the warts no longer matter. You get into the
habit of writing code in a way that doesn't brush up against them, and that
holds true for every language out there.

To clarify any mention of Perl 6, you need to realize Perl 6 isn't Perl. It is
a whole different language with a really bad name. I know this has caused
great confusion, but Perl 5 is extremely stable, still being developed, and
not going anywhere. You don't need your Perl 5 programs to run in a Perl 6
interpreter any more than you would need them to run in a Python interpreter.

I have written my share of code in other languages, but I always return to
Perl. As a C and Unix programmer, it feels like a very natural fit in ways
that other languages completely do not. It has amazing string parsing, a
superb (though extremely misunderstood) OO system, tons of great libraries,
direct interfaces to POSIX and other system interfaces, really good database
interfaces, networking, and protocol wrappers, very flexible interfaces to
native code, and a really brilliant and well evolved design.

While you should always use the right tool for the job, Perl is a better
choice far more often than people are realizing these days. There is so much
anti-Perl sentiment out there, and the great majority of it is completely
misplaced and made by people who haven't properly learned how to use Perl.

~~~
olavk
> Since when is it reasonable to judge a language on how the amateurs use it,
> instead of the professionals?

Well, if you want to judge the appropriateness of a language for a given task,
you will have to consider how it is going to be used by the people actually
using it.

Maybe some super-disciplined Perl-gurus can write beautiful Perl code, but
since Perl actively encourage ugly and unmaintainable code, the average
developer will produce better code in a language like say Python which
encourages readable code.

You can write ugly code in any language, and you can write beautiful code in
any language. But that definitively does not mean that all languages are
equally good at supporting and encuraging clean and maintainable code!

~~~
Mithaldu
> gurus

It doesn't take a guru. Only anyone who actually cares about readability or
learned from recent books like Ovid's Beginning Perl or chromatic's Modern
Perl.

The main problem Perl has is not anything to do with its language. It's all
the old books from the 90s (that some diehard still recommend), but which
teach outright shit when it comes to readable or reliable code.

------
damon_c
I used to use Perl. I got lots done in Perl from around 1998-2003, but I never
really felt like I was having fun or really understood the language very well.
I just figured out what I needed to.

Then I happened upon some Python code I needed to fix. Within a week or less I
already felt like I "knew" Python better than I would ever know Perl. It was
fun and inspiring and felt so elegant and powerful! I never typed another line
of Perl.

~~~
dorfsmay
Same story here. I can read any piece of python without looking online or in a
book, whereas I always had to look up if a particular notation was
dereferencing a pointer to an array or an array of pointers in perl.

~~~
grondilu
> I always had to look up if a particular notation was dereferencing a pointer
> to an array or an array of pointers in perl.

You should rephrase this because you can't de-reference an array. Plus a
reference to an array is always a scalar so it always has the '$' sigil, thus
it's not clear what you're talking about.

~~~
kstrauser
That is precisely the kind of minutia that made me abandon Perl the week I
discovered Python. I think I'm a reasonably intelligent person, and Perl's
cleverness was a source of fun for the first year or two. I eventually got
tired of feeling like I had to prove my subject mastery every time I opened an
editor.

~~~
grondilu
Frankly, I've never understood people complaining about Perl's references. Me,
when I first learnt about it, I felt in familiar territory, for it reminded me
of C pointers. Hell, even the '->' notation was easy to remember since it's
the same as in C. And as mentioned above, the sigil system of Perl makes it
impossible to confuse a reference with the object it refers to (PS. except
maybe for references to scalars, but those are arguably very rare).

~~~
alayne
For starters, Perl has five different kinds of references with different
qualifying characters for each one.

    
    
                   $scalarref = \$foo;
                   $arrayref  = \@ARGV;
                   $hashref   = \%ENV;
                   $coderef   = \&handler;
                   $globref   = \*foo;

~~~
grondilu
Pardon me but I see only one kind of reference here. The five references above
differ only with the kind of object they refer to. The "qualifying characters"
you're talking about do not qualify the reference, but the referenced object.

~~~
byEngineer
Couldn't make it more complicated, huh?

~~~
grondilu
No, this is not complicated. I have hard times believing people on HN are that
dumb, so stop pretending.

~~~
byEngineer
No. I get it. I do understand. Maybe I should have said needlessly complex. Ie
you can have keyless entry to a car and start the engine with a press of a
button. Or -- instead -- you can search for a key in your pockets (put the bag
in your hand on the ground first) insert it into the lock, turn the key and
then pick up the bag, take the key and put it into the ignition, turn it and
start the car.

So you tell me the first solution is dumb and the other one is smart? I would
say that exactly opposite is true.

~~~
kbenson
You are combining two features of the language that don't really have anything
to do with each other (references, and core type sigils), and conflating them
in a way that's irrelevant, which is why you are getting some pushback on your
critique.

Perl uses sigils. You can think of them like inflection in spoken language.
They provide hints as to what is being referred to, to help make intent clear.

Perl uses references. In some respect, almost all languages use references,
and it's just a matter of whether it's explicit or implicit. Perl makes it
explicit, which means the programmer has to understand it early to make some
things work (nested data structures). Other languages may have it as implicit,
but that doesn't mean the programmer can ignore it, it just means they may be
able to ignore it for a short while when first learning the language. Sooner
or later they will encounter and have to deal with whether they are working
with a copy of data or the original data. If they are lucky, this happens
before it's a nasty bug.

~~~
byEngineer
yes and key car ignition instead of a button is much more explicit too. But
again calling it dumb because of that?

------
mgkimsal
"I believe the main reason haters gonna hate Perl forever is because their
language of choice will never achieve its dominant adoption."

You keep believing that. It's not true, but keep believing it.

~~~
harvestmoon
It's an odd argument. Many technologies were dominant but their fall from the
top generally has a reason.

------
ZenoArrow
So it won because of historic marketshare? By the same logic, Commodore 64
already won. All those C64 haters with their new machines are just jealous.

~~~
claystu
I'm afraid the typewriter defeated all computers--including the C64.

~~~
ZenoArrow
Typewriters are a class of machine rather than a specific model. Can you point
to an overwhelming popular model of typewriter? Then you may have a point. ;-)

~~~
claystu
I know you're just being funny, but go check out this page on the [Underwood
typewriter]([http://site.xavier.edu/polt/typewriters/underwood5.html](http://site.xavier.edu/polt/typewriters/underwood5.html))

~~~
ZenoArrow
Thanks, that's the sort of thing I was looking for. Didn't know about the
popularity of the Underwood typewriter, thank you for the history lesson.

EDIT: What? Why was I marked down for thanking someone???

~~~
kbenson
That's why I like to present counter-arguments with questions for the
assumptions I'm not sure about. If someone can show you you're wrong, with
evidence, they probably exist on HN and will do so. To be clear, that's a very
good thing. :)

------
V-2
"I think that the average age of a Perl developer is about 35 years (I have no
official data for this, my hunch is based on the people I saw at numerous
YAPCs I had the opportunity to be present at).

Assuming this is true and assuming a dev enters into production at 23 years
old, it results that the average Perl developer has 12 years of software
development experience. What kind of code would you prefer in your business
critical, money making software products? one written by people with an
average of 12 years experience in the language of choice"

Whoah, hang on there. Even if they did have an average of 12 years of
experience, it hardly means that it's been Perl all this time.

Obviously the reasoning that led to this bit isn't rock solid, either ;)

"[...] or one written in a language that appeared on the radar in the last
decade: Ruby on Rails, the framework that made Ruby popular was launched in
late 2005"

2005, that's 9 years of experience at best. How lame in compare to 12 :)

(Don't trust Android devs, Android didn't come out until autumn 2008)

~~~
tudorconstantin
Yes, my statements might be superficial, but since when is Android a
programming language? How many developers with 9 years experience with RoR or
Ruby can you think of, besides David Heinemeier Hansson and Yukihiro
Matsumoto?

~~~
djur
I know several, including myself. But total experience is more relevant than
experience with a particular language or technology, unless you're using the
standards of the corporate HR department.

Android isn't a language but it's the kind of heavily specialized environment
that developers will put on their resume and companies will hire for.

------
foobarian
One feature I like for enterprise languages is preventing developers from
writing too clever/magic/brittle code. This usually boils down to compile-time
type checking, good module system, and fewer rather than more language
features. Nothing like digging into some old code to do a bugfix and finding
out it's a Ruby app where some cowboys decided to write their own magic
framework that intercepts field assignments, has heavily data driven control
flow, or a Scala app written by a code golfer. Perl suffers from that problem
as well, which is too bad given how robust it has proven over the years.

~~~
jqm
I've had to go through a bunch of "cowboy" Perl scripts at work. Some are a
ridiculous 2-3000 lines doing things a decently written Python script could do
in a 100 lines or less. (I don't fault the language for this... it's the way
they were written). Many of them have bugs that have existed for years. Nobody
wants to (or practically can) go through and fix the bugs... even the authors.
They are full of cleverness, regular expressions, don't make efficient use of
functions etc. So, in my limited experience, when Perl is bad, it is really
really bad. And that is a very strong negative in a language. I've finally got
permission for flat out re-writes in Python and the old timers have been
fairly sullen about the short amount of time the re-writes thus far have
taken, and how small the code is. Again.. I don't blame Perl for all this. But
it's readability sure doesn't help these kind of situations.

~~~
allendoerfer
I hate this "I do not fault the language for this". It is the argument always
brought up with PHP as well.

You can write ugly code with Python, but the Python language and community
clearly renounces itself from that and is all about readable code. Every
feature addition or remove is done with consideration of code readability and
creating one best practice to perform a task correctly.

JavaScript "maintainers" try their best to build a solid language on top of an
ugly hack. The community tries every day to avoid its own language with
another precompiler.

Java is all about defining solid interfaces, which creates new problems, but
at least they try.

On the other side, Perl people were historically often proud of their crazy
hacks.

PHP does not remove dangerous or objectively ugly language features. It could
avoid SQL injections in new versions all together but instead is focused more
on adoption and backwards compatibility.

The language is partly responsible for the type of code that is written in it.

~~~
nemo
"PHP does not remove dangerous or objectively ugly language features."

I hate to defend PHP, but they have removed some dangerous features. Over the
years there have been a lot of dangerous hacks that were deprecated and
eventually killed. register_globals was deliberately disabled, breaking a lot
of old PHP. Magic quotes got removed (though PHP's morass of variable escaping
is still a tar pit). PHP 6 (or maybe 7 depending on the number they decide to
go with) will kill mysql in favor of mysqli which will help enforce the use of
placeholders/prepared statements (you can still screw it up, but you have to
work harder). They could do better, but they have been improving in removing
dangerously broken features, and have broken back-compatibility over and over
to do so. I actually hate PHP, but when I've had to use it, PHP 5.5/5.6 isn't
nearly as dangerous/broken as PHP used to be (though it's still horrible).

~~~
allendoerfer
They have had PDO since nearly ten years now and are just now thinking about
removing the worst of the other two worse DB APIs they put in the standard
library. Instead of deprecating they were busy copying every language
construct they could find. Even if you want to stay backwards compatible, what
is so hard about deprecating it and moving the dangerous feature out of the
standard library into a module after 2 years?

I give them, that they are slowly changing now (probably because they can not
come up with further constructs), but for a while they still deserve the
rants.

~~~
nemo
If you said "PHP isn't aggressive enough in removing dangerous or objectively
ugly language features" I'd be with you 100%. I was just pointing out that
they do sometimes pull some, though I'd agree they could do better. I don't
use PHP unless its a requirement and have declined nice paying job offers
because PHP was involved (a 5.5/Laravel port from legacy code) so I no longer
stay on top of things (don't really do Perl either anymore), but I was under
the impression that they were killing a lot of deprecated legacy cruft in PHP
6/7.

------
tszming
Perl's motto: TIMTOWDI (There Is More Than One Way To do It) <\-- This include
using other languages such as Ruby/Python to solve your problem.

------
misnome
Fine, yes, Perl "Won". The problem is, that war happened two decades ago and
has very little relevance to the state of things today.

------
gusfoo
I still love Perl. I've done more diverse tasks in that language than any
other. In fact, I think that the only more go-anywhere-do-anything language
that exists is C, but why bother with the hassle of C when Perl is there?

------
lazyloop
Ruby is dead.
[http://www.tiobe.com/index.php/content/paperinfo/tpci/index....](http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html)

~~~
pmontra
It gained 0.07% but lost positions to Perl and... PL/SQL, ABAP, COBOL,
Assembly. I had to google ABAP, it's SAP. I did a little of each of the other
languages and lots of Perl in the 90s. I work with Ruby almost half of the
time now and I'm not worried about its health.

------
teamhappy
I don't know much about Perl, but after seeing "The Perl Jam: Exploiting a
20-year old Vulnerability" from 31C3 it really doesn't feel like it's winning.
You don't need to know Perl to have a great time watching the talk (at least I
didn't).

[https://www.youtube.com/watch?v=gweDBQ-9LuQ](https://www.youtube.com/watch?v=gweDBQ-9LuQ)

\---

I don't know if the talk is any good _if_ you actually do know Perl.

~~~
chromatic
Oh goodness, that's a terrible talk. I suppose the fact that someone can give
such a talk in 2014 with apparent sincerity says _something_ about the state
of Perl, but that talk is more or less equivalent to saying "Look, I passed
arbitrary user input to `unlink` and it deleted a file I didn't intend! How
high up does this conspiracy go?!"

~~~
lawl
Okay, I remember this talk, I'll try to write pseudo code for one of the real
life bugs that nobody saw for 20 years (in Bugzilla that is, not some small
script nobody knows).

    
    
        $user = new User({
            userid => $foo,
            role => "user",
            username => cgi->param("username"),
            password => bcrypt(cgi->param("password"))
        });
    

If you're seriously telling me you instantly spot the bug (if that were real
perl, i don't know perl) without having seen the talk before, then
congratulations, nobody else did, please start auditing perl software.

For anyone that didn't see the talk, no the bug isn't SQL injection or
something like that (though that'd likely be possible too, watch the talk).

If you pass ?username=foo&username=bar then cgi.param("username") will
actually return a list ("foo", "bar").

Now say you pass a list of three elements
?username=foo&username=role&username=admin ... yes seriously. It'll add the
list into the hash and use every %2 element as key and the other as value.
allowing you to overwrite stuff in hashes.

Of course, all of this is documented. But that doesn't make it not terrible.

PS: I don't hate perl. Perl -e is still very handy sometimes.

~~~
wschroed
I'll bite... I have been programming in Perl for the bioinformatics community
for about seven years.

I understand your code is pseudocode, but I should note that the "." is
considered string concatenation in Perl. My very first thought before reading
too carefully was that the bug was that someone tried to concatenate strings
instead of calling functions. :) But I kept in mind that this was
pseudocodish.

Yes, my second thought was, "He says there is a bug here; I wonder if this is
one of those cases where the function returns values in list context." For any
experienced Perl programmer, this is a thing to be aware of, especially when
calling functions in hash maps, not only because it may return multiple values
but also because it may return NO values, which would match the "username" key
with "password".

We may debate the pros and cons of list context, but it is one of the first
features I teach new hires because it can catch people accustomed to other
languages by surprise. Perl is not the only language to support this kind of
feature; it is present in Ruby with the "splat" operator (*array).

~~~
lawl
Sorry for the dot-confusion, i replaced it with "->".

As I said, it may be documented and known in the perl community, in my option
it's still horrible. But yes, that's just my opinion of course.

> Perl is not the only language to support this kind of feature; it is present
> in Ruby with the "splat" operator (*array).

Unfortunately I also don't know ruby, but as far as i understand from what
you're saying is that in ruby you need to explicitly tell ruby to "splat" the
list in.

I really have problems coming up with usecases for this kind of behaviour, but
yes, sure under some curcumstances it might be nice. But i'd argue it's the
minority and so having to explicitly "whitelist" it would make sense. To avoid
exactly this problem, of accidentaly calling a function that might return a
list. The problem that I also see is that at some point you could refactor a
function that previously couldn't return a list.

Except maybe that's actually a thing in perl, to use this behaviour as a
feature, I don't know.

~~~
chromatic
_Except maybe that 's actually a thing in perl, to use this behaviour as a
feature, I don't know._

Yes, that's common. List processing via variadic arity functions is an
explicit feature of Perl.

~~~
prodigal_erik
Not explicit enough. Perl is the only language I've ever seen where

    
    
      sub f { return 1, 2 }
      my %x = (a => f(), b => f());
    

produces a three-element hash that has '2' as a key and 'b' as a value with no
warnings. "Even offsets are keys" is far more error-prone than an actual
syntax for hash literals, and splicing a list (not a hash!) into a hash
doesn't need syntax this terse because it's hardly ever what I wanted. I think
even PHP is more sane here.

~~~
chromatic
_I think even PHP is more sane here._

I'm not sure how an appeal to PHP as lowest-common-denominator of language
sanity argues against understanding the return values of functions you call.

~~~
prodigal_erik
> understanding the return values of functions you call

Sure you should. But confusion between keys and values isn't useful, so
there's no reason for a subexpression to be able to do that, and in PHP it
can't.

------
randomstring
I wouldn't call it #winning. Did Edmund Hillary "win" because he climbed
Everest first?

I think the misunderstanding of Perl is based in the "There is more than one
way to do it" philosophy. A corollary to that motto could be "There is no
right way to do it." Using that corollary, no matter what Perl code you look
at the correctness is in the eye of the beholder.

Even looking at your own code a year later, you'll ask yourself "why did I do
it that way?" This is because the Perl syntax and choice of modules is so deep
and varied that you cannot help but continuously evolve your style.

It takes real world trial and error of writing and reading Perl code to build
your own style and get a handle on what good, readable Perl code should be...
for you.

Haters _are_ going to hate, but Perl programmers know the power and aren't
going to it give up. Winning isn't everything. Getting there first? Well, that
just means you should respect your elders. :)

------
NiklasPersson
Ok guys, let me speak for the sane people of the world: Who cares???

I mean, what are we even talking about? Pearl "won"?? Won what, exactly? The
internet? The.... money? WHAT THE FUCK! Please stop this, ok? This makes no
sense at all and it's probably the most ridiculous discussion on the planet
right now.

~~~
ZenoArrow
"probably the most ridiculous discussion on the planet right now."

HN is unlikely to ever earn that accolade...
[http://www.reddit.com/r/dogtalk](http://www.reddit.com/r/dogtalk)

------
smallsharptools
Perl was the language that I used many years ago but I moved on. Perl 6 was
announced in 2000 and took over 10 years to see a release and by then most
developers moved on like I did. When a language takes that long between
releases there's clearly a lack of enthusiasm and support for the language.
And touting market share? That is a pointless argument. You should be working
with multiple languages and move past these silly blog posts.

~~~
visarga
Perl 6 is not an upgrade of Perl 5. It is a whole different language.

Perl 5 is thriving too. It has many improvements to the Perl 5 of 10 years
ago.

~~~
smallsharptools
Perl 6 was supposed to be an upgrade but it kept changing. I lost interest and
know I will never use it. And if it is a totally different language why is it
called Perl?

~~~
Mithaldu
> why is it called Perl?

The same guy (Larry Wall) who originally wrote Perl 1 to 5.6 is the one who is
writing the spec (though not the implementations) for Perl 6. People let him
do it out of respect, even though it's disastrous for Perl 5.

------
yV2n2E
perl lost because it was unable to do asynchronous processing. folks forget
that the big web 2.0 innovation was a proliferation of ajax and related
technologies, which was the precursor to webapps, iPhone ecosystem, etc.

~~~
nemo
"perl lost because it was unable to do asynchronous processing"

That's not really true in two senses:

1) If you're just talking about AJAX request handlers, those are trivial to
implement in Perl (I put together a number of them). If you're talking about
real async processing in an app, POE/threads/etc. can handle async processing
readily.

2) People moved off Perl/chose to adopt different langs. for many reasons but
async was very rarely one of them.

