Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I Use Perl: Reliability

modernperlbooks.com

Post reply on HN
Print view View original

31–40 of 196 posts

Re: Why I Use Perl: Reliability

#31

Post by chromatic »

fennecfoxen wrote: post #28
tlianza wrote: 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 (ug…

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.

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

Re: Why I Use Perl: Reliability

#32

Post by peterwwillis »

ma2rten wrote: post #5

I remain unconvinced. Should the amount of effort that it costs to update the interpreter really be the main consideration?

Not at all. You shouldn't be updating the interpreter unless you have to, and then it should be done through your distro's package management and standard upstream path.

The OP seems to think it's a good idea to upgrade his production code to the newest stable interpreter just because it was released. This is a recipe for disaster. Sometimes there are just hidden bugs you don't see until a weird use case blows up your code, and thorough stress testing should be performed after the unit testing to ensure no major surprises after upgrade.

The best rule for keeping your software stable is: don't change anything.

Re: Why I Use Perl: Reliability

#33

Post by latj »

fennecfoxen wrote: post #28
tlianza wrote: 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 (ug…

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

Re: Why I Use Perl: Reliability

#35

Post by mhd »

nthitz wrote: post #3

Reliability? Sure. Readability? Not so much.

Beyond the "You can write Fortran in any language" argument about properly structuring your code, there is a certain amount of truth in this. But in my opinion, this is mostly about familiarity. It's like a human language that uses another alphabet. Sure, if your native language is English, Polish looks more readable than Russian, as the latter is using a different alphabet. But that's a literally superficial point of view (cf. Lisp's parens), a stepping stone that is easily surmounted and doesn't change the total learning curve a lot.

English does look simpler than French, too. On the other hand, once you get beyond the accents, you know how to pronounce French, whereas that's not the case with English (cf. "ghoti"). Personally, I never was that bothered by e.g. the type characters, and quite often they were quite helpful about the context expected/required. But then again, I'm German, so maybe growing up with a somewhat ridiculous grammar and Funky Capitalization helped (there's a Perl module that allows you to write code in Latin, and here the cases and other grammatical structures replace the funky characters).

Perl certainly has its weaknesses. Some operations should probably be bound to types/objects instead of C-like functions, references are often difficult to untangle and the default object system ain't that grand (on the other hand: Moose). But I've yet to find a language that doesn't have similar weaknesses. Due to the somewhat funky syntax, they're just quite obvious. What does that dollar sign right there indicate? On what default variable is this code operating? Schwartzian what? But I would call that "traceability" issues. And this certainly also happens with macros, meta-programming, complicated object hierarchies, generators, decorators, DoI containers, etc.

It probably does matter for casual programmers, i.e. people who don't work 20+ hours/week in Perl. Sysadmins come to mind. But if your involvement with the language is beyond that, I think "readability" is quite often a matter of taste, not more. Which, of course, doesn't totally disqualify this argument. It's just more a matter of rap vs. punk, not junk food vs. rucola salad.

Re: Why I Use Perl: Reliability

#37

Post by judofyr »

afc wrote: post #27
jbert wrote: post #11

Earlier quoted context omitted.

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): re…

    use bignum;
    use v5.10;

    =cut
    def Factorial(x):
      output = 1
      for i in xrange(x):
        output *= (i + 1)
      return output
    =cut


    # Direct translation
    sub factorial {
      my $x = shift;
      my $output = 1;
      for my $i (1 .. $x) {
        $output *= $i;
      }
      return $output;
    }

    say factorial(200);

    =cut
    def Factorial2(x):
      return reduce(operator.mul, xrange(1, x + 1), 1)
    =cut

    use List::Util "reduce";

    sub factorial2 {
      my $x = shift;
      reduce { $a * $b } (1 .. $x);
    }

    say factorial(200);

    =cut
    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
    =cut

    sub power {
      my $a = shift;
      my $b = shift // return 1;
      
      if ($b % 2) {
        return power($a, $b - 1) * $a
      }

      my $x = power($a, $b/2);
      return $x * $x;
    }

    # lambda x: x + 7
    my $plus7 = sub { $_[0] + 7 };
    # Or:
    my $plus7 = sub { my $x = shift; $x + 7 };

    say $plus7->(14);

    =cut
    def TweakValue(x):
      return x + 7
    =cut

    sub plus7 { $_[0] + 7 }
    say plus7(14);

Re: Why I Use Perl: Reliability

#38

Post by jbert »

afc wrote: post #27
jbert wrote: post #11

Earlier quoted context omitted.

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): re…

Thanks for that.

First one (not 100% sure it's constant memory, I think perl optimises the for to avoid instantiating the (1..$n) list:

    #!/usr/bin/perl
    use Modern::Perl;
    use bigint;

    say fact(5000);

    sub fact {
        my ($n) = @_;

        my $output = 1;
        for my $i (1..$n) {
            $output *= $i;
        }
        return $output;
    }
(Took the value up to 5000 to get something which ran long enough to get a measurement, on my laptop it runs (including startup time) in ~1.2s. (Can we compare runtime too? I know we're discussing readability, but I'm interested).

The reduce version (again, I'm unsure of const mem req). Comes in at ~1.4s:

    #!/usr/bin/perl
    use Modern::Perl;
    use List::Util qw(reduce);
    use bigint;

    say fact(5000);

    sub fact {
        my ($n) = @_;

        return reduce(sub { $a * $b; }, 1, (1..$n));
    }
The add a constant (true lambda, closing over lexicals in scope, etc etc) is 'sub':

    sub { my ($x) = @_; $x + 7; }
(doesn't have the python lambda limitations). (Be aware that perl GC is refcounted though, so ref cycles are possible).

Edit: I think the languages are comparable in terms of features and also readability. People may dislike leading sigils and that's fair, but I dislike python's "no need to declare your vars, just hope you don't typo an assignment" approach to lexicals.

Re: Why I Use Perl: Reliability

#39

Post by jbert »

jleader wrote: post #14
jbert wrote: post #7

Earlier quoted context omitted.

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

I thought implicit deref of references was coming in 5.16 or 5.18, at least in cases where it was unambiguous?

I saw something for 5.16 and'push', but I've not been keeping up with the featureset since 5.10 properly. That's good to know, thanks.

Re: Why I Use Perl: Reliability

#40

Post by pwaring »

adrianhoward wrote: post #22
pwaring wrote: post #17

Earlier quoted context omitted.

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.

Thanks 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.
Post reply on HN