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

Re: Not an OO RFC, take 2

Thread Previous | Thread Next
From:
Ovid via perl5-porters
Date:
June 20, 2021 16:09
Subject:
Re: Not an OO RFC, take 2
Message ID:
1932990279.616183.1624205320927@mail.yahoo.com
On Sunday, 20 June 2021, 17:17:54 CEST, oodler@cpan.org <mah.kitteh@protonmail.ch> 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.
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)

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." (https://dev.to/ovid/rewriting-the-monolith-part-2-2bgf) 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.

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.

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.) 

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.
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. https://www.reddit.com/r/perl/comments/nyuid5/were_starting_the_rfc_for_bringing_modern_oo_to/h1phg5z/)
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.

Best,Ovid
-- IT consulting, training, specializing in Perl, databases, and agile developmenthttp://www.allaroundtheworld.fr/. 
Buy my book! - http://bit.ly/beginning_perl 

 
  
Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About