From russt at releasetools.org  Mon Apr  2 11:40:32 2012
From: russt at releasetools.org (Russ Tremain)
Date: Mon, 2 Apr 2012 11:40:32 -0700
Subject: [sf-perl] the other magic e
Message-ID: <p0624080ccb9cfe48e19b@[10.1.7.162]>

Hi Joseph,

I really enjoyed your talks on the obscure corners of emacs and perl. 
I almost hate to confess my vimness.

As we discussed at the meet-up, I use the perl e modifier in my 
wiki-converter hack ... here is a simple example of how it looks in 
cado:

----------------------------------------------------------------
cado -q
data := << (
1 fred
2 sam
3 sally
)

CG_SUBSTITUTE_SPEC := s/^(\d+)\s+/append_op("$1+", "FOO")/emg
output = $data:substitute

%echo output=$output
%echo FOO=$FOO
^D
output=1+fred
2+sam
3+sally

FOO=1+2+3+
----------------------------------------------------------------

Two things to note:  1) the contents of $output has the result of 
each call to append_op(), which returns the value of the append.  2) 
the creation of a new cado variable $FOO, with the integer from each 
line of data isolated.

Also note that := in cado is the literal assignment operator, which 
avoids interpolation of the right hand side of the assignment (use 
plain = for that).  Stole that from gnu make.

Granted, you have to know how to call a cado op  (in this case 
:append), but given that, you have full access to all the cado 
functions from within a perl substitution, granted by the magic e.

I believe this will also work with perl grep(), implemented in cado 
as ":g".  Gee, I should try that.  :)

Yet another fun way to play with perl RE's.

cheers,
-Russ

P.S.  I pushed out the latest version (1.97) of the interpreter this weekend:
http://sourceforge.net/projects/cado/files/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/sanfrancisco-pm/attachments/20120402/bc244eea/attachment.html>

From walkin7 at yahoo.com  Tue Apr  3 18:46:17 2012
From: walkin7 at yahoo.com (Matt)
Date: Tue, 3 Apr 2012 18:46:17 -0700 (PDT)
Subject: [sf-perl] new to the group - how do I get involved?
Message-ID: <1333503977.48205.YahooMailClassic@web112405.mail.gq1.yahoo.com>

Greetings all,
?
I am trying to get more involved in the group.? I get the emails, but could someone send me a link to the forum?? my email is walkin7 at yahoo.com.
?
I am getting the emails, but I want to post technical questions.? is this an appropriate place?? Also, I'd like to join social perl events if you guys ever meet up??
?
Thanks,
?
Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/sanfrancisco-pm/attachments/20120403/914e6f8a/attachment.html>

From not.com at gmail.com  Wed Apr  4 16:53:21 2012
From: not.com at gmail.com (yary)
Date: Wed, 4 Apr 2012 19:53:21 -0400
Subject: [sf-perl] new to the group - how do I get involved?
In-Reply-To: <1333503977.48205.YahooMailClassic@web112405.mail.gq1.yahoo.com>
References: <1333503977.48205.YahooMailClassic@web112405.mail.gq1.yahoo.com>
Message-ID: <CAG2CFAYu=xobHjR4ARC_U-8VxnyJdW40NOnq7-nXDKztzr_E+Q@mail.gmail.com>

Hi,

this list is the place for perl and meeting discussions- and it does
tend to get a few more technical questions in the balance of things.

There are monthly meetings, more or less, you'll see the announcements here!

-y

From doom at kzsu.stanford.edu  Wed Apr  4 17:16:21 2012
From: doom at kzsu.stanford.edu (Joseph Brenner)
Date: Wed, 4 Apr 2012 17:16:21 -0700
Subject: [sf-perl] new to the group - how do I get involved?
In-Reply-To: <1333503977.48205.YahooMailClassic@web112405.mail.gq1.yahoo.com>
References: <1333503977.48205.YahooMailClassic@web112405.mail.gq1.yahoo.com>
Message-ID: <CAFfgvXX4=SsEV0w0efahXUYP8m_KGawfWKipYGE-jeYjT3sOMA@mail.gmail.com>

Matt <walkin7 at yahoo.com> wrote:


>
> I am trying to get more involved in the group.  I get the emails, but
> could someone send me a link to the forum?
>
>

Well, like Yary says, this pretty much is the forum.   We tend to some of
the organizational stuff on meetup, so if you want to look at the list of
recent mettings, those are up here:

http://www.meetup.com/San-Francisco-Perl-Mongers/


> I am getting the emails, but I want to post technical questions.  is this
> an appropriate place?
>

Sure is.


> Also, I'd like to join social perl events if you guys ever meet up??
>
>
>
Yup.  You can get word of that either on the list or on meetup, though
every now and then we'll do a smaller/off-topic gathering that you'd only
here about here.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/sanfrancisco-pm/attachments/20120404/4923877c/attachment.html>

From doom at kzsu.stanford.edu  Wed Apr  4 17:38:53 2012
From: doom at kzsu.stanford.edu (Joseph Brenner)
Date: Wed, 4 Apr 2012 17:38:53 -0700
Subject: [sf-perl] the mouse with antlers
Message-ID: <CAFfgvXU=4ci9W3fEMtEvkVFJzMsmNwjC_JB_YAGwX91661a1Hw@mail.gmail.com>

I've been messing about with Mouse.pm of late (a lightweight Moose
substitute whose star may already be fading), and I've got a basic
question/complaint.

I'm used to doing href based objects with an init routine that's
called by new, where I can do any initialization I might need to do.
In Moose land I find myself doing things like this:

use Moose
has name        =>
     (is => 'rw',  isa => 'Str', required => 1);
has subject     =>
     (is => 'rw',  isa => 'Str', default => sub{ 'Report about .
$_[0]->name }, lazy => 1);
has id              =>
     (is => 'rw',  isa => 'Str', default => sub{  lookup( $_[0]->name
) },          lazy => 1);

Where the "lazy" setting delays the use of the initialization code to
the time when the field is first accessed, and that way I can be
certain that the name field has settled down.

I find myself worrying about what I would do if I needed more than two
stages, instantiation and lazy access.  Like what if I wanted to put
the id in the subject?
I'd have to do a gratuitous access of id to make sure it was defined
before accessing subject...

From moseley at hank.org  Wed Apr  4 18:01:23 2012
From: moseley at hank.org (Bill Moseley)
Date: Thu, 5 Apr 2012 09:01:23 +0800
Subject: [sf-perl] the mouse with antlers
In-Reply-To: <CAFfgvXU=4ci9W3fEMtEvkVFJzMsmNwjC_JB_YAGwX91661a1Hw@mail.gmail.com>
References: <CAFfgvXU=4ci9W3fEMtEvkVFJzMsmNwjC_JB_YAGwX91661a1Hw@mail.gmail.com>
Message-ID: <CAKhN_m6NQ+YiaWMYTc4TeaxC0D1je9nzEaxVtedkprozP8zG-A@mail.gmail.com>

On Thu, Apr 5, 2012 at 8:38 AM, Joseph Brenner <doom at kzsu.stanford.edu>wrote:

> I've been messing about with Mouse.pm of late (a lightweight Moose
> substitute whose star may already be fading), and I've got a basic
> question/complaint.
>
> I'm used to doing href based objects with an init routine that's
> called by new, where I can do any initialization I might need to do.
> In Moose land I find myself doing things like this:
>

There's BUILD (and BUILDARGS) if you want to hook into construction.

http://search.cpan.org/~doy/Moose-2.0403/lib/Moose/Manual/Construction.pod


>
> use Moose
> has name        =>
>     (is => 'rw',  isa => 'Str', required => 1);
> has subject     =>
>     (is => 'rw',  isa => 'Str', default => sub{ 'Report about .
> $_[0]->name }, lazy => 1);
> has id              =>
>     (is => 'rw',  isa => 'Str', default => sub{  lookup( $_[0]->name
> ) },          lazy => 1);
>
> Where the "lazy" setting delays the use of the initialization code to
> the time when the field is first accessed, and that way I can be
> certain that the name field has settled down.
>

I'm wondering if you don't really want to be using a builder instead of a
default.   I tend to make heavy use of builders (mostly using lazy_build =>
1) as that makes the code, well, build itself.



> I find myself worrying about what I would do if I needed more than two
> stages, instantiation and lazy access.  Like what if I wanted to put
> the id in the subject?
>

has id => ( lazy_build => 1, ... );
sub _build_id { return shift->name }

has subject => ( lazy_build => 1, ... )l
sub _build_subject { return 'Report about '  . shift->id }


-- 
Bill Moseley
moseley at hank.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/sanfrancisco-pm/attachments/20120405/90d52978/attachment-0001.html>

From hartzell at alerce.com  Wed Apr  4 18:11:21 2012
From: hartzell at alerce.com (George Hartzell)
Date: Wed, 4 Apr 2012 18:11:21 -0700
Subject: [sf-perl] the mouse with antlers
In-Reply-To: <CAFfgvXU=4ci9W3fEMtEvkVFJzMsmNwjC_JB_YAGwX91661a1Hw@mail.gmail.com>
References: <CAFfgvXU=4ci9W3fEMtEvkVFJzMsmNwjC_JB_YAGwX91661a1Hw@mail.gmail.com>
Message-ID: <20348.61753.358506.601416@gargle.gargle.HOWL>

Joseph Brenner writes:
 > I've been messing about with Mouse.pm of late (a lightweight Moose
 > substitute whose star may already be fading), and I've got a basic
 > question/complaint.
 > 
 > I'm used to doing href based objects with an init routine that's
 > called by new, where I can do any initialization I might need to do.
 > In Moose land I find myself doing things like this:
 > 
 > use Moose
 > has name        =>
 >      (is => 'rw',  isa => 'Str', required => 1);
 > has subject     =>
 >      (is => 'rw',  isa => 'Str', default => sub{ 'Report about .
 > $_[0]->name }, lazy => 1);
 > has id              =>
 >      (is => 'rw',  isa => 'Str', default => sub{  lookup( $_[0]->name
 > ) },          lazy => 1);
 > 
 > Where the "lazy" setting delays the use of the initialization code to
 > the time when the field is first accessed, and that way I can be
 > certain that the name field has settled down.
 > 
 > I find myself worrying about what I would do if I needed more than two
 > stages, instantiation and lazy access.  Like what if I wanted to put
 > the id in the subject?
 > I'd have to do a gratuitous access of id to make sure it was defined
 > before accessing subject...

I'm not quite sure what you mean by "the name field has settled down".
It's required, so it has to be set when you create the object.  If
you're worried about it getting set and then changed a couple of times
before you ask for the subject then what you have works.  But what
happens when you change the name field *after* the first time
someone's access subject?

You could use a trigger to catch any changes to name and update
subject.  The trigger could set it if it hasn't already been
explicitly set, etc....

  http://search.cpan.org/~doy/Moose-2.0403/lib/Moose/Manual/Attributes.pod#Triggers

I think that what you have should work fine for putting the id in the
subject.  Am I missing something?

Complex object initialization goes nicely in a BUILD routine, which
might be the answer to your unquiet.  It's kind of like the init
routine that you used to have.  There's also BUILDARGS, which is
useful from building a valid set of arguments from what someone passes
in to the constructor (let's one do things like accept a single value
and construct the hash containing it's key, Person->new("123-45-6789")
is functionally Person->new({ssn => "123-45-6789"}) ).

  http://search.cpan.org/~doy/Moose-2.0403/lib/Moose/Manual/Construction.pod#BUILD
  http://search.cpan.org/~doy/Moose-2.0403/lib/Moose/Manual/Construction.pod#BUILDARGS

g.

From hartzell at alerce.com  Wed Apr  4 18:21:10 2012
From: hartzell at alerce.com (George Hartzell)
Date: Wed, 4 Apr 2012 18:21:10 -0700
Subject: [sf-perl] the mouse with antlers
In-Reply-To: <20348.61753.358506.601416@gargle.gargle.HOWL>
References: <CAFfgvXU=4ci9W3fEMtEvkVFJzMsmNwjC_JB_YAGwX91661a1Hw@mail.gmail.com>
	<20348.61753.358506.601416@gargle.gargle.HOWL>
Message-ID: <20348.62342.342911.426700@gargle.gargle.HOWL>


ps.  Have all y'all worked through Dave Rolsky's Moose intro?  It's
pretty useful stuff.

He presents it as a class, but the slides are pretty reasonable on
their own.

It also comes with a set of problems, set up as TAP tests that you
have to make pass.  Slick.

Creative Commons license.

  http://git.shadowcat.co.uk/gitweb/gitweb.cgi?p=gitmo/moose-presentations.git;a=summary

g.


From moseley at hank.org  Wed Apr  4 18:21:02 2012
From: moseley at hank.org (Bill Moseley)
Date: Thu, 5 Apr 2012 09:21:02 +0800
Subject: [sf-perl] the mouse with antlers
In-Reply-To: <CAKhN_m6NQ+YiaWMYTc4TeaxC0D1je9nzEaxVtedkprozP8zG-A@mail.gmail.com>
References: <CAFfgvXU=4ci9W3fEMtEvkVFJzMsmNwjC_JB_YAGwX91661a1Hw@mail.gmail.com>
	<CAKhN_m6NQ+YiaWMYTc4TeaxC0D1je9nzEaxVtedkprozP8zG-A@mail.gmail.com>
Message-ID: <CAKhN_m6ivkMp+jHqLv5E-Nziuyx2=fXv0jYi7s+1JBsJ40=7vg@mail.gmail.com>

On Thu, Apr 5, 2012 at 9:01 AM, Bill Moseley <moseley at hank.org> wrote:

>
>
>> I find myself worrying about what I would do if I needed more than two
>> stages, instantiation and lazy access.  Like what if I wanted to put
>> the id in the subject?
>>
>
Oops, speaking of lazy...


>
> has id => ( lazy_build => 1, ... );
>


sub _build_id { return shift->id_by_name }

where that method looks up the name, for example, in %name_to_id_map.

Might make the name attribute have a type limited to values in
%name_to_id_map;



-- 
Bill Moseley
moseley at hank.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/sanfrancisco-pm/attachments/20120405/6d945dec/attachment.html>

From cweyl at alumni.drew.edu  Wed Apr  4 19:31:16 2012
From: cweyl at alumni.drew.edu (Chris Weyl)
Date: Wed, 4 Apr 2012 19:31:16 -0700
Subject: [sf-perl] the mouse with antlers
In-Reply-To: <CAFfgvXU=4ci9W3fEMtEvkVFJzMsmNwjC_JB_YAGwX91661a1Hw@mail.gmail.com>
References: <CAFfgvXU=4ci9W3fEMtEvkVFJzMsmNwjC_JB_YAGwX91661a1Hw@mail.gmail.com>
Message-ID: <20120404193116.564d773c@mercury>

On Wed, 4 Apr 2012 17:38:53 -0700
Joseph Brenner <doom at kzsu.stanford.edu> wrote:

> I find myself worrying about what I would do if I needed more than two
> stages, instantiation and lazy access.  Like what if I wanted to put
> the id in the subject?
> I'd have to do a gratuitous access of id to make sure it was defined
> before accessing subject...

Soo...  Forgive me if I'm not reading this correctly, but it sounds like you're concerned that when subject is lazily built, you won't be able to get id's value as it won't have been built yet?

Ignore the rest if I've misread this :)

Lazily built attributes are built the first time they're read, if they haven't been explicitly set in the constructor call.  Basically, attributes are set:

* via explicit value in new()
* at new() if a default/builder is provided and the attribute is not lazy
* at any access if a default/builder has been provided, the attribute is not set, and the attribute is lazy

So long as there are no circular references between your attribute defaults/builders (exciting!), you can have them access any other lazily built attribute without worrying if it has been built already or not.  In your musing above, subject's default/builder can rely on id being set when it accesses id, as id will be built on that access if it has not already been built.

If, for whatever reason, you need to determine if an attribute has already been built, you can use a predicate; the predicate will tell you if the attribute contains a value (even if that value is undef) or if it has been set somehow.

                         -Chris

From jeff at imaginative-software.com  Wed Apr  4 20:45:21 2012
From: jeff at imaginative-software.com (Jeffrey Thalhammer)
Date: Wed, 4 Apr 2012 20:45:21 -0700
Subject: [sf-perl] the mouse with antlers
In-Reply-To: <CAKhN_m6NQ+YiaWMYTc4TeaxC0D1je9nzEaxVtedkprozP8zG-A@mail.gmail.com>
References: <CAFfgvXU=4ci9W3fEMtEvkVFJzMsmNwjC_JB_YAGwX91661a1Hw@mail.gmail.com>
	<CAKhN_m6NQ+YiaWMYTc4TeaxC0D1je9nzEaxVtedkprozP8zG-A@mail.gmail.com>
Message-ID: <DC2E9C57-CC99-4962-B35A-25B4567F28F1@imaginative-software.com>


On Apr 4, 2012, at 6:01 PM, Bill Moseley wrote:

> has id => ( lazy_build => 1, ... );
> sub _build_id { return shift->name }


Side note:  I've been hanging out on the #moose channel lately.  Apparently, lazy_build is out of fashion, because it also generates a predicate and clearer method for you, which you probably didn't want.  So now the recommended practice is... 

has id => ( lazy => 1,  builder => '_build_id' );

I think lazy_build will be removed from the documentation in the next release of Moose.

-Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/sanfrancisco-pm/attachments/20120404/435849d2/attachment-0001.html>

From cweyl at alumni.drew.edu  Wed Apr  4 21:17:55 2012
From: cweyl at alumni.drew.edu (Chris Weyl)
Date: Wed, 4 Apr 2012 21:17:55 -0700
Subject: [sf-perl] the mouse with antlers
In-Reply-To: <DC2E9C57-CC99-4962-B35A-25B4567F28F1@imaginative-software.com>
References: <CAFfgvXU=4ci9W3fEMtEvkVFJzMsmNwjC_JB_YAGwX91661a1Hw@mail.gmail.com>
	<CAKhN_m6NQ+YiaWMYTc4TeaxC0D1je9nzEaxVtedkprozP8zG-A@mail.gmail.com>
	<DC2E9C57-CC99-4962-B35A-25B4567F28F1@imaginative-software.com>
Message-ID: <CABSyATGxGM8cgQ+YAVKSzruBNGb6mx1zwtWXfqpTPnBfo9xyyw@mail.gmail.com>

On Wed, Apr 4, 2012 at 8:45 PM, Jeffrey Thalhammer
<jeff at imaginative-software.com> wrote:
> Side note: ?I've been hanging out on the #moose channel lately. ?Apparently,
> lazy_build is out of fashion, because it also generates a predicate and
> clearer method for you, which you probably didn't want. ?So now the
> recommended practice is...
>
> has id => ( lazy => 1, ?builder => '_build_id' );

*shameless plug* Or, with MooseX::AttributeShortcuts:

has id => (is => 'lazy');
 - or -
has id => (is => 'ro', lazy => 1, builder => 1);

                          -Chris

-- 
Chris Weyl
Ex astris scientia

From moseley at hank.org  Thu Apr  5 03:37:15 2012
From: moseley at hank.org (Bill Moseley)
Date: Thu, 5 Apr 2012 18:37:15 +0800
Subject: [sf-perl] the mouse with antlers
In-Reply-To: <DC2E9C57-CC99-4962-B35A-25B4567F28F1@imaginative-software.com>
References: <CAFfgvXU=4ci9W3fEMtEvkVFJzMsmNwjC_JB_YAGwX91661a1Hw@mail.gmail.com>
	<CAKhN_m6NQ+YiaWMYTc4TeaxC0D1je9nzEaxVtedkprozP8zG-A@mail.gmail.com>
	<DC2E9C57-CC99-4962-B35A-25B4567F28F1@imaginative-software.com>
Message-ID: <CAKhN_m7842i+ZNQvmfi+ftWonA4XaqZkUdpqT2+aYrio72Cgbg@mail.gmail.com>

On Thu, Apr 5, 2012 at 11:45 AM, Jeffrey Thalhammer <
jeff at imaginative-software.com> wrote:

>
> Side note:  I've been hanging out on the #moose channel lately.
>  Apparently, lazy_build is out of fashion, because it also generates a
> predicate and clearer method for you, which you probably didn't want.  So
> now the recommended practice is...
>
> has id => ( lazy => 1,  builder => '_build_id' );
>
> I think lazy_build will be removed from the documentation in the next
> release of Moose.
>

Seems to still be there in the lates trial release from a day or so ago,
but there is now a note in the Best Practices docs.

The reasoning is because it automatically creates (possibly undocumented)
methods that someone might use in your public API that might not be part of
the test suite?

I used to specify "builder" but got caught leaving out the lazy => 1 a few
times, and quite a few times typed the builder method name incorrectly. And
I also missed the predicate that I use, if only infrequently.  And there's
a lot to be said for laziness.

Time to start using MooseX::AttributeShortcuts, indeed.


-- 
Bill Moseley
moseley at hank.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/sanfrancisco-pm/attachments/20120405/5ee24346/attachment.html>

From fred at redhotpenguin.com  Fri Apr  6 18:04:47 2012
From: fred at redhotpenguin.com (Fred Moyer)
Date: Fri, 6 Apr 2012 18:04:47 -0700
Subject: [sf-perl] YAPC::NA perl testing workshop sold out
Message-ID: <CAHrynWATTA1aCZkr8xLLmfOACJfWdgBEo=54bNpGaTE+bADKuQ@mail.gmail.com>

YAPC::2012 is looking pretty solid. Paul, any chance of a charter YAPC
flight booking?

http://blogs.perl.org/users/jt_smith/2012/04/perl-testing-workshop-sold-out.html

From el.dodgero at gmail.com  Mon Apr  9 03:19:12 2012
From: el.dodgero at gmail.com (Dodger)
Date: Mon, 9 Apr 2012 03:19:12 -0700
Subject: [sf-perl] Real perl
Message-ID: <8B1E4BD3-6B57-48D3-9BAB-DFF294C9AD37@gmail.com>

So... How about some old school perl without mooses and meeses?

Anybody out there code in... You know... Perl?

-- 
Dodger

Sent from my iPhone

From sfpug at dave.sharnoff.org  Mon Apr  9 08:44:55 2012
From: sfpug at dave.sharnoff.org (David Muir Sharnoff)
Date: Mon, 9 Apr 2012 08:44:55 -0700
Subject: [sf-perl] Real perl
In-Reply-To: <8B1E4BD3-6B57-48D3-9BAB-DFF294C9AD37@gmail.com>
References: <8B1E4BD3-6B57-48D3-9BAB-DFF294C9AD37@gmail.com>
Message-ID: <CAOH-iGwvGmYgR5jPMZizKRH17L+61x-6e9-2WpBFkbN2H5Uu1Q@mail.gmail.com>

Absolutely.   Call me a luddite, but I haven't drunk the koolaid.

-Dave

On Mon, Apr 9, 2012 at 3:19 AM, Dodger <el.dodgero at gmail.com> wrote:

> So... How about some old school perl without mooses and meeses?
>
> Anybody out there code in... You know... Perl?
>
> --
> Dodger
>
> Sent from my iPhone
> _______________________________________________
> SanFrancisco-pm mailing list
> SanFrancisco-pm at pm.org
> http://mail.pm.org/mailman/listinfo/sanfrancisco-pm
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/sanfrancisco-pm/attachments/20120409/614348c7/attachment.html>

From diederich at gmail.com  Mon Apr  9 09:02:39 2012
From: diederich at gmail.com (Dana Diederich)
Date: Mon, 9 Apr 2012 09:02:39 -0700
Subject: [sf-perl] Real perl
In-Reply-To: <CAOH-iGwvGmYgR5jPMZizKRH17L+61x-6e9-2WpBFkbN2H5Uu1Q@mail.gmail.com>
References: <8B1E4BD3-6B57-48D3-9BAB-DFF294C9AD37@gmail.com>
	<CAOH-iGwvGmYgR5jPMZizKRH17L+61x-6e9-2WpBFkbN2H5Uu1Q@mail.gmail.com>
Message-ID: <CAD--fz41kGhUf8XUAN+8wiaaHZ3=oCBqcHhc-ZCdR4=EQDgY9g@mail.gmail.com>

I spend lots of time programming in 'both': 'Modern Perl' with Moose and
many friends, as well as 'vanilla Perl', without that stuff.

Best tools for the job, right?

Cheers,
-Dana

2012/4/9 David Muir Sharnoff <sfpug at dave.sharnoff.org>

> Absolutely.   Call me a luddite, but I haven't drunk the koolaid.
>
> -Dave
>
>
> On Mon, Apr 9, 2012 at 3:19 AM, Dodger <el.dodgero at gmail.com> wrote:
>
>> So... How about some old school perl without mooses and meeses?
>>
>> Anybody out there code in... You know... Perl?
>>
>> --
>> Dodger
>>
>> Sent from my iPhone
>> _______________________________________________
>> SanFrancisco-pm mailing list
>> SanFrancisco-pm at pm.org
>> http://mail.pm.org/mailman/listinfo/sanfrancisco-pm
>>
>>
>
> _______________________________________________
> SanFrancisco-pm mailing list
> SanFrancisco-pm at pm.org
> http://mail.pm.org/mailman/listinfo/sanfrancisco-pm
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/sanfrancisco-pm/attachments/20120409/297cd3ec/attachment.html>

From el.dodgero at gmail.com  Mon Apr  9 09:09:28 2012
From: el.dodgero at gmail.com (Dodger)
Date: Mon, 9 Apr 2012 09:09:28 -0700
Subject: [sf-perl] Real perl
In-Reply-To: <CAOH-iGwvGmYgR5jPMZizKRH17L+61x-6e9-2WpBFkbN2H5Uu1Q@mail.gmail.com>
References: <8B1E4BD3-6B57-48D3-9BAB-DFF294C9AD37@gmail.com>
	<CAOH-iGwvGmYgR5jPMZizKRH17L+61x-6e9-2WpBFkbN2H5Uu1Q@mail.gmail.com>
Message-ID: <B45BE03E-5CA3-4080-A177-33E91091E329@gmail.com>

Me too. I actually do like crafting modules by hand, etc. 

Right now, aside from work stuff, I have been working on a Perl port of the PHP SDK for Facebook. I'm basically mostly done but up to the point where I'm realising that to make it work I need to build another module that reads and writes PHP Session files. Fun fun! (I actually do enjoy this!)

-- 
Dodger

Sent from my iPhone

On 09/04/2012, at 8:44 AM, David Muir Sharnoff <sfpug at dave.sharnoff.org> wrote:

> Absolutely.   Call me a luddite, but I haven't drunk the koolaid.
> 
> -Dave
> 
> On Mon, Apr 9, 2012 at 3:19 AM, Dodger <el.dodgero at gmail.com> wrote:
> So... How about some old school perl without mooses and meeses?
> 
> Anybody out there code in... You know... Perl?
> 
> --
> Dodger
> 
> Sent from my iPhone
> _______________________________________________
> SanFrancisco-pm mailing list
> SanFrancisco-pm at pm.org
> http://mail.pm.org/mailman/listinfo/sanfrancisco-pm
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/sanfrancisco-pm/attachments/20120409/7778b0ae/attachment.html>

From el.dodgero at gmail.com  Mon Apr  9 11:19:08 2012
From: el.dodgero at gmail.com (Dodger)
Date: Mon, 9 Apr 2012 11:19:08 -0700
Subject: [sf-perl] Real perl
In-Reply-To: <CAMEJyivi2OQJxwZzsW6C_DvtBA7JzGu6PScHtswingGHbuQBBQ@mail.gmail.com>
References: <8B1E4BD3-6B57-48D3-9BAB-DFF294C9AD37@gmail.com>
	<CAOH-iGwvGmYgR5jPMZizKRH17L+61x-6e9-2WpBFkbN2H5Uu1Q@mail.gmail.com>
	<B45BE03E-5CA3-4080-A177-33E91091E329@gmail.com>
	<CAMEJyivi2OQJxwZzsW6C_DvtBA7JzGu6PScHtswingGHbuQBBQ@mail.gmail.com>
Message-ID: <E9B6B1A0-D0D8-4B6E-B0AA-B60BCD6E2A4C@gmail.com>

Thanks! I'm starting to look for them. 

Generally googling anything with both PHP and Perl in the search terms doesn't come out super helpful. 

Sent from my iPhone

On 09/04/2012, at 10:05 AM, Paul Makepeace <paulm at paulm.com> wrote:

> There's a module for that already on CPAN. I used it to plug into Catalyst where half our site was PHP (whose half included login and session manglement)
> On Apr 9, 2012 9:10 AM, "Dodger" <el.dodgero at gmail.com> wrote:
> Me too. I actually do like crafting modules by hand, etc. 
> 
> Right now, aside from work stuff, I have been working on a Perl port of the PHP SDK for Facebook. I'm basically mostly done but up to the point where I'm realising that to make it work I need to build another module that reads and writes PHP Session files. Fun fun! (I actually do enjoy this!)
> 
> -- 
> Dodger
> 
> Sent from my iPhone
> 
> On 09/04/2012, at 8:44 AM, David Muir Sharnoff <sfpug at dave.sharnoff.org> wrote:
> 
>> Absolutely.   Call me a luddite, but I haven't drunk the koolaid.
>> 
>> -Dave
>> 
>> On Mon, Apr 9, 2012 at 3:19 AM, Dodger <el.dodgero at gmail.com> wrote:
>> So... How about some old school perl without mooses and meeses?
>> 
>> Anybody out there code in... You know... Perl?
>> 
>> --
>> Dodger
>> 
>> Sent from my iPhone
>> _______________________________________________
>> SanFrancisco-pm mailing list
>> SanFrancisco-pm at pm.org
>> http://mail.pm.org/mailman/listinfo/sanfrancisco-pm
>> 
>> 
> 
> _______________________________________________
> SanFrancisco-pm mailing list
> SanFrancisco-pm at pm.org
> http://mail.pm.org/mailman/listinfo/sanfrancisco-pm
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/sanfrancisco-pm/attachments/20120409/264a5551/attachment-0001.html>

From elaine.richards at windriver.com  Mon Apr  9 11:56:55 2012
From: elaine.richards at windriver.com (Richards, Elaine)
Date: Mon, 9 Apr 2012 18:56:55 +0000
Subject: [sf-perl] Real perl (Dodger)
In-Reply-To: <mailman.18560.1333995567.2448.sanfrancisco-pm@pm.org>
References: <mailman.18560.1333995567.2448.sanfrancisco-pm@pm.org>
Message-ID: <664863F83705094396FD4A863BA2A8BB1FE71A23@ALA-MBB.corp.ad.wrs.com>



>From: Dodger <el.dodgero at gmail.com>
>
>So... How about some old school perl without mooses and meeses?
>
>Anybody out there code in... You know... Perl?
>
>-- 
>Dodger


I generally use out of the box perl for a lot of my scripts because I do not have access to every single workstation that may potentially use my them. It's a bit more labor intensive, but I've done enough of them that I have a lot of shared code.

I do get frisky on my group's internal web server, because the scripts only execute there.

ER



From doomvox at gmail.com  Mon Apr  9 17:26:19 2012
From: doomvox at gmail.com (Joseph Brenner)
Date: Mon, 9 Apr 2012 17:26:19 -0700
Subject: [sf-perl] the mouse with antlers
In-Reply-To: <20120404193116.564d773c@mercury>
References: <CAFfgvXU=4ci9W3fEMtEvkVFJzMsmNwjC_JB_YAGwX91661a1Hw@mail.gmail.com>
	<20120404193116.564d773c@mercury>
Message-ID: <CAFfgvXWsqE=7buN6c=wXO4011hMQQbmbP8k5pVDve7RJbGTJ1Q@mail.gmail.com>

Chris Weyl <cweyl at alumni.drew.edu> wrote:
> Joseph Brenner <doom at kzsu.stanford.edu> wrote:
>
>> I find myself worrying about what I would do if I needed more than two
>> stages, instantiation and lazy access. ?Like what if I wanted to put
>> the id in the subject?
>> I'd have to do a gratuitous access of id to make sure it was defined
>> before accessing subject...
>
> Soo... ?Forgive me if I'm not reading this correctly, but it sounds like you're concerned that when subject is lazily built, you won't be able to get id's value as it won't have been built yet?
>
> Ignore the rest if I've misread this :)
>
> Lazily built attributes are built the first time they're read, if they haven't been explicitly set in the constructor call. ?Basically, attributes are set:
>
> * via explicit value in new()
> * at new() if a default/builder is provided and the attribute is not lazy
> * at any access if a default/builder has been provided, the attribute is not set, and the attribute is lazy
>
> So long as there are no circular references between your attribute defaults/builders (exciting!), you can have them access any other lazily built attribute without worrying if it has been built already or not. ?In your musing above, subject's default/builder can rely on id being set when it accesses id, as id will be built on that access if it has not already been built.

And once I heard you say this, it was obvious.  Now I'm not sure why I
was worried about it.
Stuff like this works fine:

package Trial::LazyChain;
use Mouse;
has name        => (is => 'rw',  isa => 'Str', required => 1);
has id          => (is => 'rw',  isa => 'Str', default => '001');
has title       => (is => 'rw',  isa => 'Str',
   default =>
      sub{ 'Report for name: ' . $_[0]->name }, lazy => 1);
has full_title  => (is => 'rw',  isa => 'Str',
   default =>
      sub{ $_[0]->title . ' and id: ' . $_[0]->id  }, lazy => 1);

And later:

use Trial::LazyChain;
my $td = Trial::LazyChain->new( name => 'yawnchair' );
print $td->full_title, "\n";
  # Report for name: yawnchair and id: 001

From doom at kzsu.stanford.edu  Mon Apr  9 17:28:30 2012
From: doom at kzsu.stanford.edu (Joseph Brenner)
Date: Mon, 9 Apr 2012 17:28:30 -0700
Subject: [sf-perl] the mouse with antlers
In-Reply-To: <CAFfgvXWsqE=7buN6c=wXO4011hMQQbmbP8k5pVDve7RJbGTJ1Q@mail.gmail.com>
References: <CAFfgvXU=4ci9W3fEMtEvkVFJzMsmNwjC_JB_YAGwX91661a1Hw@mail.gmail.com>
	<20120404193116.564d773c@mercury>
	<CAFfgvXWsqE=7buN6c=wXO4011hMQQbmbP8k5pVDve7RJbGTJ1Q@mail.gmail.com>
Message-ID: <CAFfgvXXLOk6+h+EPzYp_vMuE1hxU+BNnc_BipSSBjZSmzMzf+Q@mail.gmail.com>

Chris Weyl <cweyl at alumni.drew.edu> wrote:
> Joseph Brenner <doom at kzsu.stanford.edu> wrote:
>
>> I find myself worrying about what I would do if I needed more than two
>> stages, instantiation and lazy access. ?Like what if I wanted to put
>> the id in the subject?
>> I'd have to do a gratuitous access of id to make sure it was defined
>> before accessing subject...


> Lazily built attributes are built the first time they're read, if they haven't been explicitly set in the constructor call. ?Basically, attributes are set:
>
> * via explicit value in new()
> * at new() if a default/builder is provided and the attribute is not lazy
> * at any access if a default/builder has been provided, the attribute is not set, and the attribute is lazy
>
> So long as there are no circular references between your attribute defaults/builders (exciting!), you can have them access any other lazily built attribute without worrying if it has been built already or not. ?In your musing above, subject's default/builder can rely on id being set when it accesses id, as id will be built on that access if it has not already been built.

And once I heard you say this, it was obvious. ?Now I'm not sure why I
was worried about it.

Stuff like this works fine:

package Trial::LazyChain;
use Mouse;
has name ? ? ? ?=> (is => 'rw', ?isa => 'Str', required => 1);
has id ? ? ? ? ?=> (is => 'rw', ?isa => 'Str', default => '001');
has title ? ? ? => (is => 'rw', ?isa => 'Str',
? default =>
? ? ?sub{ 'Report for name: ' . $_[0]->name }, lazy => 1);
has full_title ?=> (is => 'rw', ?isa => 'Str',
? default =>
? ? ?sub{ $_[0]->title . ' and id: ' . $_[0]->id ?}, lazy => 1);

And later:

use Trial::LazyChain;
my $td = Trial::LazyChain->new( name => 'yawnchair' );
print $td->full_title, "\n";
?# Report for name: yawnchair and id: 001

From vlb at cfcl.com  Mon Apr  9 20:24:08 2012
From: vlb at cfcl.com (Vicki Brown)
Date: Mon, 9 Apr 2012 20:24:08 -0700
Subject: [sf-perl] I'm looking for Work
Message-ID: <F5A237CD-284E-4614-812B-576C8C154045@cfcl.com>

As I think I mentioned last Fall, my job at Yahoo! started to fall apart in August after my manager resigned and the division underwent a reorg. My new VP didn't grok what I did (or why I was being paid "so much" to do it) and my position was eliminated at the end of November.

I've been looking for work since December. This is more difficult for me than for many people because the things I excel at don't fit tidily into typical job titles or search engines at job sites.

I've been a programmer. My preference is for internal tools and data filters. Historically, I've written in Perl, but my OO Perl skills are largely nonexistent and, while I used to be more than competent, I'm 7 years rusty.

I've been a tech writer / editor, with a preference for internal documentation. I love to write, but I like to be able to talk to my audience to assess their needs, etc. So, I prefer how-tos, tutorials, and the like to API documents and externally facing users' guides.

I enjoy doing technical support, but, again, internally focused, preferably level 2 or 3. I don't want to read the manual to people; I assume that they are competent to read the manual for themselves.

For the past 5+ years, I've worked primarily with TWiki -- answering questions, developing applications, writing how-tos, presenting training... I am very likely one of the most knowledgeable TWiki experts you are likely to meet. (I am outstanding in a very small field. ;-) 

The most common question I get in interviews is: "Your resume is... eclectic. You've done writing, coding, QA, support, project management... What do you _like_ to do?" 

My current answer is "I like to help. I want to feel needed. I want to help my co-workers, preferably internal engineers, to be more productive."  I'm a troubleshooter, a facilitator, and a problem solver. I love solving problems through improvements in internal communication. I like working with wikis and weblogs. I enjoy writing. I enjoy building tools to solve problems.

I loved my TWiki support role. I was very good at what I did, received excellent customer feedback, and enjoyed my job most of the time. When I read articles about "finding your passion" or "putting your strengths to work", I want to find another job like the one I had most recently.

Several co-workers have told me that I should call myself an information architect. (Unfortunately, I have never created a wire frame.) Some of the best feedback I've gotten includes:

  Vicki is the kind of person who "hears" what it is you are saying, and then gives you what you want, 
  which may not be exactly what you asked for -- but much better!

  Vicki is an exceptional technologist with a firm grasp of the combination of programming and process 
  management required to turn a disparate group of engineers into a streamlined machine.

  Vicki is a talented writer, a detailed editor, and a thorough tester. It is unusual to find someone who
  has the technical background as a programmer, who enjoys testing and documenting. 

Does your company have a position for me?

-- Vicki
 www.cfcl.com/vlb
 www.twitter.com/vlb
 www.linkedin.com/in/vlbrown

-- Vicki
  www.cfcl.com/vlb
  www.twitter.com/vlb
  www.linkedin.com/in/vlbrown

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/sanfrancisco-pm/attachments/20120409/b8419bd9/attachment.html>

From merlyn at stonehenge.com  Tue Apr 10 14:00:00 2012
From: merlyn at stonehenge.com (Randal L. Schwartz)
Date: Tue, 10 Apr 2012 14:00:00 -0700
Subject: [sf-perl] Real perl
In-Reply-To: <8B1E4BD3-6B57-48D3-9BAB-DFF294C9AD37@gmail.com> (Dodger's
	message of "Mon, 9 Apr 2012 03:19:12 -0700")
References: <8B1E4BD3-6B57-48D3-9BAB-DFF294C9AD37@gmail.com>
Message-ID: <86mx6jmhf3.fsf@red.stonehenge.com>

>>>>> "Dodger" == Dodger  <el.dodgero at gmail.com> writes:

Dodger> So... How about some old school perl without mooses and meeses?
Dodger> Anybody out there code in... You know... Perl?

Seriously, if you're launching green code and not using Moose, you have
some weird nostalgia in you that prevents you from being a useful coder
for me or my clients.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn at stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.posterous.com/ for Smalltalk discussion

From biztos at mac.com  Tue Apr 10 15:07:05 2012
From: biztos at mac.com (Kevin Frost)
Date: Wed, 11 Apr 2012 00:07:05 +0200
Subject: [sf-perl] Real perl
In-Reply-To: <86mx6jmhf3.fsf@red.stonehenge.com>
References: <8B1E4BD3-6B57-48D3-9BAB-DFF294C9AD37@gmail.com>
	<86mx6jmhf3.fsf@red.stonehenge.com>
Message-ID: <7DE7A716-2818-47D3-8FA5-40C920D9719D@mac.com>

Oops, apologies, I meant to reply to the list but replied just to Randal:

What exactly is "green code" and why is it better with Moose?

 my $green_code = 0x00ff00;

I'm not anti-Moose, except maybe for the name, but I'm pretty sure not everything needs it.  There being, well, more than one way to do it.

cheers

-- frosty

On Apr 10, 2012, at 11:00 PM, Randal L. Schwartz wrote:

> Seriously, if you're launching green code and not using Moose, you have
> some weird nostalgia in you that prevents you from being a useful coder
> for me or my clients.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/sanfrancisco-pm/attachments/20120411/5f1e5879/attachment.html>

From david at fetter.org  Tue Apr 10 15:11:26 2012
From: david at fetter.org (David Fetter)
Date: Tue, 10 Apr 2012 15:11:26 -0700
Subject: [sf-perl] Real perl
In-Reply-To: <7DE7A716-2818-47D3-8FA5-40C920D9719D@mac.com>
References: <8B1E4BD3-6B57-48D3-9BAB-DFF294C9AD37@gmail.com>
	<86mx6jmhf3.fsf@red.stonehenge.com>
	<7DE7A716-2818-47D3-8FA5-40C920D9719D@mac.com>
Message-ID: <20120410221126.GC7551@fetter.org>

"green" == "green field" i.e. fresh and new.  The opposite of "green
code" in this instance is "legacy code."

Cheers,
David.
On Wed, Apr 11, 2012 at 12:07:05AM +0200, Kevin Frost wrote:
> Oops, apologies, I meant to reply to the list but replied just to Randal:
> 
> What exactly is "green code" and why is it better with Moose?
> 
>  my $green_code = 0x00ff00;
> 
> I'm not anti-Moose, except maybe for the name, but I'm pretty sure not everything needs it.  There being, well, more than one way to do it.
> 
> cheers
> 
> -- frosty
> 
> On Apr 10, 2012, at 11:00 PM, Randal L. Schwartz wrote:
> 
> > Seriously, if you're launching green code and not using Moose, you have
> > some weird nostalgia in you that prevents you from being a useful coder
> > for me or my clients.
> 

> _______________________________________________
> SanFrancisco-pm mailing list
> SanFrancisco-pm at pm.org
> http://mail.pm.org/mailman/listinfo/sanfrancisco-pm


-- 
David Fetter <david at fetter.org> http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter      XMPP: david.fetter at gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

From biztos at mac.com  Tue Apr 10 15:18:29 2012
From: biztos at mac.com (Kevin Frost)
Date: Wed, 11 Apr 2012 00:18:29 +0200
Subject: [sf-perl] Real perl
In-Reply-To: <20120410221126.GC7551@fetter.org>
References: <8B1E4BD3-6B57-48D3-9BAB-DFF294C9AD37@gmail.com>
	<86mx6jmhf3.fsf@red.stonehenge.com>
	<7DE7A716-2818-47D3-8FA5-40C920D9719D@mac.com>
	<20120410221126.GC7551@fetter.org>
Message-ID: <B7397A4C-1B8E-40EF-B8B1-8CD34B4C1E33@mac.com>

Ah cool, thanks for the clarification.  I will now go try to think of something witty about the moose and the green field...

-- f.

On Apr 11, 2012, at 12:11 AM, David Fetter wrote:

> "green" == "green field" i.e. fresh and new.  The opposite of "green
> code" in this instance is "legacy code."
> 
> Cheers,
> David.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/sanfrancisco-pm/attachments/20120411/d5d3b2f5/attachment.html>

From diederich at gmail.com  Tue Apr 10 15:29:20 2012
From: diederich at gmail.com (Dana Diederich)
Date: Tue, 10 Apr 2012 15:29:20 -0700
Subject: [sf-perl] Real perl
In-Reply-To: <86mx6jmhf3.fsf@red.stonehenge.com>
References: <8B1E4BD3-6B57-48D3-9BAB-DFF294C9AD37@gmail.com>
	<86mx6jmhf3.fsf@red.stonehenge.com>
Message-ID: <CAD--fz4atPFqDxrERyhrPFQTFEin9BhQ3pTfzcSSVodQ6zkUaA@mail.gmail.com>

That's a bit of an absolute statement, Randal.  There are definitely highly
relevant cases where it doesn't make sense to use Moose and friends.  If
program load time or overall performance is a primary goal, 'old school'
Perl might make more sense.  Granted it's often possible to re-frame the
overall problem so those aspects aren't as important, but it often doesn't
make sense to do that.

dana at hithlum:~/bench$ cat p1
#!/usr/bin/perl

my $foo = {};
bless $foo, 'Foo';

my $counter = 1;
for(1..100000) {
    $counter = $foo->adder($counter);
}
print "$counter\n";

package Foo;

sub
adder {
    return $_ + 1;
}

dana at hithlum:~/bench$ time ./p1
100001

real    0m0.045s
user    0m0.044s
sys     0m0.000s
dana at hithlum:~/bench$ cat p2
#!/usr/bin/perl

use lib '.';
use Foo;

my $foo = Foo->new;
my $counter = 1;
for(1..100000) {
    $counter = $foo->adder($counter);
}
print "$counter\n";
dana at hithlum:~/bench$ cat Foo.pm
use MooseX::Declare;

class Foo {
    method adder (Num $ct) {
        return $ct + 1;
    }
}
dana at hithlum:~/bench$ time perl ./p2
100001

real    0m13.718s
user    0m13.661s
sys     0m0.044s
dana at hithlum:~/bench$

I write code using Moose and the wide galaxy of exceptional modules it has
spawned every day.  And I yearn for the day that I can use Perl6 in my
production environment.  (It's getting close, last time I looked!)  But
sometimes raw 'cpu' performance is important.

Most of the time, I start using the highest-level modules possible, and if
there's a performance problem, I end up 'dumbing down' the hot-spots, using
simpler Perl.  For me, this is rare.

Cheers,
-Dana

On Tue, Apr 10, 2012 at 2:00 PM, Randal L. Schwartz
<merlyn at stonehenge.com>wrote:

> >>>>> "Dodger" == Dodger  <el.dodgero at gmail.com> writes:
>
> Dodger> So... How about some old school perl without mooses and meeses?
> Dodger> Anybody out there code in... You know... Perl?
>
> Seriously, if you're launching green code and not using Moose, you have
> some weird nostalgia in you that prevents you from being a useful coder
> for me or my clients.
>
> --
> Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777
> 0095
> <merlyn at stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
> See http://methodsandmessages.posterous.com/ for Smalltalk discussion
> _______________________________________________
> SanFrancisco-pm mailing list
> SanFrancisco-pm at pm.org
> http://mail.pm.org/mailman/listinfo/sanfrancisco-pm
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/sanfrancisco-pm/attachments/20120410/d2e46cd2/attachment-0001.html>

From jeff at imaginative-software.com  Tue Apr 10 15:56:06 2012
From: jeff at imaginative-software.com (Jeffrey Thalhammer)
Date: Tue, 10 Apr 2012 15:56:06 -0700
Subject: [sf-perl] Real perl
In-Reply-To: <8B1E4BD3-6B57-48D3-9BAB-DFF294C9AD37@gmail.com>
References: <8B1E4BD3-6B57-48D3-9BAB-DFF294C9AD37@gmail.com>
Message-ID: <DA27D1D3-05A2-4854-8F09-45937A10CB5A@imaginative-software.com>


On Apr 9, 2012, at 3:19 AM, Dodger wrote:

> So... How about some old school perl without mooses and meeses?
> 
> Anybody out there code in... You know... Perl?

Not here.

The Pinto project was my first deep-dive into Moose.  Now I won't do anything without it.  Here's why:

Economy:  Moose greatly reduces the amount of code I have to write and test.  Less code means fewer bugs.  And the remaining bugs that I do create are a lot easier to spot when the aren't swimming in a sea of getters/setters and other loosely related methods.

Organization: Roles, type definitions, and meta extensions each give me convenient "compartments" for my code.  Each compartment is isolated, reusable, and testable.  I find this much faster to write and easier to use than piling everything into traditional classes.

Community: The MooseX namespace has a ton of wonderful extensions.  The've solved problems for me that I didn't even know I had.

-Jeff



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/sanfrancisco-pm/attachments/20120410/e6f8c209/attachment.html>

From jackofnotrades at gmail.com  Tue Apr 10 16:19:14 2012
From: jackofnotrades at gmail.com (Jeff Bragg)
Date: Tue, 10 Apr 2012 16:19:14 -0700
Subject: [sf-perl] Real perl
In-Reply-To: <8B1E4BD3-6B57-48D3-9BAB-DFF294C9AD37@gmail.com>
References: <8B1E4BD3-6B57-48D3-9BAB-DFF294C9AD37@gmail.com>
Message-ID: <CAJ4sp-V=VP=Ti=ivt9Ry7r2EqapRpE1fZfim-fdT8hRMom3_hQ@mail.gmail.com>

I've used Moose, and found it to be very nice, especially in comparison to
old-school Perl OO.  However, it usually seems like overkill for my
purposes (and perhaps a violation of the KISS principle).  I'm sure it has
a lot to do with context; I'm generally doing systemsy, back-end stuff, and
prefer to minimize my dependencies and assumptions about deployment
environment.

If I were doing proper app development, though, I'd use it for sure, unless
I had a compelling reason to do otherwise.  The type system alone I've
found really useful (and have abused to good effect).

On Mon, Apr 9, 2012 at 3:19 AM, Dodger <el.dodgero at gmail.com> wrote:

> So... How about some old school perl without mooses and meeses?
>
> Anybody out there code in... You know... Perl?
>
> --
> Dodger
>
> Sent from my iPhone
> _______________________________________________
> SanFrancisco-pm mailing list
> SanFrancisco-pm at pm.org
> http://mail.pm.org/mailman/listinfo/sanfrancisco-pm
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/sanfrancisco-pm/attachments/20120410/ce9e4d4d/attachment.html>

From fred at redhotpenguin.com  Tue Apr 10 16:41:47 2012
From: fred at redhotpenguin.com (Fred Moyer)
Date: Tue, 10 Apr 2012 16:41:47 -0700
Subject: [sf-perl] Real perl
In-Reply-To: <86mx6jmhf3.fsf@red.stonehenge.com>
References: <8B1E4BD3-6B57-48D3-9BAB-DFF294C9AD37@gmail.com>
	<86mx6jmhf3.fsf@red.stonehenge.com>
Message-ID: <CAHrynWCswOCwiXzaUwf75b=-LY_+w48ZkX9LN=CcX053ADK+3A@mail.gmail.com>

On Tue, Apr 10, 2012 at 2:00 PM, Randal L. Schwartz
<merlyn at stonehenge.com> wrote:
>>>>>> "Dodger" == Dodger ?<el.dodgero at gmail.com> writes:
>
> Dodger> So... How about some old school perl without mooses and meeses?
> Dodger> Anybody out there code in... You know... Perl?
>
> Seriously, if you're launching green code and not using Moose, you have
> some weird nostalgia in you that prevents you from being a useful coder
> for me or my clients.

The downside with this approach is that you are choosing a solution
without evaluating the problem.

Moose is a tool that is right for certain needs. I always encourage
people to think about the specific problem they are trying to solve
before choosing the toolset for the solution. There are many tools out
there for your specific problem needs, but you should always start off
with the most capable one, the brain.

From swartz at pobox.com  Tue Apr 10 17:05:29 2012
From: swartz at pobox.com (Jonathan Swartz)
Date: Tue, 10 Apr 2012 17:05:29 -0700
Subject: [sf-perl] Real perl
In-Reply-To: <CAD--fz4atPFqDxrERyhrPFQTFEin9BhQ3pTfzcSSVodQ6zkUaA@mail.gmail.com>
References: <8B1E4BD3-6B57-48D3-9BAB-DFF294C9AD37@gmail.com>
	<86mx6jmhf3.fsf@red.stonehenge.com>
	<CAD--fz4atPFqDxrERyhrPFQTFEin9BhQ3pTfzcSSVodQ6zkUaA@mail.gmail.com>
Message-ID: <633BE18F-0DCD-401D-BD78-005E7B16D758@pobox.com>

Dana: Agreed that performance is a consideration but Moose != MooseX::Declare!! Moose does have its startup costs, but MooseX::Declare has runtime costs *far* greater than either Moose or plain old classes.

I'm a big fan of Method::Signatures::Simple myself, because I don't need runtime type-checking on individual method arguments enough to pay the considerable price.

If you redo p2 with this code --

   package Foo;
   use Moose;
   use Method::Signatures::Simple;
   
   method adder ($ct) {
       return $ct + 1;
   }
   
   1;

I think you'll find the performance to be much closer to p1 than p2.

Jon

> dana at hithlum:~/bench$ cat p1
> #!/usr/bin/perl
> 
> my $foo = {};
> bless $foo, 'Foo';
> 
> my $counter = 1;
> for(1..100000) {
>     $counter = $foo->adder($counter);
> }
> print "$counter\n";
> 
> package Foo;
> 
> sub
> adder {
>     return $_ + 1;
> }
> 
> dana at hithlum:~/bench$ time ./p1
> 100001
> 
> real    0m0.045s
> user    0m0.044s7
> sys     0m0.000s
> dana at hithlum:~/bench$ cat p2
> #!/usr/bin/perl
> 
> use lib '.';
> use Foo;
> 
> my $foo = Foo->new;
> my $counter = 1;
> for(1..100000) {
>     $counter = $foo->adder($counter);
> }
> print "$counter\n";
> dana at hithlum:~/bench$ cat Foo.pm 
> use MooseX::Declare;
> 
> class Foo {
>     method adder (Num $ct) {
>         return $ct + 1;
>     }
> }
> dana at hithlum:~/bench$ time perl ./p2
> 100001
> 
> real    0m13.718s
> user    0m13.661s
> sys     0m0.044s
> dana at hithlum:~/bench$ 
> 
> I write code using Moose and the wide galaxy of exceptional modules it has spawned every day.  And I yearn for the day that I can use Perl6 in my production environment.  (It's getting close, last time I looked!)  But sometimes raw 'cpu' performance is important.
> 
> Most of the time, I start using the highest-level modules possible, and if there's a performance problem, I end up 'dumbing down' the hot-spots, using simpler Perl.  For me, this is rare.
> 
> Cheers,
> -Dana
> 
> On Tue, Apr 10, 2012 at 2:00 PM, Randal L. Schwartz <merlyn at stonehenge.com> wrote:
> >>>>> "Dodger" == Dodger  <el.dodgero at gmail.com> writes:
> 
> Dodger> So... How about some old school perl without mooses and meeses?
> Dodger> Anybody out there code in... You know... Perl?
> 
> Seriously, if you're launching green code and not using Moose, you have
> some weird nostalgia in you that prevents you from being a useful coder
> for me or my clients.
> 
> --
> Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
> <merlyn at stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
> See http://methodsandmessages.posterous.com/ for Smalltalk discussion
> _______________________________________________
> SanFrancisco-pm mailing list
> SanFrancisco-pm at pm.org
> http://mail.pm.org/mailman/listinfo/sanfrancisco-pm
> 
> _______________________________________________
> SanFrancisco-pm mailing list
> SanFrancisco-pm at pm.org
> http://mail.pm.org/mailman/listinfo/sanfrancisco-pm

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/sanfrancisco-pm/attachments/20120410/4205e24e/attachment-0001.html>

From rdm at cfcl.com  Tue Apr 10 17:24:36 2012
From: rdm at cfcl.com (Rich Morin)
Date: Tue, 10 Apr 2012 17:24:36 -0700
Subject: [sf-perl] Real perl
In-Reply-To: <CAHrynWCswOCwiXzaUwf75b=-LY_+w48ZkX9LN=CcX053ADK+3A@mail.gmail.com>
References: <8B1E4BD3-6B57-48D3-9BAB-DFF294C9AD37@gmail.com>
	<86mx6jmhf3.fsf@red.stonehenge.com>
	<CAHrynWCswOCwiXzaUwf75b=-LY_+w48ZkX9LN=CcX053ADK+3A@mail.gmail.com>
Message-ID: <05EA67B3-90AA-455E-9731-AC76225B845E@cfcl.com>

On Apr 10, 2012, at 16:41, Fred Moyer wrote:
> The downside with this approach is that you are choosing a solution
> without evaluating the problem.
> 
> Moose is a tool that is right for certain needs. ...

Although I'm delighted to see most Perlies accept Moose as the "normal"
way to do OO, not all scripts have enough complexity to justify OO (or
even functions, in some cases :-).

My take is that there are a number of tools for encapsulation.  They
have benefits and costs, so the trick is to balance the two and use
the appropriate tools for the project at hand.

So, don't create large programs without using the appropriate tools,
but don't require small programs to use unnecessary tools, either.

-r

 -- 
http://www.cfcl.com/rdm            Rich Morin
http://www.cfcl.com/rdm/resume     rdm at cfcl.com
http://www.cfcl.com/rdm/weblog     +1 650-873-7841

Software system design, development, and documentation



From moseley at hank.org  Tue Apr 10 20:26:04 2012
From: moseley at hank.org (Bill Moseley)
Date: Wed, 11 Apr 2012 11:26:04 +0800
Subject: [sf-perl] Real perl
In-Reply-To: <8B1E4BD3-6B57-48D3-9BAB-DFF294C9AD37@gmail.com>
References: <8B1E4BD3-6B57-48D3-9BAB-DFF294C9AD37@gmail.com>
Message-ID: <CAKhN_m7_i76PeM71pdQs=t24DoR+RXotPf4f9SNm+kpG6HopHQ@mail.gmail.com>

On Mon, Apr 9, 2012 at 6:19 PM, Dodger <el.dodgero at gmail.com> wrote:

> So... How about some old school perl without mooses and meeses?
>

You mean like: http://www.scriptarchive.com/ ?


> Anybody out there code in... You know... Perl?
>
Sent from my iPhone
>

Somewhat unfortunate comment likely due to the iPhone.  Obviously, using
Moose or any CPAN module still requires coding in Perl.

Sure would rather see programmers use DBI and LWP instead of doing it "old
school".  Likewise with Moose -- rather see code that doesn't "old school"
class attributes, ugly multiple inheritance, and uses a generic SUPER for
every type of override situation.

The think my experience with Moose is that code has fewer compile time
errors.  The code tends to work as expected sooner.  Code is consistent
across classes.  Much better compartmentalization of code.  Elimination of
replication.  It's simply a module that encourages good programming
techniques and replaces all the receptive code that one tends to get wrong
-- just like what many, many other "old school" modules on CPAN provide.

So, come on.  All your friends are doing it.   It's completely safe.  Have
some kool-ade.

-- 
Bill Moseley
moseley at hank.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/sanfrancisco-pm/attachments/20120411/a0c3aded/attachment.html>

From jeff at imaginative-software.com  Tue Apr 10 21:59:01 2012
From: jeff at imaginative-software.com (Jeffrey Thalhammer)
Date: Tue, 10 Apr 2012 21:59:01 -0700
Subject: [sf-perl] Go Pinto [Was: Real perl]
In-Reply-To: <CAJ4sp-V=VP=Ti=ivt9Ry7r2EqapRpE1fZfim-fdT8hRMom3_hQ@mail.gmail.com>
References: <8B1E4BD3-6B57-48D3-9BAB-DFF294C9AD37@gmail.com>
	<CAJ4sp-V=VP=Ti=ivt9Ry7r2EqapRpE1fZfim-fdT8hRMom3_hQ@mail.gmail.com>
Message-ID: <4B1B79B0-1707-4C9A-A826-CD4E5C09019A@imaginative-software.com>


On Apr 10, 2012, at 4:19 PM, Jeff Bragg wrote:

> I've used Moose, and found it to be very nice, especially in comparison to old-school Perl OO.  However, it usually seems like overkill for my purposes (and perhaps a violation of the KISS principle).  I'm sure it has a lot to do with context; I'm generally doing systemsy, back-end stuff, and prefer to minimize my dependencies and assumptions about deployment environment.

Then please allow me to use this opportunity to make a shameless plug for Pinto.

IMHO, dependency avoidance is a weak excuse for doing things the hard way (and usually the wrong way).  But installing stuff from the public CPAN is a lottery because you never know exactly which versions you are going to get.  And if you want to lock down those versions with a private CPAN, it is a fair bit of work to manage.  So dependency-phobia lives on.

Pinto aims to fix all that.  Pinto makes it super easy to construct a custom repository of CPAN distributions (including your own private ones) and organically evolve your dependencies over time.  So now all that "systemsy back-end stuff" can leverage anything and everything on CPAN, and you've got a solid, reproducible mechanism for building, testing, and deploying it.

-Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/sanfrancisco-pm/attachments/20120410/ff2d24d3/attachment.html>

From fred at redhotpenguin.com  Tue Apr 10 22:44:02 2012
From: fred at redhotpenguin.com (Fred Moyer)
Date: Tue, 10 Apr 2012 22:44:02 -0700
Subject: [sf-perl] Whack your Perl code
Message-ID: <CAHrynWAENcSORyoqxxY0k0OWoWfJPYCFEPXfoGOPf68CFZuGcw@mail.gmail.com>

This program uses PPI to determine what parts of your codebase are
good candidates for refactoring by looking for complicated
subroutines. I'm intrigued by the logic, but I'm not completely sold
on refactoring just to clean things up. Refactoring without business
goals can cause problems more often than not I've found.

https://github.com/wickline/whack/blob/master/whack.pl

From el.dodgero at gmail.com  Wed Apr 11 03:33:59 2012
From: el.dodgero at gmail.com (Dodger)
Date: Wed, 11 Apr 2012 03:33:59 -0700
Subject: [sf-perl] Real perl
In-Reply-To: <86mx6jmhf3.fsf@red.stonehenge.com>
References: <8B1E4BD3-6B57-48D3-9BAB-DFF294C9AD37@gmail.com>
	<86mx6jmhf3.fsf@red.stonehenge.com>
Message-ID: <59363445-A959-4CFB-8FF9-907BB8A143AE@gmail.com>

I might want to release code in CPAN that doesn't have a shit-ton of cascading prereqs. 

I might also actually like knowing intrinsically how what I have made works. 

If craftsmanship is "wierd nostalgia" then I am just as impacted by that as when I met you and you blew me off like an ass.


Sent from my iPhone

On 10/04/2012, at 2:00 PM, merlyn at stonehenge.com (Randal L. Schwartz) wrote:

>>>>>> "Dodger" == Dodger  <el.dodgero at gmail.com> writes:
> 
> Dodger> So... How about some old school perl without mooses and meeses?
> Dodger> Anybody out there code in... You know... Perl?
> 
> Seriously, if you're launching green code and not using Moose, you have
> some weird nostalgia in you that prevents you from being a useful coder
> for me or my clients.
> 
> -- 
> Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
> <merlyn at stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
> See http://methodsandmessages.posterous.com/ for Smalltalk discussion

From el.dodgero at gmail.com  Wed Apr 11 03:35:05 2012
From: el.dodgero at gmail.com (Dodger)
Date: Wed, 11 Apr 2012 03:35:05 -0700
Subject: [sf-perl] Real perl
In-Reply-To: <CAD--fz4atPFqDxrERyhrPFQTFEin9BhQ3pTfzcSSVodQ6zkUaA@mail.gmail.com>
References: <8B1E4BD3-6B57-48D3-9BAB-DFF294C9AD37@gmail.com>
	<86mx6jmhf3.fsf@red.stonehenge.com>
	<CAD--fz4atPFqDxrERyhrPFQTFEin9BhQ3pTfzcSSVodQ6zkUaA@mail.gmail.com>
Message-ID: <104BF6E5-E911-46A2-BC40-281D2E43B978@gmail.com>

package False::Laziness;
...

Sent from my iPhone

On 10/04/2012, at 3:29 PM, Dana Diederich <diederich at gmail.com> wrote:

> That's a bit of an absolute statement, Randal.  There are definitely highly relevant cases where it doesn't make sense to use Moose and friends.  If program load time or overall performance is a primary goal, 'old school' Perl might make more sense.  Granted it's often possible to re-frame the overall problem so those aspects aren't as important, but it often doesn't make sense to do that.
> 
> dana at hithlum:~/bench$ cat p1
> #!/usr/bin/perl
> 
> my $foo = {};
> bless $foo, 'Foo';
> 
> my $counter = 1;
> for(1..100000) {
>     $counter = $foo->adder($counter);
> }
> print "$counter\n";
> 
> package Foo;
> 
> sub
> adder {
>     return $_ + 1;
> }
> 
> dana at hithlum:~/bench$ time ./p1
> 100001
> 
> real    0m0.045s
> user    0m0.044s
> sys     0m0.000s
> dana at hithlum:~/bench$ cat p2
> #!/usr/bin/perl
> 
> use lib '.';
> use Foo;
> 
> my $foo = Foo->new;
> my $counter = 1;
> for(1..100000) {
>     $counter = $foo->adder($counter);
> }
> print "$counter\n";
> dana at hithlum:~/bench$ cat Foo.pm 
> use MooseX::Declare;
> 
> class Foo {
>     method adder (Num $ct) {
>         return $ct + 1;
>     }
> }
> dana at hithlum:~/bench$ time perl ./p2
> 100001
> 
> real    0m13.718s
> user    0m13.661s
> sys     0m0.044s
> dana at hithlum:~/bench$ 
> 
> I write code using Moose and the wide galaxy of exceptional modules it has spawned every day.  And I yearn for the day that I can use Perl6 in my production environment.  (It's getting close, last time I looked!)  But sometimes raw 'cpu' performance is important.
> 
> Most of the time, I start using the highest-level modules possible, and if there's a performance problem, I end up 'dumbing down' the hot-spots, using simpler Perl.  For me, this is rare.
> 
> Cheers,
> -Dana
> 
> On Tue, Apr 10, 2012 at 2:00 PM, Randal L. Schwartz <merlyn at stonehenge.com> wrote:
> >>>>> "Dodger" == Dodger  <el.dodgero at gmail.com> writes:
> 
> Dodger> So... How about some old school perl without mooses and meeses?
> Dodger> Anybody out there code in... You know... Perl?
> 
> Seriously, if you're launching green code and not using Moose, you have
> some weird nostalgia in you that prevents you from being a useful coder
> for me or my clients.
> 
> --
> Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
> <merlyn at stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
> See http://methodsandmessages.posterous.com/ for Smalltalk discussion
> _______________________________________________
> SanFrancisco-pm mailing list
> SanFrancisco-pm at pm.org
> http://mail.pm.org/mailman/listinfo/sanfrancisco-pm
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/sanfrancisco-pm/attachments/20120411/c1a05b34/attachment.html>

From el.dodgero at gmail.com  Wed Apr 11 03:38:26 2012
From: el.dodgero at gmail.com (Dodger)
Date: Wed, 11 Apr 2012 03:38:26 -0700
Subject: [sf-perl] Real perl
In-Reply-To: <DA27D1D3-05A2-4854-8F09-45937A10CB5A@imaginative-software.com>
References: <8B1E4BD3-6B57-48D3-9BAB-DFF294C9AD37@gmail.com>
	<DA27D1D3-05A2-4854-8F09-45937A10CB5A@imaginative-software.com>
Message-ID: <CF3ACE1E-FA25-4F67-B5C2-F3E13E189163@gmail.com>



Sent from my iPhone

On 10/04/2012, at 3:56 PM, Jeffrey Thalhammer <jeff at imaginative-software.com> wrote:

> 
> On Apr 9, 2012, at 3:19 AM, Dodger wrote:
> 
>> So... How about some old school perl without mooses and meeses?
>> 
>> Anybody out there code in... You know... Perl?
> 
> Not here.
> 
> The Pinto project was my first deep-dive into Moose.  Now I won't do anything without it.  Here's why:
> 
> Economy:  Moose greatly reduces the amount of code I have to write and test.  Less code means fewer bugs.  And the remaining bugs that I do create are a lot easier to spot when the aren't swimming in a sea of getters/setters and other loosely related methods

sub AUTOLOAD {}

Who writes accessors?

> Organization: Roles, type definitions, and meta extensions each give me convenient "compartments" for my code.  Each compartment is isolated, reusable, and testable.  I find this much faster to write and easier to use than piling everything into traditional classes.

I don't see any issue with this in Perl.

> Community: The MooseX namespace has a ton of wonderful extensions.  The've solved problems for me that I didn't even know I had.

CPAN has been doing that for almost 2 decades.

> -Jeff
> 
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/sanfrancisco-pm/attachments/20120411/05836b51/attachment.html>

From el.dodgero at gmail.com  Wed Apr 11 04:00:59 2012
From: el.dodgero at gmail.com (Dodger)
Date: Wed, 11 Apr 2012 04:00:59 -0700
Subject: [sf-perl] Real perl
In-Reply-To: <CAHrynWCswOCwiXzaUwf75b=-LY_+w48ZkX9LN=CcX053ADK+3A@mail.gmail.com>
References: <8B1E4BD3-6B57-48D3-9BAB-DFF294C9AD37@gmail.com>
	<86mx6jmhf3.fsf@red.stonehenge.com>
	<CAHrynWCswOCwiXzaUwf75b=-LY_+w48ZkX9LN=CcX053ADK+3A@mail.gmail.com>
Message-ID: <8F835877-BD57-4C0F-BEDE-869917CF540C@gmail.com>

I see moose and mouse as simplification methods. Syntactic sugar. That's all well and good but there's a reason that people go "ooh" and "ahh" when they hear about some old school hacker who would simplify a function by scoring a line into a drum. 

While those extremes are the stuff of legend, adding such a level of simplification, to me, adds a level of complexity that is not necessary. 

We hear all the time about people dissing Perl for looking like line noise and write it off as the side effect of sigils and our ubiquitous regexes but honestly most of it is because of crappy perl coders. People who just don't "get" the language as it is. People who try from a high end to code C in perl or, worse, hack out PHP in perl. And their results look like shit, are hard to follow, and do not work within the native perl paradigms. 

Perl's bad rep for unreadability comes not from perl but from people who don't really know perl. Unfortunately, that's also one big portion of what makes it unpopular. It's a stigma that doesn't go away even if you make it look like poetry. 

The other portion of the bad rap is a reputation for slowness. One which is undeserved. When this started it was being compared with compiled languages and generally in the context of CGIs. A bad place to start when in the 90s there was no existing alternative. 

But frameworks like Moose, while they may have a valid place in full-fledged app development, have very little place in the places Perl is most likely to come in handy. 

I would most certainly review someone in a most unfavourable way if I ever saw Moose show up in the two places its most useful. Namely I see the two following concepts as inherently counterproductive to the level of goto:

1)
perl -MMoose -e ...

2)
use Moose;

sub handler {
    my $r = shift;
    ...
}

Yet the two most useful places in the world for perl are, IMO, quick and dirty scripts that still have 500% the capacity of a shell script, and mod_perl web apps that blow anything else out of the water for capabilities and scalability. 

False. Laziness. 

There are places Moose makes sense. 

And then there are places Perl makes sense. 

With all due respect to Mr. Schwartz  (and having met him IMO that's not as much as his name showing up in O'Reilly books would lead one to believe) I simy do not feel the two are very often mutually compatible. 

When they are, however, I'm sure Moose is very useful.

-- 
Dodger

Sent from my iPhone

On 10/04/2012, at 4:41 PM, Fred Moyer <fred at redhotpenguin.com> wrote:

> On Tue, Apr 10, 2012 at 2:00 PM, Randal L. Schwartz
> <merlyn at stonehenge.com> wrote:
>>>>>>> "Dodger" == Dodger  <el.dodgero at gmail.com> writes:
>> 
>> Dodger> So... How about some old school perl without mooses and meeses?
>> Dodger> Anybody out there code in... You know... Perl?
>> 
>> Seriously, if you're launching green code and not using Moose, you have
>> some weird nostalgia in you that prevents you from being a useful coder
>> for me or my clients.
> 
> The downside with this approach is that you are choosing a solution
> without evaluating the problem.
> 
> Moose is a tool that is right for certain needs. I always encourage
> people to think about the specific problem they are trying to solve
> before choosing the toolset for the solution. There are many tools out
> there for your specific problem needs, but you should always start off
> with the most capable one, the brain.

From jackofnotrades at gmail.com  Wed Apr 11 07:48:17 2012
From: jackofnotrades at gmail.com (Jeff Bragg)
Date: Wed, 11 Apr 2012 07:48:17 -0700
Subject: [sf-perl] Go Pinto [Was: Real perl]
In-Reply-To: <4B1B79B0-1707-4C9A-A826-CD4E5C09019A@imaginative-software.com>
References: <8B1E4BD3-6B57-48D3-9BAB-DFF294C9AD37@gmail.com>
	<CAJ4sp-V=VP=Ti=ivt9Ry7r2EqapRpE1fZfim-fdT8hRMom3_hQ@mail.gmail.com>
	<4B1B79B0-1707-4C9A-A826-CD4E5C09019A@imaginative-software.com>
Message-ID: <CAJ4sp-XnVC6wBV+n6ituXrgpin_4EO=cGL2OH=O2marc4-UOyA@mail.gmail.com>

Doing things without a lot of dependencies isn't necessarily "doing things
the hard way".  I lean heavily on the core packages, and use CPAN modules
for virtually anything non-trivial, as I don't have time for a lot of
unnecessary wheel-inventing.  However, as I said, I don't always have the
luxury of assuming the resources I'll have available, outside of Perl
itself and some indispensible BASH/Linux utilities.  Some machines I have
control over, and can install what I please; others I have much more
sharply limited control over, and cannot, for example, even assume that the
CPAN kit is complete enough to build everything -- without a few specific
packages or external tools, e.g. the YAML library, make, I've seen CPAN
fail spectacularly to install what I needed.

And again I'll say, Moose, nice as it is, is overkill for much of what I
write; most of my scripts will already be most of the way finished running,
as currently written, by the time Moose loads.

I'll keep Pinto in mind because it may be useful for situations in which I
have sufficient control to use it.

Honestly, I was generally praising Moose as a good thing, but a little
heavy for some things, and just stating a fact about the situation I have
to work with; I'm not sure why you chose me to make an example of.

I feel like the Perl community is becoming pretty damned opinionated; in my
view TMTOWTDI does not just mean that there's a "right" way and a "wrong"
way (that kind of binary thinking is for other language communities).

On Tue, Apr 10, 2012 at 9:59 PM, Jeffrey Thalhammer <
jeff at imaginative-software.com> wrote:

>
> On Apr 10, 2012, at 4:19 PM, Jeff Bragg wrote:
>
> I've used Moose, and found it to be very nice, especially in comparison to
> old-school Perl OO.  However, it usually seems like overkill for my
> purposes (and perhaps a violation of the KISS principle).  I'm sure it has
> a lot to do with context; I'm generally doing systemsy, back-end stuff, and
> prefer to minimize my dependencies and assumptions about deployment
> environment.
>
>
> Then please allow me to use this opportunity to make a shameless plug for
> Pinto <https://metacpan.org/module/Pinto>.
>
> IMHO, dependency avoidance is a weak excuse for doing things the hard way
> (and usually the wrong way).  But installing stuff from the public CPAN is
> a lottery because you never know exactly which versions you are going to
> get.  And if you want to lock down those versions with a private CPAN, it
> is a fair bit of work to manage.  So dependency-phobia lives on.
>
> Pinto <https://metacpan.org/module/Pinto> aims to fix all that.  Pinto
> makes it super easy to construct a custom repository of CPAN distributions
> (including your own private ones) and organically evolve your dependencies
> over time.  So now all that "systemsy back-end stuff" can leverage anything
> and everything on CPAN, and you've got a solid, reproducible mechanism for
> building, testing, and deploying it.
>
> -Jeff
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/sanfrancisco-pm/attachments/20120411/37adb01f/attachment-0001.html>

From diederich at gmail.com  Wed Apr 11 07:57:02 2012
From: diederich at gmail.com (Dana Diederich)
Date: Wed, 11 Apr 2012 07:57:02 -0700
Subject: [sf-perl] Go Pinto [Was: Real perl]
In-Reply-To: <CAJ4sp-XnVC6wBV+n6ituXrgpin_4EO=cGL2OH=O2marc4-UOyA@mail.gmail.com>
References: <8B1E4BD3-6B57-48D3-9BAB-DFF294C9AD37@gmail.com>
	<CAJ4sp-V=VP=Ti=ivt9Ry7r2EqapRpE1fZfim-fdT8hRMom3_hQ@mail.gmail.com>
	<4B1B79B0-1707-4C9A-A826-CD4E5C09019A@imaginative-software.com>
	<CAJ4sp-XnVC6wBV+n6ituXrgpin_4EO=cGL2OH=O2marc4-UOyA@mail.gmail.com>
Message-ID: <CAD--fz63SHk68+FdtpCFfVKE9YQRD-pMDs_MCP9OJyJxbzAHgg@mail.gmail.com>

Thank you Jeff, very well said.  I believe the greatest historical strength
of the Perl community has been a real resistance to binary thinking.  I do
truly hope that continues.

Cheers,
-Dana

2012/4/11 Jeff Bragg <jackofnotrades at gmail.com>

> ...

I feel like the Perl community is becoming pretty damned opinionated; in my
> view TMTOWTDI does not just mean that there's a "right" way and a "wrong"
> way (that kind of binary thinking is for other language communities).
>
>
> On Tue, Apr 10, 2012 at 9:59 PM, Jeffrey Thalhammer <
> jeff at imaginative-software.com> wrote:
>
>>
>> On Apr 10, 2012, at 4:19 PM, Jeff Bragg wrote:
>>
>> I've used Moose, and found it to be very nice, especially in comparison
>> to old-school Perl OO.  However, it usually seems like overkill for my
>> purposes (and perhaps a violation of the KISS principle).  I'm sure it has
>> a lot to do with context; I'm generally doing systemsy, back-end stuff, and
>> prefer to minimize my dependencies and assumptions about deployment
>> environment.
>>
>>
>> Then please allow me to use this opportunity to make a shameless plug for
>> Pinto <https://metacpan.org/module/Pinto>.
>>
>> IMHO, dependency avoidance is a weak excuse for doing things the hard way
>> (and usually the wrong way).  But installing stuff from the public CPAN is
>> a lottery because you never know exactly which versions you are going to
>> get.  And if you want to lock down those versions with a private CPAN, it
>> is a fair bit of work to manage.  So dependency-phobia lives on.
>>
>> Pinto <https://metacpan.org/module/Pinto> aims to fix all that.  Pinto
>> makes it super easy to construct a custom repository of CPAN distributions
>> (including your own private ones) and organically evolve your dependencies
>> over time.  So now all that "systemsy back-end stuff" can leverage anything
>> and everything on CPAN, and you've got a solid, reproducible mechanism for
>> building, testing, and deploying it.
>>
>> -Jeff
>>
>
>
> _______________________________________________
> SanFrancisco-pm mailing list
> SanFrancisco-pm at pm.org
> http://mail.pm.org/mailman/listinfo/sanfrancisco-pm
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/sanfrancisco-pm/attachments/20120411/e20c67d0/attachment.html>

From Paul.Makepeace at realprogrammers.com  Wed Apr 11 11:39:40 2012
From: Paul.Makepeace at realprogrammers.com (Paul Makepeace)
Date: Wed, 11 Apr 2012 11:39:40 -0700
Subject: [sf-perl] Real perl
In-Reply-To: <59363445-A959-4CFB-8FF9-907BB8A143AE@gmail.com>
References: <8B1E4BD3-6B57-48D3-9BAB-DFF294C9AD37@gmail.com>
	<86mx6jmhf3.fsf@red.stonehenge.com>
	<59363445-A959-4CFB-8FF9-907BB8A143AE@gmail.com>
Message-ID: <CAMEJyisafe0LRsVwCk-tEcTnAL6Dzw2z5xCBa-z6ZxE2GKr4Lg@mail.gmail.com>

On Wed, Apr 11, 2012 at 03:33, Dodger <el.dodgero at gmail.com> wrote:
> I might also actually like knowing intrinsically how what I have made works.

Writing software is a discipline where there's a level of abstraction
where everything just goes black (box). It might be at "CPAN modules"
it might be at "Perl source code" it might be at "libc implementation"
it might be at "kernel scheduler" it might be at "filesystem device
driver" it might be at "L2 cache microcode" and so on down to particle
physics. At some point you stop caring and just trust it works.

IMO generally the higher level that is the more you can get done, and
those times when trust breaks down (i.e. an abstraction isn't
fulfilling its published contract) are the relatively fewer times you
ever have to care what's beneath the black.

That said, nothing wrong with liking knowing, it's just probably not
going to get as much made in the long run :)

Paul

From el.dodgero at gmail.com  Wed Apr 11 13:29:15 2012
From: el.dodgero at gmail.com (Dodger)
Date: Wed, 11 Apr 2012 13:29:15 -0700
Subject: [sf-perl] Real perl
In-Reply-To: <CAMEJyisafe0LRsVwCk-tEcTnAL6Dzw2z5xCBa-z6ZxE2GKr4Lg@mail.gmail.com>
References: <8B1E4BD3-6B57-48D3-9BAB-DFF294C9AD37@gmail.com>
	<86mx6jmhf3.fsf@red.stonehenge.com>
	<59363445-A959-4CFB-8FF9-907BB8A143AE@gmail.com>
	<CAMEJyisafe0LRsVwCk-tEcTnAL6Dzw2z5xCBa-z6ZxE2GKr4Lg@mail.gmail.com>
Message-ID: <0EB1255B-3A75-4885-B0C5-4C8A20A77A29@gmail.com>

Yup yup! That trade-off is also part of why I enjoy building my own abstraction layers. I can keep them slick and only doing what I need, expanding them if need be, and make them work for the way I think. And I can optimise them for their tasks. 

Not to mention that sometimes abstraction layers fail not only in not doing what they are supposed to, but in abstraction itself. 

An example of this outside of Perl I could make is an XHR with a callback function compared between a direct JavaScript XHR construction and using the prototype library.

 Me, I will happily do the stuff manually. Since I've already got a "getUA" function to handle the "IE walks its own stupid path" problem with setting up the XHR object in the first place, it only requires one more line of code than the Prototype.Ajax object--the one where I check if the state is "4"--and it's not prone to dying if some other library is used at the same time. But mostly because with the rest of the stuff I'd have to declare, it can actually take more code to use Prototype. 

The other way they can fail is by simy not being abstracted in a way that suits me. Using that same example, and having coded in Perl for 17 years, I'm used to the LWP approach, and an appropriate XHR abstraction for me would take this into account and try to act similarly. Someone used to the PHP curl interface however might want a whole different way of doing things. 

Again, I have no beef with Moose. If it gets the job done for other people more power to them. But I actually think perlishly and to me Moose is not very perly and so doesn't help me. 

I was just interested in starting some conversation on something that isn't Moose because all I seem to see on lists anymore is Moose this and Moose that. 

It's like trying to find a discussion on Ruby. Without Rails. 

-- 
Dodger

Sent from my iPhone

On 11/04/2012, at 11:39 AM, Paul Makepeace <Paul.Makepeace at realprogrammers.com> wrote:

> On Wed, Apr 11, 2012 at 03:33, Dodger <el.dodgero at gmail.com> wrote:
>> I might also actually like knowing intrinsically how what I have made works.
> 
> Writing software is a discipline where there's a level of abstraction
> where everything just goes black (box). It might be at "CPAN modules"
> it might be at "Perl source code" it might be at "libc implementation"
> it might be at "kernel scheduler" it might be at "filesystem device
> driver" it might be at "L2 cache microcode" and so on down to particle
> physics. At some point you stop caring and just trust it works.
> 
> IMO generally the higher level that is the more you can get done, and
> those times when trust breaks down (i.e. an abstraction isn't
> fulfilling its published contract) are the relatively fewer times you
> ever have to care what's beneath the black.
> 
> That said, nothing wrong with liking knowing, it's just probably not
> going to get as much made in the long run :)
> 
> Paul

From el.dodgero at gmail.com  Wed Apr 11 13:35:14 2012
From: el.dodgero at gmail.com (Dodger)
Date: Wed, 11 Apr 2012 13:35:14 -0700
Subject: [sf-perl] Go Pinto [Was: Real perl]
In-Reply-To: <CAD--fz63SHk68+FdtpCFfVKE9YQRD-pMDs_MCP9OJyJxbzAHgg@mail.gmail.com>
References: <8B1E4BD3-6B57-48D3-9BAB-DFF294C9AD37@gmail.com>
	<CAJ4sp-V=VP=Ti=ivt9Ry7r2EqapRpE1fZfim-fdT8hRMom3_hQ@mail.gmail.com>
	<4B1B79B0-1707-4C9A-A826-CD4E5C09019A@imaginative-software.com>
	<CAJ4sp-XnVC6wBV+n6ituXrgpin_4EO=cGL2OH=O2marc4-UOyA@mail.gmail.com>
	<CAD--fz63SHk68+FdtpCFfVKE9YQRD-pMDs_MCP9OJyJxbzAHgg@mail.gmail.com>
Message-ID: <F887290A-AC11-425E-9653-1BA0E2426A04@gmail.com>

Agreed. That stuff is the biggest turn-off for me with Ruby, and I've just been concerned about Moose becoming our very own Rails (in the sense of it being impossible to find one without the other, not in what they do).

-- 
Dodger

Sent from my iPhone

On 11/04/2012, at 7:57 AM, Dana Diederich <diederich at gmail.com> wrote:

> Thank you Jeff, very well said.  I believe the greatest historical strength of the Perl community has been a real resistance to binary thinking.  I do truly hope that continues.
> 
> Cheers,
> -Dana
> 
> 2012/4/11 Jeff Bragg <jackofnotrades at gmail.com>
> ... 
> I feel like the Perl community is becoming pretty damned opinionated; in my view TMTOWTDI does not just mean that there's a "right" way and a "wrong" way (that kind of binary thinking is for other language communities).
> 
> 
> On Tue, Apr 10, 2012 at 9:59 PM, Jeffrey Thalhammer <jeff at imaginative-software.com> wrote:
> 
> On Apr 10, 2012, at 4:19 PM, Jeff Bragg wrote:
> 
>> I've used Moose, and found it to be very nice, especially in comparison to old-school Perl OO.  However, it usually seems like overkill for my purposes (and perhaps a violation of the KISS principle).  I'm sure it has a lot to do with context; I'm generally doing systemsy, back-end stuff, and prefer to minimize my dependencies and assumptions about deployment environment.
> 
> Then please allow me to use this opportunity to make a shameless plug for Pinto.
> 
> IMHO, dependency avoidance is a weak excuse for doing things the hard way (and usually the wrong way).  But installing stuff from the public CPAN is a lottery because you never know exactly which versions you are going to get.  And if you want to lock down those versions with a private CPAN, it is a fair bit of work to manage.  So dependency-phobia lives on.
> 
> Pinto aims to fix all that.  Pinto makes it super easy to construct a custom repository of CPAN distributions (including your own private ones) and organically evolve your dependencies over time.  So now all that "systemsy back-end stuff" can leverage anything and everything on CPAN, and you've got a solid, reproducible mechanism for building, testing, and deploying it.
> 
> -Jeff
> 
> 
> _______________________________________________
> SanFrancisco-pm mailing list
> SanFrancisco-pm at pm.org
> http://mail.pm.org/mailman/listinfo/sanfrancisco-pm
> 
> 
> _______________________________________________
> SanFrancisco-pm mailing list
> SanFrancisco-pm at pm.org
> http://mail.pm.org/mailman/listinfo/sanfrancisco-pm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/sanfrancisco-pm/attachments/20120411/b1eefba4/attachment.html>

From fred at redhotpenguin.com  Wed Apr 11 18:34:55 2012
From: fred at redhotpenguin.com (Fred Moyer)
Date: Wed, 11 Apr 2012 18:34:55 -0700
Subject: [sf-perl] Nordic Perl Workshop announced
Message-ID: <CAHrynWBz56EdyyAreRQXX5GiHAnXvjMO47U9OkkGJWOsx-6CLg@mail.gmail.com>

I've been to two of these. Highly recommended.

http://act.yapc.eu/npw2012/

From merlyn at stonehenge.com  Wed Apr 11 22:59:06 2012
From: merlyn at stonehenge.com (Randal L. Schwartz)
Date: Wed, 11 Apr 2012 22:59:06 -0700
Subject: [sf-perl] Real perl
In-Reply-To: <05EA67B3-90AA-455E-9731-AC76225B845E@cfcl.com> (Rich Morin's
	message of "Tue, 10 Apr 2012 17:24:36 -0700")
References: <8B1E4BD3-6B57-48D3-9BAB-DFF294C9AD37@gmail.com>
	<86mx6jmhf3.fsf@red.stonehenge.com>
	<CAHrynWCswOCwiXzaUwf75b=-LY_+w48ZkX9LN=CcX053ADK+3A@mail.gmail.com>
	<05EA67B3-90AA-455E-9731-AC76225B845E@cfcl.com>
Message-ID: <86pqbdlcd1.fsf@red.stonehenge.com>

>>>>> "Rich" == Rich Morin <rdm at cfcl.com> writes:

Rich> Although I'm delighted to see most Perlies accept Moose as the "normal"
Rich> way to do OO, not all scripts have enough complexity to justify OO (or
Rich> even functions, in some cases :-).

Yes, sorry for being brief there.  I don't think of small scripts any
more... I think only of larger applications.

And for those, Moose is now the *first* thing I reach for.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn at stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.posterous.com/ for Smalltalk discussion

From merlyn at stonehenge.com  Wed Apr 11 23:00:04 2012
From: merlyn at stonehenge.com (Randal L. Schwartz)
Date: Wed, 11 Apr 2012 23:00:04 -0700
Subject: [sf-perl] Real perl
In-Reply-To: <CF3ACE1E-FA25-4F67-B5C2-F3E13E189163@gmail.com> (Dodger's
	message of "Wed, 11 Apr 2012 03:38:26 -0700")
References: <8B1E4BD3-6B57-48D3-9BAB-DFF294C9AD37@gmail.com>
	<DA27D1D3-05A2-4854-8F09-45937A10CB5A@imaginative-software.com>
	<CF3ACE1E-FA25-4F67-B5C2-F3E13E189163@gmail.com>
Message-ID: <86lim1lcbf.fsf@red.stonehenge.com>

>>>>> "Dodger" == Dodger  <el.dodgero at gmail.com> writes:

Dodger> sub AUTOLOAD {}

Dodger> Who writes accessors?

Until you get bitten by that... sure.  I have too many scars from
hand-rolled AUTOLOADs interacting badly with other belly-button
introspection systems.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn at stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.posterous.com/ for Smalltalk discussion

From fred at redhotpenguin.com  Thu Apr 12 18:54:13 2012
From: fred at redhotpenguin.com (Fred Moyer)
Date: Thu, 12 Apr 2012 18:54:13 -0700
Subject: [sf-perl] Whack your Perl code
In-Reply-To: <CAFzRDhBHx7d+q_hcP9F7X3K284UBwUPP4nk_ss-Z2ursAAFWqQ@mail.gmail.com>
References: <CAFzRDhBHx7d+q_hcP9F7X3K284UBwUPP4nk_ss-Z2ursAAFWqQ@mail.gmail.com>
Message-ID: <CAHrynWBqjVC+rt6bUR9YpLmBY0Q3efvT6Xa3ZzQYpHKkJdMwWQ@mail.gmail.com>

On Thu, Apr 12, 2012 at 6:07 PM, matthew wickline <matthew at wickline.org> wrote:
>> Refactoring without business goals can cause
>> problems more often than not I've found.
>
> and then there are the cases where some very complicated piece of code
> has been given the "minimal working edit" so often because nobody
> wants to risk a refactor when not strictly needed. Eventually you can
> end up with subroutines thousands of lines long with loops/conditions
> up to a dozen layers deep. I've seen them. I've heard about them from
> others. There is never a task which in and of itself warrants
> re-writting such behemoths. Eventually you see enough buggy
> implementations from folks failing to grok the giant sub that you
> decide that there is business value in re-writting it for the sake of
> making it easier to maintain and modify in the future.

I've written them myself, it happens sometimes even when I strive to
keep things simple. I ran whack.pl on some of my code and it picked
those subroutines out accurately.

I agree there's business value in refactoring code like that. My
previous email may have come across as anti-refactoring
unintentionally, but I was attempting to convey that I've found it
useful to define my goals when refactoring code. I've found with my
own code that going in and 'cleaning up' things (not tidy or critic
compliance efforts) doesn't always add value to it.


> If you're not working in code old enough, of sufficient scope, and/or
> worked on by folks with sufficient range of experience to have these
> sorts of problems, then consider yourself blessed that you don't need
> to whack it :)

From fred at redhotpenguin.com  Fri Apr 13 12:23:49 2012
From: fred at redhotpenguin.com (Fred Moyer)
Date: Fri, 13 Apr 2012 12:23:49 -0700
Subject: [sf-perl] HipChat notifier in Perl
Message-ID: <CAHrynWCRXetmSDnnfrg8GvvPWa5m+iurJ-oVbxbGk4H3fNp86g@mail.gmail.com>

This looks like a good way to push svn commit diffs to HipChat. I
personally haven't used HipChat but have heard a lot of good things
about it.

http://blogs.perl.org/users/jason_a_crome/2012/04/simple-hipchat-notifier.html

From doomvox at gmail.com  Mon Apr 16 15:26:51 2012
From: doomvox at gmail.com (Joseph Brenner)
Date: Mon, 16 Apr 2012 15:26:51 -0700
Subject: [sf-perl] request for speakers (moose-heads, moose-haters, ... ? )
Message-ID: <CAFfgvXWHVVu92ceVHm9rniqcdar2j_hCrxaS=hNE93qSJkAcTg@mail.gmail.com>

I just thought I'd ask if anyone's interested in doing a talk at one
of the upcoming perl meetings (you know, 4th Tuesdays).

A moose-heads/moose-haters smackdown could be fun...

From fred at redhotpenguin.com  Thu Apr 19 21:34:18 2012
From: fred at redhotpenguin.com (Fred Moyer)
Date: Thu, 19 Apr 2012 21:34:18 -0700
Subject: [sf-perl] Fwd: You've scheduled: Hackathon
In-Reply-To: <1891830610.1334896318057.JavaMail.nobody@app20.meetup.com>
References: <1891830610.1334896318057.JavaMail.nobody@app20.meetup.com>
Message-ID: <CAHrynWARuHaEU-Wo1HTp58-w0eAJPa0v9AhJNm3Xr-0HDOU1AA@mail.gmail.com>

The April meeting will be a hackathon next Tuesday at 7pm at Muddy's
on Valencia. Bring your laptops!

http://www.meetup.com/San-Francisco-Perl-Mongers/events/61368142/

Tuesday, April 24, 2012
at 7:00 PM
Muddy's Coffee House
1304 Valencia Street
San Francisco, CA 94110

---------- Forwarded message ----------
From: Meetup <info at meetup.com>
Date: Thu, Apr 19, 2012 at 9:31 PM
Subject: You've scheduled: Hackathon
To: fred at redhotpenguin.com




You're confirmed!
Hackathon
Your Meetup has been scheduled!

Fred Moyer
San Francisco Perl Mongers

Tuesday, April 24, 2012
at 7:00 PM
Muddy's Coffee House
1304 Valencia Street
San Francisco, CA 94110
Directions


Add info at meetup.com to your address book to receive all Meetup emails

To unsubscribe from emails like these, click here

Meetup, PO Box 4668 #37895 New York, New York 10163-4668

Meetup HQ in NYC is hiring! http://www.meetup.com/jobs/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: meetup.ics
Type: text/calendar
Size: 1234 bytes
Desc: not available
URL: <http://mail.pm.org/pipermail/sanfrancisco-pm/attachments/20120419/4944510c/attachment.bin>

From fred at redhotpenguin.com  Thu Apr 19 21:36:49 2012
From: fred at redhotpenguin.com (Fred Moyer)
Date: Thu, 19 Apr 2012 21:36:49 -0700
Subject: [sf-perl] You've scheduled: Hackathon
In-Reply-To: <CAHrynWARuHaEU-Wo1HTp58-w0eAJPa0v9AhJNm3Xr-0HDOU1AA@mail.gmail.com>
References: <1891830610.1334896318057.JavaMail.nobody@app20.meetup.com>
	<CAHrynWARuHaEU-Wo1HTp58-w0eAJPa0v9AhJNm3Xr-0HDOU1AA@mail.gmail.com>
Message-ID: <CAHrynWCqwS6LNEsi-8tp2mowVMsF_DrKAy5RMFv8cx0USE=+rw@mail.gmail.com>

Whoops, that was supposed to be plain text. Apologies if a .ics
attachment came through. Nothing nefarious, just Gmail trying to be
helpful.

On Thu, Apr 19, 2012 at 9:34 PM, Fred Moyer <fred at redhotpenguin.com> wrote:
> The April meeting will be a hackathon next Tuesday at 7pm at Muddy's
> on Valencia. Bring your laptops!
>
> http://www.meetup.com/San-Francisco-Perl-Mongers/events/61368142/
>
> Tuesday, April 24, 2012
> at 7:00 PM
> Muddy's Coffee House
> 1304 Valencia Street
> San Francisco, CA 94110
>
> ---------- Forwarded message ----------
> From: Meetup <info at meetup.com>
> Date: Thu, Apr 19, 2012 at 9:31 PM
> Subject: You've scheduled: Hackathon
> To: fred at redhotpenguin.com
>
>
>
>
> You're confirmed!
> Hackathon
> Your Meetup has been scheduled!
>
> Fred Moyer
> San Francisco Perl Mongers
>
> Tuesday, April 24, 2012
> at 7:00 PM
> Muddy's Coffee House
> 1304 Valencia Street
> San Francisco, CA 94110
> Directions
>
>
> Add info at meetup.com to your address book to receive all Meetup emails
>
> To unsubscribe from emails like these, click here
>
> Meetup, PO Box 4668 #37895 New York, New York 10163-4668
>
> Meetup HQ in NYC is hiring! http://www.meetup.com/jobs/

From not.com at gmail.com  Fri Apr 20 05:45:06 2012
From: not.com at gmail.com (yary)
Date: Fri, 20 Apr 2012 08:45:06 -0400
Subject: [sf-perl] Moose, mouse, cpanm long story
Message-ID: <CAG2CFAZ7ZiAF11Ytoj+F6_bG4q_tCE+22jTb+HbDX6VPc-4Pew@mail.gmail.com>

Around the time the various Moose threads started I was faced with a
medium-ish sized Perl project at work. Most of the perl projects
before were small or started small and grew to medium, and weren't
object-oriented in any way. This project would benefit from OO
structure, so I dove in and used Moose.

The time saved from writing and re-writing bits of setup and checking
code made up the learning curve within the first week. Its constraint
checking found some errors quickly that would have had me sprinkling
printfs or using the debugger otherwise. It's made it easy to focus on
what my code needs to do and worry less about the mechanics of fitting
the pieces together.

That said, I fibbed a bit. I'm using Mouse, not Moose. This is a
command-line tool where startup time matters, also it needs to be
installed on machines behind strict firewalls where we don't have many
privileges. In fact at the time the project started, I couldn't even
be sure what version of perl was on the target host or if it had any
compiler tools available. Using any non-core modules meant downloading
them somewhere else and scp'ing them over, only pure-perl acceptable.

Mouse has no dependencies and has a pure-perl version, and it worked
perfectly from start to finish during development. I was wary of their
warning "if you see strange errors, use Moose" and kept watch for each
new bit of Mouse I used, but it solidly did what the docs said it
would. Perhaps that warning was for users of the various Mo[ou]seX
modules on top of Mouse.

That said, I fibbed a bit. The dev machine has the cpan client
installed and the firewall does let cpan load modules via ftp. By
using local::lib and fatpacker (scp'd over) I was able to have cpan
build modules in the home directory, and then I could put the
essential bits into the project's "lib". I did that for Mouse.

What I didn't realize until I deployed my project to the hitherto
mystery production box was that cpan had built Mouse with the
compiled-C XS backend on the dev box. And the production machine has
perl 5.8.8 but the dev has perl 5.8.7 so that compiled back-end won't
work in both places. "No problem," I think, "I'll just have Mouse use
its pure-perl backend". I remove the deployed Mouse files from the lib
tree (including the object file hiding in "auto"), build Mouse with
Pure::Perl from source- just a couple commands inside the unzipped
source dir- put it in place, and test my app.

Oops, there are some strange errors. Or rather non-errors, the code
runs but stops without producing any output in one simple test. Is
this what that warning was about? Perhaps the Mouse developers worked
out all the kinks in the C/XS version and didn't port those fixes back
into the Pure-Perl version.

"No problem," I think, "cpan will rebuild it for me on the production
box too"- only the compiler chain is also different on the prod box,
and the it can't compile Mouse's C code. I'm fine with C, learned that
before Perl, but I don't have time to dive into it. I don't think I
mentioned that deploying to the prod box was happening the morning of
a demo that was that afternoon, and I also had received a directory
full of sample files that morning that had to be used in this demo.

Now, I had heard of cpanm ("cpan-minus") many times, and was a cpanm
skeptic. I have always had success installing modules with the cpan or
cpanp ("cpan-plus") clients. But then, that was mostly on my own
machines, and here I was in a situation where I could not install the
Mouse I needed, not from pure source nor from cpan, and had no time to
fiddle with settings. I scp'd the standalone "cpanm" perl program,
pointed it at the Mouse working directory cpan had started- and cpanm
built it, compiling the C backend, on the first try. So now I'm a
convert... though I will save it for the sticky cases.

I fibbed a bit. That error from the pure-perl Mouse? I'm not sure it
was Mouse's fault after all. This work project talks to a SQL
command-line tool, which is also different versions on the dev and
production machines. The versions differ subtly in both the way they
get the password and the way they report errors, so I had to figure
those out, and make my code do something both versions accepted.

phew. That's that for now... I do have some more thoughts on Moose,
and some questions on how to best structure a part of my code, maybe a
little later.

-y
ps. Dev & deployment has been on locked-down Solaris boxes. Eventually
these will also run on Windows boxes using ActiveState perl, with far
more "core" modules pre-installed, and I've been able to update
existing modules/add new ones with "ppm"- so cpan[m] is not an issue
there.

pps. Sorry to join in the Moose-ish conversations late. It seems there no
 $time !~ /work|home/

From doom at kzsu.stanford.edu  Fri Apr 20 10:46:08 2012
From: doom at kzsu.stanford.edu (Joseph Brenner)
Date: Fri, 20 Apr 2012 10:46:08 -0700
Subject: [sf-perl] Moose, mouse, cpanm long story
In-Reply-To: <CAG2CFAZ7ZiAF11Ytoj+F6_bG4q_tCE+22jTb+HbDX6VPc-4Pew@mail.gmail.com>
References: <CAG2CFAZ7ZiAF11Ytoj+F6_bG4q_tCE+22jTb+HbDX6VPc-4Pew@mail.gmail.com>
Message-ID: <CAFfgvXVDbJ13J8vRVzmg=hjSamMf5ciKsvEO_ggTxstAKVq1CA@mail.gmail.com>

 yary <not.com at gmail.com> wrote:

> The time saved from writing and re-writing bits of setup and checking
> code made up the learning curve within the first week. Its constraint
> checking found some errors quickly that would have had me sprinkling
> printfs or using the debugger otherwise.

I haven't had that experience yet... I'm still a little skeptical
about the constant type checking everywhere.  But then, I like the
data validation features of relational databases, so this could just
be one of my little hypocrisies.

(Wouldn't it be nice to be be able to flip-off the type checking when
in production?  But that's such an obvious idea, some one must have
done something like that already.)

> [...] also it needs to be
> installed on machines behind strict firewalls where we don't have many
> privileges. In fact at the time the project started, I couldn't even
> be sure what version of perl was on the target host or if it had any
> compiler tools available.

I have a theory that a lot of the gods of perl don't quite grasp the
locked-down conditions a lot of us have to make do with.  These days
their answer to everything is "let them eat cpan", but it's not always
that simple.

> Now, I had heard of cpanm ("cpan-minus") many times, and was a cpanm
> skeptic. I have always had success installing modules with the cpan or
> cpanp ("cpan-plus") clients. But then, that was mostly on my own
> machines, and here I was in a situation where I could not install the
> Mouse I needed, not from pure source nor from cpan, and had no time to
> fiddle with settings. I scp'd the standalone "cpanm" perl program,
> pointed it at the Mouse working directory cpan had started- and cpanm
> built it, compiling the C backend, on the first try. So now I'm a
> convert... though I will save it for the sticky cases.

Pretty much the same with me.  I can deal with getting CPAN.pm or
CPANPLUS.pm set-up, so what's the big deal with cpan-minus?  But when
you don't own the box, and you're in a hurry to get something working,
cpanm comes to the rescue.

By the way, one thing I think we have to thank cpan-minus for is that
I think it shamed the CPAN.pm maintainers into making the setup more
automagical.  The last time I did it, it seemed a lot eaisier.

> pps. Sorry [not] to join in the Moose-ish conversations late. It seems there no
> ?$time !~ /work|home/

Yes, I've been feeling the same.  I'm the one who got a lot of it
started, but my replies have been sketchy at best.

(It doesn't help that I gave that lightning talk about "rep.el".  Now
I'm trying to get Emacs::Rep version 0.8 working right... emacs data
structures *still* strike me as a horrible pain to work with.)

From doomvox at gmail.com  Fri Apr 20 10:55:49 2012
From: doomvox at gmail.com (Joseph Brenner)
Date: Fri, 20 Apr 2012 10:55:49 -0700
Subject: [sf-perl] Moose, mouse, cpanm long story
In-Reply-To: <CAFfgvXVDbJ13J8vRVzmg=hjSamMf5ciKsvEO_ggTxstAKVq1CA@mail.gmail.com>
References: <CAG2CFAZ7ZiAF11Ytoj+F6_bG4q_tCE+22jTb+HbDX6VPc-4Pew@mail.gmail.com>
	<CAFfgvXVDbJ13J8vRVzmg=hjSamMf5ciKsvEO_ggTxstAKVq1CA@mail.gmail.com>
Message-ID: <CAFfgvXWRX-APogHxxD_W0mH0V20euw+2m8=jSJKgdS-yRkPkBQ@mail.gmail.com>

Joseph Brenner <doom at kzsu.stanford.edu> wrote:

> (Wouldn't it be nice to be be able to flip-off the type checking when
> in production? ?But that's such an obvious idea, some one must have
> done something like that already.)

Apparently not quite yet, though they're working on it:

http://perl.enstimac.fr/perl5.8.5/site_perl/5.8.5/Moose/Cookbook/FAQ.html#can_i_turn_off_type_constraint_checking

   Can I turn off type constraint checking?

   Not yet, but soon. This option will likely be coming in the next release.

From greg at blekko.com  Mon Apr 23 13:31:16 2012
From: greg at blekko.com (Greg Lindahl)
Date: Mon, 23 Apr 2012 13:31:16 -0700
Subject: [sf-perl] SVPerl: Message Passing (May 3)
Message-ID: <20120423203116.GK13160@bx9.net>

http://www.meetup.com/SVPerl/events/57859822/

Dana Diederich of LiveOps will be leading a discussion about an
unusual method of message based programming in Perl. In the spirit of
TIMTOWTDI (There Is More Than One Way To Do it), Dana will be
presenting a new CPAN module that implements message passing using a
venerable but still relevant mechanism. Key features of this
methodology include seamless multi-processing without threads,
clustering and highly scalable systems. The well-known and excellent
POE module will also be lightly covered.

Plug & Play Tech Center
440 North Wolfe Road, Sunnyvale, CA
Thursday, May 3, 7pm

From doom at kzsu.stanford.edu  Mon Apr 23 14:44:46 2012
From: doom at kzsu.stanford.edu (Joseph Brenner)
Date: Mon, 23 Apr 2012 14:44:46 -0700
Subject: [sf-perl] hackfest tomorrow night
Message-ID: <CAFfgvXVzgyRs+-GdCD2jHo-pvVK824i0G0Pj==pL7REgjWVb1w@mail.gmail.com>

As I'm sure y'all have heard, we've got a "hackfest" coming up tomorrow night:
  http://www.meetup.com/San-Francisco-Perl-Mongers/events/61368142/?a=cr1_grp&rv=cr1&_af_eid=61368142&_af=event

This one is at a new location for us, so I'm being anal about
underlining where it is: this is "Muddys" on Valencia Street, at the
corner of 24th Street.   It's close to the 24th Street BART stop, just
down the hill from Noe Valley along the 48 bus route:

   http://g.co/maps/av5wp

'Tis not to be confused with the similar place on Valencia, with a
similar name,  up by 16th Street.

Muddys has some serious coffee (a dark French Roast, though without
the burned/carmelized flavor the Four Barrel fans are into), and it
has some pretty serious chocolate cake, but if you're in need of food
I'd suggest getting a burrito from Papalote's around the corner (or
from one of the less slick, but more authentic Mission and 24th
places, like Taco Loco or El Farralito's).  Muddys is relaxed enough
that no one is going to care if you bring some food in with you.

We don't really have a particular theme in mind for this one, though
if anyone wants to suggest one, feel free.

From doomvox at gmail.com  Tue Apr 24 20:58:18 2012
From: doomvox at gmail.com (Joseph Brenner)
Date: Tue, 24 Apr 2012 20:58:18 -0700
Subject: [sf-perl] appy poly oggies
Message-ID: <CAFfgvXUPZ6DoREfbiAYcDsHmXhyKLOJz7dGbuGeqo7BuAzktXQ@mail.gmail.com>

Just wanted to apologize to anyone who showed up at Muddys tonight
looking for the hackfest.
It sounds like Fred was sick tonight, and I missed the train I needed
to be on to get there (I'm commuting up from Sunnyvale at present).
By the time I got there everyone had given up already and left.

From doom at kzsu.stanford.edu  Tue Apr 24 21:14:08 2012
From: doom at kzsu.stanford.edu (Joseph Brenner)
Date: Tue, 24 Apr 2012 21:14:08 -0700
Subject: [sf-perl] appy poly oggies
Message-ID: <CAFfgvXUFhCtdq_-x=gPZW-pwqdk7JvZk6iNcVEpaNG0bNWuN5g@mail.gmail.com>

Just wanted to apologize to anyone who showed up at Muddys tonight
looking for the hackfest.

It sounds like Fred was sick tonight, and I missed the train I needed
to be on to get there (I'm commuting up from Sunnyvale at present).
By the time I got there everyone had given up already and left.

From not.com at gmail.com  Thu Apr 26 10:30:28 2012
From: not.com at gmail.com (yary)
Date: Thu, 26 Apr 2012 13:30:28 -0400
Subject: [sf-perl] Pure perl Moose
Message-ID: <CAG2CFAYaKEvymfGTwJpPh5bDWRzY6UV9M5c112wQju1jFBzCwA@mail.gmail.com>

Hi folks,

I see references to Moose being pure-Perl, but I don't see any
instructions on builiding & installing the PurePerl variation. Anyone
here have any ideas/tips?

I have been manually building its dependencies, which have both
PurePerl and XS versions, with some success, but have reached a point
where Moose is asking for Class::Load::XS even though I have
Class::Load::PP installed.

As an FYI,, I started with building Mouse (not Moose) as a Pure Perl
variant and it mostly worked, but alas, the MouseX::NativeAttributes
gave those "strange errors' with Mouse::PP that didn't happen with
Mouse::XS. Which made me want to try the Pure Perl Moose. And if
someone were to say "Moose used to work in pure perl, but now has XS/C
dependencies," I would reply, "Point me to the latest Moose that was
Pure Perl." This code is only making use of the basic Moose bits, it
is fine with Mouse::XS, and it does not need to be the latest &
greatest.

Thanks

-y

From swartz at pobox.com  Thu Apr 26 10:38:36 2012
From: swartz at pobox.com (Jonathan Swartz)
Date: Thu, 26 Apr 2012 10:38:36 -0700
Subject: [sf-perl] Pure perl Moose
In-Reply-To: <CAG2CFAYaKEvymfGTwJpPh5bDWRzY6UV9M5c112wQju1jFBzCwA@mail.gmail.com>
References: <CAG2CFAYaKEvymfGTwJpPh5bDWRzY6UV9M5c112wQju1jFBzCwA@mail.gmail.com>
Message-ID: <30CBF246-41D8-48A4-AD08-8DD0060C7536@pobox.com>

I think references to Moose being pure perl - like this http://www.linuxjournal.com/content/moose - generally mean that its syntax is built on top of Perl, rather than being an extension to the Perl core.

Moose is definitely not pure perl in the sense of "doesn't need a compiler", since it depends on Class::MOP which uses XSLoader. And a good thing, too, we don't want it to be pure-perl from a performance perspective. Hopefully more of it will end up in XS over time as it stabilizes.

On Apr 26, 2012, at 10:30 AM, yary wrote:

> Hi folks,
> 
> I see references to Moose being pure-Perl, but I don't see any
> instructions on builiding & installing the PurePerl variation. Anyone
> here have any ideas/tips?
> 
> I have been manually building its dependencies, which have both
> PurePerl and XS versions, with some success, but have reached a point
> where Moose is asking for Class::Load::XS even though I have
> Class::Load::PP installed.
> 
> As an FYI,, I started with building Mouse (not Moose) as a Pure Perl
> variant and it mostly worked, but alas, the MouseX::NativeAttributes
> gave those "strange errors' with Mouse::PP that didn't happen with
> Mouse::XS. Which made me want to try the Pure Perl Moose. And if
> someone were to say "Moose used to work in pure perl, but now has XS/C
> dependencies," I would reply, "Point me to the latest Moose that was
> Pure Perl." This code is only making use of the basic Moose bits, it
> is fine with Mouse::XS, and it does not need to be the latest &
> greatest.
> 
> Thanks
> 
> -y
> _______________________________________________
> SanFrancisco-pm mailing list
> SanFrancisco-pm at pm.org
> http://mail.pm.org/mailman/listinfo/sanfrancisco-pm


From not.com at gmail.com  Thu Apr 26 11:18:32 2012
From: not.com at gmail.com (yary)
Date: Thu, 26 Apr 2012 14:18:32 -0400
Subject: [sf-perl] Pure perl Moose
In-Reply-To: <30CBF246-41D8-48A4-AD08-8DD0060C7536@pobox.com>
References: <CAG2CFAYaKEvymfGTwJpPh5bDWRzY6UV9M5c112wQju1jFBzCwA@mail.gmail.com>
	<30CBF246-41D8-48A4-AD08-8DD0060C7536@pobox.com>
Message-ID: <CAG2CFAZGL48zW9YfJzcWTiM=6BFjEoWGdvzBA6jCHtZTRNamtA@mail.gmail.com>

On Thu, Apr 26, 2012 at 1:38 PM, Jonathan Swartz <swartz at pobox.com> wrote:
> I think references to Moose being pure perl - like this http://www.linuxjournal.com/content/moose - generally mean that its syntax is built on top of Perl, rather than being an extension to the Perl core.
>
> Moose is definitely not pure perl in the sense of "doesn't need a compiler", since it depends on Class::MOP which uses XSLoader. And a good thing, too, we don't want it to be pure-perl from a performance perspective. Hopefully more of it will end up in XS over time as it stabilizes.

It seems it once was pure perl in the "non-XS" sense, based on things
like notes in Moose's "Changes" document, for example-

    0.66 Sat September 20, 2008
    ..
    introspection of a class's method with Class::MOP::Class

      Tests and XS
        We (us maintainers) now run all tests with XS and then without
XS, which should help us catch skew between the XS/pure Perl code.
(Dave Rolsky)


Not sure how much longer I will look down this path, I would like to
see which way it leads reagardless.