Live data from Hacker News

Why I Use Perl: Reliability

modernperlbooks.com

21–30 of 196 posts

Re: Why I Use Perl: Reliability

#21
post #19
post #3

Reliability? Sure. Readability? Not so much.

You can write readable Perl, just like you can write secure PHP. The fact that a large number of people don't is not necessarily a failing of the language.

Disagree.

Readability and reasonable shoot-self-in-foot protection are not optional. See the article from earlier today about not catering to power users. Same concept. You can't really design a language for the top 5% of programmers and expect it to gain any sort of acceptance. (See: Haskell, Ocaml)

Re: Why I Use Perl: Reliability

#22
post #17
post #4

Earlier quoted context omitted.

I heard some else say Perl is COBOL of the web. (COBOL is also used by banks for it's reliability)

Is 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.

Is 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 for some of job adverts. This old 2009 article http://www.guardian.co.uk/technology/2009/apr/09/cobol-inter... is still pretty much true AFAIK.

Re: Why I Use Perl: Reliability

#23
The 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?

Re: Why I Use Perl: Reliability

#24
post #20
post #3

Reliability? Sure. Readability? Not so much.

The favorite argument of the weak programmer. Some people act like if it's not spelled out for them letter by letter it's not readable. Perl is no less readable then HTML5, given that there is proper indentation. Get over it.

I think reliability implies readability and even impossible without it.

Re: Why I Use Perl: Reliability

#25
post #13

Good 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 Per…

To 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 :-)

We in the finance sector killed it years ago. We're now trying to kill java and move to python.

Re: Why I Use Perl: Reliability

#26

Earlier quoted context omitted.

To 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 :-)

We in the finance sector killed it years ago. We're now trying to kill java and move to python.

Well - since you've still not managed to kill COBOL I'd bet on there still being a lot of Perl in ten years time :-)

Re: Why I Use Perl: Reliability

#27
post #11
post #3

Reliability? Sure. Readability? Not so much.

Would 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…

Lets 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?

Re: Why I Use Perl: Reliability

#28
post #23

The 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?

The 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.)

Re: Why I Use Perl: Reliability

#29
post #3

Reliability? Sure. Readability? Not so much.

This is getting rapidly less true. Perl used to get dinged for having "funny" syntax like the prefix glyphs on variables, infix if, etc... That was in a world where the language mindshare was dominated by Java, which made its name by simplifying C++ and not making any weird or unconventional choices in syntax.

These days all the cool languages have funny syntax (hell, Ruby lifted most of perl's weirdness directly), sometimes (as with coffeescript) it's touted as a feature. So go back and look at perl with modern eyes. I think you'll find most of the conventional wisdom about its readability was more about the conventions than the wisdom.

Re: Why I Use Perl: Reliability

#30
post #17
post #4

Earlier quoted context omitted.

I heard some else say Perl is COBOL of the web. (COBOL is also used by banks for it's reliability)

Is 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.

Yes, 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.

Post reply on HN