Front page | perl.perl5.porters |
Postings from March 2021
Re: Let's talk about trim() so more
From: Darren Duncan
March 27, 2021 21:17
Re: Let's talk about trim() so more
Message ID: email@example.com
On 2021-03-27 5:34 a.m., Paul "LeoNerd" Evans wrote:
> There seems to be a lot more people replying on this email thread who
> seem to care about higher principles of language design, than were ever
> present on the original github discussions about the feature:
> I would like to ask: Where were you all earlier? Why didn't you respond
> there before we'd written it?
> This isn't trying to come across as an accusation - it's a genuine
> question. If all of this discussion had happened much earlier over
> there we probably wouldn't be in the awkward situation we are now. It
> is annoying that it is happening so late.
> I wonder whether this is a suggestion that our current github-based
> design process is not working properly, as it doesn't bring the right
> mix of people to view things at the right time.
Speaking for myself and my own participation, there are several factors:
1. I choose to mostly follow Perl development at a higher level, such that I'm
subscribed to p5p, and as time permits I look into threads that seem interesting
from their subject lines, and I may reply and give input ad-hoc based on what I
see at the time. I don't follow all the messages and tangents so I may not know
that something was brought up before, only that it isn't being discussed where I
2. I recognize that GitHub etc are good for having organized threads for
decision making, but generally I have to take more action to go and look for
conversations there. In contrast, I'm looking at my email constantly and p5p
stuff comes to me so I see it most quickly with the least effort.
3. Given how I was operating, it didn't even occur to me until this thread that
trim() might be getting implemented in a way I might think was deficient, and I
just assumed when the feature was proposed it was so simple that yes I support
it and I don't need to get into the weeds, so I didn't know until now that my
assumptions were wrong, and so I wrote in.
4. I am giving input mainly from the point of view of what I think would be a
good language design, either language-agnostic or Perl-specific, but I know I
will never be involved in actually implementing it, so don't get into the weeds
5. I have limited skin in the game, due largely to being a polyglot that uses
multiple languages professionally. I have been in the Perl community for 23
years and love it and want it to be a strong ongoing concern, but I won't be
hurt financially if it doesn't. So I limit how much time and effort I
personally invest to help Perl be the best it can be, and mainly give input on
areas I feel I can make a more valuable contribution. Time is very limited and
I can't read or participate in everything.
6. While useful, ultimately I consider trim() to be a relatively minor feature,
in contrast say with Corrina, and ultimately feel that it doesn't matter if I
get my way on this, those implementing it will do it how they want, and that's
fine with me.
7. My time is very limited and I have other things which are my main passion
projects. They are language-agnostic and I expect would help Perl but are not
specific to Perl. A core example is my in-development Muldis Object Notation
(MUON), a format for data/code interchange/config/RPC/etc meant to be better
than JSON/YAML/SQL/etc. These are open source on GitHub.
As for how can this be resolved, one thing that will help I think is the
proposal made in the latest PSC update #12, about having threads on p5p about
individual design decisions, will be a great help.
-- Darren Duncan