develooper Front page | perl.perl5.porters | Postings from February 2022

Re: trim vs trimmed revisited

Thread Previous | Thread Next
February 24, 2022 09:11
Re: trim vs trimmed revisited
Message ID:
On Thu, 24 Feb 2022 at 09:19, Christian Walde <>

> On Thu, 24 Feb 2022 05:40:05 +0100, demerphq <> wrote:
> hysterical
> Very bad form and meaningless character assassination regardless of what
> one thinks about the technical subject.

Even though I think it is inappropriate to criticize my choice of a single
word without including the context that it was used in, I apologize for
using it anyway.

What word would you have me use for a position that I feel is not rooted in
any strong technical basis but is essentially a matter of personal
preference unfounded by secondary policy objectives? The evidence is we
*can* modify strings in place, and we know it is more efficient to do so,
so eschewing doing so is purely a matter of personal preference. We are not
a language like Java which chooses to accept the performance penalty of
immutable strings for specific secondary objectives , eg Java has immutable
strings because it makes implementing their thread model simpler (or
perhaps even "possible"), at the cost of using much more memory for string
operations. Our threads do not share buffers at all and copy data when
initiating a thread, so why would we impose the downsides of immutable
strings without any benefit?

Our use of in place modifications allows us to operate on very large
strings without incurring huge overheads. Chopping a 4GB buffer does not
result in us using 8GB. Trimming a buffer with 4GB of text without inplace
modification WOULD result in using 8GB.  What technical reason is there for
us to pay that penalty?


perl -Mre=debug -e "/just|another|perl|hacker/"

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