Why I Left Perl(leancrew.com)
leancrew.com
Why I Left Perl
http://www.leancrew.com/all-this/2012/02/why-i-left-perl
9 comments
If you're interested in serious completely mind-bending hacking, don't forget to check eyepopslikeamosquito [1] posts on perlmonks.org. The golfing adventures (in Perl, Python and Ruby) really read like fantasy tales from another planet of superior brains :)
[1]: http://www.perlmonks.org/?node_id=176576
[1]: http://www.perlmonks.org/?node_id=176576
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.
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.
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.
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.
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:
Of course, it doesn't actually matter because you're not supposed to program like that in Python. But if you chose to anyway, ...
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
sub foo {
my $reset = sub { my $x; $x = 0 }
my $inc = sub { my $x; $x++ }
...
}
Of course, it doesn't actually matter because you're not supposed to program like that in Python. But if you chose to anyway, ...
Python has pychecker, which will catch that error for you (as I understand it solves the same issues that "use strict" does).
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.
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.
I have same experiences as you. I can remember arguing with my friend about how inflexible "use strict" made Perl feel--Like it was trying to force C idioms onto a dynamic language (having to define variables, for example). But yeah, after running into bug after bug in my programs I finally saw the light...
The Perl community has pretty clearly collectively decided that "use strict" is the thing to do. I firmly believe the only reason it isn't the default behavior of Perl is because the core community holds backwards compatibility in such high regard.
The Perl community has pretty clearly collectively decided that "use strict" is the thing to do. I firmly believe the only reason it isn't the default behavior of Perl is because the core community holds backwards compatibility in such high regard.
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.
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.
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.
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.
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 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.
Compare what happens when running:
perl -e "print \"\$bob = $bob\";"
perl -e "use strict;print \"\$bob = $bob\";"
python -c "print('bob = ', bob)"
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.
No, YOU have missed the point. I'm not talking about syntax checking. I'm talking about getting a fast compile-time check for my most common mistakes.
The default behavior that you demonstrated from Python is a run-time exception. Until you've gone through every code path, you have no idea whether you're going to trigger that exception. (Even 100% test suite coverage is not enough to guarantee that you won't blow up.) In even a moderate sized program, this can take a good while.
By contrast Perl's behavior with strict is to blow up at compile time, before I begin running the program. This significantly shortens the edit/debug cycle for my most common mistakes.
If you want the equivalent in Python, you have to use external tools like PyChecker.
As for the defaults, there is nothing as hard to change as a misfeature. Everyone agrees that the default would be better if it was reversed, but there is no way to do so without losing backwards compatibility. And given how much critical infrastructure runs on Perl, backwards compatibility matters a lot.
The default behavior that you demonstrated from Python is a run-time exception. Until you've gone through every code path, you have no idea whether you're going to trigger that exception. (Even 100% test suite coverage is not enough to guarantee that you won't blow up.) In even a moderate sized program, this can take a good while.
By contrast Perl's behavior with strict is to blow up at compile time, before I begin running the program. This significantly shortens the edit/debug cycle for my most common mistakes.
If you want the equivalent in Python, you have to use external tools like PyChecker.
As for the defaults, there is nothing as hard to change as a misfeature. Everyone agrees that the default would be better if it was reversed, but there is no way to do so without losing backwards compatibility. And given how much critical infrastructure runs on Perl, backwards compatibility matters a lot.
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.
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.
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)
Yeah, I ran the wrong example code before I posted. Sorry for the noise.
[deleted]
As a long time Perl guy (I had a few websites break when my ISP upgraded from Perl4 and all my email addresses broke with unescaped @ symbols), I think of strict and warnings as being like speed limits. It's a _really_ good idea for inexperienced drivers/perl-programmers to stick to them. Once you've got a bit of experience behind you, you can choose when to ignore that good advice - and just like teenaged boys in cars, mostly people make that choice before they're actually experienced enough to have made a good call, and the near-misses/speeding-tickets/accidents as a result of those poor calls is what ends up becoming the foundations of real experience later on.
I'm firmly of the opinion that telling everybody (especially inexperienced Perl programmers) "you've got to use strict and warnings" is the right approach - with the unstated acknowledgement that if you know what you're doing and are prepared to accept the risks, you'll occasionally choose to ignore that advice.
I'm firmly of the opinion that telling everybody (especially inexperienced Perl programmers) "you've got to use strict and warnings" is the right approach - with the unstated acknowledgement that if you know what you're doing and are prepared to accept the risks, you'll occasionally choose to ignore that advice.
You write that it is not nagging - but you don't really know that guys experience. I can very well imagine some internet pundits nagging him about it.
But yeah - I wrote that only as a devil's advocate :)
But yeah - I wrote that only as a devil's advocate :)
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.
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.
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.
There is one thing that I cannot reconcile in my mind. First is the advice to 'make it a story' - I think it really improved my writings. The second is blog posts like this one - what has this whole life-story to do with the point about abrasive on-line pundits?
And actually it is not only blog posts - journalists often do the same thing, but maybe they don't so often write about their own lives.
And actually it is not only blog posts - journalists often do the same thing, but maybe they don't so often write about their own lives.
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.
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.
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.
Edit: grammar correction.
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.
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.
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.
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.
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."
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."
>>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.
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.
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.
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.
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...
(Note the optional typing of method parameters and attributes.)
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...
(Note the optional typing of method parameters and attributes.)
Yeah, as opposed to perl.
I have to add "my" to a variable to get reasonably-sane scoping, the default is that everything's global.
Perl's defaults tend more to the insane side of the spectrum, especially in comparison with Python (who's entire design philosophy is a reaction to Perl). Not that there's anything wrong with that, and if you've done mostly perl I'm sure it seems natural, but compared to conventions across every other mainstream language it seems crazy.
I have to add "my" to a variable to get reasonably-sane scoping, the default is that everything's global.
Perl's defaults tend more to the insane side of the spectrum, especially in comparison with Python (who's entire design philosophy is a reaction to Perl). Not that there's anything wrong with that, and if you've done mostly perl I'm sure it seems natural, but compared to conventions across every other mainstream language it seems crazy.
> I have to add "my" to a variable to get reasonably-sane scoping, the default is that everything's global
To be precise if strict is not enabled then any variable declared without a "my" becomes a package variable.
With use strict enabled then any variable declared without my, our or state will give a compilation error.
> Perl's defaults tend more to the insane side of the spectrum, especially in comparison with Python
Actually Perl with use strict is the sanest IMHO. Because this means that Perl avoids the sloppy (but serious) errors that can easily creep into code in languages that don't have explicit scoping / variable declaration: http://news.ycombinator.com/item?id=3087990 | http://news.ycombinator.com/item?id=3587659
To be precise if strict is not enabled then any variable declared without a "my" becomes a package variable.
With use strict enabled then any variable declared without my, our or state will give a compilation error.
> Perl's defaults tend more to the insane side of the spectrum, especially in comparison with Python
Actually Perl with use strict is the sanest IMHO. Because this means that Perl avoids the sloppy (but serious) errors that can easily creep into code in languages that don't have explicit scoping / variable declaration: http://news.ycombinator.com/item?id=3087990 | http://news.ycombinator.com/item?id=3587659
Well, in Perl, you have to turn on `use strict`.
> “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.
> 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.
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.
Compilers are good enough for type systems to be advantages, now.
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/