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