Simon Cozens:
# I'm becoming somewhat disillusioned with Perl 6 these days;
# sometimes because it's too radical, more often than not
# because it's not radical enough, and quite often because it's
# more than a year behind schedule and still slipping. But that
# last point is by the by; with three people now working
# full-time on it, I'm sure we can expect it any day now.
It's actually starting to get a bit scary... ;^)
# What's really actually letting me down with it is the
# half-measures we're applying. We seem to be trying to please
# everyone, and it's not going to work; indeed, it's going to
# end up presenting a burden to the implementors.
#
# Let's take an example. One of the major points of Perl 6, and
# one of its major attractions for me, was that we finally put
# the backwards compatibility ghost to rest. We can do brave,
# new, exciting things, without worrying about needing to
# maintain obscure pieces of functionality. Yey! Except that we
# can't do that any more; we've constrained ourselves to
# faithfully regressing to Perl 5 when we see a "package"
# declaration. Why? Because we're scared. "package parses Perl
# 5" is a sop to people who don't want to program in Perl 6,
# and we're worried about losing those people.
Who says it's a bad thing to be scared, or that our fear isn't
justified? Fear is a survival instinct, and a relatively good one.
In this case, I think what happened is closer to "we saw a hook to bring
in backwards compatibility and used it". Unless I'm mistaken, the new
C<class> and C<module> keywords will probably have slightly different
meanings, so C<package> was insufficient anyway. So we said, "OK, we're
changing this, and if we see it the old way we switch to Perl 5". I
don't think anyone's decided exactly what that means yet--we may load a
different rule set, set up some sort of source filter, or just cop out
and invoke p52p6. In any case, I think of it more as a convenience than
a major feature, and I suspect most Perl 6 users will agree with that
assessment.
# Maybe we've realised that we are going too far, and the new
# stuff doesn't look all that much like Perl 5, but we're not
# sufficiently committed to what we have to cut the umbilical
# cord. Are we going to innovate and improve Perl, no matter
# what the cost, or is this just a marketing exercise to draw
# in new users without scaring away the old ones?
#
# We have a wonderful new pattern matching language, with some
# really innovative ideas. It too is burdened by the beast of
# backwards compatibility. We're too worried about scaring
# people with change, so we provide these half-measure
# concessions to keep them happy.
Can you specify how? It looks to me like it's changed fairly
dramatically, but is still similar enough to be easy to adjust to.
# I feel like we're carrying around old luggage full of old and
# dirty clothes, and even when we pick up new suitcases and new
# clothes, we refuse to put down the old ones because they've
# been a part of our lives for so long. And so the burden gets
# heavier. The implementors have a tough enough job to do,
# dealing with a language which ended up being more difficult
# to parse and compile than Perl 5, not easier, and I suspect
# won't enjoy the extra baggage that's being forced upon them.
#
# So that's my warning: decide how innovative we're going to
# be. If we're really going to drive Perl forwards, let's not
# keep turning backwards, lest we end up as pillars of salt. If
# we're just giving Perl a spring clean, then maybe we've
# already gone too far. But let's not get stuck in the middle,
# doling out half measures all round.
Just because we're trying to make radical changes doesn't mean we can't
make a small sacrifice to the backwards-compatibility gods. After all,
it would be kinda nice if there were users besides p6* list members, and
I doubt it'll work without at least the small sacrifice of imperfect
emulation. (And I don't believe we're promising perfect emulation,
either--just "we'll try our best".)
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
blink: Text blinks (alternates between visible and invisible).
Conforming user agents are not required to support this value.
--The W3C CSS-2 Specification
