Front page | perl.perl5.porters |
Postings from June 2021
Re: Not an OO RFC, take 2
June 23, 2021 08:08
Re: Not an OO RFC, take 2
Message ID: CAB=rbOnnu=jfe+AezD-2_j_EYKiAsbQ=qs8v-v+9ps-G_bxrSA@mail.gmail.com
On Mon, 21 Jun 2021 at 07:53, Ovid via perl5-porters <firstname.lastname@example.org>
> On Monday, 21 June 2021, 02:34:10 CEST, Yuki Kimoto <email@example.com>
> > Ovid
> > I feel a strong anxiety about you.
> > Are you afraid of Perl's death?
> More and more we get companies contacting us who are actively purging all
> Perl from their code bases. Some are well-known companies, some are small,
> but it's happening widely. Perl is dying. Oh, it will still be around in 20
> years time, but at the current rate, it will be some obscure little hobby,
> maybe running a few legacy Linux tools that we've mostly forgotten about,
> and it will move on from being your grandparent's language to your
> great-grandparent's language. 2040: "Perl? Yeah, I heard about it. Does
> that even compile any more?" Perl will be a curiosity in a technology
dying - true.
Purging all Perl ... do we have some data why is it so? How it can be
> Now, I *don't* want to relitigate the past—that would reopen too many
> wounds—but we've known about this mess since 2000. That's 21 years ago.
... and we are still discussing ...
> People see things like Foo::->bar() and wonder what the heck is that
Ugliness? just lack of "package literal" as first class citizen. And
> Calling a function with a leading a ampersand is allowed, but ask the
> average user what's the difference between &function and &function()? More
> warts, and pretty important ones.
adding "goto &function" and difference between "function 1, 2, 3" and
"&function 1, 2, 3" to the list.
True, it's about consistency and language vision (vision may evolve but
should not be ad-hoc).
Even more, you can create "sub and", you can call it with ampersand or as a
With "my sub and" you can even override keyword and.
> wantarray and context. Ugh.
Again, mostly consistency. There should be optional keyword for implicit
- there should be optional keyword 'then' as counterpart to 'else'
- there should be keywords 'list' and 'void' as counterparts to 'scalar'
Of course then there should be a way to declare implicit context of sub
Also an evolution. What was great idea at the time of implementation may
not be good idea now.,
For example it make look reasonable to switch implicit context of fat comma
rhs to scalar.
For that perl needs language protocols. If it means to stick with "use v",
that's fine. Even better, that can be sold as competitive advantage.
> SUPER is bound at compile-time and we're stuck with that. Decades of the
> SUPER bug hanging around our necks.
> We have threads, but we're told not to use them. People still do and then
> stuff breaks.
Thread documentation should start with:
Using threads (in any language) is like mixing napalm with atomic bomb,
bare hand, and hoping to survive.
> And we don't get used to nice techniques like inversion of control because
> we're so used to ignoring encapsulation and using abominations like
> Sub::Override (I wrote that). It seems that very few people in Perl really
> "get" OO and developers who get OO probably won't reach for that write-only
> language we love.
Inversion of control is only subset of something larger.
It has to be part of language, applicable without author's intention. It
should not only inject, it should resolve. It should be even able to
prohibit usage of subset of workflow
(eg: prohibit login/password authentication favouring token based)
> Not one of those things is a language killer in and of itself. All them
> piled on top of one another, along with many, many other things we could
> cover, along with a rabid community of users who revel in writing arcane
> code, means that Perl is not a welcoming language.
> But we are stuck with that and we can't break existing code. So where do
> we want to go from here and how do we get there? Corinna isn't the answer.
> But I think it (or something like it) is a huge part of the answer.
> We have try/catch now. We need exceptions.
> We need asynchrony.
> We need signatures (damn it!)
- we need to tread subs as methods:
- we need dependencies: multiple use cases starting at
> We need the beginning of a type system—something useful for humans, not
> just computers. UInt is great for optimization the sofware, but creating a
> "Celsius" type for a weather app is great for optimizing the wetware.
Types are bad. We should use constraints (or contracts).
Difference is: type represents implementation. type behaviour can be
altered (eg: accepting and providing values outside of parents range)
On contrary constraint represents intention. It can be only extended.
Celsius is good example.
Kelvin extends Temperature
Celsius extends Temperature
Fahrenheit extends Temperature
or maybe another structure is more appropriate ?
Kelvin extends Temperature
Celsius extends Kelvin
Fahrenheit extends Celsius
> We need so many things it's not even funny, but we're not going to get to
> them unless we change our mindset. Perl 7 was a brilliant idea. This RFC
> process is also brilliant. There are many more things needed, but this is a
> good start.
We need clear statement why to use perl.
We need killer features (in my eyes Domain-Driven Development and
We need to show that perl can handle changes and can help user to do that -
make code maintenance possible (80%+ of costs) instead of making creation of
new code even more sexy.
- "use v"
- "use feature"
both are great start, but should be used extensively, for example, module
like Construct::Syntax should not exist (it should be part of core)
Pluggable keywords are good example: it's important to have them, but
- no tooling support (language server, critic, tidy)
- and second step is still missing (pluggable grammar)
> I worked *years* on Corinna and her design. I opened up the process and
> had many other people help. That was humbling, seeing all of the mistakes I
> made, but it's made Corinna even better. I've poured through arcane
> programming languages, seeing how they handle some of the issues we face.
> I've read books on OO programming best practices (and find myself envying
> Java at times). I've juggled various ideas, wrote software to help explore
> some thoughts, stripped out everything I could to distill a viable MVP. And
> in various forums (not here, thank goodness), I still keep running into
> people saying "bless" is all you need!
> So that's what's bugging me.
> IT consulting, training, specializing in Perl, databases, and agile
> Buy my book! - http://bit.ly/beginning_perl