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

Re: Let's talk about trim() so more

Thread Previous | Thread Next
Darren Duncan
March 27, 2021 21:17
Re: Let's talk about trim() so more
Message ID:
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 
too much.

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

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About