[gatlin]

I actually despise Moose as much as I despise blindly over-doing OO. To me Modern Perl meant tackling problems in a much more Lisp-inspired way (via lexical scoping, anonymous functions, closures, lists, etc) ... but in Perl. Kind of like "Higher Order Perl."

I had the impression it was more a cultural shift, a renewed interest in Perl and people wielding it much differently. There's a different CPAN web interface[1], a lighter cli client[2], and everyone is on GitHub and writing hundreds of tests. I guess Moose is part of that shift but I'm torn a lot of the time - I support modern Perl but I hesitate to support blindly copying the warts from other languages just to appear modern.

This[3] is a result of searching for common::sense ... yikes.

[1]: http://metacpan.org [2]: https://metacpan.org/module/App::cpanminus [3]: https://metacpan.org/module/Real::Handy

[phaylon]

Personally, I think Moose' value to the community is much larger than that it just provides good OO.

It pushed a much more declarative approach than usual, that swaps over to other projects (Moo, Mo, even Class::Accessor supports has declarations now). It has a community that is focused on best practices with regards to OO. It put introspection more in the spotlight (like the idea of getting Getopt definitions by introspecting classes).

It is also flexible, which allows for lots of extensions to its functionality. That means a lot of concepts are tried out on CPAN already. Even if someone doesn't use Moose, there is lots of OO knowledge to be found in the ecosystem. Same goes for runtime type constraints/coercions.

Then there's the p5-mop project, that would provide a common core, so many of the things above could find themselves in a much more light-weight and broadly usable variety, with side-effects like less heavy anonymous packages.

Personally, while I'm very excited about where Perl 5 has come so far, I'm even more excited by the things we haven't thought of yet.

[einhverfr]

We moved to Moose only in the last year, and the reason was that at the time we started LedgerSMB 1.3, Moose was still relatively immature at least in the versions shipping with supported Linux distros. We felt it was an immature technology with too many dependencies to build our software on at that time (2007). After the 4 year development cycle and a release that happened only slightly after Duke Nukem Forever, we had cleaned up a significant part of the codebase, and Moose had changed.

Moose is a bit heavyweight. It may not be what you want in some applications. However, it strikes me as an inspiring example of design done right, and for that reason it's worth learning.

I think this exemplary aspect is why Moose has had the impact it has, not only being somewhat widely used, but also defining approaches that many other object approaches have borrowed. The fact that things are declarative is very helpful.