Re: Half measures all round
Brent wrote: > # And I'll be porting most of my 30 or so (not the Perl6:: > # ones, obviously). > > Why bother? You've already put P::RD and T::B effectively in the core! Not to mention Switch and Attribute::Handlers and Class::Contract and Class::Multimethods and Filter::Simple and Inline::Files. And eventually maybe even NEXT and Text::Reform and Quantum::Superpositions. Yes, my cunning plan is revealed: Perl 6 is nothing but a plot to reduce the number of modules I have to maintain! ;-) Damian
Re: Half measures all round
On 6/4/02 4:08 PM, "Brent Dax" <[EMAIL PROTECTED]> claimed: > Why bother? You've already put P::RD and T::B effectively in the core! > ;^) And Switch. And Next? And Q::S? Larry, have you decided on that one yet? :-) Regards, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
RE: Half measures all round
Damian Conway:
# Schwern wrote:
#
# > For what it's worth, I'm looking forward to porting my
# 50-odd modules
# > to Perl 6. In a lot of cases, I'll finally be able to remove some
# > awful hacks.
#
# And I'll be porting most of my 30 or so (not the Perl6::
# ones, obviously).
#
# There. Nearly 3% of the CPAN ported in two fell swoops! ;-)
Why bother? You've already put P::RD and T::B effectively in the core!
;^)
--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
Re: Half measures all round
Schwern wrote: > For what it's worth, I'm looking forward to porting my 50-odd modules to > Perl 6. In a lot of cases, I'll finally be able to remove some awful hacks. And I'll be porting most of my 30 or so (not the Perl6:: ones, obviously). There. Nearly 3% of the CPAN ported in two fell swoops! ;-) Damian
Re: Half measures all round
On Tue, Jun 04, 2002 at 03:53:18PM +0100, Dave Mitchell wrote: > One word: CPAN. For what it's worth, I'm looking forward to porting my 50-odd modules to Perl 6. In a lot of cases, I'll finally be able to remove some awful hacks. -- This sig file temporarily out of order.
Re: Half measures all round
On Tue, 4 Jun 2002 10:06:44 -0700 (PDT) Larry Wall <[EMAIL PROTECTED]> wrote: >It's really not that difficult to run two interpreters in the >same process. I already made Perl and Java run together nicely. Agree. >Scaffolding is supposed to be ugly. You wouldn't believe how ugly >the transitional form between Perl 4 and Perl 5 was, when half the The difference in software branches and highways is that software can be built completely off-site until it's reasonably functional, and then moved in on the back of a semi-trailer. There is no reason why we shouldn't produce a "Purely P6" virtual machine, parser, etc. first, then start building the scaffolding. -Melvin
Re: Half measures all round
At 5:40 PM +0100 6/4/02, Simon Cozens wrote: >Steve Simmons: >> We have said that perl5 will be *mostly* mechanically translatable into >> perl6. > >And we shall keep saying this until we believe that it is true? Coming from the man who wrote part of a Python->Perl converter? >Hubris is when you really do have it, enough so only the gods slap you >down. Pretentiousness is when you don't have it, and everyone slaps >you down. Arrogance is somewhere in between. Interesting quote... -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even Perl class: stemsystems.com/class teddy bears get drunk
Re: Half measures all round
Larry Wall: > That's exactly what I've been arguing for all along. Grr Thank you. Now I'm somewhat less concerned. And that makes the implementation much easier. It was just when people were saying that the parser needed to be sufficiently flexible to parse both languages that I got the heeby-jeebies. -- Britain has football hooligans, Germany has neo-Nazis, and France has farmers. -The Times
Re: Half measures all round
On Tue, 4 Jun 2002, Dave Mitchell wrote: > Having said that, I have real, real doubts that Perl 6 will ever be able > to execute Perl 5 code natively. Its not just a case a writing a new > parser and some P5-specific ops; P5 has so many special features, boundary > conditions and pecularies, that to get P6 to execute P5 is a task > equivalent to reimplementing P5 from scratch. I'm wondering if instead, > we continue to maintain the P5 src tree, and embed P5 within P6 (embed in > the sense of Apache and Mod_perl). Sick and ugly, but maybe more practical > than the alternatives. It also means that the P6 src doesn't have to be > saddled with knowing (much) about P5. Eventually of course the P5 bit > would have to be thrown away. That's exactly what I've been arguing for all along. Grr And that's why I see the "package" hack and the new :p5 modifier as having the weight of two features, not the weight of an entire re-implementation of Perl 5. It's really not that difficult to run two interpreters in the same process. I already made Perl and Java run together nicely. If anything the impedence mismatch between Perl 5 and Perl 6 will be even less. Scaffolding is supposed to be ugly. You wouldn't believe how ugly the transitional form between Perl 4 and Perl 5 was, when half the opcodes were interpreted by the old stacked interpreter, and half by the new stackless one. Larry
Re: Half measures all round
On Tue, 4 Jun 2002, Simon Cozens wrote: > Steve Simmons: > > We have said that perl5 will be *mostly* mechanically translatable into > > perl6. > > And we shall keep saying this until we believe that it is true? As a Perl user (the kind of guy who uses Perl at work for everything humanly possible), I personally don't have a use for backward compatibility at all. If there's a cool P5 module that I just *need* in P6, I'll port the thing myself. At work I will install the latest P5 and P6 at the same time. If I need P5 I'll use it, otherwise I'll use P6. I personally believe that getting P5 compatibility in Perl 6 is entirely possible, but I would never use it and I would perfer that the massive amount of work that would go into it, go into something else, like porting popular modules (like DBI, etc) or just plain working on the core language to make it all that it can be. Furthermore, *if* enough people could be motivated into creating such a compatibility layer (many people have noted the slowness at which development is happening now), I can't believe that it would be complete enough to rely on in a production system, but to be fair I may be underestimating the community in that respect. I think that compatibility is a goal that looks nice on paper, but as someone who's "in the trenches" I don't think it will be that useful to me. - D <[EMAIL PROTECTED]>
Re: Half measures all round
On Tue, 4 Jun 2002, Simon Cozens wrote: : Steve Simmons: : > We have said that perl5 will be *mostly* mechanically translatable into : > perl6. : : And we shall keep saying this until we believe that it is true? No, we'll keep saying this until we make it true. Faith without works is dead. Larry
Re: Half measures all round
On Tue, Jun 04, 2002 at 05:40:08PM +0100, Simon Cozens wrote: > Steve Simmons: > > We have said that perl5 will be *mostly* mechanically translatable into > > perl6. > And we shall keep saying this until we believe that it is true? *grin* My apologies for using the wrong name, Simon. Doh! -- STEP 4: PRACTICE THE RULE OF THREE: If an e-mail thread has gone back and forth three times, it is time to pick up the phone. from the 12-Step Program for email addicts, http://www.time.com/time/columnist/taylor/article/0,9565,257188,00.html
Re: Half measures all round
Steve Simmons: > We have said that perl5 will be *mostly* mechanically translatable into > perl6. And we shall keep saying this until we believe that it is true? -- Hubris is when you really do have it, enough so only the gods slap you down. Pretentiousness is when you don't have it, and everyone slaps you down. Arrogance is somewhere in between. - Thorfinn
Re: Half measures all round
On Tue, 4 Jun 2002, Simon Cozens wrote: : Dave Mitchell: : > > (Please CC me on replies) : : Actually, now I come to think of it, please don't CC on replies. One thing I : really hated about Perl 6 was the number of people sniping from the sidelines : providing no useful contribution. And now I've become one. Urgh. Don't stress. Whenever I see someone sniping from the sidelines, I take it as a clue that I haven't communicated well enough. : > One word: CPAN. : : I understand this argument, but it is bogus, and doesn't address my point. : Either we're breaking backwards compatibility and doing something very new, or : we're seeking to retain compatibility with the past. Which is it to be? Whenever someone asks "Which is it to be?", I always suspect they're setting up a false dichotomy. In this case, you're ignoring a very real engineering issue, which is migration strategy. Your question is posed in the eternal present tense, but this is a temporal issue. When they're building a new interchange on an interstate highway, they don't tear down the old one and then put up the new one. The traffic has to keep flowing. So over the course of time there will be various odd temporary roads that take you through and around the construction area, and you're always afraid the temporary scaffolding is going to come down on your head. But eventually the scaffolding does come down, and what's left is all concrete, and nobody remembers how the old road went. When DEC first invented the VAX, they put in an emulation of PDP-11 assembly language, because they knew it would take time for people to migrate. Eventually the emulation went away. Anyway, you seem to be saying that two features of Perl 5 scaffolding will ruin Perl 6. I think you haven't really thought about migration strategy long enough. : Yes, there's a lot of legacy crap out there. Much of the important parts of it : are XS, which we can't hope to support. (No, Dan, be realistic) So, let's go : through the CPAN argument: : : * Allowing CPAN code to be run in Perl 6 tantamounts to legitimizing its : use. In what sense does Perl 6 de-legitimize Perl 5 code? Perl 5 is as legitimate as it is. Perl 6 neither adds to nor takes anything away from that. Perl 6 may be better, but only if you have the Perl 6 code to run. We have to get there from here, and there has to be gentle but relentless pressure to migrate, but if Perl 6 really is better, that pressure will be there. Treating Perl 5 programs (and by extension, Perl 5 programmers) as illigitimate is not going to speed up the process. : * Legitimizing the legacy code means it'll never get ported to Perl 6 No, requiring everyone to translate everything all at once means nothing will get ported. Open source projects only know how to do things piecemeal. They don't know how to do things all at once. : * Producing Perl 5 results in a Perl 6 world may not make much sense : anyway. Don't understand what you're saying there. Data is data, and most results aren't either Perl 5 or Perl 6 results. They're just data. : * Subtle differences between P5 usage and P6 usage would give module : authors a support nightmare. Once you have a working P6 module, you can throw away the P5 module, or at least treat it as no-longer-supported. : * Some of those authors may not know about or want to support a Perl 6 : use of their module anyway. (Thank you for your bug report, but it : appears to be written in a different language.) Dinosaurs happen. But eventually they evolve into birds. : * Digging a pit for module authors to fall into considered unfriendly. Yeah, but we're using the extra dirt to raise a mountain for them to climb. The capacity for greater good always comes with the capacity for greater evil. : * It's still a backwards compatibility sop. Perl 4 libraries had to be : rewritten for Perl 5. I don't see why Perl 5 libraries should escape. Perl 5 libraries do have to be rewritten (or translated) for Perl 6. But that will only happen if Parrot can emulate Perl 5 long enough for people to climb each rung of the ladder one step at a time. Most people can't leap tall buildings in a single bound. Larry
Re: Half measures all round
On Tue, Jun 04, 2002 at 04:13:36PM +0100, Simon Cozens wrote: Hmm, June 4. Independence day, with an off by 1 error. Must be a C program involved somewhere. :-) In brief, I'm with Damien on this one. IMHO C++ is an ugly bastard of a programming language because they cut the cord ineffectively and much too late in the process. OOPerl is an ugly bastard of a language. We have the opportunity to clean that up; we should sieze it. As for CPAN . . . don't get me started. CPAN is a blessing, but has become a curse as well. It's contents need to be razed to the ground and better/more conistant rules set up for how to do installations into and out of the standard trees. If you think this is a bitch now, just wait until simultaneous per-author and per-version installation and invocation is allowed as Larry has promised. I have this horrible fear of perl module installations becoming a bowl of spagetti that's been run thru a blender and mixed with a packet of jello. Speaking as a 20+-year sysadmin, if CPAN is used for Perl6 with those new features and without a massive clean, I foresee a nightmare. We have said that perl5 will be *mostly* mechanically translatable into perl6. IMHO, that's close enough. Full backwards compatibility leads to paralysis or an even further expansion of the complexity and bizarreness that is all too often perl. We should draw the line on translation at a program that will translate p5 source to p6 source. We should not auto-compile it and tolerate it forever; that way lies madness. Sorry to be so pessistic and negative, but that's my story and I'm sticking to it.
Re: Half measures all round
On 6/4/02 8:13 AM, "Simon Cozens" <[EMAIL PROTECTED]> claimed: > Yes, there's a lot of legacy crap out there. Much of the important parts of it > are XS, which we can't hope to support. (No, Dan, be realistic) So, let's go > through the CPAN argument: Personally, I'm still really jazzed about Perl 6, but I certainly see your point, Simon. As a CPAN contributor myself, I intend, once Perl 6 is delivered, to port my modules to Perl 6 (where appropriate -- Data::Types likely won't even be necessary anymore!), and leave the Perl 5 stuff to slowly die off. I think that if we can agree to forego backwards compatibility, we might also be in a better position to set up a CP6AN with much better quality control. All of the most important modules will be ported very quickly (e.g., the DBI), and a lot of the cruft will be left to die (at least from the Perl 6 perspective). And I like the idea that the designers mentioned on Use Perl the other day, that Perl 6 may not ship with any add-ons, and there would instead be development kits available. This will have the affect of establishing n packages that are officially endorsed by the planners/maintainers, but don't burden the distribution. So I guess I'm agreeing with you, Simon. I have no problem with thinking of Perl 6 as a completely new language, and will be happy to work in both P5 and P6 in parallel for a while. And if my Perl 5 modules don't work in Perl 6, I will be motivated to port them. Plenty of folks are still dedicated to Perl 5, and it will likely to continue moving forward for some time -- it may never die. And I think that's true regardless of whether Perl 6 supports Perl 5 or not. So it's okay by me to dump it. Lots of people will freak out, but many won't. Regards, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
RE: Half measures all round
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 and C keywords will probably have slightly different
meanings, so C 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
Re: Half measures all round
Dave Mitchell: > > (Please CC me on replies) Actually, now I come to think of it, please don't CC on replies. One thing I really hated about Perl 6 was the number of people sniping from the sidelines providing no useful contribution. And now I've become one. Urgh. > One word: CPAN. I understand this argument, but it is bogus, and doesn't address my point. Either we're breaking backwards compatibility and doing something very new, or we're seeking to retain compatibility with the past. Which is it to be? Yes, there's a lot of legacy crap out there. Much of the important parts of it are XS, which we can't hope to support. (No, Dan, be realistic) So, let's go through the CPAN argument: * Allowing CPAN code to be run in Perl 6 tantamounts to legitimizing its use. * Legitimizing the legacy code means it'll never get ported to Perl 6 * Producing Perl 5 results in a Perl 6 world may not make much sense anyway. * Subtle differences between P5 usage and P6 usage would give module authors a support nightmare. * Some of those authors may not know about or want to support a Perl 6 use of their module anyway. (Thank you for your bug report, but it appears to be written in a different language.) * Digging a pit for module authors to fall into considered unfriendly. * It's still a backwards compatibility sop. Perl 4 libraries had to be rewritten for Perl 5. I don't see why Perl 5 libraries should escape. Anyway, I've done my Ancient Mariner bit now and given my warning. Be sure to cast off that albatross. -- Everything that can ever be invented has been invented - Charles H. Duell, Commisioner of U.S. Patents, 1899.
Re: Half measures all round
On Tue, Jun 04, 2002 at 10:43:02AM +0100, Simon Cozens wrote: > (Please CC me on replies) > > I don't often express many opinions on Perl 6 these days, but I feel I have to > warn people about what I see as a potential loss of direction. > > 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. > > 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. One word: CPAN. (Okay, that was three words.) It will be a long, long time before all the CPAN modules are rewritten in Perl 6. In the meantime, Perl 6 code has to be able to use Perl 5 modules, or it will be crippled, and probably stillborn. Having said that, I have real, real doubts that Perl 6 will ever be able to execute Perl 5 code natively. Its not just a case a writing a new parser and some P5-specific ops; P5 has so many special features, boundary conditions and pecularies, that to get P6 to execute P5 is a task equivalent to reimplementing P5 from scratch. I'm wondering if instead, we continue to maintain the P5 src tree, and embed P5 within P6 (embed in the sense of Apache and Mod_perl). Sick and ugly, but maybe more practical than the alternatives. It also means that the P6 src doesn't have to be saddled with knowing (much) about P5. Eventually of course the P5 bit would have to be thrown away. Dave. -- "There's something wrong with our bloody ships today, Chatfield." Admiral Beatty at the Battle of Jutland, 31st May 1916.
