Beefy Boxes and Bandwidth Generously Provided by pair Networks
"be consistent"
 
PerlMonks  

Re^4: The future of Perl?

by Your Mother (Archbishop)
on Dec 13, 2014 at 23:22 UTC ( #1110287=note: print w/replies, xml ) Need Help??


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

Up front: I am not the right one for the job; I am largely recycling things I’ve read and heard. My experience domain in OO in other languages is sparse. So, I’ll rely on an expert!

I'd say the Moose OO model is far more powerful and useful than Python's. Roles, method modifiers, lazy builders, delegation and coercion are all really good for reducing repetitive code and improving OO design. With enough work most of that can be emulated in Python, but Moose gives it to you straight out of the box. Re: Python OO v Moose

Perl supports a vast ground of different techniques and does not hinder from crossbreeding or intermixing. Types + coercion for example, only hinted in the quote, can be bondage oriented or loose and accommodating or anything in between. You can write Perl that does what Java does in the way it does it (though private methods and such are less fun, you know they can be done in at least a couple ways; anonymous/lexical code and inside-out). You can’t do the reverse. Every personal sweet spot in between is possible in Perl. And though some languages—as I understand it, I’m *not* a xlang OO exert in the slightest—make some of the techniques easier and remove some of the bad behavior (like methods bumping into functions)… still Perl can do it.

Now to recycle another thing someone else said recently: The main problem with Perl isn’t Perl, it’s that while the CPAN is enormous, Perl at large is not grounded enough in complete, out of the box, applications. WordPress or Wikimedia would have been easy to write in Perl for example but the ethos of the Perl community, in my estimation, finds it more fun to work on gears than complete machines… I’ve thought a lot about this and I’ve never come to any conclusions; why, is it better, should, could it change? PHP only exists and flourished, in my view, not because Perl couldn’t do what it ended up being but because the Perl hackers of the day wouldn’t.

I ducked most of the real question, I know. It would be a good bit of work to address for someone who is an expert. It would be a three month research project for me. :P

Replies are listed 'Best First'.
Re^5: The future of Perl?
by Arunbear (Prior) on Dec 14, 2014 at 14:37 UTC
    What would be the Moose version of this (a queue that maintains a fixed size by evicting the oldest items) ?
    class FixedSizeQueue def initialize(size) @max_size = size @items = [] end def pop @items.shift end def push(item) @items.push item if @items.size > @max_size pop end end end
    With usage
    2:16% irb -r ./fsq.rb irb(main):001:0> q = FixedSizeQueue.new(3) => #<FixedSizeQueue:0x9317c6c @max_size=3, @items=[]> irb(main):002:0> q.push 2 => nil irb(main):003:0> q.push 3 => nil irb(main):004:0> q.push 5 => nil irb(main):005:0> q => #<FixedSizeQueue:0x9317c6c @max_size=3, @items=[2, 3, 5]> irb(main):006:0> q.push 7 => 2 irb(main):007:0> q => #<FixedSizeQueue:0x9317c6c @max_size=3, @items=[3, 5, 7]> irb(main):009:0> FixedSizeQueue.instance_methods(false) => [:pop, :push]

      That's a great question and that’s graceful code from Ruby. We can do similar several different ways in Perl including tying an array, using an array as the object, minimal OO harnessing like Class::Accessor, or even a code ref. This kind of problem strikes me as a good candidate for a code ref. But that's not the topic :P so here are three different ways to do it. All are more verbose than the Ruby; and the least verbose of them (array object) is probably confusingly terse/unusual to most Perl hackers. The last two are FIFO, not FIFI in the example and the third is a hard fixed queue in that its length never changes. It hold undef in “empty” slots. Putting packages in <readmore/> since it’s longish–

      Some sample code with them and output.

      eval { fQ_moofancy->new } or say $@; my $foo = fQ_moonimal->new(size => 3); my $fooncy = fQ_moofancy->new(3); my $fixed = fQ_FIXED->new(3); for ( 1 .. 5 ) { say " foo -> $foo"; say "fooncy -> $fooncy"; say " fixed -> $fixed"; $foo->push($_); $fooncy->push($_); $fixed->push($_); } __END__ isa check for "size" failed: size must be a positive integer at… foo -> fooncy -> fixed -> _ _ _ foo -> 1 fooncy -> 1 fixed -> _ _ 1 foo -> 1 2 fooncy -> 1 2 fixed -> _ 1 2 foo -> 1 2 3 fooncy -> 1 2 3 fixed -> 1 2 3 foo -> 1 2 3 fooncy -> 2 3 4 fixed -> 2 3 4

      I have no doubt there are other, likely cleaner approaches. I was winging it, first drafts, all that sort of caveat.

        As Lao Tzu might have said: The API that exposes inner workings is not the true API.

        Users of the queue shouldn't need to know that there's an array inside that holds the items, yet the Moo(se) examples all expose this at API level.

        The real point of the Ruby example is to show that in Ruby (also Python and Java) you aren't compelled to

        • expose an object's internals via an API
        • use a function call to get/set an attribute from inside the class

        Of course the examples that used vanilla Perl OO don't suffer from this problem, but given that Moo(se) inevitably leads to loss of Encapsulation, it can't really be considered as providing superior OOP.

        I see little or no benefit of any of those over a bog standard perl 5 OO implementation:

        package FixedSizeQueue { sub new { my( $class, $size ) = @_; bless { max_size => $size, items => [], }, $class; } sub pop { my $self = shift; pop @{ $self->{ items } }; } sub push { my( $self, $item ) = @_; shift @{ $self->{ items } } if @{ $self->{ items } } == $self- +>{ max_size }; push @{ $self->{ items } }, $item; } 1; }; __END__ [0] Perl> $Q = FixedSizeQueue->new( 3 );; [0] Perl> $Q->push( 2 );; [0] Perl> $Q->push( 3 );; [0] Perl> $Q->push( 5 );; [0] Perl> pp $Q;; bless({ items => [2, 3, 5], max_size => 3 }, "FixedSizeQueue") [0] Perl> $Q->push( 7 );; [0] Perl> pp $Q;; bless({ items => [3, 5, 7], max_size => 3 }, "FixedSizeQueue") [0] Perl> pp %FixedSizeQueue::;; ( "new", *FixedSizeQueue::new, "push", *FixedSizeQueue::push, "import", *FixedSizeQueue::import, "pop", *FixedSizeQueue::pop, )

        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.
      I am not really an expert on Moose but here is one attempt:
      package FixedSizeQueue; use Moose; has "max_size" => (is => "ro", isa => "Int", default => 10); has "items" => (is => "ro", isa => "ArrayRef", default => sub { [] }); sub pop { my($this)=@_; pop @{$this->items}; } sub push { my($this, $item)=@_; push @{$this->items}, $item; shift @{$this->items} if scalar @{$this->items} > $this->max_size; }
      This is fuctional but you need to be intantiate it like this:
      my $q = FixedSizeQueue->new(max_size => 3); $q->push(3); $q->push(5); $q->push(7); $q->push(9); print Dumper($q);
      If you want to supply only an integer to the constructor you need to add a BUILDARGS-method to the above:
      sub BUILDARGS { my($this, $max_size)=@_; return { max_size => $max_size }; }
      Now you can use it like your Ruby-example:
      my $q = FixedSizeQueue->new(3); $q->push(3); $q->push(5); $q->push(7); $q->push(9); print Dumper($q);
      </c>
Re^5: The future of Perl?
by vkon (Curate) on Dec 15, 2014 at 13:31 UTC
    I heard this argument that in process of Perl6 development perl5 got better OO, 'mop', Moose , etc etc etc

    I am not bying this, and here is why:

    Not a secret that most of these ideas was already in the air, and invented some 20 or 30 years ago...
    and not a secret that LISP had better and superior OO system (CLOS) which was then stolen into the perl6...

    In my vision, the people that were busy with choosing OO system for perl6 could spent their efforts and develop perl5 mop OO system directly from LISP to perl5, if they wish to.

    What happened with Perl6 - is that at y2000 there was a number of inspiration based on success of perl5 and on fitire perl5++ which is to be perl6...
    what happened then - after 10 years - the project stale, and then existence of the name 'perl6' became more of a problem, and damage to the community started happening.

    You could accept that or not, but this is what happened.
    Not recognizing this problem is another problem, which makes resolution even harder.

    I was also inspired by perl6, and very much like its syntax and power....
    but I do not see any usable implementation of perl6...

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1110287]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others musing on the Monastery: (9)
As of 2021-01-16 15:33 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Notices?