>> It's nearly part of Perl's language signature. I wouldn't count
>> on this going away if you still think to call this "Perl". It is
>> of course much more likely in the renamed "Frob" language, however.
>First off, this argument is just a little too grandiose, because if we
>can't change anything because of precedent, then we're stuck and Perl 6
>should just be Perl 5.9 instead.
How nice of you to put words in my mouth. Please cite me the precise
message ID, date, and appropriate text in which I said "we can't
change anything because of precedent".
<time passes>
Right. I didn't say that. So don't *you* go saying that I did say
it, or pretend that I did, or allege that I did, or infer that I
did. It's deceptive, misleading, and flat-out wrong, and I'll thank
you not to repeat the error. Yes, it's a hot button, so don't push
it.
Here's something you can quote, however: You cannot hope to just
mutate absolutely *everything* willy-nilly and still expect that
the language should keep the same name. It's not fair to anyone.
If you want to make a language with a similar relationship to Perl
as Scheme has to Lisp, then by all means do so, but note the wisdom
of the name-change that the lispers pulled. Thus, there *is*
fundamental merit in respecting and understanding the appeal of
precedent. That is a *long* way from saying "never change anything".
Where are the reasonable boundaries here? Well, although it's hard
to say with inerrant precision, it's trivially easy to make a good
stab at it. You just look at usage--how much has this feature been
used? For how long (eg been there since perl1 vs just got added
in perl5.003)? What is its prevalence in Perl scripts? Is it a
rare feature (like formats) or a ubiquitous one (like hashes)?
While there are other criteria one can apply, such as whether its
presence necessarily dead-ends some other desired functionality,
this has to be taken in the light of understand what's indispensable
because of its longevity and ubiquity--not to mention convenience.
If you look at the perl1 manpage, then consider usage over time,
you'll get a good feel for these fundamentals, which range from
single- vs double- vs back-quote distinctions to if/unless variances,
from pick-your-own-quotes features to automatic memory management.
Almost of these in turn have their ancestral roots as well, like
dollar signs for variables inside of interpolated strings.
Perl is easy to learn because you don't need to know much of it,
and also because the parts you do need to know you're apt to already
know from Perl's parents. These two features are also critical.
>That being said, I don't see why this wouldn't work still. As I noted in
>an email to Scott, at the very least this will work:
> next if m/\s+/ || m/\w+/;
Having to write m// is needlessly burdensome, flying in the face
of thirteen years of experience and millions of users. I guarantee
you that there are more people who know about
if (/foo/)
and about
if ($var =~ /foo/)
than there are people who know that you can use m// for the same things.
Have you ever noticed how that
many Most of the drastic changes suggested here seem to
I have a long list of changes, things I'd like to see *fixed* in
Perl, but virtually none of which anybody here has ever even managed
to mention. You're all too busy giving the baby a brain-transplant
than you are to trim his toenails. (And you forget that the baby
is rather grown up now.) An exception is Mark's addressing of the
empty regex problem, which was on my list of niggles. Another of
my fix-the-pointy-edges niggles is the way wait() and waitpid()
have the wrong semantics for a syscall, since they should always
be writable as syscall() || die, just like the rest of them. Then
there's the "1;" at the end of a require()d file, or that index/rindex
don't grok negative offsets the way the rest of the language does.
I think there might have been something about $/ and its currently
all-filehandle nature, but certainly that's there, too. There are
plenty more where that came from, but they're all easy and obvious
changes that could almost be called fixes to simple design oversights.
Nearly none of them seem to be being addressed.
--tom
