Re: 6PAN (was: Half measures all round)
On Thu, Jun 13, 2002 at 12:00:13AM +0300, [EMAIL PROTECTED] wrote: > > |On 6/4/02 12:22 PM, David Wheeler wrote: > |> 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), Actually I doubt that complex extensions with lots of XS/C code will get ported "very quickly" since the work involved may be considerable. That's one of the reasons I've put so much effort into making DBI::PurePerl a viable tool. It'll automatically give people a working Perl6 DBI (for pure-perl drivers) as soon as there's a working perl5-to-perl6 translator. Tim.
Re: 6PAN (was: Half measures all round)
|On 6/4/02 12:22 PM, David Wheeler wrote: |> 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). | |Speaking of "CPAN for Perl 6" (or "CP6AN", or "6PAN"), what's the status of |this effort? Do we even have a vague idea of the requirements? Or does |everyone think CPAN (and module distribution/installation in general) as it |exists now it pretty much okay, and just needs some tweaks to work with Perl |6 code? I really hope that's not the case! :) ]- I think there is CPANTS initiative underway which may be will solve some of ]problems of the current CPAN... there was even a write-up on www.perl.com about it ...
Re: 6PAN (was: Half measures all round)
For the record, you will hear no disagreement from me. I recognize that this is a HARD problem. Nonetheless, I think it's an important one, and solving it (even imperfectly, by only supporting well-defined platforms) would be a major coup. --Josh At 23:31 on 06/05/2002 BST, Nicholas Clark <[EMAIL PROTECTED]> wrote: > On Wed, Jun 05, 2002 at 12:55:36AM -0400, Josh Wilmes wrote: > > > > Good stuff. Sounds halfway between CPAN.pm and activestate's ppm. See > > also debian's apt-get. > > > > Which brings me to my pet peeve- I think it's time to start doing binary > > packaging in CPAN, for those who don't want to bother with compilation. > > > > That has interesting implications for how we deal with paths, but still, I > > think it's worthwhile. > > > > Of course you would want to support source as well, but having binary > > available for those who want it just seems like a darn good idea. > > OK. Say I want binaries for my 3 boxes: > > On Bagpuss /usr/local/bin/perl -v says: > > This is perl, v5.8.0 built for armv4l-linux > (with 1 registered patch, see perl -V for more detail) > > but you had better actually build that with -v3 flags on your ARM compiler > because my machine's hardware can't cope with the v4 instructions on the CPU > > On Thinking-Cap /usr/local/bin/perl -v says: > > This is perl, version 5.004_05 built for i386-freebsd > > Copyright 1987-1998, Larry Wall > > 5.004 is officially still supported, and some modules do build on 5.004 > > [Third box, Marvellous-Mechanical-Mouse-Organ is an SGI Indy and doesn't > doesn't want to power up for some reason, probably because it's been off > for about 12 months] > > I presume you're going to suggest that they are too obscure for binary CPAN > to support them. So limit things to the most recent perl. But having > experimented with trying to ship 5.8.0-RC1 between FreeBSD versions, there > are sufficient changes between libc on 4.4 STABLE and 4.5 STABLE such that > you can't run a binary compiled on 4.5 on a 4.4 box due to missing symbols. > So you're starting to enter version compatibility nightmare. > > And if you have module needing a C++ compiler, are you going to ship your > x86 linux binaries using RedHat's 2.96, or a real gcc? > > And are you doing dependencies, or are you interfacing with the OS package > manager? And if you're not interfacing, but you are adding modules to the > OS perl, then what do you do if one of your dependency modules is already > there? Do you just go "oh good", have binary CPAN say nothing, and then > hope that the OS packaging system doesn't remove the dependency module from > under you? > > I believe that binary CPAN would have problems that scale as the number > of OS subversions that binary CPAN would try to support. > > This may sound rather negative, but it basically means that I'm feeling > sufficiently pessimistic that I don't think there are reasonable solutions > to the problems. However, that's only my opinion, and others' will differ. > > On the other hand, I think the idea of multiple platforms automatic CPAN > testing is a very good idea. > > Nicholas Clark > -- > Even better than the real thing: http://nms-cgi.sourceforge.net/
Re: 6PAN (was: Half measures all round)
> For the record, you will hear no disagreement from me. I recognize that > this is a HARD problem. Nonetheless, I think it's an important one, and > solving it (even imperfectly, by only supporting well-defined platforms) > would be a major coup. I'd like to take that even further: just supporting Win32 binaries would be a major coup. Very few windows users can compile, but a much more significant percent of Un*x users can. A few more ways to address issues of multi-platform (my favorite is at the end): - Divide and conquer: design the 6PAN so that individuals and small groups can set up their own binary specific distribution sites. One person might decide to set up a Win32 distribution site, another a Mac distribution site. They can all register on the central 6PAN server. Users can then choose which distributions they prefer in general. - Unit testing: with binaries it becomes more imperative that downloaded modules are rigourously tested. Unit tests should be distributed with modules, and download clients should have a way of saving errors and (if the user givesd permission) sending them back to the developer. - My favorite: don't do binaries. With bytecode Pure Perl makes all the more sense. I'm not saying binaries should be prohibited, but the culture should steer away from them.
Re: 6PAN (was: Half measures all round)
On Wed, Jun 05, 2002 at 12:55:36AM -0400, Josh Wilmes wrote: > > Good stuff. Sounds halfway between CPAN.pm and activestate's ppm. See > also debian's apt-get. > > Which brings me to my pet peeve- I think it's time to start doing binary > packaging in CPAN, for those who don't want to bother with compilation. > > That has interesting implications for how we deal with paths, but still, I > think it's worthwhile. > > Of course you would want to support source as well, but having binary > available for those who want it just seems like a darn good idea. OK. Say I want binaries for my 3 boxes: On Bagpuss /usr/local/bin/perl -v says: This is perl, v5.8.0 built for armv4l-linux (with 1 registered patch, see perl -V for more detail) but you had better actually build that with -v3 flags on your ARM compiler because my machine's hardware can't cope with the v4 instructions on the CPU On Thinking-Cap /usr/local/bin/perl -v says: This is perl, version 5.004_05 built for i386-freebsd Copyright 1987-1998, Larry Wall 5.004 is officially still supported, and some modules do build on 5.004 [Third box, Marvellous-Mechanical-Mouse-Organ is an SGI Indy and doesn't doesn't want to power up for some reason, probably because it's been off for about 12 months] I presume you're going to suggest that they are too obscure for binary CPAN to support them. So limit things to the most recent perl. But having experimented with trying to ship 5.8.0-RC1 between FreeBSD versions, there are sufficient changes between libc on 4.4 STABLE and 4.5 STABLE such that you can't run a binary compiled on 4.5 on a 4.4 box due to missing symbols. So you're starting to enter version compatibility nightmare. And if you have module needing a C++ compiler, are you going to ship your x86 linux binaries using RedHat's 2.96, or a real gcc? And are you doing dependencies, or are you interfacing with the OS package manager? And if you're not interfacing, but you are adding modules to the OS perl, then what do you do if one of your dependency modules is already there? Do you just go "oh good", have binary CPAN say nothing, and then hope that the OS packaging system doesn't remove the dependency module from under you? I believe that binary CPAN would have problems that scale as the number of OS subversions that binary CPAN would try to support. This may sound rather negative, but it basically means that I'm feeling sufficiently pessimistic that I don't think there are reasonable solutions to the problems. However, that's only my opinion, and others' will differ. On the other hand, I think the idea of multiple platforms automatic CPAN testing is a very good idea. Nicholas Clark -- Even better than the real thing:http://nms-cgi.sourceforge.net/
Re: 6PAN (was: Half measures all round)
At 12:55 AM -0400 6/5/02, Josh Wilmes wrote: >Good stuff. Sounds halfway between CPAN.pm and activestate's ppm. See >also debian's apt-get. > >Which brings me to my pet peeve- I think it's time to start doing binary >packaging in CPAN, for those who don't want to bother with compilation. > >That has interesting implications for how we deal with paths, but still, I >think it's worthwhile. The biggest issues with binaries are relocatability (which is a problem on some OSes), build options, compiler compatibility, and size. Size is the biggest obvious problem--there are a lot of modules with C code, and object code is generally larger than the C it came from, often by an order of magnitude or two. Multiply that by the potential number of OS/compiler/perl build options and you get a number that's rather large. The rest are just complicated icing on the cake. -- 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: 6PAN (was: Half measures all round)
At 2:59 PM -0400 6/5/02, Steve Simmons wrote: >My seat of the pants number say our current tools (which use DBI to >access databases) spend about as 10% of their CPU and wall clock time >in compilation. This is measured by deliberately running the tools >with an error (bad switch) vs running it correctly and comparing >the times. Go to a module/version/release seach pattern and a >ten-fold minimum increase in serach time . . . and you double the tool >run times. That's intolerable in our environment. I recently spent >a solid month peeling 9 seconds of per-tool overhead down to 1 second, >getting a documented(!) savings of 16.25 hours *per week* in our >operations group. The prospect of losing that time again with perl6 >is, er, not acceptable. Again, this argues towards indexes. Nah. It argues for precompilation and a faster engine, both of which you'll get. :) -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: 6PAN (was: Half measures all round)
On 6/5/02 2:59 PM, Steve Simmons wrote: > Sticking just to the disk-intensive issue for a moment -- > [...] > With the new one, we seem to have agreed that `most recent' will be > used, not `first found'. That means that every tree must be probed, > and probed with globs or sub-searches to match the various author, > version, $RELEASE, etc stuff. > [...] > I recently spent a solid month peeling 9 seconds of per-tool overhead down to > 1 second, getting a documented(!) savings of 16.25 hours *per week* in our > operations group. The prospect of losing that time again with perl6 is, er, > not acceptable. Again, this argues towards indexes. More generally, I'd just call it caching. This can be done in many ways: cached "flattened" bundle files, traditional indexes, or even simply another module that does some (or all) of this for you, when needed, by augmenting the "use" implementation with its own cached information: use Module::Cache; use Foo; # subsequent "use"s are faster now! :) use Bar; ... There may be some bootstrapping issues, but so far everything in Perl 6 seems up for "user replacement/augmentation." Why not "use" as well? :) >>> The current perl module tree is pretty difficult for the average day to >>> day scripter to comprehend. I'd go even further and say that it's so >>> complex as to be unmanagable. >> >> Encapsulating by module would make the structure pretty easy to understand, >> IMO. > > Yes, that would help with the understanding. It would not help with > the search time overhead. But that's fixable. It's much harder to make an inherently confusing (but "fast") on-disk organization "more understandable", IMO :) -John
Re: 6PAN (was: Half measures all round)
On Tue, Jun 04, 2002 at 04:15:02PM -0400, John Siracusa wrote in response to me: > > Frankly, I'd argue that nothing in 6PAN ought to be in alpha/beta state. > . . . > Nah, I think it's useful to be able to upload "unstable" versions to 6PAN to > get the widest possible audience of testers. It's a lot easier than hosting > it on a web site or whatever--for both the developer and the users. . . . True, true. You've convinced me. > > . . . . With (potentially) many modules having > > the same name and multiple authors/versions, the current complexity of > > the perl /lib tree could increase to the third power. That gonna be > > very disk-intensive for every frigging perl script that runs. > > See my earlier framework/bundle suggestion. I don't think it's that bad, > disck-access-wise. Sticking just to the disk-intensive issue for a moment -- Due to our judicious writing of modules, libraries, etc, we tend to have a lot have relatively simple (less than 1000 lines) scripts that do quite useful things for managing our network (sorry, can't talk about 'em -- proprietary software and all that sort of rot). Each tool does a direct use or require of about a half-dozen things, but our master modules and libs grab quite a few more. All in all I guestimate we're loading anywhere from 30 to 100 modules per `simple' tool run. With standard @INC plus our two or three more, that's 8-10 directory trees that must be searched. The current perl module naming schema means (essentially) one probe per directory per package until the module is found. Once it's found, all is done. With the new one, we seem to have agreed that `most recent' will be used, not `first found'. That means that every tree must be probed, and probed with globs or sub-searches to match the various author, version, $RELEASE, etc stuff. Only once we know what's available can we make an intelligent `most recent' decision. At a minimum, with 10 items in @INC we have a tenfold increase in number of dir reads. Then add in the checking for author, version, etc ... and we've got to either embed the author/version/release data into the file names (the horror, the horror) or open the individual modules and read the author/version/release data from each one (the horrorer, the horrorer). This very strongly argues towards indexes. My seat of the pants number say our current tools (which use DBI to access databases) spend about as 10% of their CPU and wall clock time in compilation. This is measured by deliberately running the tools with an error (bad switch) vs running it correctly and comparing the times. Go to a module/version/release seach pattern and a ten-fold minimum increase in serach time . . . and you double the tool run times. That's intolerable in our environment. I recently spent a solid month peeling 9 seconds of per-tool overhead down to 1 second, getting a documented(!) savings of 16.25 hours *per week* in our operations group. The prospect of losing that time again with perl6 is, er, not acceptable. Again, this argues towards indexes. > > The current perl module tree is pretty difficult for the average day to > > day scripter to comprehend. I'd go even further and say that it's so > > complex as to be unmanagable. > > Encapsulating by module would make the structure pretty easy to understand, > IMO. Yes, that would help with the understanding. It would not help with the search time overhead. > Disk space and RAM are cheap and getting cheaper. Think about what you mean > by "gigantic." Anyone who exhausts memory by running 150 different versions > of the Tk module at once deserves what they get ;) > > > On the other hand, there's no reason that shared libs couldn't be stored in a > > standard location and symlinked to. > > Yes there is: sanity! I think that's a foolish optimization. It makes > things much too fragile. Stuff like that already drives me nuts in regular > Unix OS/app installations. I picked Tk as my example because it *cannot* work with multiple versions of the shared libraries (the .so files, not the perl modules) simultaneously. Every window, every widget, every Ghu-knows-what down to a fairly low level must reside in the same context. If they don't, subwindows don't get managed properly, widgets from version X can't be attached to units from version Y, etc, etc. The same is almost certianly true of DBI modules, Gnome modules, and many others. The 6PAN installation tree and perl6 module builds must be able to deal with this issue. If they don't, then Larry's promise of the ability of simultaneous load is only going to apply to pure perl modules. But I don't think that's what Larry means, and I don't think it's a restriction we *have* to live with. Steve -- 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,2
Re: 6PAN (was: Half measures all round)
On Tue, Jun 04, 2002 at 01:11:58PM -0700, David Wheeler wrote: > On 6/4/02 12:59 PM, "Steve Simmons" <[EMAIL PROTECTED]> claimed: > > > Actually, for 6PAN I think they should have to pass. And maybe we > > need a bug submission setup, and status checks, and . . . OK, OK, I'll > > stop now. They're nice ideas, but who bells the cat? The again, if > > Tim O'Reilly wants to fund me I'd be happy to do it. :-) > > On what platform(s)? Who's going to pay for the test bed for every possible > combination of perl version, OS, various libraries, etc., etc.? I think that > *requiring* that all tests pass is unrealistic. Perhaps so, but I'd prefer to see this as a goal and fall short rather than set our sights lower and achieve an empty success. As for funding - well, one source has been mentioned above. Another might be the H/W vendors. Suppose we modify the proposal to have a list of systems on which the module has been known to pass (or fail) self-test? Get H/W and O/S donations from Sun, HP, etc, volunteer labor to assemble a test framework, and then let people upload. On the web page for a given 6PAN module put a pass/fail indicator for all the stuff that vendors have donated. Vendor X wants to be on the list? Let 'em donate hardware, S/W, and (maybe eventually) something towards overhead. Hmmm, we may have a good idea here...
Re: 6PAN (was: Half measures all round)
Good stuff. Sounds halfway between CPAN.pm and activestate's ppm. See also debian's apt-get. Which brings me to my pet peeve- I think it's time to start doing binary packaging in CPAN, for those who don't want to bother with compilation. That has interesting implications for how we deal with paths, but still, I think it's worthwhile. Of course you would want to support source as well, but having binary available for those who want it just seems like a darn good idea. Of course there would be issues of who's providing the binaries, how they are built, how external dependencies on third-party libraries are managed, etc, but still, I think it's worth looking into. It might not be a problem that's worth solving, in the end, but I think it's one worth giving serious thought to. --Josh At 23:38 on 06/04/2002 EDT, "Miko O'Sullivan" <[EMAIL PROTECTED]> wrote: > [This seems like a good time to post something that's been on my mind for > some time.] > > SUMMARY > > The world needs a really easy CPAN client. Here's one design for such a > thing. > > DETAILS > > A few brief philosphical points: > > 1) People like languages that have tons of built-in > doohickeys. See PHP and Java. > > 2) Instead of a huge standard library, a really easy to use CPAN > client allows programmers to have the world of modules almost > as easily as built-in, and with the advantage of up-to-date-ness > and quantity. > > 3) The current CPAN.pm isn't really easy to use. Now matter how > simple it may seem to the Perl Guru community, inexperienced > users find it intimidating to download CPAN modules. > Remember: beginners end up ruling the world. See Microsoft. > > Solution: a simple program that is called from the command line. Here's a > brief tour: > > Download and install a module from CPAN. Loading a module also automatically > loads its dependencies. > >cpan load Date::EzDate > > The command above would ask the user if they want to install using the > current directory as the root of library tree, and is also mentions that if > they want to specify another dir they can use this command: > >cpan --lib ~/lib load Date::EzDate > > Update a module. > >cpan update Date::EzDate > > Don't download dependencies: > >cpan --dep 0 load Date::EzDate > > Update all currently installed modules: > >cpan update * > > Update a namespace: > >cpan update Date::* > > Get help on using cpan: > >cpan help > > No configuration files (.e.g .cpan) are necessary. However, you can use a > configuration file if you want tp indicate a .cpan-like file > >cpan --conf ~/.cpan load Date::EzDate > > Get from a particular FTP server > >cpan --server cpan.idocs.com load Date::EzDate > > By default, progress messages are kept to a minimum. No more of those > hundreds of lines of bewildering make messages. > >cpan --lib ~/perllib load Date::EzDate >finding server >downloading module >determining dependencies >downloading dependencies >installing >done > > Optional verbose mode >cpan --verbose load Date::EzDate >(hundreds of lines of lovely make messages) > > Request particular operating system compilation (e.g. Win32) > (usually not needed explicitly because cpan.pl will know which compilation > to ask for) > >cpan --compile win32 load Date::EzDate > > Indicate latest development vs. latest stable > >cpan --latest beta load Date::EzDate > > Remove a module >cpan remove Date::EzDate > > > - > Other Misc CPAN Ideas > > - Authors don't need to indicate dependencies. CPAN figures it out from the > use's and require's. CPAN will not accept modules that depend on other > modules that aren't on CPAN. (Yes, there might be a chicken and egg problem > there, I'm sure we can find a solution.) This leads me to... > > - Run-time dependencies: Dependencies can be indicated explicitly with > something like this: > > use Dependency Date::Language::French; > > - CPAN conformity: All modules served from CPAN must meet certain > specifications. They must include a version, POD, license statement, and > probably other meta-info. The meta-info would be standardized so that the > system could tell that the module conforms. > > - Automated load balancing: cpan.perl.org doesn't have to pay for the > bandwidth of the whole world. cpan.pl should recognize a command from > CPAN.org to redirect to another server. > > - 6pan.org: The domain name 6pan.org is available as of this writing. Larry, > are you planning on saying "6PAN" enough to merit somebody registering > 6pan.org? > >
Re: 6PAN (was: Half measures all round)
On Tue, 4 Jun 2002, Luke Palmer wrote: > On Tue, 4 Jun 2002, Miko O'Sullivan wrote: > > > No configuration files (.e.g .cpan) are necessary. However, you can use a > > configuration file if you want tp indicate a .cpan-like file > > > >cpan --conf ~/.cpan load Date::EzDate > > What about no configuration file if ~/.6pan's not there, and ~/.6pan if it > is. Personally, I'd like it to: 1) work just fine without a config file, 2) if I specify one, it uses that, 3) if I don't specify one, but the default exists, it uses that 4) if it uses a config file (specified or default) it shows the full path to what it's using, so that I have a chance of detecting Trojans and typos if I'm paying attention (I don't need or want it to ask for confirmation, just show a message and maybe 'sleep 1' before continuing) > > - Authors don't need to indicate dependencies. CPAN figures it out from the > > use's and require's. CPAN will not accept modules that depend on other > > modules that aren't on CPAN. (Yes, there might be a chicken and egg problem > > there, I'm sure we can find a solution.) This leads me to... > Having it figure out the dependencies is definitely a major plus. As to how to solve the chicken-and-egg...just provide a way to upload multiple separate modules simultaneously. Dave
Re: 6PAN (was: Half measures all round)
On Tue, Jun 04, 2002 at 10:48:06PM -0600, Luke Palmer wrote: > Hmm... I like it. It took me a good 6 months before I learned how to use > CPAN. I don't see how your proposal is that different from: > > alias cpan='perl -MCPAN -e shell' CPAN.pm already installs a cpan program for you that's exactly that. schwern@blackrider:/usr/local/src/CPAN/CPAN-1.61$ cat cpan #!/usr/bin/perl use CPAN; shell; As for the rest of the message, this all seems to already exist, in one form or another, in the CPAN shell or CPANPLUS shell. If you want to see a better CPAN shell, don't wait for Perl 6! Help the CPANPLUS folks out now! http://cpanplus.sourceforge.net/ > But I get the idea. Someone (well, you've inspired me now, so I) could > write a perl5 equivilent, because command line is quite nice. I'll see > how it flies with my next class. > > More comments below. > > On Tue, 4 Jun 2002, Miko O'Sullivan wrote: > > > [This seems like a good time to post something that's been on my mind for > > some time.] > > Sure. It's been pretty dull around here. > > > DETAILS > > > > A few brief philosphical points: > > > > 1) People like languages that have tons of built-in > > doohickeys. See PHP and Java. > > See Perl 5 (though PHP and Java far exceed it, in doohickeys) > > > 2) Instead of a huge standard library, a really easy to use CPAN > > client allows programmers to have the world of modules almost > > as easily as built-in, and with the advantage of up-to-date-ness > > and quantity. > > Indeed. And it should be _really_ easy to install to a different source > tree and have Perl use it. I want more modules on systems I don't > administrate, and asking for them is a pain. > > > The command above would ask the user if they want to install using the > > current directory as the root of library tree, and is also mentions that if > > they want to specify another dir they can use this command: > > > >cpan --lib ~/lib load Date::EzDate > > Hmm... yeah, I think that's as easy as library root's gonna get. I like > C better than C, though. -- This sig file temporarily out of order.
Re: 6PAN (was: Half measures all round)
Hmm... I like it. It took me a good 6 months before I learned how to use CPAN. I don't see how your proposal is that different from: alias cpan='perl -MCPAN -e shell' But I get the idea. Someone (well, you've inspired me now, so I) could write a perl5 equivilent, because command line is quite nice. I'll see how it flies with my next class. More comments below. On Tue, 4 Jun 2002, Miko O'Sullivan wrote: > [This seems like a good time to post something that's been on my mind for > some time.] Sure. It's been pretty dull around here. > DETAILS > > A few brief philosphical points: > > 1) People like languages that have tons of built-in > doohickeys. See PHP and Java. See Perl 5 (though PHP and Java far exceed it, in doohickeys) > 2) Instead of a huge standard library, a really easy to use CPAN > client allows programmers to have the world of modules almost > as easily as built-in, and with the advantage of up-to-date-ness > and quantity. Indeed. And it should be _really_ easy to install to a different source tree and have Perl use it. I want more modules on systems I don't administrate, and asking for them is a pain. > The command above would ask the user if they want to install using the > current directory as the root of library tree, and is also mentions that if > they want to specify another dir they can use this command: > >cpan --lib ~/lib load Date::EzDate Hmm... yeah, I think that's as easy as library root's gonna get. I like C better than C, though. > Don't download dependencies: > >cpan --dep 0 load Date::EzDate So, what's the difference between --dep 2 and --dep 3? Is that depth or something? Or max number? > Update all currently installed modules: > >cpan update * Oh, if only shells could DWIM... Naturally this would do cpan update and then every file in the current directory. To remedy this you have to do some awful thing like: cpan update \* or cpan update '*' Maybe 'all' would serve the purpose better. > Update a namespace: > >cpan update Date::* I like that idea a lot. > Get help on using cpan: > >cpan help Err, howsabout the GNU way... cpan --help > No configuration files (.e.g .cpan) are necessary. However, you can use a > configuration file if you want tp indicate a .cpan-like file > >cpan --conf ~/.cpan load Date::EzDate What about no configuration file if ~/.6pan's not there, and ~/.6pan if it is. > By default, progress messages are kept to a minimum. No more of those > hundreds of lines of bewildering make messages. > >cpan --lib ~/perllib load Date::EzDate >finding server >downloading module >determining dependencies >downloading dependencies >installing >done We could just go with the idiomatic "don't say anything unless it's bad." I've developed a taste for that. Perhaps this is better for the default and you can enable quiet through ~/.6pan. > - > Other Misc CPAN Ideas > > - Authors don't need to indicate dependencies. CPAN figures it out from the > use's and require's. CPAN will not accept modules that depend on other > modules that aren't on CPAN. (Yes, there might be a chicken and egg problem > there, I'm sure we can find a solution.) This leads me to... What about version discrepancies? I guess that can come from the Cs. > - Automated load balancing: cpan.perl.org doesn't have to pay for the > bandwidth of the whole world. cpan.pl should recognize a command from > CPAN.org to redirect to another server. Definitely. I like on-6pan mirrors better than on-client mirrors. About the name 6PAN... I mean it reads well, but does it mean anything? The, er, 6 Perl Archive Network? RCPAN? Really Comprehensive Perl Archive Network? :) Or just PAN? I got nuthin'. Luke
Re: 6PAN (was: Half measures all round)
[This seems like a good time to post something that's been on my mind for some time.] SUMMARY The world needs a really easy CPAN client. Here's one design for such a thing. DETAILS A few brief philosphical points: 1) People like languages that have tons of built-in doohickeys. See PHP and Java. 2) Instead of a huge standard library, a really easy to use CPAN client allows programmers to have the world of modules almost as easily as built-in, and with the advantage of up-to-date-ness and quantity. 3) The current CPAN.pm isn't really easy to use. Now matter how simple it may seem to the Perl Guru community, inexperienced users find it intimidating to download CPAN modules. Remember: beginners end up ruling the world. See Microsoft. Solution: a simple program that is called from the command line. Here's a brief tour: Download and install a module from CPAN. Loading a module also automatically loads its dependencies. cpan load Date::EzDate The command above would ask the user if they want to install using the current directory as the root of library tree, and is also mentions that if they want to specify another dir they can use this command: cpan --lib ~/lib load Date::EzDate Update a module. cpan update Date::EzDate Don't download dependencies: cpan --dep 0 load Date::EzDate Update all currently installed modules: cpan update * Update a namespace: cpan update Date::* Get help on using cpan: cpan help No configuration files (.e.g .cpan) are necessary. However, you can use a configuration file if you want tp indicate a .cpan-like file cpan --conf ~/.cpan load Date::EzDate Get from a particular FTP server cpan --server cpan.idocs.com load Date::EzDate By default, progress messages are kept to a minimum. No more of those hundreds of lines of bewildering make messages. cpan --lib ~/perllib load Date::EzDate finding server downloading module determining dependencies downloading dependencies installing done Optional verbose mode cpan --verbose load Date::EzDate (hundreds of lines of lovely make messages) Request particular operating system compilation (e.g. Win32) (usually not needed explicitly because cpan.pl will know which compilation to ask for) cpan --compile win32 load Date::EzDate Indicate latest development vs. latest stable cpan --latest beta load Date::EzDate Remove a module cpan remove Date::EzDate - Other Misc CPAN Ideas - Authors don't need to indicate dependencies. CPAN figures it out from the use's and require's. CPAN will not accept modules that depend on other modules that aren't on CPAN. (Yes, there might be a chicken and egg problem there, I'm sure we can find a solution.) This leads me to... - Run-time dependencies: Dependencies can be indicated explicitly with something like this: use Dependency Date::Language::French; - CPAN conformity: All modules served from CPAN must meet certain specifications. They must include a version, POD, license statement, and probably other meta-info. The meta-info would be standardized so that the system could tell that the module conforms. - Automated load balancing: cpan.perl.org doesn't have to pay for the bandwidth of the whole world. cpan.pl should recognize a command from CPAN.org to redirect to another server. - 6pan.org: The domain name 6pan.org is available as of this writing. Larry, are you planning on saying "6PAN" enough to merit somebody registering 6pan.org?
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: 6PAN (was: Half measures all round)
On 6/4/02 3:59 PM, Steve Simmons wrote: >> : 1c. Distinctions like "alpha", "beta", and "stable" need to be made >> : according to some convention (a la $VERSION...perhaps $STATUS?) >> >> Can probably burn that bridge when we get to it. > > Frankly, I'd argue that nothing in 6PAN ought to be in alpha/beta state. > An author could make a package available that was in that condition, > but it shouldn't be uploaded to 6PAN. Once one has that restrition, > $STATUS isn't really needed. The adventurous will upload the alpha > code from the author and install it into the 6PAN tree by specifying some > sort of `force' flag. Thereafter, our adventurere is on his own. Nah, I think it's useful to be able to upload "unstable" versions to 6PAN to get the widest possible audience of testers. It's a lot easier than hosting it on a web site or whatever--for both the developer and the users. Obviously the 6PAN shell would install "latest stable" by default, but interested parties could get a glimpse of the future if they wanted, and with no harm done to existing code. Also think about the ramp-up to the first stable release. Users may want to try out all the pre-stable versions because they're better than nothing, even if they understand that there I no "API contract" until the first stable release. > On Tue, Jun 04, 2002 at 11:13:53AM -0700, Austin Hastings wrote: >> The following examples of font names are derived from the screen fonts >> shipped with the X Consortium distribution. >> >> Charter 12 pt ... >> -Bitstream-Charter-Medium-R-Normal--12-120-75-75-P-68-IO8859-1 >> Charter Bold 12 pt ... >> -Bitstream-Charter-Bold-R-Normal--12-120-75-75-P-76-ISO8859-1 >> Charter Bold Italic 12 pt ... >> -Bitstream-Charter-Bold-I-Normal--12-120-75-75-P-75-ISO8859-1 >> Charter Italic 12 pt ... >> -Bitstream-Charter-Medium-I-Normal--12-120-75-75-P-66-ISO8859-1 > . . . > > I was about to run screaming from the room until reading the item a bit > closer. No no, you should still run screaming :) > My current understanding (my hope) is that just saying > > use foo; > > always gets you the latest foo. With (potentially) many modules having > the same name and multiple authors/versions, the current complexity of > the perl /lib tree could increase to the third power. That gonna be > very disk-intensive for every frigging perl script that runs. See my earlier framework/bundle suggestion. I don't think it's that bad, disck-access-wise. > The current perl module tree is pretty difficult for the average day to > day scripter to comprehend. I'd go even further and say that it's so > complex as to be unmanagable. Encapsulating by module would make the structure pretty easy to understand, IMO. > In re putting everything for a given module into a given directory -- > it's a good thought, but I foresee problems with shared libraries > (.so files). With a gigantic module like the Tk:: core, you don't always > want multiple copies of each shared lib for each Tk:: version. It just > ain't gonna fly. Disk space and RAM are cheap and getting cheaper. Think about what you mean by "gigantic." Anyone who exhausts memory by running 150 different versions of the Tk module at once deserves what they get ;) > On the other hand, there's no reason that shared libs couldn't be stored in a > standard location and symlinked to. Yes there is: sanity! I think that's a foolish optimization. It makes things much too fragile. Stuff like that already drives me nuts in regular Unix OS/app installations. -John
Re: 6PAN (was: Half measures all round)
On 6/4/02 12:59 PM, "Steve Simmons" <[EMAIL PROTECTED]> claimed: >> It shouldn't be required that all tests pass, however. A statement showing >> what platforms they pass on and what platforms they don't at the top of the >> download page would be good enough. But the tests have got to be there. > > Actually, for 6PAN I think they should have to pass. And maybe we > need a bug submission setup, and status checks, and . . . OK, OK, I'll > stop now. They're nice ideas, but who bells the cat? The again, if > Tim O'Reilly wants to fund me I'd be happy to do it. :-) On what platform(s)? Who's going to pay for the test bed for every possible combination of perl version, OS, various libraries, etc., etc.? I think that *requiring* that all tests pass is unrealistic. Regards, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: 6PAN (was: Half measures all round)
On Tue, Jun 04, 2002 at 12:59:38PM -0400, John Siracusa wrote: > In the spirit of Simon's desire to see "radical changes" when appropriate, I > propose the following high-level goals for 6PAN . . . > 1. Multiple versions of the same module may be installed on a single system > with no possibility of conflicts. That means no conflicts of any kind, > whether it be in Perl code, XS-ish stuff, private shared libs, etc. Larry has stated this as a goal, and in this thread on Tue, Jun 04, 2002 at 10:26:22AM -0700, Larry Wall wrote: > Yes, I'm already on record that multiple installed versions will > coexist peacably, certainly on disk, and to the extent that they can > in memory. We can't stop two versions of a module from fighting over a > shared resource, for instance . . . And that's an issue that needs to be resolved -- modules are going to have to be able to test for each others state of being loaded and have some mechanisms to disambiguate and defer to each other. I won't go down the sytactic rathole of what *that* entails, just noting it as an issue. Back to John S: > : 2. Module packaging, expansion, and installation only requires a working > : install of Perl 6 (unless the module contains non-Perl code, such as C, > 3. Module removal should be as easy as installation. Yes, yes. > 1a. Modules may be "use"-ed in several ways (syntax ignored for now): I addressed a few of these in RFC78 and quite a few more in an as-yet unpublished rewrite of it; Larry mentioned a line or two of syntax in a recent email that's not terribly dissimilar. All the things you specify are relatively easy in the perl world. It's mapping them into filenames and directories that @INC can use that gets, er, interesting. However . . . > 1b. 6PAN modules comply with an informal contract to maintain > backward-compatibility within all N.MM versions, where N is constant. . . IMHO it should be a stated requirement, just as one needs a Makefile.PL. And while person's tweak is another persons incompatible blotch, we ultimately have to defer to `in the opinion of the author.' On Tue, Jun 04, 2002 at 10:11:40AM -0700, David Wheeler responds to Johns stuff above: > This might be asking too much -- it's not very perlish, in the sense of > TIMTOWTDI. It might make sense for DKs, but different people may want to use > the conventions their comfortable with. Perl is there for you to create > applications (and APIs) the way you want, not the way the gods demand. I must respectfully disagree. Perl has rules, and strict ones -- and more than just the syntax and the semantics. Anyone can *change* perls syntax, but they have to get buy-in from a fairly large and conservative community to get it incorporated into perl. Why should we not be as careful about 6PAN? We could take this a step further -- let CPAN be the perl equivelent of Sourceforge, but hold 6PAN to a higher standard. TIMTOWTDI. > One thing I think is as important -- or perhaps more important -- is to > enforce the presence of unit tests. There are a lot of modules on the CPAN > that have no tests, and most of them suffer for it. Yes, but . . . > It shouldn't be required that all tests pass, however. A statement showing > what platforms they pass on and what platforms they don't at the top of the > download page would be good enough. But the tests have got to be there. Actually, for 6PAN I think they should have to pass. And maybe we need a bug submission setup, and status checks, and . . . OK, OK, I'll stop now. They're nice ideas, but who bells the cat? The again, if Tim O'Reilly wants to fund me I'd be happy to do it. :-) On Tue, Jun 04, 2002 at 01:21:26PM -0400, John Siracusa wrote on the same thread: > Heh, I was going to suggest that new minor-version 6PAN submissions > automatically have all the earlier minor-version test suites run against > them before allowing them to go into the archive... :) Yep, that too. Which means . . . On Tue, Jun 04, 2002 at 10:57:15AM -0700, David Wheeler wrote: > On 6/4/02 10:21 AM, "John Siracusa" <[EMAIL PROTECTED]> claimed: > Hmmm...perhaps as a warning: > > All regression tests not passed. Do you still want to upload this module? s/Do you still want to upload this module?/Upload rejected./ On Tue, Jun 04, 2002 at 10:26:22AM -0700, Larry Wall wrote: > : 3. Module removal should be as easy as installation. > > Fine. There ought to be something in the metadata that says, "This version > of this module hasn't been used since 2017." Then you can clear out the > deadwood easily. Course, disk space will be a little cheaper by then, so > maybe we'll just hang onto everything forever. Nu? If you mean used in the sense of 'use foo', that would imply all running programs would have to write some sort of usage db, or touch a global file, or a lot of other things that I don't think are going to fly. > : 1c. Distinctions like "alpha", "beta", and "stable" need to be made > : according to some convention (a la
Re: 6PAN (was: Half measures all round)
--- Larry Wall <[EMAIL PROTECTED]> wrote: > : > : 1a. Modules may be "use"-ed in several ways (syntax ignored for > now): > : > : # Note "...installed on this system" is implied at the end > : # of each of the following descriptions > : > : "Use the latest stable version of module Foo" (probably the > default) > : "Use the latest version of module Foo" > : "Use the latest stable version of module Foo 1.xx" > : "Use the latest version of module Foo 1.xx" > : "Use module Foo 1.2" > > Yes, there have to be ways of getting at modules by their long names, > their > short names, and various intermediate wildcard names. Perl 6 will > have to > keep track of which version you used, so when you use the short name, > it > knows which long name you really mean. > > : 1c. Distinctions like "alpha", "beta", and "stable" need to be made > : according to some convention (a la $VERSION...perhaps $STATUS?) > > Can probably burn that bridge when we get to it. > Been done before: 3.1.3. Examples The following examples of font names are derived from the screen fonts shipped with the X Consortium distribution. Charter 12 pt ... -Bitstream-Charter-Medium-R-Normal--12-120-75-75-P-68-IO8859-1 Charter Bold 12 pt ... -Bitstream-Charter-Bold-R-Normal--12-120-75-75-P-76-ISO8859-1 Charter Bold Italic 12 pt ... -Bitstream-Charter-Bold-I-Normal--12-120-75-75-P-75-ISO8859-1 Charter Italic 12 pt ... -Bitstream-Charter-Medium-I-Normal--12-120-75-75-P-66-ISO8859-1 Courier 8 pt ... -Adobe-Courier-Medium-R-Normal--8-80-75-75-M-50-ISO8859-1 Courier 10 pt ... -Adobe-Courier-Medium-R-Normal--10-100-75-75-M-60-ISO8859-1 Courier 12 pt ... -Adobe-Courier-Medium-R-Normal--12-120-75-75-M-70-ISO8859-1 Courier 24 pt ... -Adobe-Courier-Medium-R-Normal--24-240-75-75-M-150-ISO8859-1 Courier Bold 10 pt ... -Adobe-Courier-Bold-R-Normal--10-100-75-75-M-60-ISO8859-1 Courier Bold Oblique 10 pt ... -Adobe-Courier-Bold-O-Normal--10-100-75-75-M-60-ISO8859-1 __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com
Re: 6PAN (was: Half measures all round)
On 6/4/02 1:26 PM, Larry Wall wrote: > : Speaking of "CPAN for Perl 6" (or "CP6AN", or "6PAN"), what's the status of > : this effort? Do we even have a vague idea of the requirements? Or does > : everyone think CPAN (and module distribution/installation in general) as it > : exists now it pretty much okay, and just needs some tweaks to work with Perl > : 6 code? I really hope that's not the case! :) > > I haven't gotten to that Apocalypse yet. :-) Is this where I get scared by the reference to the year "2017" later in your message? ;) > : 2. Module packaging, expansion, and installation only requires a working > : install of Perl 6 (unless the module contains non-Perl code, such as C, > : etc., in which case the appropriate tools for C builds need to be present: > : cc/gcc, ld, make, and so on). Requiring "make" and friends to install pure > : perl files is a legacy relic, IMO. > > Certainly, though it's trivially easy to come up with something that's even > uglier than make. Been done many times... I'm not really concerned about the syntax so much as the dependency on "something other than Perl" for simple modules. Along similar lines, platform-specific binary distributions should probably be an (automatically-generated during submission?) first class citizen in 6PAN for systems that don't have "anything but Perl" on them (no compiler, no make, no nothing) but still want to be able to install any 6PAN module... or, heck, for people who just don't want to be bothered with compiling. I guess there are OS/library version issues there, but I think you could hit 90% of the "common" target environments pretty easily, and it should be extensible to cover more exotic targets down the road (which is why it should be an automatic part of 6PAN and not manual :) > : 3. Module removal should be as easy as installation. > > Fine. There ought to be something in the metadata that says, "This version > of this module hasn't been used since 2017." Then you can clear out the > deadwood easily. Course, disk space will be a little cheaper by then, so > maybe we'll just hang onto everything forever. Obviously you meant to type "holographic cube" ;) > : 1c. Distinctions like "alpha", "beta", and "stable" need to be made > : according to some convention (a la $VERSION...perhaps $STATUS?) > > Can probably burn that bridge when we get to it. Well, to have use/require/etc. Support the "get me the latest-stable installed version" semantics as the default meaning, won't we need some standard way to define "stable" right off the bat? Or does "right off the bat" == "when we get to it"? Or does the absence of any $STATUS-like variable imply "stable"? (That last one seems Wall-ish, if not Perlish ;) -John
Re: 6PAN (was: Half measures all round)
On 6/4/02 10:21 AM, "John Siracusa" <[EMAIL PROTECTED]> claimed: > Well, there are already "suggested" conventions for version number formats. > > Anyway, CPAN is supposed to be organized! It's not a free-for-all dumping > ground for modules. Let the version numbering and API anarchists use > SourceForge, I say! :) It's not like we're demanding EJB-like API rigidity. > So we'll continue to have $foo.setBlah() and $foo.blah() and $foo.Set_Bar() > in 6PAN, for better or for worse. All I'm asking for is some small meaning > behind version numbering. Is that so wrong? :) Okay, I'll buy that. And I think that suggested guidelines for compatibility between version numbers would be valuable, but I wouldn't think that we should enforce it. There may be good reasons to break backward compatibility in some cases. > Heh, I was going to suggest that new minor-version 6PAN submissions > automatically have all the earlier minor-version test suites run against > them before allowing them to go into the archive... :) Hmmm...perhaps as a warning: All regression tests not passed. Do you still want to upload this module? That'll stop the vast majority of offenders, and those who upload anyway will be more likely to have documented changes. David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
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: 6PAN (was: Half measures all round)
On Tue, 4 Jun 2002, John Siracusa wrote: : On 6/4/02 12:22 PM, David Wheeler wrote: : > 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). : : Speaking of "CPAN for Perl 6" (or "CP6AN", or "6PAN"), what's the status of : this effort? Do we even have a vague idea of the requirements? Or does : everyone think CPAN (and module distribution/installation in general) as it : exists now it pretty much okay, and just needs some tweaks to work with Perl : 6 code? I really hope that's not the case! :) I haven't gotten to that Apocalypse yet. :-) : In the spirit of Simon's desire to see "radical changes" when appropriate, I : propose the following high-level goals for 6PAN (yes, that's my favorite of : the bunch ;) : : 1. Multiple versions of the same module may be installed on a single system : with no possibility of conflicts. That means no conflicts of any kind, : whether it be in Perl code, XS-ish stuff, private shared libs, etc. Yes, I'm already on record that multiple installed versions will coexist peacably, certainly on disk, and to the extent that they can in memory. We can't stop two versions of a module from fighting over a shared resource, for instance. Two different database modules may have to figure out who really has the connection to the database engine, and who just thinks they have the connection. Possibly it would help to have package variables that are explicitly shared among different versions of the same package when they represent a shared object. : 2. Module packaging, expansion, and installation only requires a working : install of Perl 6 (unless the module contains non-Perl code, such as C, : etc., in which case the appropriate tools for C builds need to be present: : cc/gcc, ld, make, and so on). Requiring "make" and friends to install pure : perl files is a legacy relic, IMO. Certainly, though it's trivially easy to come up with something that's even uglier than make. Been done many times... : 3. Module removal should be as easy as installation. Fine. There ought to be something in the metadata that says, "This version of this module hasn't been used since 2017." Then you can clear out the deadwood easily. Course, disk space will be a little cheaper by then, so maybe we'll just hang onto everything forever. : I can think of many other worthy high-level goals, but these are the most : important, IMO. And number one is by far the most important to me. A few : natural extensions of it are: : : 1a. Modules may be "use"-ed in several ways (syntax ignored for now): : : # Note "...installed on this system" is implied at the end : # of each of the following descriptions : : "Use the latest stable version of module Foo" (probably the default) : "Use the latest version of module Foo" : "Use the latest stable version of module Foo 1.xx" : "Use the latest version of module Foo 1.xx" : "Use module Foo 1.2" Yes, there have to be ways of getting at modules by their long names, their short names, and various intermediate wildcard names. Perl 6 will have to keep track of which version you used, so when you use the short name, it knows which long name you really mean. : 1b. 6PAN modules comply with an informal contract to maintain : backward-compatibility within all N.MM versions, where N is constant. In : other words, incompatible API changes are only allowed by incrementing the : "major version" (e.g. going from 1.xx to 2.xx), and upgrades from one minor : version to the next (e.g. 1.05 to 1.11) MUST be "safe" (i.e. : "backward-compatible"). Fine. We can separate out interface from implementation better in the language too. : 1c. Distinctions like "alpha", "beta", and "stable" need to be made : according to some convention (a la $VERSION...perhaps $STATUS?) Can probably burn that bridge when we get to it. : I don't think the implementation details are too hard to hash out (he says, : optimistically... ;) But to meet these goals, they have to be thought about : early on. Some of them even require hooks in the language proper (e.g. : "use/require" extensions.) Those are details, the like of which would be easy to determine at the last moment. But the underlying mechanisms have to be design in, yes. : Thoughts? Or has this stuff already been hashed out elsewhere and I missed : it? :) It's here and there. Some of it has been in my speeches, and some in the Apocalypses. Larry
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: 6PAN (was: Half measures all round)
On 6/4/02 1:11 PM, David Wheeler wrote: > On 6/4/02 9:59 AM, "John Siracusa" <[EMAIL PROTECTED]> claimed: >> 1b. 6PAN modules comply with an informal contract to maintain >> backward-compatibility within all N.MM versions, where N is constant. In >> other words, incompatible API changes are only allowed by incrementing the >> "major version" (e.g. going from 1.xx to 2.xx), and upgrades from one minor >> version to the next (e.g. 1.05 to 1.11) MUST be "safe" (i.e. >> "backward-compatible"). > > This might be asking too much -- it's not very perlish, in the sense of > TIMTOWTDI. It might make sense for DKs, but different people may want to use > the conventions their comfortable with. Perl is there for you to create > applications (and APIs) the way you want, not the way the gods demand. Well, there are already "suggested" conventions for version number formats. Anyway, CPAN is supposed to be organized! It's not a free-for-all dumping ground for modules. Let the version numbering and API anarchists use SourceForge, I say! :) It's not like we're demanding EJB-like API rigidity. So we'll continue to have $foo.setBlah() and $foo.blah() and $foo.Set_Bar() in 6PAN, for better or for worse. All I'm asking for is some small meaning behind version numbering. Is that so wrong? :) >> Thoughts? Or has this stuff already been hashed out elsewhere and I missed >> it? :) > > One thing I think is as important -- or perhaps more important -- is to > enforce the presence of unit tests. There are a lot of modules on the CPAN > that have no tests, and most of them suffer for it. Heh, I was going to suggest that new minor-version 6PAN submissions automatically have all the earlier minor-version test suites run against them before allowing them to go into the archive... :) -John
Re: Re: 6PAN (was: Half measures all round)
On 6/4/02 12:34 PM, Steve Simmons wrote: > 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. Oh, so then this has been talked about before (surprise :) > 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. I'm a big fan of the "framework" abstraction as seen I Mac OS X. All the big, ugly mess is neatly encapsulated in "atomic" directory structures whose internals are accessed only through a well-defined (and always backwards- compatible) API. The internal organization of these directories can change over time, and many versions of the format may coexist, since the manipulation API would understand them all. Moving modules around should be as simple as moving directories around. Similarly, removing (all versions of) a module should be as simple as "rm -rf dirname" Obviously I favor encapsulation-by-module, where each "module directory/framework/whatever" contains all installed versions of that module. I think that's a better (physical) arrangement than by-author, by-version, or by-origin. (Those distinctions can be made in the abstract through introspection.) The current Perl 5 module system of physically dividing up files by type and origin is ins?ane, IMO. We've got a single Perl 5 "module" installing files in 10 different, widely-separated directories. That's a very inconvenient physical layout, future fancy keep-track-of-what-I-installed-where RPM-like facilities or no. Arbitrary (physical) divisions are easy enough once the modules are individually encapsulated. I dream of seeing a Perl 6 @INC path (or equivalent) like: /usr/local/lib/perl6/core /usr/local/lib/perl6/site and that's it! One directory per "place to look for modules." -John
Re: 6PAN (was: Half measures all round)
On 6/4/02 9:59 AM, "John Siracusa" <[EMAIL PROTECTED]> claimed: > 1b. 6PAN modules comply with an informal contract to maintain > backward-compatibility within all N.MM versions, where N is constant. In > other words, incompatible API changes are only allowed by incrementing the > "major version" (e.g. going from 1.xx to 2.xx), and upgrades from one minor > version to the next (e.g. 1.05 to 1.11) MUST be "safe" (i.e. > "backward-compatible"). This might be asking too much -- it's not very perlish, in the sense of TIMTOWTDI. It might make sense for DKs, but different people may want to use the conventions their comfortable with. Perl is there for you to create applications (and APIs) the way you want, not the way the gods demand. > Thoughts? Or has this stuff already been hashed out elsewhere and I missed > it? :) One thing I think is as important -- or perhaps more important -- is to enforce the presence of unit tests. There are a lot of modules on the CPAN that have no tests, and most of them suffer for it. It shouldn't be required that all tests pass, however. A statement showing what platforms they pass on and what platforms they don't at the top of the download page would be good enough. But the tests have got to be there. Regard, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
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: 6PAN (was: Half measures all round)
On 6/4/02 12:22 PM, David Wheeler wrote: > 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). Speaking of "CPAN for Perl 6" (or "CP6AN", or "6PAN"), what's the status of this effort? Do we even have a vague idea of the requirements? Or does everyone think CPAN (and module distribution/installation in general) as it exists now it pretty much okay, and just needs some tweaks to work with Perl 6 code? I really hope that's not the case! :) In the spirit of Simon's desire to see "radical changes" when appropriate, I propose the following high-level goals for 6PAN (yes, that's my favorite of the bunch ;) 1. Multiple versions of the same module may be installed on a single system with no possibility of conflicts. That means no conflicts of any kind, whether it be in Perl code, XS-ish stuff, private shared libs, etc. 2. Module packaging, expansion, and installation only requires a working install of Perl 6 (unless the module contains non-Perl code, such as C, etc., in which case the appropriate tools for C builds need to be present: cc/gcc, ld, make, and so on). Requiring "make" and friends to install pure perl files is a legacy relic, IMO. 3. Module removal should be as easy as installation. I can think of many other worthy high-level goals, but these are the most important, IMO. And number one is by far the most important to me. A few natural extensions of it are: 1a. Modules may be "use"-ed in several ways (syntax ignored for now): # Note "...installed on this system" is implied at the end # of each of the following descriptions "Use the latest stable version of module Foo" (probably the default) "Use the latest version of module Foo" "Use the latest stable version of module Foo 1.xx" "Use the latest version of module Foo 1.xx" "Use module Foo 1.2" 1b. 6PAN modules comply with an informal contract to maintain backward-compatibility within all N.MM versions, where N is constant. In other words, incompatible API changes are only allowed by incrementing the "major version" (e.g. going from 1.xx to 2.xx), and upgrades from one minor version to the next (e.g. 1.05 to 1.11) MUST be "safe" (i.e. "backward-compatible"). 1c. Distinctions like "alpha", "beta", and "stable" need to be made according to some convention (a la $VERSION...perhaps $STATUS?) I don't think the implementation details are too hard to hash out (he says, optimistically... ;) But to meet these goals, they have to be thought about early on. Some of them even require hooks in the language proper (e.g. "use/require" extensions.) Thoughts? Or has this stuff already been hashed out elsewhere and I missed it? :) -John
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.
Half measures all round
(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. 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. 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. -- The dumb joke of the day is: "Call Microsoft. When the operator answers, "Microsoft, may I help you?" respond: "I can't understand you. You're breaking up."
