24 ms·
Why I Use Perl: Reliability
- f055 14y agoPerl is like C++ for the Web. Bulletproof. Unless you intentionally remove the kevlar plates. But then it's on you ;)
- ma2rten 14y agoI heard some else say Perl is COBOL of the web. (COBOL is also used by banks for it's reliability)
- 10098 14y agoI always thought Java was the COBOL of the web :-)
- pwaring 14y agoIs COBOL still used by banks? The people I know who work in two different major UK banks suggest everything is Java now, with Oracle as the preferred database solution.
- adrianhoward 14y agoIs COBOL still used by banks? Short answer: Yes :-) Still the backbone of many banks, building societies, credit card companies, etc. See http://www.careerjet.co.uk/cobol-jobs.html http://www.careerjet.co.uk/cobol-jobs.html for some of job adverts. This old 2009 article http://www.guardian.co.uk/technology/2009/apr/09/cobol-internet-programming http://www.guardian.co.uk/technology/2009/apr/09/cobol-inter... is still pretty much true AFAIK.
- pwaring 14y agoThanks for the links - looks like the COBOL jobs are not promoted as much (I couldn't find any on the four bank sites I looked at) but still there, and reasonably well paid too.
- pauljonas 14y agoMost of those COBOL jobs were offshored or are now performed by Indian/Asian vendor non-immigrant visa holders imported. Within hour drive from my house, I can tally at least a half-dozen corporate IT shops that outsourced heavily in this way, axing thousands (in aggregate) of jobs that normally were served by internal/domestic consulting houses. Yes, on the backend there is still a lot of COBOL, even if it is running on micro-hardware as opposed to the old big iron. Claims adjudication, utility metering, charge card processing, billing for just about any corporation that existed pre-1980, etc.…
- pja 14y agoYes, absolutely. A friend of mine makes his living optimising COBOL programs on IBM mainframes. It turns out there's a pile of cash to made offering to take a look at people's code in return for a cut of the first year of savings when they're paying by the CPU-second. Nothing beats a mainframe for throughput & reliability and lots of the code is still COBOL. IIRC SocGen has a vast amount of code written in some awful monstrosity of an internal language that nobody else has used for decades, but the cost of changing everything over to something more modern is so prohibitive that they just keep on accreting over the existing codebase.
- nthitz 14y agoReliability? Sure. Readability? Not so much.
- pthread 14y agoWell you know, some people tell me Haskell is readable, others say C++ is readable, I tend to argue.
- bengarvey 14y agoSuch a tired argument. Perl has its issues, but you can write unreadable code in any language. Perl is my set of power tools that sit in my basement for weeks until I get them out and fix/make/do something. And what the OP said is correct. I can install new versions and run 10 year old code without issues.
- jbert 14y agoWould you like to post a representative snippet in your favourite lang? I'll try and rewrite in perl and we can compare. (All langs have particular sweet spots, if you do an R or APL oneliner or something it's going to be much more verbose in perl, obviously) It's not that I think perl will be significantly (or at all) nicer, but I think the readability difference is often overstated and I'd like to test that thought.
- afc 14y agoLets see, what about factorial in constant memory? Exponentiation (a to the power of b, where they are positive integers) in logarithmic time (not using built-in exponentiation functions/syntax)? Anonymously add a constant to a number and return it (in a way that can be passed to a function like 'map' or some such)? def Factorial(x): output = 1 for i in xrange(x): output *= (i + 1) return output def Factorial2(x): return reduce(operator.mul, xrange(1, x + 1), 1) I provided two versions, both with constant memory, to show how it'd look with explicit iteration and without it. With this, I get: >>> Factorial(200) 788657867364790503552363213932185062295135977687173263294742533244359449963403342920304284011984623904177212138919638830257642790242637105061926624952829931113462857270763317237396988943922445621451664240254033291864131227428294853277524242407573903240321257405579568660226031904170324062351700858796178922222789623703897374720000000000000000000000000000000000000000000000000L Exponentiation: def Power(a, b): if not b: return 1 if b % 2: return Power(a, b - 1) * a x = Power(a, b/2) return x * x Add a constant: lambda x: x + 7 Or, if you want to name it globally: def TweakValue(x): return x + 7 How do they look in Perl?
- ma2rten 14y agoI remain unconvinced. Should the amount of effort that it costs to update the interpreter really be the main consideration?
- chromatic 14y agoAs I wrote, it's one of the reasons I use Perl.
- jbert 14y ago> I remain unconvinced. Should the amount of effort that it costs to update the interpreter really be the main consideration? No, it shouldnt. But it's a proxy measure for the engineering and productisation effort which goes in. It's relatively easy to get features in quickly with breakage. It's easy to have stability with no change. It's relatively hard to continuously improve with good reliability and back-compat. Perl was a major leader for automated testing since before TDD was a buzzword. Modern perl is a cool language with a great OO model and a shitty threading system (seriously, use multiproc if you want concurrency or just go async with one of the eventing systems). It has some serious warts (no implicit deref of references, the scalar/list context is arguably more trouble that it's worth) and suffers from an image problem. But it's a bulletproof, fast, widely deployed, portable, actively improving scripting language which doesn't have a lot of the warts of it's competitors (broken lexical scoping, problematic object model, poor performance etc). Oh "and CPAN" (ObMention)
- staunch 14y agoAny language would be improved if it had Perl's testing and library culture. Two things it's absolute unsurpassed at so far.
- ryeguy 14y agoDoes ruby not have the same level of both?
- adrianhoward 14y agoShort answer - no. CPAN has had many more years than Ruby's Gems to mature and develop. There are 2560 [edit: I was wrong. 39411 is the right number] gems on http://rubygems.org/ http://rubygems.org/. There are 24,920 distributions on CPAN. Well over 100k modules. The automated testing infrastructure, documentation, etc. also makes it much easier to figure out what modules work on what systems and what versions of perl than in ruby land. Things like meta.cpan.org and cpantesters.org are a god send that I wish I had when I'm using other languages. And the testing infrastructure rocks. It's evolved so everything produces and consumes TAP (http://testanything.org/ http://testanything.org/) a simple human-readable protocol for expressing pass/fail results (with standard modules that help people output and consume TAP). This means I can write tests procedurally, or in an xUnit style, or a BDD style, or a specification-based testing style, or use various DSLs for things like exception testing or for testing web apps... and so on. I just use the style that seems most appropriate for the thing being tested. They all output TAP. All the standard test runners consume TAP. Everything "just works" and plays nice together. I can even easily integrate tests running in other languages or environments as long as they output TAP. In addition - since almost all of the Perl testing modules use a common TAP output module - you can usually integrate different styles in the same test code. So, if appropriate, I can pop some specification-based tests and some friendly web-testing DSL as assertions inside my xUnit tests. Fun :-) Wish other languages test environments were setup this way.
- noste 14y agoAccording to rubygems.org stats page[1], there are 39411 gems available. I think the number 2560 on "all gems" page[2] is the number of gems starting with letter "a". 1. http://rubygems.org/stats http://rubygems.org/stats 2. http://rubygems.org/gems?letter=A http://rubygems.org/gems?letter=A
- c250d07 14y agoGood article with some good points. But it did get me thinking, is Perl getting ready to be in a prime position to become the next Cobol? Probability will go up considerably if Perl 6 never comes out to shake up the ecosystem, but even if it does come, what's to say that there won't be Perl 5 applications running into the next century? Combine its shorthand and with the fact that it's already getting hard to find Perl people, and we could see some dedicated Perl warriors doing very, very well in the coming years.
- adrianhoward 14y agoTo some extent it's already true. There's a lot of Perl in the financial sector. That community is paying a lot more than the average for Perl dev's already :-)
- gouranga 14y agoWe in the finance sector killed it years ago. We're now trying to kill java and move to python.
- adrianhoward 14y agoWell - since you've still not managed to kill COBOL I'd bet on there still being a lot of Perl in ten years time :-)
- gouranga 14y agoWe killed that as well!
- adrianhoward 14y agoConsidering the number of folk dealing with COBOL systems I bumped into at GOTO Copenhagen last week, and the number of COBOL jobs that pop up after a quick google I would beg to differ. I can, of course, understand why you would really want it to be dead ;-)
- tlianza 14y agoThe article makes a good point. But, the title (and comments here) infer that there are a mountain of reasons why people don't use it. Is there a compelling argument against that mountain, or is this just a reminder that Ruby/Python/Closure/Scala communities would be well-served to try and improve in this area?
- fennecfoxen 14y agoThe worst problem with Perl as a language is hiring for a good Perl programmer. It's easy to hire a mediocre Perl programmer, mind you, sometimes even a mediocre programmer who's really good at Perl specifically and knows all the packaging tricks and whatnot so he can get through the interview before falling apart on the job, but really hard to find the good ones. It just doesn't have much mindshare at the moment (ugh, I used the word "mindshare", but it's true). My last job was programming a snazzy Perl system. My current job is at a startup that my last boss helped found. He chose Ruby because he was tired of trying to hire for Perl programmers. After being involved with the hiring process over there as well, I'm inclined to sympathize. Honestly, we ended up just mostly advertising for programmers with experience in Ruby/Python/etc who would be willing to do Perl. That's the only insurmountable-mountain I know of. (Postscript. If you're the rare actual-really-good Perl programmer looking for a job, I am aware of two places willing to hire you, one in Sunnyvale and one in NYC. PPS. Sorry, probably no telecommute. But I don't work there these days so I'm not sure.)
- chromatic 14y agoIf you're the rare actual-really-good Perl programmer looking for a job, I am aware of two places willing to hire you, one in Sunnyvale and one in NYC. Most of the great Perl programmers I know either have full-time jobs or have little desire to relocate. (I'd entertain interesting short-term telecommute gigs now and then myself.)
- latj 14y agoIt sounds like "being a perl programmer" was one of the main characteristics you and your boss were looking for in the beginning... this is a red flag for me- if I am learning more about a job and they seem too concerned to get a "perl programmer", "java programmer", etc, I know to steer clear- it means the people designing the software and managing the projects think its hard to learn a new programming language which means they themselves probably arent good. At moment, there are plenty of programming jobs, and there seems to be a demand for perl programmers- probably because it has fallen out of favor with fresh grads and also a lot of the perl openings are for working on existing code base instead of a new shiny project. I dont blame the kids- they should go work at start ups. But they shouldnt for a moment buy into the anti-perl sentiment that pops up at software meetings and conferences (perl 6 jokes are just easy one-liners for people with no imagination).
- madhadron 14y agoUnleash the smug Lisp weenies! After all, Perl's stability is minimal compared with Common Lisp's.
- jrockway 14y agoAh yes, SBCL, the runtime that manages memory with a signal handler on SEGV. Stable!
- housel 14y agoThat's a feature, not a bug. Write-protecting memory areas using mprotect() and the like, and handling the resulting SIGSEGV, is a popular technique for implementing a write barrier needed for generational garbage collection.
- chromatic 14y agoI've seen it used before to good effect, but one concern is that it's really easy to write flaky and unsafe signal handlers. Getting that right has never seemed easy to me.
- jasomill 14y agoIt's very easy to write flaky and unsafe memory management code in general, yet memory management is used with good results in nearly every production system. And there's nothing wrong with using "tricky" OS and hardware services to implement language runtimes and core libraries --- that's what they're there for.
- pcwalton 14y agoJava does that, for null checks.
- jasomill 14y agoThe CLR uses a similar technique on Windows[1]. [1] http://blogs.msdn.com/b/oldnewthing/archive/2007/08/16/4407029.aspx http://blogs.msdn.com/b/oldnewthing/archive/2007/08/16/44070...
- deleted 14y ago[deleted]
- jwr 14y agoI was about to note that the OP clearly hasn't used Clojure if he uses it as a negative example in terms of reliability, but then I remembered — I promised myself not to get too deeply into these kinds of silly discussions. So, dear OP, good luck writing your large-scale multithreaded high-performance distributed applications using Perl. And BTW, I do use Perl quite a bit and I really like it, for certain tasks. But I'd never make these kinds of comparisons.
- regularfry 14y agoThat's not a comparison he makes.
- adrianhoward 14y agoI was about to note that the OP clearly hasn't used Clojure if he uses it as a negative example in terms of reliability, but then I remembered — I promised myself not to get too deeply into these kinds of silly discussions. Erm... He didn't? He said: "While so much of the shiny-chasing buzz in the micro-ISV startup built-it-and-they-will-fund world seems to chase Clojure and Node.js and app-in-a-page tricks, Perl 5 continues to be my workhorse." No comment on the reliability (or otherwise) of Clojure. And much as I love Clojure - there's an element of truth there. Lots of folk using it because it's the new-and-shiny rather than it being necessarily the best solution. I know I've binned some Clojure stuff that would have been fun for me - because adding the JVM to the mix in production wouldn't have helped us actually get stuff done. (and while it's an unfair comparison - since it's a vastly younger language - the transition to 1.3 wasn't fun for many folk :-)
- grout 14y agoThe readability arguments need to include such modules as Method::Signatures::Simple, which replaces the old manual method (no pun intended) with: method foo ($a, $b) { $self->blargh($a + $b); }
- jrockway 14y agoIs "my ($self, $a, $b) = @_" really that hard to read? It's slightly more characters but I've never found it particularly annoying.
- gatlin 14y agoI actually like the explicit "I'm reading from a special list" syntax because that's what it's doing. A lot of Perl's "ugliness" comes from the language being pretty honest about what it's doing.
- wazoox 14y agoActually, though I tried C++ starting in 1993, Java from 1996, I didn't really grok OO until I tried it in Perl a few years later. Because it shows its guts out, without any sugar coating, I understood what it was about.
- gatlin 14y agoA favorite koan of mine: objects are a poor man's closures, but closures are a poor man's objects.
- pyre 14y agoWhat's more readable? Example 1 (my work's internal source filter format): sub function1( CODE $code, ARRAY $arr ) { # body } Example 2 (standard Perl): sub function1 { my ($code, $arr) = @_; die "Bad params." unless ref($code) eq "CODE" and ref($arr) eq "ARRAY"; # body } Example 3 (Method::Signature): func function1 (Code $code, Array $arr) { # body }
- pauljonas 14y ago7-10 years ago, Perl was my daily bread and butter. It was the language I used the most, and not only did it supplant a lot of C code, but was the optimal scripting solution. Now, for me, Ruby has supplanted Perl in nearly every conceivable way -- OO Perl was always painful, and I do not miss ever having to bless a refrent again…
- ZeroMinx 14y agoI do Perl on a daily basis, and I can't remember when I last blessed a ref. use Moose;
- irahul 14y agoDo you use Moose, or MooseX::Declare? Moose has a startup penalty, but when I am willing to accept that, I would rather use declare extensions as well.
- iloveponies 14y agoIf the startup penalty is such a concern, There is Moo. And Mo. And M. Or failing that tools like Class::Accessor.
- einhverfr 14y agoI bless refs occasionally but not often. Maybe sometime I will get out of the habit but yeah Moose rocks in general.
- rcthompson 14y agoFor any value of $LANGUAGE, imagine this situation: your boss comes to you and say "Hey, they just released a new major version of $LANGUAGE today. Can you go upgrade it on all our production servers?" What is your emotional response to that request? For many values of $LANGUAGE, there would probably at least some element of terror (for many languages, probably much more than just "some"). But Perl is one where, depending on the circumstances, the response could plausibly be as article says: boredom. "Yeah, sure, whatever. I'll go upgrade them." (Certainly there are others, but Perl is definitely one of the best in this regard.)
- Goladus 14y ago> What is your emotional response to that request? Heh the worst upgrade experience I've had with any language was with perl. The issue wasn't with changes to language features, it was chaos resulting from CPAN XS module compatibility and compilation failures. I remember one trivial module (array::compare) went from a having few core dependencies to dozens of CPAN dependencies (including all the moose OO modules). And that was just one module, there was a list of others that had issues. To be fair, that was a Solaris environment and was the only time I had issues that serious. But I'd argue documentation of dependencies is a much bigger factor no matter what the language.
- canadiancreed 14y agoFor most of my previous employers, if I ever heard... "Hey, they just released a new major version of $LANGUAGE today. Can you go upgrade it on all our production servers?" I'd probably fall out of my chair from shock. Most employers that I've had tend to stick with the version of software that they honed their skills on and were hellbent against upgrading at any cost. (Note: Most of my former employers developed on the LAMP stack, which doesn't help PHP's rep much I suppose)
- knighthacker 14y agoReliability, community, and CPAN are some of the main reasons we use Perl at Crowdtilt! Good article.
- danpalmer 14y agoLanguage keywords: Ruby ~40 Python ~40 Java ~50 Perl ~1800 Perl can have all the community support, packages, and testing that it wants, but I dislike programming in it and find it difficult to code in. This is not because I have only ever done Ruby or Javascript, I would consider my strongest languages to be Objective-C and Java, I have used C quite a lot, I know what I am doing with programming languages. I just dislike Perl. Did you know there is a Perl package that will catch references to undefined symbols and fuzzy match them to the closest it can find in the current scope. To me, that seems to be the marker for the general quality of the code.
- chromatic 14y agoWhere did you get the ~1800 figure? Is it possible you're thinking of PHP? To me, that seems to be the marker for the general quality of the code. There's also a module which allows you to program in Latin. Does that mean that every Perl programmer eventually has to live in Europe?
- berntb 14y agoA karma 16 account with some fast and wrong insults. It is old enough not to be green colored. Yet another language war troll account on HN. Edit: I'd guess the troll's main account votes the troll posts up... maybe a heuristic can be made for the HN algorithm?
- whateverer 14y agoI think it's much more likely that it's just somebody who dislikes a language and stated it in a smartass way, as programmers are wont to do.
- bloblaw 14y agoThis sounds wrong...so I thought I'd see what Notepad++ has built into its syntax highlighting lexer (langs.model.xml): * ~ 35, Python * ~ 53, Java * ~ 59, Ruby * ~189, Bash * ~253, Perl <===== * ~928, PHP Perl has a higher keyword count than Ruby or Python, but remember Perl's keyword list includes its core socket/network library (which Ruby/Python/Java don't contain in theirs...according to Notepad++).
- TheRevoltingX 14y agoI've used Ruby, Java, and Perl professionally and my favorite by FAR is Perl.
- gouranga 14y agohave you tried Python? I find it far more "normalised" than Ruby, Perl or Java.
- TheRevoltingX 14y agoNot yet, right now I have no need to learn yet another scripting language. I've been spending most of my language learning efforts on Erlang lately.
- jhuni 14y agoA quick note on sigils: recently I have been thinking that the dollar sign sigil could be used to denote place forms such that $_ is the top place form. Any place form could be cast into a function to be used on any object, for example you could use the place form $first on a collection like &$first(coll) and you could always set the value of a place with something like setf($first, 1). Inside any function $_ will refer to the argument of the function, so you could program without ever using named parameters like in Perl 5. A parameters list like ($x,$y,$z) will just create new place forms rather then variables. I think this would make for a pretty interesting programming language semantics. On the other hand, I don't see much use for the @ and % sigils because I just consider lists to be structures with numeric places and maps to be structures with general places, so I actually prefer PHP style sigils.
- michaelpinto 14y agoYes Perl is a great language -- stability, maturity, etc. But does anybody realize just how hard it is to find decent Perl programmers? It's not a large community to begin with and the pool of decent programmers is even smaller.
- jerf 14y agoUnless you're completely impatient, you can pretty much take anybody with a "scripting" language background and throw them in and it's fine. Works the other way around, too. Python, Ruby, and Perl are all nearly the same language under the hood, with Javascript and Lua somewhat more distant but still not all that different. (Also, I mean someone who knows Javascript, not merely someone who can copy and paste some snippets of jQuery.) Yeah, they may not know the exact APIs you're using, but that's usually the case anyhow. What doesn't work so well, or at least takes a lot longer, is to take somebody with only Java, C/C++, or other such languages, and throw them in.
- michaelpinto 14y agoMy old CTO would have argued with you that Perl was not a mere scripting language* and that our shop's style of coding was indeed object oriented. The other problem we ran into was that the programmers who loved other languages were very religious about it. In fact I use to visualize that each programmer worshipped the specific animal that shown on the O'Reilly book cover: And I'm still haunted in my dreams by that camel. Of course the best programmers in my experience like to work in multiple languages -- but again there aren't that many of them... * This was a few years ago so this was a reference to PHP and Cold Fusion which tended to get mashed into HTML. Python was around then, but a very new thing -- and this was before the age of Ruby on Rails.
- jerf 14y ago"that our shop's style of coding was indeed object oriented" All of the other languages I mentioned are roughly as OO as Perl. (You sometimes have to go looking for it, and Perl's probably ultimately the weakest at the core, but it's still there and mostly strong enough it doesn't matter.)
- nyddle 14y agoSpeaking of Moose, dependencies and reliability: I love Perl but today having to download the whole CPAN to use a MongoDB driver (based on Moose) forced me to switch to pure javascript with mongo js interpreter.
- draegtun 14y agoYou don't need to download the whole of CPAN to install Moose: http://deps.cpantesters.org/?module=Moose&perl=5.16.0&os=any+OS http://deps.cpantesters.org/?module=Moose&perl=5.16.0... MongoDB (if that's what you are using?) has a few more dependancies however it actually uses Any::Moose and so could you Mouse instead of Moose: http://deps.cpantesters.org/?module=MongoDB&perl=5.16.0&os=any+OS http://deps.cpantesters.org/?module=MongoDB&perl=5.16.0&... Were you using cpanminus to install your modules? Because its much faster than default cpan command. I just tested using cpanminus (cpanm) on a vanilla perl install and installing Moose & MongoDB modules took 4 minutes here. Here's a summary: Install perl-5.16.0 via perlbrew - under 15 mins Install cpanminus - 5 secs cpanm Moose - 2 mins 5 secs (installed 22 distros) cpanm MongoDB - 1 min 52 secs (installed another 20 distros) Here's the log: https://gist.github.com/2836306 https://gist.github.com/2836306