# Why I left Perl

OK, I suppose I really haven’t left Perl; I have many scripts written in it that I still tweak when I find a bug or, more often, want to add a feature. And I’ll even write a new script in Perl if it has a distinctly better library for the task. But it hasn’t been my go-to language for years, even though I programmed in it almost exclusively for over a decade. My reasons for leaving probably aren’t what you expect.

Like most engineers my age, I started programming in a Fortran course my freshman year in college. I got my A, but I’m not sure I learned much about programming or Fortran. I did, however, learn how to operate a keypunch machine, a skill whose usefulness hasn’t held up over the years.

My senior year I had a slot open for an unrestricted technical elective, so I took a Pascal class. The course was taught by Sam Kamin, a freshly minted Ph.D. at the time, who didn’t know he was supposed to take it easy on his class of mostly non-CS majors. As a result, I learned a lot about data structures and structured programming (the hot paradigm back then). The final project for the course was a fully functional line-oriented text editor—a simplified version of the Illinois Central Editor (ICE) we did all our code editing in. If you think that sounds easy, let me point out that the Pascal we were using didn’t have string variables and we didn’t use any code libraries. All we had were stone knives and bearskins.

My last year of grad school, I got a Fat Mac. I programmed it in Mac Pascal, an interpreter that ran very slowly, and in Forth, which became mildly popular on the Mac because it was one of the few ways to create standalone programs without using a Lisa. I read Leo Brodie’s Forth books, and they, like the earlier Pascal class and my later dabbling in Lisp/Scheme, had a big influence on how I build programs up out of smaller pieces.1

After grad school, I programmed in several languages and environments: more Forth, 68xxx assembler, Turbo Pascal, Excel’s macro language, HyperTalk, Lisp/Scheme, and even Basic. Whatever seemed to do the job at hand. But in the mid-90s, when I started doing a lot of text manipulation for both CGI scripts and local utility scripts, I got into Perl and pretty much stayed there for a decade.

Perl was fun. There was a depth to the language that belied its “glue language” origins, so there was always something new to try. Learning it and Unix at about the same time was ideal, because each new bit of knowledge in one raised my understanding of the other. It got the job done with a minimum of fuss.

And I used it for everything. There was the office-y stuff: SGML processing, label making, file and project organization, contact management, boilerplate correspondence. But there were also less obvious uses: a rainflow analysis program for fatigue analysis, a database-like system for tracking and querying a disparate history of shipments from steel mill, pre- and post-processing of finite element results.

So why did I leave? It wasn’t because of any of the common complaints about Perl. I did not find it to be a write-only language. To this day, I open up scripts that were first written in the late ’90s and have no trouble seeing what they do and how they do it. Only the more complex regular expressions are hard to understand, and they’d be tricky in any language. I’ve always thought this complaint about Perl was overblown, made primarily by people who never really understood Perl in the first place.

It wasn’t because of the sigils, either. I confess it’s hard to get back into them when you’ve been away for a while, but when I was programming in Perl regularly, the $s and @s seemed as natural as can be. Lisp programmers often say they don’t see the parentheses anymore; that’s how I was with sigils. It wasn’t because of TMTOWTDI. I’m not a computer scientist and couldn’t care less about orthogonality. I know perfectly well that when there’s an if statement there’s no need for an unless, but sometimes unless just fits better with the flow of my thoughts. If Perl’s programmers don’t mind the extra work in giving it to me, why should I turn my nose up at it? What about the mess that is Perl 6? Well, now we’re getting somewhere. As the years went by and more was written about Perl 6 than was written in Perl 6, my feelings toward the language began to change. I stopped reading the Apocalypses and Exegeses and began looking for a way out. I knew that Perl 5 was still perfectly usable; the language I enjoyed was still there, still getting updated, but the vibe was different. I know this isn’t rational, but likes and dislikes aren’t entirely rational. I wouldn’t say this was a big factor in my shift from Perl, but it played a role. More important was something that Perl 6 was supposed to fix: Perl 5’s awkward implementation of object-oriented programming. Because my formative programming years predate the object revolution, I can work quite comfortably in a non-object environment. The problem was that module writers kept adding object features, so module users (like me) couldn’t avoid the clumsy syntax. Again, I know this isn’t entirely rational, but I can’t tell you how much I hated typing ->. I knew the longer I kept writing Perl—and the longer Perl 6 stayed in the planning stages—the more I’d have to be typing it. The big reason for leaving Perl, though, was people in the Perl community, who had become annoying scolds. Not Larry Wall and the other old Perl guys,2 but the later generation of experts who had taken it upon themselves to tell the rest of us that we were doing everything wrong. “You must use strict” these people said. “Programs that don’t use warnings are the purest hackwork.” “All variables must be declared my or our. That you would even consider doing otherwise reveals what a despicable coder you are.” It’s possible that my memory is off and I’m overstating things a bit, but that was clearly the sentiment: using Perl’s clever and helpful defaults may be OK in a one-liner, but no program more complicated than that should ever rely on them. 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. Update 2/13/12 Unsurprisingly, Mark Jason Dominus was here before me. See his brief writeup on “Why I Hate strict.” I think these counterproductive commandments were the Perl community’s response to outsiders’ criticism of Perl’s freewheeling style. “See,” they were saying, “we can be just as buttoned-down as the next guy.” Rather than celebrating the language’s freedoms, they thought it best to suppress them and to browbeat the rest of us into doing the same. Couldn’t I just ignore these reprimands? No. They were in every new Perl book and every Perl article. If I wanted to learn some new technique or module, I had to run the gauntlet of reproach. I began to doubt every program I wrote and every program I’d ever written. Perl stopped being fun. And so I left. I considered shifting to Ruby but ultimately decided to go with Python. My thinking was that if I was going to break with Perl I should make it a strong break, and Ruby was too Perlesque. Also, I thought I’d take up NumPy for numerical programming and doing everything in a single language seemed the most efficient. As it turned out, I’ve never programmed in NumPy beyond a few tutorial examples—so much for efficiency—but I’ve been happy with Python. And I’ve done and seen enough Ruby programming to know that I could jump over to it with little difficulty. (MacRuby may be my stimulus for doing so.) Is lack of fun a good reason to leave a programming language? Not if it’s how you make your living. Fortunately, I have the freedom to choose among several capable languages and can pick the one (or two or three…) that keep me happy and productive. Because happy and productive go together. Update 2/13/12 A few commenters think it’s odd/ironic/funny/stupid that I’d complain about being told to add restrictive commands to my code and then leave to adopt a language that is inherently more restrictive. My initial response is that I think it’s odd/ironic/funny/stupid that people who think these restrictions are essential wouldn’t move to a language that provides them automatically. So there! My more thoughtful response is that I don’t like being told repeatedly to clutter up my scripts with nonfunctional code. When restrictions are part of the language, as they are with Python, there are no extra lines. Do I have frustrations with Python? Oh yes, and I’ll probably write a post about them soon. But they’re frustrations with the language, not the people. Despite the Python community’s reputation for prescriptiveness, I haven’t run into the sort of scolding that I found with Perl. And that I’m now finding in my comments section. Which is also odd/ironic/funny/stupid. Update 2/14/12 Like presidential candidates who answer the question they wish was asked instead of the the question that was asked, many commenters, both here and at Hacker News, are using this post as jumping-off point for discussing civility on IRC (or Stack Overflow or Perl Monks). That’s fine, but you should know that I never complained about being scolded in those forums. What I was talking about was a sort of preemptive scolding that came as part of seemingly every Perl article and book back in the early ’00s. It wasn’t in response to my asking for someone’s valuable time to help solve a problem that would be easily diagnosed by strict or warnings. It was, instead, writers taking it upon themselves to waste my time by telling me about the hellfire and damnation that would come my way if the variables in my 10-line scripts weren’t declared with my. 1. Those of you who actually read my code may be surprised at this statement, as my scripts here seldom have any formal subroutines at all. It’s true that I no longer write functions for the sake of writing functions—I tend to use them only when they’re going to be reused—but I definitely think of my code as a set of stanzas, each doing one particular part of the job, independent of the others. 2. As I recall, they were all guys except Abigail. Update I’ve been informed by reliable sources that Abigail is also a guy. ## 47 Responses to “Why I left Perl” 1. Jamie says: Similar path. I’m a web developer for a living, and have moved new projects to Python. I love Perl, and it is now as much a part of the unix tool chain as sed or awk, but the culture became groupthink. I like exploring Python, but frequently end up is a situation where I know exactly what I’d do in Perl, and can’t. The answer is usually that I’m Doing It Wrong, use a lambda or something. Sure. I’m just not yet rewired that way. 2. The problem with the advice people give, or rather the whole “use strict/use warnings” thing is that many, many people fail to realise that while in theory it’s a good idea (it does cut down on the number of errors, and increases maintainability), more often than not you don’t need it if you’re just writing something for yourself that will do just one single little thing. If you go and write a big web application, then it makes sense to sprinkle use strict/use warnings around purely because it will make your own life easier in the long run. For one-liners and short “take data from here, munge it, and dump it in a text file”, it’s overkill and not having it isn’t the end of the world. But a lot of people don’t see it like that, it’s either black or white, no grey in the middle. I’m still doing Perl, still enjoying it, mostly because I don’t care to listen to advice from theory-crafters. Dr. Drang, good on you for picking up Python, it’s the better choice - Ruby isn’t just Perlesque, Ruby is a god-awful mixture of Perl and Python that takes the worst parts from both and makes it worse. 3. Andrew says: I can understand that you’d be tired of hearing certain things all of the time, but are you sure that your irritation isn’t leading you to project unreasonableness onto other people? In my experience, Perl folks are a pretty reasonable bunch — one of the least dysfunctional language communities I’ve met. I won’t tell you that you must use strict and warnings always and forever or you’re a horrible person, but I will tell you that they’re good for your health, and if you ask me to debug your code and they’re not to be found, I’m only going to have a limited amount of patience. Why? Because I actually spend a large portion of my life helping people with Perl and Perl-related projects, and I want to make as many of those people happy as I can. But that means I focus my efforts on the people that I can most productively help. If you come to me with a bug, and your code (which is more than a line or two long) doesn’t use strict, then I will need to scan it thoroughly for typos before I can even begin understanding it. If it’s a gigantic mess of globals (which it is, if you’re not using my 99% of the time) then I need to spend my time searching for the unexpected action-at-a-distance. If you don’t use warnings, and I take your code, turn on warnings, and there’s a warning right there telling you exactly what you did to cause the bug… well then, I will insult your intelligence. What other choice do I have? 4. Andrew says: There is, of course, also some humor to be found in someone complaining about being told to turn on a few of Perl’s strictnesses… and leaving for a language where bondage and discipline isn’t optional, it’s a way of life :) 5. You also have the choice to not insult someone’s intelligence. 6. Erik says: I spent some time doing Perl development at a previous job, and I’m sympathetic to the view that strict and warnings are good defaults, especially for larger programs. In fact, I prefer the “bondage and discipline” of Python, push-come-to-shove. But I disagree with Andrew’s comment. I don’t think it’s fair to blame someone for using (or not using) a language feature, and it’s wrong to insult someone’s intelligence. I can understand being frustrated at Perl (or e.g. Larry Wall) for having a “non-strict” mode (which can make debugging harder) but that doesn’t justify taking that out on internet strangers, or members of a community who ask for help. 7. “use strict and warnings” is good advice to novices as it makes it easier for us to help them — the errors they come up with are better errors — but I also hate to see Perl alienating hackers who are able to break rules, norms, guidelines, best practices, etc, etc exactly because they know what they’re doing. This goes beyond strict and warnings. Even though a lot of what Moose does is wrap and replace globs entries in a stash, you’re shunned if you ever do that yourself without using Moose, unless you’ve somehow become famous for doing entertaining things, then this is tolerated as eccentricity. The real art is knowing when to use things. If you’re cow-orking with cows who benefit from strict/warnings, then it’s logical that you would use it for most of the code you share with them. Some times Perl programs benefit greatly from strong typing, enforced at compile time. The question is knowing when. Sometimes sheer effort and intelligence can mitigate the need to use the better tool for the job. Sometimes it’s fun to use the wrong tool just for fun. Some time it’s fun to use the wrong tool just to scare the ever-loving shit out of your cow-orkers and create terror in your department. I guess the rule is never say never. Anyway, cheers, and happy hackin’, whatever you write in. 8. Andrew, it is appalling that you find it necessary to insult others. Such actions actively drive people away from our community, as you see here. Please change your actions, for the sake of the community. 9. (Echoing MJD.) You can also choose to take it as a teaching opportunity. Some people learn by hands-on experience. When somebody comes to you needing help with code that’s full of globals and doesn’t have warnings enabled or strict checking enabled, that’s when you show them how to use the tools they have to help themselves. If you don’t, then who will? 10. Olivier Mengué says: I’ve been much deceived by Python’advertised “bondage and discipline” when I quickly found out that there was no way of checking for variable name typos at compile time, before runtime. I was missing “use strict” and “perl -c”. I spent too much time in Python debugging problems due to typos in code I just wrote or, worse, in an obscure path never tested of some old code. And so Perl is still my main scripting language, and even my main general programming language. 11. It’s too bad - Not just that you’re getting frustrated and walking away from Perl (capitalized because I refer to both the community and the language) but that you’re an experienced hacker with legitimate concerns about community and attitude. Now, Hobbs does make a good point - when one asks for help and knows that the language has built-in facilities that might just reveal the problem, but doesn’t use them, then that’s something anybody should have limited patience with. But hobbs also makes another point, though indirectly. I, among others, have observed (especially in Perl IRC channels) that just under the surface of of otherwise helpful advice and instruction, there’s a certain amount of hostility. That makes me sad indeed. It’s not everybody, but there are more than a few, and it’s far too many. We’re all programmers because we love solving problems, and because we love learning (if I may speak in the general :) Sure, somebody may wander in asking for help and simply refusing to take good, sound and friendly advice, and those people probably do deserve to get whacked with a clue-by-four, but nobody should end up getting insulted or derided, especially not publicly. Now, interestingly enough… I never got into the Python community for the same reason that you’re withdrawing from the Perl community! I experienced the same sort of scolding and condescension and the “why would you ever do that” and the attitude in statements like, “the only right way to do it is…” and “nobody ever really needs multi-line-lambdas…” They were a whole lot more polite about it, but what can I say, we Perl hackers are a rowdy bunch :) 12. brad says: i agree that a huge amount of energy has been misdirected into perl6. the spec does not even detail concurrency yet. i’m not talking implementation, i’m talking the spec. meanwhile ghc for haskell has deployed interesting and useful support for concurrency and parallelism for years now. i also once followed the perl6 design documents closely…but i no longer bother, i no longer care. perl5 is still a great tool i use all the time. 13. Ian says: Yes, I agree with others here that it’s pretty odd to leave Perl due to a perceived ‘you’re doing it wrong’ attitude, only to move to Python! 14. How strange! You know why I eventually came back to Perl from Python? Python didn’t seem fun, and Perl just seems to … I don’t know, empower me? I just can’t get past CPAN. 15. Oh, and forget about Perl 6 - sure, it took some of the air out of the Perl 5 balloon for a little bit, but we’ve learned a few tricks from them and now have awesome things like function/method signatures, type constraints (though those could be better) and the awesome Moose OO toolkit/framework. This past year I’ve spent a lot of quality time at$work with Clojure and C++ and both of them make me miss using Moose very, very much. (Though Clojure has a lot going for it. Dare I even say, it sometimes feels almost perlish!)

16. stento says:

You’re not alone. Lots of us were driven away by chromatic and the like. Now they have whole nonfunctioning modules (Modern::Perl, Common::Sense) that add nothing to the code.

17. I did too resent a bit all the advice to ‘use strict’ - some people just don’t have any other advice and want to show that they know something. But after I started doing it automatically - I think it is a better default. The disadvantage are minute (and for most of the time you don’t need to add an additional line to do the declarations - you just add ‘my ’ to the first occurrence of a variable - like ‘for my \$a (@a)’) and as to advantages - maybe do a lot of typos - but it often spares me the debug cycle and it is perhaps most visible with old code with out ‘use strict’ that I have to maintain. I wish it was default.

18. billthecat says:

Andy Lester, it is appalling that you find it necessary to use such hyperbole. Please change your actions, for the sake of the internet.

Andrew, nobody is making you be a dick. Any time you do that, it’s because you choose to.

Scott, you’re a hacker. I’ve always liked reading your ramblings, it’s something I miss about the “community”, I guess.

Mark Dominus is another hacker. A hacker whose keen mind produces teh awesome, put forth with a temperate, concise word. A rare hacker, indeed.

19. Andrew says:

For anyone who was in doubt earlier: that was a joke. I always do my best to be reasonable with people. My actual response to someone who doesn’t use warnings and then makes a mistake that warnings would have caught is more along the lines of “do you see now why turning warnings on is a pretty good idea?” I don’t make personal insults. I was just making humor of the fact that spending hours of your own time, and someone else’s time, to find a problem that the computer would have told you about in milliseconds, if only you’d asked, is a pretty big mistake.

20. camel says:

I can’t understand people who say “Python and Ruby is more modern than Perl.” :) They don’t have strict mode and a real lexical variable. Need Numpy? Use PDL( http://science.slashdot.org/story/12/02/06/148248/perl-data-language-2410-released )

21. seano says:

8: Andy, your self-righteous scolding is a significant part of what makes the Perl “community” so irritating these days.

The mindless chanting has only gotten worse over the last 5 years or so. Just look at the variety of bizarre boilerplate you see at the top of 5-line code snippets on Perlmonks. Just the other day I saw a “helpful” example that started with use Modern::Perl (strict, warnings, and a few other random things), but contained no variables. FAIL. Then there’s the business of random modules being “helpful” by force-importing strict and warnings into your code, e.g.

use Moose; # an OOP framework... plus strict/warnings!
use Dancer; # a web framework... plus strict/warnings!


FAIL.

22. seano says:

Just to clarify, I’m not leaving Perl over this — the core practical, useful language that Larry Wall created is still mostly there. I just find the behavior irritating and self-destructive.

23. Prakash says:

TMTOWTDI! Isn’t that the Perl way?

So there are Perl-folk preaching the religion of strictures because they found their calling. Don’t like it? Ignore it. Do what feels right to you.

Don’t like modules like Modern::Perl, common::sense etc? Don’t use’em. Perl won’t mind. Use what works for you. If there isn’t anything on CPAN that works for you, create something and put it up there. I am sure there is at least a few people out there that might find it useful.

Perl is your tool. Make it work for you.

24. Paul says:

25. Vincent says:

Definitely it’s whining of old diletant who more often and often pointed on his old crapy code. Programming is a fun, but first it’s a RESPONSIBILITY. How you with all your mistakes is responsible? Most likely with nothing. But when respiratory system of your mom will be under your code, you’ll think hundred times to check that every variable is declared instead of appearing from nowhere. Problem here (and you even don’t see it!) that “new born variable” can have “good default”, but wrong value at all! (for current line of algorithm) So… leave IT area, you cannot explain even why you leave Perl even in 20 paragraphs! So many unnecessary words of “unnecessary guy” in IT.

26. My 2 cents,

Regarding strict/warnings: As many have pointed out, if you don’t like it, don’t use it. Nobody is forcing you to. I don’t quite understand how this needs to be such a big deal. In Perlsphere, there are lots of choices of doing almost everything. Even when it comes to large module/framework like Moose which can impact you even when you do not use it (e.g. through dependency), there are almost always alternatives.

Regarding the community: There are jerks, elitists, and all sorts of other types in every community of sufficient size. We just need to deal with it. Or better, treat it as a solveable problem just like a technical problem, and try to find its solution.

Regarding ‘People who use pseudonyms are nothing but trouble.’. This is everything that’s wrong with Facebook/social media. Where’s our original Internet spirit?

27. Geoff says:

I’ve been developing with Perl as my go-to language for more than 12 years now. I was self-taught in the language, although I had a pretty solid grounding in programming from college. I didn’t spend much time, if any, on the Perl-oriented newsgroups, PerlMonks, or the like.

When I decided to take a look at the greater Perl world around me, I was completely offput by the harshness and incivility of the frequent posters. There are a lot of people in that sphere who not only have opinions to share but also the attitude that the opinions they hold are sacrosanct, and divergence makes you a loser.

CPAN is awesome. The Perl ‘community’ in newsgroups and websites is not awesome.

I continue with Perl today because it gets the job done, and I have a serious, large application written in it. I have begun dabbling with Python just because it appears to be ascendent, and this gig I’ve had for 12 years now probably won’t last forever. But I’ve given up on Perl 6 — it became obvious to me it would never materialize at least 10 years ago — and I see now where the community seems to have lost forward progress again after the 5.14 release. Since I have no interest in Ruby, Clojure, or .NET for that matter (which somehow always seems to overcomplicate things) I guess it’s Perl until circumstances force me elsewhere.

28. billthecat says:

seano wrote:

the core practical, useful language that Larry Wall created is still mostly there

Yup. But it’s at a critical tipping point. Folks who want to preserve that practical language are getting tired. The best technical documentation is being replaced by dubious suggestions (see the new perltut in blead, and the count the lines of Tom’s documentation that have disappeared in the last three years).

It makes me sad that Perl 5 isn’t happy being Perl 5. Maybe there are enough of us that a 5.8 fork followed by some Unicode re-plumbing will be in order some day.

geoff said:

CPAN is awesome. The Perl ‘community’ in newsgroups and websites is not awesome.

It’s too bad. For years and years there was a healthy turnover. Some folks would stay forever, sometimes they would be jaded, sometimes they would be encouraging, mostly a mix of both. New folks would be encouraged not to cargo-cult, but to understand what they were doing. The loudest of the current crop of “leaders” is loud, and not encouraging, except to encourage folks to cargo-cult their crap piles (to their credit, they quickly understand that their recommendations are crap-piles, and then they make new ones, and encourage people to cargo-cult their new crap-piles).

This masks the fact that there are wonderful, reasonable folks still left in the Perl community.

Que sera, sera.

29. Bruce says:

People are always praising Python, but I have had lots of little troubles with whitespace, either because it is missing or insufficient during cut and paste or because I keep having to convert spaces to tabs and back again, and the thought of having my program logic subservient to a troublesome, invisible little devil is scary to me. But what is horrifying is that so many people praise it and code in it, that it makes me less secure in my rejection of it.

30. Sorry to correct you again, but Abigail isn’t a pseudonym, it’s merely a reasonably common male name in the Netherlands. If it makes you feel any better, I once snapped at Aristotle to pick a new nickname when I didn’t like one of his replies on my blog. Afterwards, I learned it was his actual name.

31. I just said this about the Mojolicious team. It was a very sad day for me.

“The big reason for leaving Perl, though, was people in the Perl community, who had become annoying scolds. Not Larry Wall and the other old Perl guys,2 but the later generation of experts who had taken it upon themselves to tell the rest of us that we were doing everything wrong.”

32. Don’t apologize, Scott, I’m happy to be corrected. I shouldn’t have added that self-directed joke.

And I do find multi-gender names interesting, especially those that change from predominantly one gender in some places at some times to predominantly the other gender in other places and times. Vivian and Leslie come to mind.

33. “It wasn’t in response to my asking for someone’s valuable time to help solve a problem that would be easily diagnosed by strict or warnings. It was, instead, writers taking it upon themselves to waste my time by telling me about the hellfire and damnation that would come my way if the variables in my 10-line scripts weren’t declared with my.”

I suspect this is, at least in part, because about every fourth 10-line script we (the helpers/supporters of the community) get asked about that doesn’t contains a bug that would be obvious if it did.

So then when people who do a lot of answering questions on line end up writing, they don’t just teach the code that they think people should write, they teach the code that they would prefer to help a reader of the book debug.

Then we have seano’s comment of:

“Then there’s the business of random modules being “helpful” by force-importing strict and warnings into your code, e.g.”

“When restrictions are part of the language, as they are with Python, there are no extra lines.”

I prefer working with strict+warnings in 99% of cases. I like the fact that a significant percentage of the tools that I use (Catalyst, Dancer, Web::Simple, Moose, Moo, etc.) push those things into my code without costing me extra lines.

I think if I ever write a perl tutorial type thing, I’m going to start off with a paragraph that says something like “I’m going to write my code here such that if you added ‘use strict;’ and ‘use warnings FATAL => “all”;’ at the top of the files it would still work pefectly. In fact, when I wrote this code, I did it with those two lines at the top because I find that I’m too stupid to write working perl without them. But it’s totally up to you whether you actually do that.” and from then on focus on actually teaching them how to do stuff.

Maybe that’ll work. Maybe it won’t. But I do think we have a tendency to forget the distinction between “I don’t want to debug code that doesn’t use X” and “If you don’t use X, you are a terrible person and should kill yourself immediately.”

Also, as Andy Lester was kind enough to elegantly demonstrate, being proscriptive and condescending is massively offensive even if you do only use polite words to do so. I think all things considered I’d actually rather hear “If you don’t use X you can go fuck yourself for all I’ll care about you or your shitty codebase” than be scolded, although I’m perfectly willing to consider the possibility that that’s just me being special.

Then again, ALL of us being special one way or another is pretty much what perl’s supposed to be about. The past decade or so has been interestingly transformative for the community, and I hope we’re starting to get back to having a handle on that fact and remembering that it has a value in and of itself - and to get back to realising that perl has value due to being perl, and that making it a better perl is a more valuable exercise than trying to pander to the expectations of outsiders by dumping a chunk of their aesthetic into our language to appease their fears about incompetent programmers making a mess.

Ask me in another five years, maybe.

— mst, out

34. seano says:

billthecat wrote:

The best technical documentation is being replaced by dubious suggestions (see the new perltut in blead, and the count the lines of Tom’s documentation that have disappeared in the last three years).

The ongoing bowdlerization of the old documentation, trying to make it all consistent with the fashion of the month (perlootut is the most obvious example, but there has been steady stream of minor brain damage). Comparing blead’s docs to those released with 5.005 or 5.6 is truly discouraging.

35. J. R. Andom says:

Ask me in another five years, maybe.

If current behavior is any indicator, nobody will have to ask. You will loudly volunteer your opinion as fact.

Your unprofessional and prickish ways are a large part of the problem. It’s compounded by the fact that some zitty teenagers think you are cool, and parrot you.

Back when the rest of the world cared about Perl, we had to be professional at the conferences, because the world was watching. We were quirky, but professional. It was good for us.

J.R.

36. runrig says:

I still don’t pick my socks up off the floor. Why do you let people telling you what to do bother you?

37. tangent says:

Telling people to always use strictures is no different to telling a learner driver to always check their rear-view mirror before making a manoeuvre, and to do that forever. Any driver who ignores that rule is a menace to everyone.

Perl gives you the freedom to take risks, but any code you write like that will be risky no matter how confident you are in your ability. And lots of risky Perl code in the wild reflects badly on the Perl community, so their reaction is perfectly reasonable.

I am sorry you feel the need to leave Perl for the reasons you give. You will find grandstanding, bickering and bitching in many areas of life. But underneath the not so shiny surface of Perl I have found a wealth of professional knowledge and experience, as well as a more general wisdom, and all freely shared.

38. Paul says:

Never cared for Perl, despite its obvious power and ubiquity, although I’ve programmed in Perl. Now Python … never did, never will … just can’t get past the indentation-as-code-block paradigm … refuse to, on principle.

39. John Smith says:

You voluntarily read free Perl articles, authored in good faith by persons having donated their time in composing said articles for the betterment of the community, and then proceed to publicly lament that your time has been wasted because some emphasis was placed on the topic of Perl best practices?

We’re not going to apologize for encouraging best practices.

With respect to fun, we find that strictures, warnings, et al., actually promote fun since they remove many common sources of frustration.

Here’s where the disconnect is:

You state, “but the later generation of experts who had taken it upon themselves to tell the rest of us that we were doing everything wrong.”

That message is intended for the general public and the expression of that message is absolutely in the best interest of the community. It’s certainly understandable that you may have felt resentment about being apparently dictated to, however, you, having used Perl for over a decade, are not the intended audience of that message.

40. My apologies to Andrew. My comment was not kind. I try to follow THINK when I comment (Thoughtful, Honest, Intelligent, Necessary, Kind) and failed on the K.

41. You’ve accurately described some of the more irritating elements of the community here, but your specific targets seem off.

I’ve been working with Perl almost exclusively for ten years, and the dogmatism from some actors who seem to have never encountered legacy codebases or real world problems is still discouraging.

But … ‘use strict;’? You are a liability without it, and it’s hard to identify any situation where not scoping properly - even in your five line script - is not appropriate, and hard to identify any situation where losing spell-checking of identifiers is a win.

In my circle, we talk a lot about finding the right level of refactoring and the right level of architectural support for your work. Your five line script probably doesn’t need automated tests. For these things to be worth doing, you need a return on investment.

But I can’t imagine a Perl script of any real length which wouldn’t benefit from ‘use strict;’. And if you insist on writing code without it, perhaps it’s better that you’re not contributing to the type of code which gives Perl a bad reputation.

42. I know, I am one says:

No, Andy Lester, you failed on Intelligent and Necessary, too. And it may have been Thoughtful and Honest in your mind, but as the shrink in “Office Space” said, “Whoa, man. That’s messed up!”

You don’t get to follow up being a buffoonish prick with, “But look, I did these other four things all just right!”. You didn’t. You were just a dick.

43. Alex says:

Provocation!

44. Alex says:

I think, the problem is that there is thousands people that just want to get job done without thinking. I have seen a lot of noobs copying parts of code that are using strict and non-strict approach. And that code snippets that work alone - does not work together. Current situation demands another language design approach, so monkey can construct programs using copypaste…

45. SillyMoose says:

It sounds like your coding style is not going to get the most from what the modern Perl renaissance (Moose, Catalyst etc) has to offer. This is no big deal; it may make sense to move to another language so good luck with Python.

46. jrw says:

I haven’t read all the comments yet, but I agree with at least part of your thesis: if you’re not having fun, why bother? Perl is the most fun language I know, which is why it’s still my go-to language. I know when I need to use strict and when I don’t, and I treat strict as my helper only when I think I need a helper. (I like to feel that the language works for me, not the other way around.) If you’ve found python (or whatever) more fun for you, then I’d say, “go for it”. Me, I’m still happy with the freedom that I have using perl.

47. On freenode#perl, I’ve been brutally scolded for atrocious, time wasting code by just about everyone. I appreciate the help no matter what form it comes in. I always assume the problem is within myself. The fact that busy (or bored) people drop everything to help me with random, yet very important to me, problems is a miracle. I could care less about how I am treated, when it comes to the code.

When it comes to personal interactions, it just common sense that the Golden Rule applies. People who don’t follow that are immature and simply don’t know what their doing. It is a shame when this kind of thing harms the Perl community, but when it comes to help with code, I almost want to say that if online Perl help had a reputation for being stringent, exacting, demanding and harsh, that would probably be the best case scenario.