http://qs321.pair.com?node_id=11117000


in reply to Re: Cor—An object system for the Perl core
in thread Cor—An object system for the Perl core

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.

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.

Cheers,
Ovid

Hire me for training or software development.

  • Comment on Re^2: Cor—An object system for the Perl core

Replies are listed 'Best First'.
Re^3: Cor—An object system for the Perl core
by 1nickt (Canon) on May 20, 2020 at 22:01 UTC

    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.
[reply]
[d/l]
Re^3: Cor—An object system for the Perl core
by bliako (Monsignor) on Jun 01, 2020 at 13:06 UTC 
    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

[reply]
Re^3: Cor—An object system for the Perl core
by perlfan (Vicar) on Jun 01, 2020 at 18:23 UTC
    (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).
[reply]
[d/l]
      When I was updating the slightly-outdated PDL::Dataflow doc recently, it occurred to me that
      • Perl is single-threaded and there are various ways to get round that, but no amazing ones
      • PDL's current multi-core functionality (which is indeed shared-memory, using POSIX threads) freezes the main thread until all the broadcasted operations are finished
      • it doesn't use the GPU at all yet
      • so long as there's only one POSIX thread running Perl, there's no reason PDL couldn't fire off other pthreads (or, in due course, GPU operations) then "await" (pun intended) / react to the completion of those in an async fashion with a suitable event loop
      That would be a lot closer to proper SMP, within Perl. My limited knowledge of parallel programming suggests that it's hard to reason about unless you have a "main" thread that's in overall charge, which this model would retain.
[reply]

In Section Perl News