|Do you know where your variables are?|
Re^3: How Large Does Your Project Have To Be to Justify Using Moose? (encourage)by tye (Cardinal)
|on Oct 06, 2011 at 23:46 UTC||Need Help??|
First, let me stress that I think you should be very proud of Moose. It is a stellar accomplishment. Really.
Now, I'd be more convinced by the standard "don't blame the tool" arguments if I had argued that one shouldn't use Moose because it fails to prevent you from doing stupid things. I'm a Perl programmer; having the freedom to do things previously considered stupid is something I highly value.
I'll go to a simple analogy. I was not arguing, "Please don't use Acme brand hammers because I've seen people trying to drive screws in with a hammer and that is a bad idea". I was more arguing "Nails relatively suck compared to screws when it comes to holding two pieces of wood together. Sure, it is much easier up front to pound a nail in with one good whack, but in the long run, you'll be happier with how well the two pieces of wood stay held together if you take the time to twist a good screw all of the way in. And this makes it not the best allocation of resources to set up to use an extremely well-made Acme pneumatic nail driver that can't really be used unless you also pull in a whole trailer full of gas generators and compressors. And I know this because I've seen smart, professional carpenters nail themselves into a corner in ways that were very easy for them because they didn't even have to do any pounding in order to toss another nail into the pieces of wood that they were trying to assemble."
The worst part of that analogy (IMHO) is that if I set up an Acme pneumatic nail driver and use it to make a cheap little birdhouse, then I can give that birdhouse to my grandmother and she can just hang it up in her tree without even needing a K-Mart hammer. But if I build a module using Moose, then anybody who wants to use that module is expected to do the equivalent of setting up their trailer full of generators and compressors and then to wait for at least some of the compressors to come on-line each time they want to use my module.
Nothing about Moose forces you into doing something as idiotic as you describe.
That particular "idiotic" thing I described is pretty close to what was proposed very recently by somebody smart who I respect when they talked about how they would go about doing what we are instead doing much more "by hand" (in part because Perl seems to still lack a simple, small, rechargeable screwdriver and in part because, at a certain scale, a custom tool can fit so much better than an amalgam of general-purpose components, even when those components are quite well-built, and our problem is at that scale).
Are you telling me that Moose documentation discourages the use of pre and post method wrappers and generated accessors with type-based constraints? Since you chose to describe that as "idiotic", surely the documentation discourages it. Most certainly, the documentation can't encourage it!
If I go to pick up Moose (much as the original poster in this thread suggested), the documentation will naturally encourage me to think about design first in terms of the interface I want to provide and will surely give me good advice about keeping attributes hidden behind that interface.
I'm not so foolish as to think that Moose forces bad design. But surely, Moose won't encourage bad design. Surely, it won't just immediately suggest to me that I should start with type-enforced, auto-generated accessors with before/after wrappers and inheritance! Why, that's most of the way to what you called "idiotic" combined with what every wise old hacker I check with knows is just plain a bad idea (inheritance).
Well, let us start reading Moose documentation...
Oops. Wow, the encouragement didn't take any effort at all to find.
So, you can claim that only stupid people would do stupid things with Moose. But my experience is quite at odds with that (though that experience covers more than just Moose; it also covers other tools that make auto generation of accessors easy).
Certainly, exceptionally smart and careful people can make good use of some features of Moose without ever being lured into the problematic but easy routes. But that doesn't make Moose the best nor cheapest way to accomplish those smart things.
Where is the code? I would love to have a look.
It is not like I'm hiding it. I'm working on it. I release parts as I am able to make them release-worthy. I discuss the ideas fairly often and provide example code as well. Some of the current bottleneck is figuring out which directions scale better to more complex designs. Plus the past couple of months have been less productive due to burn-out (which I seem to have finally broken out of just recently). Much of the code will likely hit CPAN as individual modules. I expect most of the modules to be useful in isolation (and to not require each other) even though I plan to use them together. I also expect them to be quite small. Some code experiments will get posted at PerlMonks before CPAN.
But there are also some fundamental "direction" decisions that I have to sort out. And there is also the wordsmithing of prose and examples in hopes of framing some of the overarching principles to help people be more likely to understand what I'm trying to get at.