Front page | perl.perl5.porters |
Postings from January 2022
Re: Inner classes/modules (was Re: RFC: Amores...)
Thread Previous
|
Thread Next
From:
Ovid via perl5-porters
Date:
January 26, 2022 20:02
Subject:
Re: Inner classes/modules (was Re: RFC: Amores...)
Message ID:
1731815155.1426073.1643227330967@mail.yahoo.com
> The next step would the racy Ars Amatoria (Art of Love), then exile
> for offending the emperor (possibly because some of those love poems
> were a bit too racy),
Strictly speaking, Ovid was relegated to the frontier city of Tomis, not exiled. They're almost the same, but with relegation, you retain your citizenship and property (though on his trip to Tomis, his servants stole everything).
> followed by the composition of the Metamorphoses
> (Changes), where almost anything can be transformed into anything else
I'm absolutely shooting for Metamorphoses. Background of our company, over the course of many years:
1. We were getting plenty of requests for new Perl development.
2. We started getting fewer contracts.
3. With the COVID economy, we're getting multiple "how do we get rid of Perl?" requests.
In speaking with other consultants, their specifics differ, but not too much. And I suspect that we're probably getting more people reaching out to us than others due to my name.
Since https//allroundtheworld.fr/ does more than just Perl, it was natural for companies to contact us about transitioning. We're really good at project management.
But this is the endgame for Perl. I do not wish to go gently into that dark night. Thus, it's time to change the game.
I've tried different approaches, some of which are private and won't be discussed here. My primary obstacles have been:
1. I can't hack on Perl internals (my C is too rusty)
2. Even if I could hack on Perl internals, I have too much paying work to do
3. Many others I've spoken to don't have the time/energy/desire to continue
When we started getting fewer contracts, a common issue in speaking to potential clients was "we're waiting for Perl 6 for an upgrade path." No amount of explaining *ever* overcame this objection.
So there was no Perl 6.
Perl 7 was announced and there was no Perl 7.
Thus, companies again see no upgrade path and we are getting more of the "delete Perl" requests. Many of us are older and I've seen more than one older Perl hacker saying, "I can ride this out to retirement." I completely respect that. Younger Perl developers are leaving for Python or other languages. I can respect that, too.
Maybe I should choose one of those options, but instead, I choose to make a last stand.
I want Perl 7 to come out.
First, let's talk about goals. What do we want to accomplish?
If we have a goal, we also need to explain why we want this goal.
We then plan a strategy to achieve that goal.
We then use tactical responses (RFCs) to implement our strategy.
But I don't know what our strategy is, though I assume our goal is the survival of the Perl language. We're in the endgame and we don't know what game we're playing.
Deprecating a little-used feature is nice for Perl, but doesn't add much value for business. `say` was a beautiful feature for developers, but doesn't add much value to business. Fixing obscure bugs is important, buy doesn't add much value for business.
These are clearly defined tactical responses to an undefined strategy to support a somewhat defined goal.
Both the Perl 6 and Perl 7 initiatives were strategies to achieve the goal of survival of a language we love (or at least are comfortable with).
I don't see any strategy now.
So, fuck it. I want Metamorphosis. I've tried (and failed) with various approaches. I can admit my failures, even if some of them were private. Those failures were largely due, quite frankly, to me not admitting my limitations. So if my goal is the survival of the Perl language, I need a new strategy to support my goal of Perl's survival. My current strategy involves:
1. Design features in groups that are thought out together.
2. Limit new feature scopes to avoid the issue of simply having `use v7` in legacy code break things.
3. Adopt a more uniform KIM syntax (keyword, identifier, modifier).
4. Address a definition of done for feature groups necessary to say "this is Perl 7."
New *holistic* features. not tweaks. Create a backwards-compatible vision of the future. We don't have the popularity to support a Python 2/3 split.
Stop playing the game that we're playing now because the definition of insanity is ... well, you know the quote.
Change the game. Throw the Hail Mary pass.
<neo>I don't know the future. I didn't come here to tell you how this is going to end. I came here to tell you how it's going to begin</neo>
Best,
Ovid
--
IT consulting, training, specializing in Perl, databases, and agile development
http://www.allaroundtheworld.fr/.
Buy my book! - http://bit.ly/beginning_perl
Thread Previous
|
Thread Next