Hi,

Moose is new to me (and perhaps to others on this list).
Since Moose is already baked in to the core Perl AppEngine code,
it would perhaps be nice to do some Moose evangelism here to
bring the rest of us up to speed.

[Questions]
Why was Moose chosen by the developers of protobuf-perl and perl-appengine?
What are the alternatives to Moose? (i.e. what are the competing
solutions for what it tries to do?)
I see that Moose got a subdomain on perl.org (http://moose.perl.org).
What Perl luminaries have endorsed Moose?

For further reading,

  * http://www.iinteractive.com/moose/
  * http://search.cpan.org/~sartak/Moose/lib/Moose.pm
  * http://search.cpan.org/~sartak/Moose
  * http://search.cpan.org/~sartak/Moose/lib/Moose/Cookbook.pod
  * http://blog.jrock.us/articles/Myth:%20Moose%20is%20an%20unnecessary%2...

Stephen

On Thu, Aug 28, 2008 at 4:35 PM, Jonathan Rockway

...

Well, I am biased (since i am the original author), but I will try and
help answer your questions:

I spoke with brad at OSCON about this, as to why he made the final
decision I cannot say, however he asked a lot of very detailed
questions and then worked with Yuval Kogman (another core Moose dev)
over the next few days, so the decision was not made lightly, he had
plenty of information to go on.

There really are none, not complete ones anyway. Moose provides a full
and complete object system and a rich underlying MOP (Meta Object
protocol), previously you could only get something kind of close by
combining several CPAN modules and some hand-written glue.

Now, that said, if you only use a small subset of Moose, then there
are alternatives out there. But going this route means that at some
point you hit a ceiling with what your system can do for you. With
Moose when you hit that ceiling, you can (quite often) break right
through it by diving into the MOP and extending the system for your
needs.

Now, it has been argued that some of the meta-level stuff that Moose
provides can be done with symbol table hacking and the like. This is
100% true, but anyone who has done enough symbol table hacking will
know that it has a fragility to it and certainly should not be done by
the less experienced. Moose provides an API over all that stuff, and
hides a lot of the ugly fragility as well, making it easy for the
experienced hacker and much less dangerous for those less
experienced.

Yes, I just asked Ask and Robert and got it, it is not special mark of
acceptance or endorsement.

Well, we do not seek endorsements, nor do I think that is relevant.
The Moose community has been steadily growing over the last 2 years
and many people have contributed to the project both directly (with
code) and indirectly (as members of the community). IMO it matters
very little if a perl "luminary" uses something, and matters more if
the community behind it is solid, stable and growing.

That said, I can tell you some well known and well respected (at least
by me) perl hackers who have spoken well of Moose and/or use Moose on
some level. These should be in no way seen as "endorsements" though,
only observations made by me regarding the people listed below.

- Larry Wall currently uses it in his Perl 6 on Perl 5 scripts, and he
has mentioned it in the last couple State of the Onion addresses.
- Randal Schwartz wrote some nice articles about Moose and shows up on
the #moose channel regularly, not sure how much he uses it though
since he seems more focused on Smalltalk these days.
- Tim Bunce spoke very highly of Moose in his "Perl Myths" talk, and
there was once talk that DBI v2 would use Moose. Although I don't know
if he uses it personally or if that DBI v2 talk went anywhere.
- Matt Trout (Catalyst, DBIx::Class) has used Moose from version 0.01
and has been a key figure in the Moose community all along.
- Dave Rolsky (DateTime, Mason, Albazo, etc) uses Moose heavily and
actually is now a core developer.
- Max Kanat-Alexander (Bugzilla) uses Moose regularly and in fact,
credits Moose with him staying with Perl for Bugzilla.
- Ricardo Signes (Email::* is his burden to carry) uses Moose pretty
regularly and contributes much good discussion on #moose.
- CLKao (svk, Best Practical) is a big Moose fan and in fact was one
of the people who pushed Brad my way at OSCON
- Jesse Vincent (RT, Best Practical) has been a major force lately in
pushing for better performance in Moose and has been a huge help by
providing us with NYTProf output for their Moose based app.

There are plenty others too (sorry guys/gals, this doesnt mean I don't
respect or know you)  but I need to go take the dog for a walk and he
is not willing to wait for me to list them.

But in the end, if you don't want to use Moose for your project, it is
your decision. But I suggest you put aside the FUD and try it out.
Issues like speed and startup time are solvable problems, you only
need to compare a version of Moose from 1 year ago with Moose today to
see the strides already made.

Okay, my dog is getting impatient (http://skitch.com/stevan/q5f8/
cam-12-1) so I must go.

- Stevan

Speaking for myself, I started using Moose a month ago for the first time,
and am actively using it in several projects.

One of those projects is a complete Perl-implemented object-relational DBMS
and programming language; and the DBMS (Muldis::Rosetta) is functionally
another kind of "app engine" if you will.  Another project (for a client)
is a non-trivial web application built over that DBMS and Catalyst.

Already being used to doing "classic" Perl 5 OO (using blessed hashes and
direct hash accesses within objects), and having much familiarity with Perl
6 OO, I found that learning Moose was only a bit challenging, and I was
able to start using it competently within a few hours and a day.

The IRC channel #moose at irc.perl.org was very helpful in my figuring some
things out, and also the documentation and examples with the Moose and
Class::MOP were quite helpful.

Moose is not Perl 6 OO but it is a serious and backwards compatible
enhancement to the normal Perl 5 OO system.  To *users* of
Moose-implemented modules, they generally don't have to learn anything and
can just use them as they're used to, but they get added benefits too if
they choose to use them.  To implementers of Moose-using modules, you have
a choice to use as little or as much of the Moose goodies as you want.

I found that using Moose made my code a lot more elegant and maintainable,
and other than the small learning curve, still feels very much like classic
Perl 5.

I highly recommend that any new Perl projects like Perl AppEngine just use
Moose by default and you won't be sorry.

-- Darren Duncan

On Aug 30, 1:42 pm, "Stephen Adkins" <spadk...@gmail.com> wrote:

Me, of course.  As a full-time perl luminary I can say that I full
endorse this message.  This message being one of Moose.

Joking aside, I've been using Moose with every project I've started
since I got my first chance to use it. I started using it as a
replacement for Class::Accessor-esque things.  I appreciated the
clear, descriptive attribute declarations and enjoyed the fact that
the Moose test suite was doing a ton of work I didn't have to.  Even
though Moose is "different", I'm confident that any user will not have
to crawl my source looking for magic if they need to find
clarification of something.  Then, as time went on, I found more and
more things that Moose could help me with .  I started using roles,
finding 'free' features in the MooseX namespace where other developers
have solved some of my problems.

I'm not one to preach or to push people into using one-thing-or-
another.  But I strongly implore any developer that hasn't had looked
Moose over to do so.  The gains have come for me in testing (the "I
don't have to test this, they did" feature), error checking (the "i
typed the attribute and that value doesn't pass it" feature) and
features (the "zomg someone already did this and it's either in Core
or MooseX::*" feature).  I also cured my ingrown toenail, hooked my
HDTV for me and straightened out my gopher problem.

Cory G Watson
http://www.onemogin.com/blog

One way to think about Moose is to look at it from the perspective of
someone new to Perl.
Typically, that new developer will have questions like:

  "How do I declare a class? Is there a 'class' statement?"
  "How do I extend a class?"
  "How do I define the constructor?"
  "How do I specify the attributes for a class?"
  "Is multiple inheritance allowed?"

For class extending, for example, you can explain @ISA to them, and
say,

   Well, first you do 'use vars qw/@ISA/' or 'our @ISA' and then
   you extend by doing something like:

         push @ISA, 'SomeParentClass'

   Wait, you mean I use the 'push' function to extend a class?

Or, you can point them towards Moose and say:

   Use the 'extends' statement at the top of your file, like so:

         use Moose;

         extends 'SomeParentClass'

Perl has a great OO model, but the interface is a little rough. Moose
makes OO in Perl easy to digest, and presents an interface that is
better suited
for making direct comparisons to how OOP is done in Java or C++.

From poking around in CPAN, I mostly have experience with
Class::Accessor:: or
Class::MethodMaker, but these two packages aren't really in even the
same league as Moose. Essentially
they're just attribute specifiers: no class declaration and still need
to use @ISA manually.

All-in-all, someone coming to the Perl AppEngine *will* want to do OO,
and I don't really want to have to explain "@ISA" or "bless {}"
to them. I'd much rather tell them to "use Moose".

Rob

On Aug 30, 2:42 pm, "Stephen Adkins" <spadk...@gmail.com> wrote:

Without Moose, I'd probably have lost the faith and left Perl for
another language.  This is not a lightly written statement, since I've
been using Perl as a primary server side development language since
1996.  When I first started programming I gravitated toward Perl for
two reasons:  First, it let me do what I needed to do without getting
in the way or forcing me to jump through a lot of hoops.  Second, it
introduced me to what is now broadly though of as the Open Source
community, an idea of how software and knowledge sharing could be that
excited my idealistic nature.  I have to imagine there are quite a few
programmers in Perl with a similar story.  A lot of us started using
Perl because the module CGI made it trivial to create server side web
forms, while DBI created a straightforward means to shuffle
information between the web and back end databases.  Perl did what I
needed it to do.

However, over the time, my love affair with Perl diminished.  Perl's
default OO model is very minimalistic and I found myself envious of
languages that allowed --and even encouraged-- a best practices
approach in modeling your application.  For the first time I started
to feel like Perl was getting in the way of me just doing what I
needed to do, mostly because I was spending a lot of time jumping
through hoops and not expressing my problem domain.  Even worse, this
lack in Perl lead most large projects to create there own ways to
close the gaps left open by existing methodologies.  How many
different and incompatible component systems have been written for
Perl?  How many systems for making it easier to do object oriented
programming?  And each time you go to load a new module from CPAN, you
end up also loading a bunch of dependencies for yet another half baked
OO framework that is only being used on a handful of projects.  This
reality makes in much harder for newcomers to usefully contribute
code, since each you you have to learn a new underlying framework and
all its idiosyncrasies.  That's why most important Perl CPAN modules
have at most a small handful of contributors.  Worse, if fed the
common belief that Perl is spaghetti code not suitable for larger
applications.  Now, I do think having competing ideas is good, and is
one of the things that makes Perl strong, however for basic, core
programming task, the lack of consistency really hurts us.  Where
would Perl be if CGI had not bee so complete, or if DBI did not become
the dominate method of accessing databases?

Moose has reinvigorated my love for the Perl language, it's community
and programming in general.  It cleanly solves the problem of Perl's
minimal OO features.  I write less boilerplate and spend more time
expressing my problem domain.  It provides a wealth of expression
around which a rich economy of best practices and shared solutions can
grow.  Additionally, since it's written for programmers by
programmers, I find that it fits my brain better than any other ivy
tower OO solution.  It has a large and growing community of supports,
more than any other competing system AFAIK.  Lastly, some of the most
important Perl projects of our day, such as Catalyst, DBIx::Class, etc
are either using Moose or moving toward Moose.  For me, Moose makes OO
Perl just as expressive and fun as I found Perl to be when I first
started writing website applications all those years ago.

Is it perfect?  No, certainly there is a lot of room for Moose to
improve.  However, all the right decisions to let that improvement
happen have been made.  The developer community is very serious about
improvements and about growing adoption of the framework as well as
growing the number of contributors.  I am a case in point, since
although I've been using Perl for more than 10 years, Moose is one of
a small number of projects that I've managed to become involved at the
contributor level.  Moose not working the way you need?  That's fine,
come to IRC and make your case. However, I would encourage to do your
homework first, since the Moose channels have some of the brightest
minds I have ever had the chance to see in action.

For me, properly written Perl starts with Moose.  It should serve as
the basis for any serious project you may be about to undertake.

Sincerely
John Napiorkowski

I think Robert & John have hit the nail on the head.

While I'm crap at predicting the future I'd be very amazed if Moose
didn't become the defacto standard for building apps in Perl5.

So to sell Perl AppEngine to Perl & to non-Perl programmers I think
Moose being integral could be fundamental.

/I3az/

On Aug 30, 7:42 pm, "Stephen Adkins" <spadk...@gmail.com> wrote:

At this moment I'm preparing to teach a Moose class to about a dozen
developers over here at ValueClick.  We've been using moose in
production for about a year now and are very happy with its
performance and how it helps us write cleaner, easier to maintain, and
more robust code.  So far we have 24 modules that use moose.

Just recently we rewrote the underlying CGI dispatching code for our
old and crufty UIs (which are 150,000+ lines, spread across 6 modules,
of crappy C-styled perl) to use Moose and mod_perl 2.  This was a
great exercise in using Moose alongside code that was written by non-
coders back in the days when perl 5.6 wasn't even around.

Two developers on my team, along with myself, have been on the
forefront of learning Moose and applying it.  We are now at a point
were we are finally going to tell the masses that Moose is the "one
true way" to write OO modules in Perl.  This is a big statement to
make, but I think Stevan's original response in this thread does a
good job summing up why we would think this way.

I'm looking forward to when DBIx::Class and Catalyst are using Moose
under the covers.

Writing OO modules in Perl used to be a pain, now it just gives me a
warm and fuzzy feeling inside.

Aran (bluefeet)

I know this thread is mostly over, but this thread is in large part
responsible for some new docs I wrote for the latest release of Moose,
and it might be of interest to folks here.

First is Moose::Intro - http://search.cpan.org/~drolsky/Moose-0.57/lib/Moose/Intro.pod

This document aims to explain what Moose is, why it's better than the
existing body of Perl 5 OO, and introduces each Moose concept with
definitions and comparisons to existing practice. The intended
audience is folks familiar with Perl 5 OO but who haven't been exposed
to more advanced OO concepts like meta-object protocols (ala Common
Lisp Object System).

Second is http://search.cpan.org/~drolsky/Moose-0.57/lib/Moose/Unsweetened.pod

This takes a couple small class examples, and shows them first in
Moose, and then in plain old hand-written Perl 5. The idea here is to
try to show exactly what Moose is doing for you behind the scenes.

-dave