
Why I Left Perl - jashkenas
http://www.leancrew.com/all-this/2012/02/why-i-left-perl
======
tomku
This doesn't make much sense. If anything, I'd argue that the Perl community
is taking a page out of Python's book with their recent emphasis on readable
code, best practices and things like "use strict" over the freewheeling
hackery that formed Perl's reputation. I'm not sure what I'd recommend to the
author if they prefer a less prescriptive community, but it certainly wouldn't
be either Python or Ruby. Maybe something from the Lisp family, like Racket?

On a side note, the very things that the author complains about are the same
things that have been motivating me to learn Perl recently. My previous
experience with it had been exposure to badly-written sysadmin scripts and
clever one-liners. However, the stuff I've seen recently (particularly
chromatic's "Modern Perl" book [1] and the Enlightened Perl Organisation [2])
has shown me that it's possible to write Perl that's downright elegant,
without resorting to the ugly mess that many people think of when they hear
"Perl script".

[1] <http://www.onyxneon.com/books/modern_perl/index.html>

[2] <http://www.enlightenedperl.org/>

~~~
mey
As an outsider to the perl community, looking in. I see an identity crisis. Is
perl a shell scripting language, a web framework to scale, a OO Monolith EE
system? Talk to different people you will hear yes. The fact that use strict
exists is a flaw in and of itself. It divides a community on the "correct" way
to use the language.

As an outsider, I don't have a niche that perl fits, that something else with
a clearer purpose doesn't already cover. I appreciate it for it's
contributions to language development, but that's about it.

~~~
autarch
Is this any different than Ruby or Python (or any other scripting(ish)
language)?

Ruby and Python are both good for sysadmin scripting, web frameworks, and big
apps. So is Perl.

The fact that use strict exists is hardly a flaw. It's a useful tool, and one
that many of us use most of the time. The fact that is _doesn't_ exist for
Ruby or Python seems like the flaw.

But if Python did add it, I wouldn't be surprised to see it default to off for
a long time because of backwards compatibility, just like Perl.

------
jrockway
The good news is, you don't have to type "use strict" anymore; it's the
default if you opt to declare Perl 5.11 or higher as the minimum for your
module or script.

People seem to hate typing "my" to declare a variable, but that's fine. I
appreciate the number of times that's caught bugs for me, and I appreciate the
clarity of scoping it allows for. I never really figured out scoping in
Python, because you never declare variables. In Python, you could write:

    
    
       def foo():
          def reset():
             x = 0
          def inc():
             x += 1
          def print():
             print x
    

And it would compile, but not be what you mean. In Perl, you'd write:

    
    
       sub foo {
           my $reset = sub { my $x; $x = 0 }
           my $inc   = sub { my $x; $x++ }
           ...
       }
    

and know exactly what's going on because you had to explicitly declare $x. You
can instantly tell that the Perl is broken. But the Python looks like it works
(but doesn't). That, to me, is a big deal.

Of course, it doesn't actually matter because you're not supposed to program
like that in Python. But if you chose to anyway, ...

~~~
hythloday
Python has pychecker, which will catch that error for you (as I understand it
solves the same issues that "use strict" does).

------
btilly
I remember when I felt as he does about strict.

I also remember the day that I made a trivial error that strict would have
instantly caught, and took out Bloomberg's ftp server as a result. That was
also the day that I was converted.

It is important to know what strict does and doesn't do. It is not a panacea.
But that said, it is a very good default to have on. But most days it catches
problems for me, and they are usually real bugs. Keeping it quiet involves
very little work. And my experience seems typical.

I believe him when he says that he has lots of working scripts that don't use
it. However I also believe that a habit of using it would improve his
productivity. And based on past experience, I'd be willing to bet that if he
put strict on those scripts, he'd find and fix at least one real bug. (And
probably a lot more.)

Given how useful strict is, why shouldn't it be a default "best practice" that
gets recommended? This is not nagging. This is sharing useful information that
makes people's life better. I've had people thank me for it.

~~~
jlarocco
I think part of the point he's making is that it's easier to just use a
language where the "safer" option is the default. Then I don't need to worry
about it, and I don't have to listen to people repeat the same thing over and
over.

And to be honest, people constantly pointing out the same advice over and over
gets old. An occasional, "Hey, did you know..." with some _new_ advice is
cool, but people have been beating a dead horse with "use strict" and "use
warnings". If somebody isn't using strict, it's not because they don't know
about it.

~~~
btilly
I find this statement ironic when the language he moved to is Python, and
Python does _not_ offer the direct equivalent of strict. (Though there are
external verification tools that do. But it is not built into the language.)

In Perl if I have a typo in my variable names or function calls, it gets
flagged by strict vars or subs respectively.

As for people not using strict, someone who is not using strict at this point
in Perl either has very good reason (eg Damian Conway) or is sabotaging
themselves.

~~~
jlarocco
You're still missing the point. It's not about having a syntax checker. It's
about removing the onus from the user and putting it on the
compiler/interpreter writer.

Compare what happens when running:

    
    
        perl -e "print \"\$bob = $bob\";"
        perl -e "use strict;print \"\$bob = $bob\";"
        python -c "print('bob = ', bob)"
    

Python throws an exception and warns about the undeclared variable
automatically. It has the same behavior as "use strict", and I didn't have to
do anything to get it.

Perl makes the special case that's bad 99.999% of the time (you've basically
said as much yourself) the default. At the very least, reverse the situation,
make "use strict" implied, and add a "use unsafe" or something.

~~~
chromatic
_I didn't have to do anything to get it._

You had to use -c; how often do you see Python programmers do so?

With that said, strict mode _should_ be the default for Perl 5 programs.
Having to know the magic incantation to ask the compiler to help you is a
barrier to novices.

~~~
tomku
The -c flag doesn't have anything to do with that behavior, it's just how you
pass a one-liner as a command line argument. From the usage output:

    
    
      -c cmd : program passed in as string (terminates option list)
    

Edit: fixed formatting.

~~~
chromatic
Yeah, I ran the wrong example code before I posted. Sorry for the noise.

------
rhizome
First sentence: "OK, I suppose I really haven’t left Perl"

It's a couple thousand word memoir, about 1/2 comprised of reasons he's _not_
using to "leave Perl," before telling us that it's Perl people who bug him. He
needs to get together with that "no semicolons in Javascript" guy in another
HN post.

~~~
sciurus
It's the sentiment in the Perl community that some of the language constructs
are unsafe and should be avoided that bugs him, not the people themselves.

~~~
Natsu
I guess I don't get what he has against use strict? I've found that it's
usually less painful than the alternative.

------
prg318
I have met several avid Perl developers in my line of work and at conferences
that have been abundantly helpful. IRC users, on the other hand, can be
somewhat of a disaster. I was working a script and couldn't find in the
documentation of how to set a custom error code with "die". I decided to ask
in #perl on freenode, but I was constantly "trolled" with some of the users
spamming "Have you considered reading the documentation?". One of these users
did in fact answer my question (just use exit), seconds before I was banned.
When I pm'd the user who banned me, he explained to me that I had "not
answered his question whether I had answered the documentation". Heh.

Ironically, the user that banned me runs a blog whose most recent blog post
was regarding "Exit statuses and how $? works". So I guess my question wasn't
so stupid after all.

I have heard that #perl on OFTC is slightly more sane and helpful, but can't
attest for that personally.

~~~
petdance
Your IRC experience is not an uncommon one, unfortunately. Next time, check
out #perl-help, which is a bit less hostile.

------
brcrth
It's just me or it's really strange that he's "moved" from Perl to Python
because he doesn't like the fact that there's a preferred (by some people) way
of doing things. Which, again, for some people, it's the "advantage" of
Python, where there should be "one true/simple way" of doing things which,
AFAIK, is summarized at PEP8.

Edit: grammar correction.

~~~
ddelony
I think every programming language has a preferred way of doing things. Every
profession also has a preferred way of doing things. For example, as a
professional writer, I can site the AP Stylebook, Strunk & White, the Chicago
Manual of Style.

Work doesn't happen in a vacuum, and when you're dealing with other people,
some kind of standard is necessary, even if it does seem a little annoying at
times.

------
reuser
OK, so I love Python.

But you are going to find people in the Python world telling you to abide by
PEP8. And saying that you should be using virtualenv. And saying that you
should not use (module-level) globals. And saying that you should be using
various checking tools. And the checking tools may say annoying things (some
of which will be good points about your code).

And I'm kind of one of those people, as well; not saying that there aren't
reasons to break a rule, or that it instantly makes your code crap if you do,
but I understand these arguments.

And a vocal number of those on Python IRC channels tend to be dicks to newbies
or people with unusual ideas.

So I guess I would question whether Python is going to give you what you want.
I can't speak much to Ruby's culture.

Use the tools you like which make your life better, and if it makes your life
better then ignore other people's unsolicited opinions on the internet and
just do your thing.

~~~
TylerE
Python is much better positioned here, since the default is to be sane.

So the typical question is "I'm trying to do something a bit odd, can I?" vs
"Help, that unlabeled lever I bumped into just blew my foot off."

~~~
berntb
>>Python is much better positioned here, since the default is to be sane.

As opposed to Perl? Are you trolling or can you list a few insane things in
e.g. the Perl Best Practices book?

Edit: page 470 of Perl Best Practices (also pg 429 and 431) -- recommends
using strict and warnings. It is _hardly_ controversial or insane, it catches
bugs.

~~~
hythloday
if there are 469 pages of best practices more important than "use strict", I
think "insane" is a fair description of the language.

I'm not making the point it's impossible to write good Perl, because I know
it's possible, I'm saying it's easy to write bad Perl - much easier than in
most other languages I've seen.

~~~
berntb
Sigh, the best practices book is not only about syntax. Troll much? (If you do
_crave_ bondage and discipline use Java.)

There are advantages and disadvantages with everything. Some of Perl's
advantages today are CPAN, Moose and quite extensible syntax.

This is a good example of those three advantages:

[http://search.cpan.org/~flora/MooseX-
Declare-0.35/lib/MooseX...](http://search.cpan.org/~flora/MooseX-
Declare-0.35/lib/MooseX/Declare.pm)

(Note the optional typing of method parameters and attributes.)

------
halayli
> “All variables must be declared my or our. That you would even consider
> doing otherwise reveals what a despicable coder you are.”

> This was stupid advice, but it was common. Perl’s defaults were as much a
> part of the language as regular expressions and were just as useful. I’d
> written dozens of scripts that relied, for example, on variables springing
> to life when first referenced, and they’d all been working perfectly for
> years. It’s not hackwork to take advantage of a language’s documented
> features.

The point here is not it will break the script but maintaining the script
becomes a nightmare. that's why it's a bad practice. Clarity should always be
favored over magic in programming.

------
grout
The only valid reasons to "leave" Perl apply equally to Python. Sorry, but
it's true.

Compilers are good enough for type systems to be advantages, now.

