tl;dr summary:  I'll (++n)th Perl as my primary language.  I know it, I
like it, and, gosh-darnit, it's just fun to use.

On Fri, Mar 26, 2010 at 12:31:12PM -0500, Mike Miller wrote:
> It seems like the conventional wisdom these days is that Perl is hard to 
> manage for larger projects and Python is easier to read and share.  I 
> really don't know, personally, but this is what I've heard several times 
> from seemingly independent sources.

That definitely is the conventional wisdom, but how trustworthy is
conventional wisdom (on this or anything else)?  There are currently a
lot of people trying to change that impression under the banner of
"Modern Perl", although I can't honestly say how effective the attempt
is being.  The main focus of this is on the Enlightened Perl
Organization's "Perl Iron Man Blogging Challenge" at
http://ironman.enlightenedperl.org/


On Fri, Mar 26, 2010 at 04:24:38PM -0500, Robert Nesius wrote:
> Support for object oriented programming was bolted onto perl
> after the language had been around for awhile.  Python was
> designed from step-1 with object orientation in mind.  That's
> why it's implementation is cleaner.
<snip>
> In short, often where Perl is kind of mesy - especially with respect
> to object oriented programming, Python is nice and clean.

If you have particular issues with OO in Perl, how well does Moose
(particularly in conjunction with MooseX::Declare and
MooseX::Has::Sugar) address them?  Personally, plain old blessed-
reference Perl OO doesn't bother me in the least (I like getting my
hands dirty in the guts of my code), but here's one of the classes from
my current online-game side project:

--- cut here ---
package PRangers::Cargo;

use MooseX::Declare;

class PRangers::Cargo
  with KiokuDB::Role::Intrinsic {
use MooseX::Has::Sugar;
use PRangers::Item;

has item => ( isa => 'PRangers::Item', ro, required );

has qty => ( isa => 'Num', rw, required );
around qty (Num $new_value?) {
  return $self->$orig unless defined $new_value;
  $new_value = 0 if $new_value < 0;
  $self->_clear_calculated;
  $self->$orig($new_value);
}
method add_qty    (Num $delta) { $self->qty($self->qty + $delta) }
method remove_qty (Num $delta) { $self->qty($self->qty - $delta) }

has [ qw( mass volume ) ] => ( isa => 'Num', ro, lazy_build );
method _build_mass   { $self->item->mass   * $self->qty }
method _build_volume { $self->item->volume * $self->qty }

method _clear_calculated {
  $self->clear_mass;
  $self->clear_volume;
}

}

1;
--- cut here ---

That doesn't feel overly messy to me.  How about you?

On Fri, Mar 26, 2010 at 04:24:38PM -0500, Robert Nesius wrote:
> Someone remarked it's important to know best practices in Perl to
> write good, maintanable code.

Knowing how to write good, maintainable code is important in any
language.  The more freedom a language gives you, the more important
this becomes.  Is Perl more demanding than most languages in this area?
Absolutely.  But I feel that it's a reasonable price to pay for the
flexibility in expressing my thoughts that Perl provides.

On Fri, Mar 26, 2010 at 04:24:38PM -0500, Robert Nesius wrote:
> You just have to accept indentation (white space) matters.

When I first heard about Python, my initial reaction was "I could never
trust a language with syntactically-significant whitespace."

When I finally tried Python, I have to admit that, aside from a little
initial confusion about the rules regarding it, the whitespace thing
didn't bother me at all.  A ton of other things did, though.  Perhaps it
was just lack of familiarity, but I felt constantly hamstrung by having
to work out how to think like Guido instead of being able to express my
thoughts directly.

I'm not, by any means, trying to say that there's anything wrong with
Python or that Perl is objectively "better", but Perl works the way my
mind works, so I like it.  Python doesn't, so I prefer to avoid it.
That's what works for me; YMMV.

On Fri, Mar 26, 2010 at 04:24:38PM -0500, Robert Nesius wrote:
> I also think Perl 6 was the worst thing to happen to Perl.  Perl 6
> was supposed to "fix perl" and make it better.

Maybe, maybe not.  On the flip side, Perl 6 has inspired a lot of new
things which have gone into Perl 5 and Perl 6 is often credited with
being the cause of the current "Perl Renaissance"/"Modern Perl"/
"Enlightened Perl" push to overcome the language's historical baggage.

I really do wish it had been named something different, though, so that
people wouldn't be assuming that Perl 5 is now an evolutionary dead end.
It isn't, at least not in the short-to-medium term - if anything, it
seems to be under heavier development and releasing more frequently now
than any time in the last several years - but it's natural to expect
that Perl 6 is intended to supercede Perl 5, no matter how many times
the core devs state that they're "two separate languages in the Perl
family, like C and C++", plus it means that, if both lines continue,
we'll eventually end up with Perl 5.420.0 alongside Perl 12.0.0.  Bleah!

-- 
Dave Sherohman