Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Moose has it's issues... certainly the big memory overhead and the slow startup are issues.

    (Yes, I know they are working on it, and it's gradually getting better...)

    But even though it's heavy, source filters are up there in a whole different (worse) class of crazy, as it the original bad implementations of Inside Out objects.

    But you have to remember that this weight is there for a reason, and that's to allow not-brilliant programmers to do useful work without hurting themselves as seriously.

    • Switch.pm has no dependencies. It's short. Moose has many deps and lots of code. Certainly source filters carry a lot of bad juju. Moose is huge and complex. I can't honestly say that that makes it "as bad" as Switch, but I think the analogy is fair. Or, as I said in another comment, comparing it to Inline::C vs XS might have been more fair. When distributing modules on CPAN, it's much better to use XS. Using Inline::C, which though it's awesome and generally works well, you're piling magic on top of magic, and it's a simple fact that the abstraction will leak. Memory and CPU is only one way the abstraction leaks. The stack trace thing is a (solvable, but real) example of another way it leaks. Failed dep installs are another.

      I don't care if people use Moose in their own apps or in enterprise apps, but I'm seeing people write 30 line "helper" modules that use Moose and get sucked in as a dep five layers of deps down. That's just lame.

      Ruby is getting a lot of attention for its OO, but it's also being praised for its minimal design aesthetic. An extremely feature rich OO thingie won't impress the Java people, and people don't even care about Java any more -- it's the Pythons and Rubys with simplicity and adaptability rather than some kind of "completeness" that impress people. It seems an awful lot to me like after lots of attempts at OO systems that clean up Perl's OO syntax and idiom, the mindset of the Perl community decided to concede that battle and start fighting a different one in stead, as a distraction -- and as it turns out, it's a lot easier to add a whole bunch of features to Perl's OO than it is to clean it up.

      And I agree, the InsideOut object fad was lame and sucked. But will this one suck too, in retrospect? Remember, people were really into their inside-out objects for a while there.

      -scott