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

Reply via email to