develooper Front page | perl.perl5.porters | Postings from June 2021

Re: Not an OO RFC, take 2

Thread Previous | Thread Next
mah.kitteh via perl5-porters
June 20, 2021 17:29
Re: Not an OO RFC, take 2
Message ID:
Please see my comments below with the idea that I want there to be a successful RFC for OO in Perl. My thoughts are expressed below with the goal of saying something that might be helpful. I appreciate your efforts and agree Perl needs _something_ compelling in this area to offer the programming world and long time users, alike.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Sunday, June 20th, 2021 at 11:08 AM, Ovid <> wrote:

> On Sunday, 20 June 2021, 17:17:54 CEST, <> wrote:
>> I can't speak for p5p. But personally, I'd rather see a series of RFCs that introduce fundamental core capabilities that will come together to provide this "effective" OOP in Perl, rather than a kitchen sink take-it/leave-it approach.
> As mentioned, I didn't sent an RFC. I tried to follow the suggested protocol and effectively sent a query letter. Thus, what you suggested—completely reasonably—misses the mark because I was trying to not send an entire RFC. A change of this scope requires more than three or four terse paragraphs to do it justice. So what I really need is a "yes or no" regarding whether or not P5P would be interested in an RFC, not shooting down points which my query letter didn't propose. However, in reading what you've written, it's clear you're acting in good faith, so maybe I misunderstood the RFC process? I don't know.
> That being said, as Chris pointed out, most people don't think about OOP to this level and, as you've stated, you're less familiar with it, so I realize why I've not done a great job of conveying what is needed. It's easy to preach to the choir. If you're in an entirely different religion, it's a touch harder 😃
> When you talk about "a series of RFCs", it sounds like what you're saying is a gradual refactoring (correct me if I'm wrong). In my opinion, this will fail on multiple fronts.

No, I mean a comprehensive path forward with an end in mind; only starting from what we have now to something that brings us to the general benefits most turn to OOP for,

* extensibility
* inheritence, composability (i.e., intelligently managing/define @ISA)
* data encapsulation, protection

> First, consider Perl signatures. They came in when? 5.20 I think? Seven years ago? Method/subroutine signatures have been best practice since before many of us were even born and we still can't get them out of experimental status? This is an embarrassment for Perl and it's one of many reasons why our company is getting contacted more and more by potential clients who are looking for "an exit strategy from Perl." How many other languages have to explain why something as fundamental as `my $foo = @_;` is broken? (that was rhetorical. Let's not get into language bashing here)

I understand what you're saying here. I see this more as a procedural failure or lack of technical leadership than an issue with the merits of the feature. As of late, this seems to be changing and I am highly encouraged by this RFC process still in its infancy. Lack of leadership is more than just embarrasing, it's extremely dangerous.

> In the last four years, the number of companies contacting our company for an exit strategy from Perl has increased dramatically. I know of several large employers (that I cannot name) whose codebase is primarily Perl but are already in the process of eliminating it. This is part of the reason I wrote "rewriting the monolith." ( For many of our clients, it's gone from "Perl is dying" to "It's dead; we need to amputate." This was anticipated years ago, but it's happening now.

I suspect this is happening where I work as well, though since I identify as a Perl programmer, that just means I need to move on if it's clear that I'd be put in the position to learn something else. That's my decision but one I've already made, in principle. Maybe Perl needs it's own #rideordie hashtag. OOP is not going to save it nor is parity with other languages that are all starting to look the same. Hence my reference to the "counter cultural".

> If you want to go gently into that good night, I will respect that you have a right to make that choice. Me? I will go down kicking and screaming because it didn't have to be this way. Maybe it still doesn't, but I don't know if we're too late.

Does it look like I am being passive? Perl can't "die" (I mean in the literal sense) and it won't die. But's what's worse to me is a loss of its soul or identity. If Perl "lives" but becomes indistinguishable from something else, to me that's worst than it "dying". That said, I want this effort to succeed. There's definitely value in it. I just want perl to be recognizable after.

> A long, slow, "one feature at a time" dribble of experimental changes will be the nail in the coffin. Those changes will take *years* to get through. But I'll be retired before they do, so what do I care? (Hint: I care.)

It is clear you care. I suppose what I am suggesting is, can we start with addressing the insufficiency of "bless"? It is necessary in what it does, but not sufficient - so in the list of "OOP things we need" how far does "bless" take us? What is missing that "bless" _should_ do; what things in the "OOP things we want list" does bless not address and are not at all appropriate for it to handle? That's what I mean "incremental".

So what do we want:

* more intelligent composition (@ISA) [notable this also requires a 'signatures' component for dispatch/polymorphism]
* better "introspection"
* data encapsulation

What else?

As I said, my fear is not this "death" of Perl but the undeath. Moose/moo already created this weird schism with its DSL and runtime MOP framework. It also begat some weird ways to handle composition that seemed orthogonal to not only Perl, but Moose/moo itself. In practice it also made testing a nightmare.

The proof that it enabled a whole slew of cool things is a clear indicator to me that this kind of thing is wanted. How it did it and the way it fundamentally caused people to think differently far removed for traditional perl/Perl is what has always concerned me about it. What can be done to get the best of both worlds? My suggestions above are just some attempts to figure this out.

> Second, a series of refactorings implies that the current shambolic mess of Perl OO is topologically equivalent to Corinna. I do not believe that they are. In topology, you can't gradually transform a donut into a bowl, but I still know which one I'd rather eat soup out of. I concede I could be making the same "irreducible complexity" mistake that creationists make, but even if I am, I think the first point—years of slow, minor features being dribbled out to an audience who won't see the end goal—shows that it's not better to err on the side of caution.

What would it take for us to go from "bless" to Corinna?

Maybe a good MVP would be, for example, the introduction of the keyword "class" that is has a well defined behavior defined in terms of "bless", "package", and "parent". "class" would be constrained by the current vision of Corinna, as well. I am not so naive as to suggest "let's implement class then see where we're at". I am suggesting, "is there a way to implement 'class' that is a natural progression from package/bless/parent and a singular step forward?" Furthermore, does it allow us a path forward to the other "general" goals? Or something that would represent a huge improvement and opening up of options - all from a single "class" keyword.

For example, I should be able to replace the "bless" keyword with "class" with little or no changes; but with now a with a way to be even more perlish about the OOP module I am presenting.

> Third, you refer to a "kitchen single take-it/leave-it approach." I apologize because that statement is my fault. I wasn't clear in my email. We have been working for many months to strip *everything* out of the MVP that we don't absolutely need. What is presented is, given the scope of what is needed, just about the smallest change we think we can make but that will still provide the needed value. We wanted to ensure that we didn't go overboard and back ourselves in a corner by offering features that we think are right, but aren't completely sure of. It's been a couple of years of acrimonious debate, but it's not been rushed.
> Instead, we have something minimal enough, but powerful enough, that it's already being used in production by companies that appreciate OO and use it.

I am not on reddit. I'll check this out.

> Summary: I never wanted to say this, but I need to. Perl is dying. It's time to get off our butts and do something about this, but do it in a way that doesn't break backwards compatibility. We can be timid and let it die. Or we can be bold and have a chance. Given the companies that are seeking exit strategies for Perl, I don't believe that's a false dichotomy.

I said above what I thought about this. I would suggest that things be named as clearly as possible. None of the OOP solutions in perl use clear names:

* bless
* Moose
* Util::H2O
* Zydaco
* Co/Corinna
* Object::Pad

I think focusing on proving a more sufficiently power "bless" using the keyword "class" would allow sever things; but most importantly focused discussion around defining what the "means" as a standalone capability. And once this is well defined (again, in terms of bless, etc); then I think you'll find a lot of support.

The other part I think I am trying to balance is this fickle line you're walking. Go too far in one direction, and you'll find yourself with a new language an community. I don't say this to be sarcastic, I say this because "perl" will show you the way if you keep your ear to the ground and hands on the grind stone. This has happened time and again; it's about time we recognize it and try to work _with_ this dynamic.


> Best,
> Ovid
> --
> IT consulting, training, specializing in Perl, databases, and agile development
> Buy my book! -
Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About