in reply to Re^8: The future of Perl?
in thread The future of Perl?

We lose some error checking and ability to use it as role or put type checks or coercion (none of which I did either but some of it would be a one or two line addition)

Any errors will be checked when the underlying array operations are performed. And the messages will be concise and informative.

Unlike those that Moose produces!

for example a web spider object would have a user agent but it would be pleasant to have $spider->get instead of having to write $spider->user_agent->get

But, that can be done in one line with no modules:

package Spider;
...
*get = *{ $self->ua->get };
...

[download]
The bare bones mop that may come into the core in 5.24 or something is an example of how little agreement there is on which features are crucial and which are in the way.

Oh Dog! If Perl core starts coming with a MOP; then I sure hope that they also provide a compile-time -DBukIt to throw it away.

I mean, what good is a MOP without a BukIt :)

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.

Replies are listed 'Best First'.
Re^10: The future of Perl?
by Your Mother (Archbishop) on Dec 15, 2014 at 06:11 UTC

    For error checking I meant your constructor can be called with incorrect/missing size or “bad” invocant and won’t complain then will complain “cryptically” and not from caller’s perspective on its methods (but only if warnings are on); e.g.: Argument "camel" isn't numeric in numeric eq (==) at Package line number…

    Your counter examples are spot on and if stevan couldn’t convince you Moose is a good tool there is no way I ever could. :P The traits give you more flexibly and depending on the package add exactly one line of code. Whereas the aliasing you’re doing would add up to hundreds to achieve the same thing and would not be properly overridable/inheritable/mixable/requirable, Unstandardized and probably untested. Types doing any number of complicated checks and validation with just a line as well and one more to do something like upgrade "http://asfd.qwer" to isa(URI). My examples being mostly toy code is not making a terribly good case I know… :| Since the stuff is just Perl more just Perl can be shown to do the same-ish; we haven’t talked around/after/before either which is quite a bit harder in plain Perl, especially in a way that can be altered or overidden in consuming classes. Some of the strength is that Moo/Moose and friends come with docs, tests, community: consistency and support and extensibility; DRY too. I find it much easier to debug than YAOO system or series of inconsistent idioms executed by 5 different hackers on a code base, all with their own style and rationale.

[reply]
[d/l]
      Your counter examples are spot on and if stevan couldn’t convince you Moose is a good tool there is no way I ever could. :P

      You're right. I wrote what is inside the spoiler tags before I thought again about that statement and you're right, I'm arguing with the wrong man. You've been polite and generous enough to conduct a discussion with me -- which is most appreciated -- so, please feel free not to look inside the spoiler. And if you do peek inside, do not feel obliged to respond :)

      <Reveal this spoiler or all in this thread>
      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
[d/l]
[select]
        I agree with you almost completely.

        Though, I see an advantage in having a MOP and it is that you can mix extensions working at the meta-object level in a sane way. For instance, in bare Perl, it is quite easy to write a class that uses AUTLOAD to create methods on demand, but then, if you try to use again AUTOLOAD in a subclass, everything becomes a mess. Having a protocol eliminates that kind of problems. Cooperating becomes easy... and before you say it, yes, I agree, there are very few cases in practice where this is a real issue! but having a common language is also a good thing, otherwise you end writing your own ad-hoc mini-meta-protocols.

        The main problem I see in Moose is actually not in Moose per se but in so many programmers using it wrongly. Abusing it. Creating overcomplicated inheritance/roles structures. Adding abstraction layers where they are not required. Type-checking everything... it reminds me of the first days of the web when people felt obliged to use all the HTML tags in every page.

        Then there is the performance issue: the high setup time which breaks the you-pay-for-what-you-use principle that any good MOP should honor. For comparison, in Common Lisp/CLOS (which is at least as feature rich as Moose), defining a class that does nothing requires virtually no time: 

        $ echo "(defclass foo () ())" | time sbcl
This is SBCL 1.2.3.debian, an implementation of ANSI Common Lisp.
...
* 
#<STANDARD-CLASS FOO>
* 0.00user 0.00system 0:00.00elapsed 140%CPU (0avgtext+0avgdata 32360m
+axresident)k
0inputs+0outputs (0major+901minor)pagefaults 0swaps

        [download]
        While in perl, just loading Moose is on the order of the thens of a second: 
        $ echo "package Foo; use Moose;" | time perl
0.13user 0.00system 0:00.13elapsed 100%CPU (0avgtext+0avgdata 19492max
+resident)k
0inputs+0outputs (0major+3909minor)pagefaults 0swaps

        [download]
[reply]
[d/l]
[select]

In Section Meditations