Live data from Hacker News

Why I Use Perl: Reliability

modernperlbooks.com

111–120 of 196 posts

Re: Why I Use Perl: Reliability

#111
post #66

Earlier quoted context omitted.

Does ruby not have the same level of both?

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/

Nice site. Well found.

I find it interesting that PHP doesn't have anything in the same league as Perl/Ruby/Python even after all these years.

Any PHP folk out there?

Re: Why I Use Perl: Reliability

#112

Language 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 di…

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

Re: Why I Use Perl: Reliability

#113
A 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.

Re: Why I Use Perl: Reliability

#114
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 think.

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.

Re: Why I Use Perl: Reliability

#115

For 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, depe…

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

Re: Why I Use Perl: Reliability

#116
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…

Definitely sounds like a bad test. Unless there's a specific reason for the test to have an external dependency like that, the test harness could always bring up the (HTTP) service locally before it runs.

Re: Why I Use Perl: Reliability

#117
post #49

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

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

The problem is in practice @_ is abused like crazy. For example:

1) I've often seen people shift from @_ half way in the middle of a function. If you really want to be certain about a method's formal parameters you have to read the entire function.

2) Also @_ is used in other circumstances which can cause mass confusion. For example Try::Tiny uses @_. It is difficult to guess if you getting a formal parameter or something else entirely (I"m not a fan of magic variables in case you can't tell). If you're Chromatic you might be able to know the probably hundred of uses of @_, but for a normal programmer you're screwed.

3) What if you want to use named parameters? You essentially have make a pointer to a hash, populate it, and unreference it. my $p = {'name' => 'val1', 'name2' => 'val2' }; f($p); sub f { my $name = $_[0]->{'name'}; my $name2 = $_[1]->{'name2'}; }

In other languages like python you can just do something like: def f(name, name2): ...

f(name = 'val', name2 = 'val2')

I've never seen a language handle function parameters as poorly as Perl. I forget almost all the Ruby I once knew but I'm pretty sure it is handled in a reasonable way similar to Python.

Re: Why I Use Perl: Reliability

#118
post #117

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.

The problem is in practice @_ is abused like crazy. For example: 1) I've often seen people shift from @_ half way in the middle of a function. If you really want to be certain about a method's formal parameters you have to read the entire function. 2) Also @_ is used in other circumstances which can cause mass confusion. For example Try::Tiny uses @_. It is difficult to guess if you getting a formal parameter or some…

1) Adopt a convention of extracting your arguments at the beginning of the function.

Also, sometimes you just want to work on an arbitrary list of items. If you process one item and then shift it, that's a reasonable thing to do.

2. If you adopted the convention in 1, this shouldn't bite you. (I've never actually encountered this issue myself...)

3. You are misinformed. You can easily do something along the lines of:

    f({a => 'foo', b => 'bar'});
    
    sub f{ my ($args) = @_; say $args->{a}; }
There's probably a module of CPAN to do this even nicer.

Re: Why I Use Perl: Reliability

#119
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.

The word itself is basically a joke, sure, but it serves as a nice accumulation of letters that have a somewhat unexpected pronunciation, certainly a feature of the English language. Pronunciation and emphasis are pretty hard for non-native speakers, and the written form doesn't help that much. On the other hand of the Latin alphabet spectrum, there are languages like Vietnamese, where you've got a boatload of accents and diacritical marks to help with it.

Although I'm not sure whether describing Perl as the Vietnamese of programming languages would be a good selling point, so I'll stick with French ;)

Re: Why I Use Perl: Reliability

#120

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

I do Perl on a daily basis, and I can't remember when I last blessed a ref. use Moose;

I bless refs occasionally but not often. Maybe sometime I will get out of the habit but yeah Moose rocks in general.
Post reply on HN