On Sat, Jan 24, 2009 at 04:55:44AM -0800, Ovid wrote:
> In chromatic's latest "Perl 6 Design Minutes" post
> (http://use.perl.org/~chromatic/journal/38334), he writes
>
> "Missing a discussion on.trim and gilding the lily."
>
> Nicholas:
> * if I wanted PHP I know where to find it
>
> So there's a lot of context missing there and I'm unsure of what this
> implies, but if it's deemed that .trim and friends are too much, so be it. I
> would submit that .chop is also a great candidate for removal (.chop? Why is
> it even in there?)
>
> Is there guidance on where to go from here or what the balance is between
> convenience functions and the bare minimum?
My personal opinion, which I can remember, was that .trim itself was a useful
addition, as it's a good terse answer to the F.A.Q. "How do I strip blank
space from the beginning/end of a string?"
In particular, being able to trim both ends of the string at once efficiently
both in code terms and implementation terms solves the conundrum of this part
of the answer in the FAQ:
You can also write that as a single substitution, although it turns
out the combined statement is slower than the separate ones. That
might not matter to you, though.
s/^\s+|\s+$//g;
If there's one answer that is both elegant and fast, there is no longer a
compromise needed, nor do journeymen programmers waste time questing for a
better answer that masters know does not exist.*
But personally I feel that the added conceptual complexity of having
over-ridable regexps, and in particular .ltrim and .rtrim methods with
over-ridable regexps is not worth it. It's probably more typing than directly
doing a substitution on the string (and note, I don't qualify as part of
@Larry because I can't actually remember the Perl 6 syntax for any of this)
and I can't see any way it can be more efficient in implementation**. So I see
it as all downside, and no upside.
Perl 6 is a much bigger language than Perl 5. Often it makes me think of the
difference between C++ and C, including the standard libraries. C is small
enough that mortals stand a chance of remembering it all, and maybe even
mastering it. C++ (particularly with templates and their nuances) has always
felt as if the contest would end with me dying first (and that it was
cheating, because it was undead.)
All these individual operators *are* useful, *in context*. But it then becomes
a matter of remembering all the special cases for the special contexts. And
at that point, maybe it's faster to implement it using the memorable general
tools in your toolbox, rather than the "correct" special builtins.
It's like Lego, going wrong by adding all these special purpose bricks that do
only one thing. Or the Perl 5 documentation, to which everyone*** wants to add
a paragraph with their own little caveat, which had they known that particular
fact in advance would have saved them an hour or a day. But who reads the fine
manual any more, let alone remembers it?
Perl 6 hasn't reached the level of date_sunrise() or .ninth yet, nor will it
ever. But one of the criticisms of Perl 5, valid in context, is that unlike
some other languages, because there's more than one "right" way to do it, it's
difficult to bring in inexperienced programmers to look at a codebase, because
different house styles can be so different.
So be wary of adding ever more features to the language, because the trade off
is that everyone has to remember them, the language becomes fractionally
harder to learn, and fractionally harder to understand.
And no I didn't answer the question. I don't think that the discussion on the
call did either. And if left alone I can ramble that much, is anyone surprised
that chromatic can't manage to minute several people discussing it? :-)
Nicholas Clark
* Maybe journeyman isn't the right term, but I mean the dangerous middle
state in
1: Apprentice - I have a lot to learn
2: Journeyman - I know nearly everything.
3: Master - You can never know everything.
Although the Victorian physicists weren't actually that dangerous.
** I think it's likely that a both-ends trim might just be. Certainly one that
is implemented directly, rather than a pair of substitutions using the rules
engine. But this is micro-optimising, and likely beaten by a better
algorithm somewhere else.
*** For a small value of everyone. Heck. A big value of everyone would be
worse. We'd be spending all our time apologising about rejecting
enthusiastic contributions.
