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

141–150 of 196 posts

Re: Why I Use Perl: Reliability

#141

Post by michaelpinto »

jerf wrote: post #127
michaelpinto wrote: post #125

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

Unless 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 sn…

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

Re: Why I Use Perl: Reliability

#142

Post by chromatic »

pyre wrote: post #102
jbert wrote: post #48

Earlier quoted context omitted.

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.

You can partially unpack in Python too: def method(self, *args): a, b = args[:2] super(self).method(*args[:2]) Perl's lack of using the definition for the variables doesn't necessarily make it 'more powerful.'

Python's approach is very reasonable. Both Perl and Python are nicer than C varargs.

Re: Why I Use Perl: Reliability

#143

Post by cytzol »

Goladus wrote: post #114
staunch wrote: post #9

Any language would be improved if it had Perl's testing and library culture. Two things it's absolute unsurpassed at so far.

I once had a large CPAN dependency install fail because one of the modules' tests included an http request to a 3rd party website which happened to be down that day. I wanted to strangle that developer when I finally tracked down the error (it wasn't failing with an obvious error that would let me easily recognize what was happening, I had to read the code itself). That is going a bit too far with the testing, I thin…

IIRC, the correct protocol with network testing is to prompt the user first that it's going to connect to another host, so they can skip the tests if there's something wrong with their network (or the site on the other end).

The other way to do it is to start an HTTP server locally and use that (which is what WWW::Mechanize does)

Re: Why I Use Perl: Reliability

#144

Post by salvadors »

sbmassey wrote: post #99
mhd wrote: post #35

Earlier quoted context omitted.

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

The 'ghoti can be pronounced as fish' thing is a bit unfair to English orthography, where you must take the surroundings of the letter cluster into account.

You also have to take the rest of the sentence into account too. English has a lot of words which mean different things depending on how they're pronounced (or, from the other side, that you can't know which way to pronounce until you already know the meaning), e.g. bass, close, desert, does, dove, familiar, have, intimate, invalid, lead, lives, number, object, present, produce, read, refuse, sewer, sow, subject, tear, wind, wound.

Re: Why I Use Perl: Reliability

#145

Post by zalew »

pjscott wrote: post #135
JonnieCache wrote: post #108

Earlier quoted context omitted.

wrt testing, ruby is getting there with http://travis-ci.org Also the rspec ecosystem is becoming more and more mix-and-match. It's nowhere near as integrated as perl yet though.

Travis-CI also works for a bunch of other languages, so if you're a library maintainer, it's definitely worth checking out: http://about.travis-ci.org/docs/user/getting-started/

It will be amazing when it supports any repo path. Now it's just a github utility.

Re: Why I Use Perl: Reliability

#146

Post by hkolek »

kamaal wrote: post #131
jshen wrote: post #128

Earlier quoted context omitted.

"Lots of folk using it because it's the new-and-shiny rather than it being necessarily the best solution" How do you know what is in people's head? I assert that lots of folk are using perl because it's comfortable to them rather than it being the best solution.

The difference between computer science and software engineering is Software engineering is real work for the real world. Often the constraints are money, time, resources. So demands of a software project in the real world are very different than the academia. Although you can argue that Lisp is far more a better language than Perl, based on some parameters you wish to evaluate. Others might have totally different pa…

You said it yourself, comfort is a subjective term. So why do you talk as if Lisp were objectively more complicated. If I'm familiar with Lisp but have no clue about Perl I don't need to be a university professor with endless time to choose Lisp over Perl every time. To me, Perl looks vastly more complicated than Lisp. I believe you'd find that if you'd know Lisp like you do Perl you'd be at least as productive as you're in Perl.

Re: Why I Use Perl: Reliability

#147

Post by draegtun »

pyre wrote: post #100
jrockway wrote: post #60

Earlier quoted context omitted.

Is "my ($self, $a, $b) = @_" really that hard to read? It's slightly more characters but I've never found it particularly annoying.

What'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 }

Yes examples 1 & 3 are much better. At some point signatures will be added to core Perl (class/method nearly made it into 5.16 as part of p5-mop proposal. Fingers crossed it will be in 5.18 next year).

When not using perl5i or playing with MooseX::Declare I will usually default to Params::Validate so your example would look like this:

  sub function1 {
    my ($code, $arr) = validate_pos( @_, {type => CODEREF}, {type => ARRAYREF} );
    ...
  }

Re: Why I Use Perl: Reliability

#148

Post by adrianhoward »

jonathansizz wrote: post #137
zentrus wrote: post #104

Earlier quoted context omitted.

Check this site out for a comparison of the various module counts per language. It is really incredible that rubygems surpassed CPAN last year and continues to grow at a very rapid rate. Quality may be another matter, but still, impressive. http://www.modulecounts.com/

Except that there's over 107,000 Perl modules on CPAN, and fewer than 40,000 Ruby gems.

That's not comparing like with like. Gems are the equivalent of CPAN distributions.

Re: Why I Use Perl: Reliability

#149

Post by adrianhoward »

Goladus wrote: post #114
staunch wrote: post #9

Any language would be improved if it had Perl's testing and library culture. Two things it's absolute unsurpassed at so far.

I once had a large CPAN dependency install fail because one of the modules' tests included an http request to a 3rd party website which happened to be down that day. I wanted to strangle that developer when I finally tracked down the error (it wasn't failing with an obvious error that would let me easily recognize what was happening, I had to read the code itself). That is going a bit too far with the testing, I thin…

That is going a bit too far with the testing, I think

Agreed :-)

And though I admit the culture is great overall, that does seem to be my experience with CPAN. You never know what you're going to get. It's like that to some degree with every language but with CPAN there's so much trust in the system it can be harder to identify and filter out the lesser quality stuff.

There are lots of nice tools that help with that though. https://metacpan.org/, http://cpantesters.org/, http://cpanratings.perl.org/, etc.

Re: Why I Use Perl: Reliability

#150

Post by vog »

bgilroy26 wrote: post #98
adrianhoward wrote: post #91

Earlier quoted context omitted.

You're quite correct. My apologies. I misunderstood the 39411 number to be the total number of gems submitted over all time, rather than the total number of extant versions. My bad.

Don't worry, it happens all the time [1]. http://news.ycombinator.com/item?id=3238544

Ironically, this is the same issue of sloppy testing, just at another level (i.e. missing usability tests on the http://rubygems.org/gems website for at least months, maybe years)
Post reply on HN