This is PerlMonks "Mobile"

Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris
 
PerlMonks  

FYI: I've been doing a lot of of work speccing out Cor, an object system for the Perl core.

You can read about it on the wiki. There are also extensive links on different pages for people to provide feedback.

Per discussion with Sawyer, the current Perl pumpking, the current plan is that Cor will go into the Perl core. Unlike previous attempts, this one looks like it will really happen. So get your feedback in now.

To give you a little taste, here's a simple LRU cache written in Cor.

class Cache::LRU { use Hash::Ordered; has $cache :handles(get) :builder; has $max_size :new(optional) :reader :isa(PositiveInt) = 20; has $created :reader = time; method _build_cache () { Hash::Ordered->new } method set ( $key, $value ) { if ( $cache->exists($key) ) { $cache->delete($key); } elsif ( $cache->keys > $max_size ) { $cache->shift; } $cache->set( $key, $value ); # new values in front } }

Also, holy carp! I've had an account here for 20 years!

Replies are listed 'Best First'.
Re: Cor—An object system for the Perl core
by Arunbear (Prior) on May 20, 2020 at 15:52 UTC

    From the wiki:
    Cor must be better than what you can get in Python 3, Ruby, Swift, and so on.
    That would be really nice (and I do appreciate the effort put into this), but some reasons I think it falls short of being truly better:

    1. No autoboxing. What if you'd used a plain hash instead of Hash::Ordered? In Python/Ruby e.g. it's nice that when dealing with hashes and arrays you can call methods on them so there isn't the kind of mental switching between OO and procedural that we must do in Perl.

    2. Lack of uniformity between built in containers and user defined ones. In the Hash::Ordered docs there is this snippet:

    $oh->add( 'a', 5 ); # like $oh{a} += 5 $oh->concat( 'a', 'hello' ); # like $oh{a} .= 'hello'
    I don't get the impression Cor would actually let both of those work. Whereas in Python this would look like:
    >>> h = {'a' : 1} >>> h['a'] += 2 >>> h {'a': 3} >>> >>> from collections import OrderedDict >>> oh = OrderedDict(h) >>> oh OrderedDict([('a', 3)]) >>> oh['a'] += 2 >>> oh OrderedDict([('a', 5)]) >>> oh['b'] = 'hello' >>> oh['b'] += ' world' >>> oh OrderedDict([('a', 5), ('b', 'hello world')])

    3. We're still conflating interfaces and implementations (surely we can do better?). I'd really wish class definitions to be more self documenting so I can first get an overview of what it does, and then focus on the "how". FWIW, I did a proof of concept of what this could be like. So e.g. the first thing you see is the "what" which can be more rich than just a list of methods (contracts in fact).

      Maybe we'll do autoboxing later (I doubt it, but who knows?), but that falls outside the scope of an MVP.

      As for your other points, maybe join the IRC channel? Some of your points come down to different opinions about how to define and approach correctness and that's often very subjective.

Re: Cor—An object system for the Perl core
by haj (Vicar) on May 20, 2020 at 15:13 UTC

    I am really, really looking forward to that. I'm pretty sure I'll use it for new modules as soon as it is available.

    As for the reasons, I'll just follow the points raised by 1nickt and explain why my opinions are different.

    • An OO framework in the core is what I expect from a contemporary programming language. I'll expand on this in the last point.
    • bless is fine, but not a framework, and the many degrees of freedom it provides make things complicated when you maintain sources written by different authors. Including packages written by myself if I look at them five years later.
    • The syntax is unPerlish was my first reaction when I attended my first presentation about Moose. Well, technically this isn't even true since Moose itself is Perl, working with Jurassic Perl or better. Nonetheless I decided to give it a try, and I found the benefits well worth the learning curve. I'll do the same when Cor is available, only that this time I'm following the discussion and I know what to expect.
    • (I don't care for the name, so this is just to keep the sequence)
    • Today I am happily using Moo or Moose, though I found that there are a few things which I don't like. In my opinion Cor did nicely build on the lessons learned from Moo*. Some of my itches are:
      • It isn't core. This may be just a formality, but the fact that it isn't core makes it just one of the many OO systems bolted upon Perl 5. It turns out that Perl has a lot of experienced developers, and many of them are pretty opinionated which of them is the Only True one. I hope that an OO system in core will be the primary choice in the future. It won't be perfect for me, maybe it won't be perfect for anybody, but given the open discussion Ovid is moderating here I am optimistic that it will be a system most of us can live with quite fine.
      • The syntax is a bit clumsy. I guess that this can't be avoided if you want to run it on Jurassic Perl, and I still find it amazing that it is possible to implement Moo(se) with the feature set of Perl 5.8. In core, an OO system can do better.
      • The has function is overworked (I seem to recall that there's an article by Ovid about that but can't find it right now). With plain bless, parameters for object creation and object attributes were totally independent (which means you have to code it all by hand), with Moo* everything needs to occur in has (or as a fallback munged in BUILDARGS).
      • An object system in core will be faster than Moo*.

    That said, I'm also curious how and when PPI, PPR and the various editor modes will recognize and support Cor.

      The has function is overworked ... With plain bless, parameters for object creation and object attributes were totally independent (which means you have to code it all by hand), with Moo* everything needs to occur in has (or as a fallback munged in BUILDARGS).

      They're totally independent for Cor. has $data; only declares instance data. That's all. Absolutely nothing else. The optional attributes describe other aspects of the class. I worked very hard to make sure that was correct.

      As an aside, even pure-Perl Cor will be faster that Moo/se, but I can't say much more about that right now.

        As an aside, even pure-Perl Cor will be faster that Moo/se, but I can't say much more about that right now.

        *Everything* is faster than Moose so…

        For my part, the syntax and its power look nice. All seems quite well thought out; what I skimmed on the wiki sounds terrific. I would maybe still argue it’s better on the CPAN—even if there is core support necessary to go with it—before the core to gauge adoption and suitability. If it’s good—appropriate, doesn’t drag a bunch of stuff down because of core changes—it will see quick adoption and clean-up and such making it even better for the core. If not, it will avoid a lot of fights, core issues that could be rolled back, and problems going forward. I’d like to hear what people like dave_the_m think about it.

        Sidenote: This is the first I’ve heard about it and I find that a little troubling though I understand that opening everythig up to committee is a good way to prevent progress.

Re: Cor—An object system for the Perl core
by dsheroh (Monsignor) on May 21, 2020 at 10:57 UTC
    A couple of basic procedural questions about the coring:

    1) Will Cor be getting added to the core language or the core distribution? In other words, if you want to use Cor's syntax, will you need to use 5.whatever; or use Cor;?

    2) Will Cor be available on CPAN for use with Perl versions prior to its inclusion in core? If so, do you know yet what the earliest supported Perl version will be?

    I'm not likely to use it for my own code in any case (I'm one of the weirdos who actually like bless), but I manage systems running third-party Perl code for my day job, so, if Cor gets significant traction, I'll be interacting with it regardless.

      Cor is probably going to be part of the core language. There will be no need to use Cor;. And Cor might be available for earlier versions because there's some transpiler work being done to target older Perls.

      Absolutely none of what I say is a promise :)

Re: Cor—An object system for the Perl core
by Fletch (Bishop) on May 21, 2020 at 14:34 UTC

    I'm curious if there's been any commentary from or interaction with some of the big Moose-y using projects (e.g. Mojolicious to name a specific instance) as far as what their plans would be / are.

    Edit: Not that Mojo uses Moose in as such but it has its own maybe call it "Moose inspired" flavor.

    Another: One of my worries (for lack of any better term) is that maybe at best it's an xkcd 927 situation and J Random Perlhaxor is now going to need to know how to do OOP TASK X / Y / Z in n+1 ways depending on the specific project/the ecosystem being used/the phase of moon.

    (That being said these aren't really strong "worries" and it does look interesting at first (admittedly cursory) glance. I understand there may be whatever fundamental underlying implementation problems that won't go away without a re(design|write) and grant YET ANOTHER OOP SYSTEM may truely be the only way forward.)

    The cake is a lie.
    The cake is a lie.
    The cake is a lie.

      One of my worries (for lack of any better term) is that maybe at best it's an xkcd 927 situation and J Random Perlhaxor is now going to need to know how to do OOP TASK X / Y / Z in n+1 ways depending on the specific project/the ecosystem being used/the phase of moon.

      That's a valid concern. However, Cor is designed to be part of the language itself, not an alternate object system to choose from. Thus, you could reach for Moo, Moose, Mu, Class::Std, Class::Tiny, Class::InsideOut, etc, but if Perl's built-in OO system satisfies your needs, why make your life harder aside from backwards-compatibility?

      We need to end this mess where new developers ask how to do OO and the response is "first, learn how to use a CPAN client; second, pick one of the myriad OO systems on the CPAN; third, here are common installation errors; fourth, well, that OO system isn't well-known, so maybe pick my personal favorite; sixth ..."

Re: Cor—An object system for the Perl core
by 1nickt (Canon) on May 20, 2020 at 12:18 UTC

    Hi Ovid,

    I know you've been scheming for quite some time about this and have been showing your work to Sawyer and consulting with him on your plans. I don't know the details. My feedback is: No, thanks!

    • I see no need to clutter the Perl core with this or any other OO framework.

    • The current options including bless, which is in the core, are more than adequate, and offer choice to the Perl programmer.

    • The syntax is unfamiliar and IMHO unPerlish.

    • The name is awful, combination of cutsey 21st Century non-word and the British euphemism for God.

    • What's wrong with Moo?

    Honestly this whole effort seems like it would be far more appropriate for the Raku language. I do not believe Perl needs or would benefit from this.

    There are so many other ways one could contribute to improving Perl, without trying to make it a different language than it is. (E.g. stop Test::Most from exporting Test::Deep's any and all by default ;-) )

    No offense, but Perl stagnated for almost a decade last time some brainy people decided it needed some major Java/Raku/insert-name-here functionality stuffed into it. Leave it alone! Publish "COR" to CPAN if you think it's worthy.

    I'm sorry, but I think it's a bad idea, and I don't like the implementation.

    Thanks, but no thanks!


    The way forward always starts with a minimal test.

      Thanks for your feedback! I'll try to address your points as clearly as I can. You've stated your positions fairly strongly and I may not convince you, but I need to address this for others.

      Before I address your points, there's an overriding point which must be taken into account. Barring something going horribly wrong, it's going to be part of the Perl language. People can work to support it or improve it, but stopping it isn't likely. So rather than focus on what you think should be done, maybe focus on what can be done? Help improve it instead of throwing stones.

      I see no need to clutter the Perl core with this or any other OO framework.

      Perl's core OO facilities are so primitive that there are around 100 or so OO systems on the CPAN trying to "improve" it. Most of them are to scratch personal itches (usually around attribute access) and fall far short of what a robust system needs. What's worse is that most of them are broken in numerous ways.

      When I work for clients, one of the main problems they face is the time it takes for their developers to get up to speed on whatever OO system they're using (I often stumble on brand-new OO systems that, again, developers have to learn). Even Python 2, whose OO system is abominable, manages to have just enough of a sugar layer that people have stuck with it. We need that "just enough" sugar layer, but "good enough" isn't good enough if we want to offer something compelling to new developers.

      The current options including bless, which is in the core, are more than adequate, and offer choice to the Perl programmer.

      bless isn't going away. If you want to drop to that level, go ahead! We're not taking anything away.

      The syntax is unfamiliar and IMHO unPerlish.

      New syntax is always unfamiliar. I still remember when our was introduced and people were confused about how to use it. And let's not even begin to discuss the debates around Moose, even though Moose and its spin-offs have clearly won the OO war.

      As for whether or not it's "unPerlish", that's very subjective. I've worked hard to try to not make it too different and I've been onboarding advice from both new developers and old. The general consensus has been "ok, that leverages things we already know." The objections have been technical. The syntax generally doesn't scare them. I realize that not everyone will agree.

      The name is awful, combination of cutsey 21st Century non-word and the British euphemism for God.

      The name is not a "combination of cutsey 21st Century non-word and the British euphemism for God." It's short for "Corinna", a love interest of the poet Ovid. But this isn't a real objection and, over time, it will no longer exist because this will be part of the language.

      What's wrong with Moo?

      Oh, where do I start? Where do I stop?

      The Moo/se family of languages have generally won the "OO wars" in the language, but that's only because they were so much better than the alternatives, not that they were the "right" way to approach things. Stevan Little, the creator of Moose, agrees that there were tons of design mistakes made, but that's to be understood in creating something new. Matt Trout, the creator of Moo, agrees, in principle, with many of the design directions of Cor (though we often disagree on implementation details). Let me list some issues.

      • Moo/se conflates instance data and data access. This is terrible for maintenance of large-scale systems.
      • Method modifiers for roles break the associative/commutative contract that roles were supposed to offer.
      • Method modifiers in general are a lazy way to avoid thinking about how and when to actually call methods.
      • Moo/se must use heuristics and helper modules to distinguish between methods and subroutines.
      • Moo/se is complicated enough that it's harder to optimize because so many edge cases would have to be pushed down to the C level were it to go core.
      • Moo->meta is sort of a no-op, but allows calling the MOP, requiring an inflation of Moo to Moose, thus requiring Moose and its myriad dependencies to be in core.

      The above list isn't exhaustive and it's not well-explained because I don't feel like retyping the wiki, many emails, or extensive IRC communications on the topic.

      And looking at Moo, it's trivial to add attributes with ro, rw, or rwp. All of those offer the wrong affordance for minimizing the public contract of your object. I'm designing something that's easier for beginners to use, but it also easier for large-scale codebases to manage. Just create a DBIx::Class instance in your debugger and type m $result and be amazed at how many methods it offers. Many of them are helper functions and not methods. Many of them should be private methods that you should never call. Real developers get bit by those things all the time. It's time to end the madness of 100+ object systems and make something that not only works, but offers the right affordances for building solid code.

      I realize I may not have satisfied you and that's OK. I don't expect everyone to agree. But even amongst my detractors who are heavily, publicly involved in the language, there's general agreement that Cor is a good way to go.

        Thanks Ovid!

        I sure as heck do not disagree that Moo has its drawbacks. I am well aware of and frequently affected by some of the very ones you highlighted, in particular the conflation of attributes and methods. (Not all Perl programmers whose work is "maintenance of large-scale systems" are "heavily, publicly involved in the language" ...) On the other hand, I've never been unable to work around those things, even the funky method modifier limitations, in a relatively painless way.

        I think your point that there is already a plethora of OO modules and frameworks on CPAN just confirms what I am saying: it is not possible to write a system that satisfies everybody, and thus, putting one in core Perl is the wrong thing to do.

        (By the way: is it your plan that Cor should be a core module distributed with Perl, or actually part of Perl itself (ie builtin methods)?)

        I think of what lwall says, "good chemistry is complicated and a little messy", and the fact that the absolute Number One killer feature of Perl is TIMTOWTDI, and I think that you may be tilting at windmills. Cor may be so good that I'll switch from Moo (I can't conceive of anything likely to become reality that would make me do that, but I'm open to it), but I still would not support stuffing it into the Perl core.

        I really hope you finish Cor, publish it to CPAN, let it bake for a couple of years and a couple of major releases, then *perhaps* it can be added to the core distribution and maintained as a "dual-life" module, like, e.g. HTTP:Tiny.

        ( Wrt to your name, see also: https://en.wiktionary.org/wiki/cor_blimey; https://en.wikipedia.org/wiki/Cor!! )

        Thanks again for your reply!


        The way forward always starts with a minimal test.
        a love interest of the poet Ovid

        who also wrote (actually documented):

        Here Phaethon lies
        who in the sun-god's chariot fared.
        And though greatly he failed,
        more greatly he dared.

        Since you made the connection with the ancient Ovid, it has nothing to do with Cor

        bw, bliako

        (moved from OOP and the Perl core per suggestion in rt)

        I am not sure how these Quests work, but I will offer something to this notion. Why have all attempts to add a MOP or some sort of "object system" to Perl failed?

        The answer for me is simple. The resulting attempts have, rather than created an idiomatically consistent linguistic interface to Perl, created monstrousities that have lead us away from perl. Moose and all its bastard children are perfect examples. Not only have they simply created new declarative and unrecongizable mini-languages with-in perl, but they have spurred wasted time and talent in totally separate languages with-out. Moose (and it's elk), Perl 6/Rakudo/Pugs/Parrot/MoarVM, etc have become poisoned pills that shattered the community and distracted us from true enlightenment. I've watch this train wreck for nearly 20 years and each passing year only confirms for me that this is true. Every fight, every new release, every name change.

        Recently I have seen something that gives me true hope that an idiomatically consistent approach to objects in Perl is possible. That thing is Util::H2O. I am not saying it is perfect, but hot dang it's exciting to see what can happen as a post-modern approach to OOP begins to spring to light.

        One last thing I has point out is any successful OOP in Perl shall recognize a couple of things:

        • Perl doesn't have strong types (other than, yanno - hashes, arrays, scalars, etc); and it never will.
        • Perl is a forever language. It will never die, therefore we must accept its "limitations" (in quotes because I don't think they exist)
        • Any "OOP" will simultaneously looks like beautiful, idiomatic Perl to those who can appreciate it - and satisfy the itch (I say, chaffe) to have TRUE_OOP_IN_PERLtm.
        Previously I brought up Util::H2O. In closing, I shall bring up a great example of a different kind of language that was cast into the mold of Perl by people who love Perl. PDL is a data language created by such people (and by their own admission). Notable in their handbook 1 is this experpt:
        This is an important PDL concept: PDL stores its data arrays in simple perl variables ($a, $x,
        $y, $MyData, etc.). PDL data arrays are special arrays which use a more efficient, compact
        storage than standard perl arrays (@a, @x, ...) and are much faster to access for numerical
        computations.
        
        What is my point? Well, this is important, too: up to now people who have championed OOP in Perl have been people who arguably HATE Perl. What shall succeed will be done so by thoses who LOVE Perl and everything about it. Maybe it's the person who wrote Util::H2O. Maybe it's someone who has yet to be born. I have no idea. But I do know that this is how I feel after 20 years of being immersed in Perl.

        References

        1. PDL Handbook
        Update In addition to finding a perlish way to have OOP, also having a perlish to do through SMP threading would also have a tremendous impact. I suspect the path to this is withing something like PDL, which I believe has the right approach and is the right place for introducting some shared memory type things (if it's not there already, been a while).
Re: Cor—An object system for the Perl core
by 1nickt (Canon) on May 22, 2020 at 15:26 UTC

    Hi again Ovid,

    Well, you've made it clear in your replies in this thread that your intent is nothing less than to extend the Perl language itself to have a built-in object factory. Better than any of the other object framework/tools that currently exits for Perl -- and better than any that exist for any other language, built in or not.

    Wow. That's an ambitious goal! Were it to become reality, that would be fantastic.

    However, foremost in my mind, besides what Fletch highlighted, is what I mentioned earlier: that the last time someone had an idea this grandiose and it was stuffed into Perl, we got the decade-long smartmatch fiasco. Meanwhile Damian Conway and the rest realized that wasn't going to work, so they started the "Perl6" project, squatted on the Perl name for 15 years, blocking Perl's major release process, and finally, thankfully, took their ball and left to play elsewhere.

    Many people said during that ordeal (I think you were among them?) that Perl did not deserve a major version release because it was lacking at least two prerequisistes: a built-in method signatures framework, and a built-in object framework.

    IIUC from reading here, signatures are likely to be implemented in Perl 5.32 or 5.34. I'm not a fan of that personally, for the same reason I am not a fan of your idea: I will continue to use Method::Signatures because I don't think the new stuff is as good, so now my perl will have stuff built in that I don't want and won't use. Frankly, I don't think that is the Perl way.

    I'd much rather see signatures and Cor, or whatever /p(?:7|34|42|2021)p/ decides upon, included in the next major version release of Perl.

    Like it or not, Moo is the de facto standard for modern Perl application development. "Real developers" (coff, coff) of "large-scale codebases", who may or may not be "heavily, publicly involved in the language" know this, and maintain uncounted applications, all around the world, that depend on hundreds of CPAN modules, as well all their in-house libraries, that are all based on Moo. None of those "real developers" is going to change any of that production code; it's absurdly arrogant to think so.

    Your own mostly wonderful Test::Most is a great example of how a designer's assumptions that are baked in make things less than completely Perlish. RJBS decided that he would export methods named all and any by default from Test::Deep, then you implemented Test::Most in a way that disallows controlling the bundled imported methods. So now it's impossible to test code that uses a method named any, e.g. from List::Util, without fiddling with the symbol table to rename the methods Rik and you assumed everyone wants exported.

    I wish you well, but please adjust your plan to aim at the next Perl major version release. Perl can't withstand another backward-compatibility mistake that hamstrings it for a decade.


    The way forward always starts with a minimal test.

      1nickt wrote (emphasis mine):

      Your own mostly wonderful Test::Most is a great example of how a designer's assumptions that are baked in make things less than completely Perlish. RJBS decided that he would export methods named all and any by default from Test::Deep, then you implemented Test::Most in a way that disallows controlling the bundled imported methods. So now it's impossible to test code that uses a method named any, e.g. from List::Util, without fiddling with the symbol table to rename the methods Rik and you assumed everyone wants exported.

      This is not true. Specifically, it's not true that "it's impossible to test code that uses a method named any" (nitpick: it's a subroutine, not a method).

      First, you can fully qualify your subroutine name as List::Util::any to test it.

      However, a better solution is to simply exclude Test::Deep via use Test::Most '-Test::Deep';. This behavior is clearly documented and has been in Test::Most for a decade.

      Neither solution requires "fiddling with the symbol table."

        Neither does either proposed solution solve the problem.

        I have a class. The class uses a bundle module. The bundle imports List::Util::any into the calling package.

        I like to test my classes. I like to use Test::Most. If I use Test::Most with default imports I get an exception (under strictures).

        Instructing Test::Most to not import Test::Deep in order to avoid this collision means that I cannot use the other methods in Test::Deep that I require.

        Test::Most does not allow granular control over the exports of the modules it imports.

        That's a design assumption: the user will either want all of Test::Deep or none of it. It limits the value of Test::Most.

        I don't want to see similar design assumptions baked into Perl. No one set of assumptions can possibly meet everyones's needs.

        It would be a mistake to put Cor or any other OOP framework into the Perl language.

        Q.E.D.


        The way forward always starts with a minimal test.

      Alternatively, release and maintain a fork, maybe "CorPerl - Perl with objects"?

      In that scenario, you'd be equivalent to RPerl and CPerl; you could get endorsement, support, maybe cash, from TPF. Because Perl is a family of languages, don't you know. Heck, maybe Will the Chill wants core objects, and y'all could get together and publish "CoRPerl", if fast is among your goals.


      The way forward always starts with a minimal test.
        I tried to upboat this more than once, but it won't let me.

        I've mention Qore here before. Although Perl folks pretend it doesn't exist and the creator of Qore at one point said he'd never heard of Perl. So idk, that's a little strange.

        Anyway, TFM says,

        Programmers familiar with C, C++, Java, and/or Perl should find the standard Qore syntax intuitive and should be productive fairly quickly with the language. However Qore has unique features that differentiate it from other languages, and these features must be mastered in order to leverage the full power of Qore.

        In fact, it goes well beyond, ...Perl (programmers) should find the standard Qore syntax intuitive and should be productive fairly quickly.

        Well I've found that it's demonstrably true that a useful subset of Qore is identical to a marginally useful subset of Perl.

        It's also:

        • truly SMP with real threading
        • supports $REAL OOP when you actually want it
        • super cool
        And I have mentioned this before, too. It's not my go-to language. Perl is. Why, despite knowing darn well what's good for me?
        • Qore is not perlish to the degree I want it to be
        • I don't need SMP, and when I think I do, fork works well enough for me (who needs child processes to communicate back with their parents? ha!)
        • I can assume perl is anywhere I need it to be

        Even if Perl and Qore pretend each other doesn't exist, it's still a better and less awkward love story than all the perl forks and broken dreams.

        Update - found this nice down about Qore on their GH wiki, Why Use Qore. And it's on MacPorts! (no they don't call it MacQore)...now I gotta go lookup MacPorts vs Homebrew.

        Update 2 - it occurred to me why I do prefer Perl. It's because it's the perfect tool for bending *nix to one's will. It turns a system into putty in a master's hands (or even a baby's). And that's why I use it. Of course implied is also it's fabulous community of free thinkers and hackers.