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

41–50 of 196 posts

Re: Why I Use Perl: Reliability

#41

Post by fennecfoxen »

latj wrote: post #33
fennecfoxen wrote: post #28

Earlier quoted context omitted.

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

The problem revolves around being able communicate what's going on. If you try to be helpful and informative and say something like "Object-oriented software engineer (Perl)" as your job post title, you immediately (a) get every schmuck who once did testing with Perl who is now searching for 'perl' to apply, even if they don't know any OO, thus jamming the interview process, (b) immediately get most anyone else to say "ewwwwww, Perl, I'd never be interested / I have no experience". You have to end up saying "Object-oriented software engineer in a dynamic programming language", request people in with experience in (e.g.) languages such as Ruby, Python or Perl, and only mention that it's actually in Perl further down the post once you've got their attention with the rest of it. This is a trifle more manipulative and less straightforward than a decent straightforward honest software engineer would instinctually prefer. Anyway. It's true, a couple of of the best candidates actually hired there came from Python backgrounds.

By contrast, I assume you can say something like "Object-oriented software engineer (Python)" or "Object-oriented software engineer (Ruby)" (or Frontend Engineer / Backend Engineer / etc) and not have this particular set of problems. I don't know what problems you would have, but... not those.

Now, to be fair, it worked marginally better when the company-recruiters weren't all jerks about letting us post a programming challenge with the posting (because it didn't fit in with a preexisting workflow)... which makes it easier to find the random Spanish major with decent programming instincts and a little Perl. But still.

Re: Why I Use Perl: Reliability

#42

Post by gouranga »

adrianhoward wrote: post #26
gouranga wrote: post #25

Earlier quoted context omitted.

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

We killed that as well!

Re: Why I Use Perl: Reliability

#43

Post by ralphgoodtimes »

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…

I'm interested. I love Perl, and would love to work for a company that requires me to program in Perl. Care to share which companies are these?

Thanks.

Re: Why I Use Perl: Reliability

#44

Post by zem »

jbert wrote: post #38
afc wrote: post #27

Earlier quoted context omitted.

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

that also highlights one of my perl peeves - having to scrape function args out of @_ rather than declaring them as part of the function definition.

Re: Why I Use Perl: Reliability

#45

Post by jwr »

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

Re: Why I Use Perl: Reliability

#46

Post by adrianhoward »

gouranga wrote: post #42
adrianhoward wrote: post #26

Earlier quoted context omitted.

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

We killed that as well!

Considering 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 ;-)

Re: Why I Use Perl: Reliability

#47

Post by irahul »

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…

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

Umm, did you mean:

    def factorial(x):
        output = 1
        for i in xrange(2, x):
            output *= i
        return output
Here are the perl versions. Such trivial examples are going to look the same in languages which share the same paradigms.

    use List::Util qw(reduce);

    # This is how I would write it.
    sub fact1 {
        my $num = shift;
        my $output = 1;
        $output *= $_ for (2 .. $num);
        return $output;
    }

    # Most people don't prefer inline loops and $_ variable, though
    # I don't see why not.
    sub fact2 {
        my $num = shift;
        my $output = 1;
        for my $i (2 .. $num) {
            $output *= $i;
        }
        return $output;
    }

    sub fact3 {
        my $num = shift;
        return reduce { $a * $b } 2..$num
    }

Re: Why I Use Perl: Reliability

#48

Post by jbert »

zem wrote: post #44
jbert wrote: post #38

Earlier quoted context omitted.

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

that also highlights one of my perl peeves - having to scrape function args out of @_ rather than declaring them as part of the function definition.

Yes, that sucks. It's not much extra typing:

def function(x, y, z):

versus

sub function { my ($x, $y, $x) = @_; }

The overhead is only really the 'my = @_;' chars, but it is annoying. On the other hand, it does allow you to do things like partially unpack args and pass the rest as a bundle to a super class.

Re: Why I Use Perl: Reliability

#49

Post by grout »

The 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);
   }

Re: Why I Use Perl: Reliability

#50

Post by irahul »

jbert wrote: post #38
afc wrote: post #27

Earlier quoted context omitted.

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

I don't program in perl now a days. But when I did, I generally used perl's shortcuts a lot.

For example:

    return reduce(sub { $a * $b; }, 1, (1..$n));
would be:

    reduce { $a * $b } 1..$n;
This

    my $output = 1;
        for my $i (1..$n) {
            $output *= $i;
    }
would be:

    $output *= $_ for (1..$n)
So, I have a question for you(assuming you write perl for a living). Is this your preferred style, or you do this to appease readability police which demands programming languages be readable by non programmers? Because really, what kind of programmer programs in perl and is averse to $_?
Post reply on HN