Re: Perl Doesn't Suck
On Fri, Jun 29, 2001 at 05:29:53PM -0500, Elaine -HFB- Ashton wrote: Not all OS, though most, have Perl in the base install and those that do even have problems. Config.pm has issues on HP and Sun, RedHat has spotty RPMs that occsaionally go awry. That's their fault. Find a better distribution. *Then again, even for big things like Tk or LWP, I've found perl's *installation process to be at least more consistent. perl Makefile.PL * make test make install will just about do it. By contract, I've *had to install the JMF under Linux. HOoboy, that was a mess. All *sorts of little hard-coded paths and config options to tweak and *jigger, copying things around by hand. Unpleasent. I'd imagine it *would be easier to do on Solaris, but that doesn't help me. Well, call your Linux support and ask for them to make it better/easier to install Java on Linux. Sun isn't going to do it for the other platforms I would imagine. Well, see there's the trick. Sun (and thus Java) cares about Solaris and Windows. Everyone else has to fend for themselves. To make matters worse, its very difficult to get your hands on the JVM source code, so its not like I can even fix it. With Perl, I can at least fix it myself and roll it back into the core. Its the old Open vs Closed Source argument. As a Solaris gal, this might all seem perfectly sensible. Myself, I'm doubly screwed running Linux (which is not Windows or Solaris) on a PowerPC (which is not Intel or Sparc). Sun might have perfectly valid business reasons for concentrating on Solaris and Windows, but in the end it still means I'm screwed. With Perl, if you're running some fucked up OS on some fucked up hardware we'll at least give it our best shot to get it working. If you figure out how to get it working, we'll do what we can to roll it into the core (mod a little p5p squabbling). The one time I did have an issue with a Java package I had an engineer issue a patch within the day...and he was awakened at 4am. Did Sun do this out of the goodness of their heart or did you have commercial support? Given that Sun charges $200 per incident for a two day response time ($1600 for four hour reponse) this is not something most people can afford. Expensive, commercial support, while it is nice for those who can afford it, is not a general solution. *But yes, module installation can be made easier. We're working on it. No, module installation isn't hard and wasn't what I was driving at. Enterprise wide deployment. Make it easy to install and deploy perl across 5k boxes in a farm and you'll have a winner. :) With Debian I just make dpkgs (or use the Debian ones), stick them into a local repository and sync normally from there. Most OS's have a similar packaging system. Otherwise, you can use CPAN::Site to set up a local CPAN repository which overlays your own. Or you can set up your own local CPAN mirror of approved modules. After that its all cron jobs. Making it easier to do those last two is a good way to go. That an Ingy's NAPC idea. Like I said, we're working on it. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One Only mindless violence can raise my spirits now!
Re: Perl Doesn't Suck
On Sat, Jun 30, 2001 at 11:57:42AM -0500, Elaine -HFB- Ashton wrote: If Java sucks to install on some boutique/niche platforms it could mean that a) noone has told them about the issues I can't even conceive they're not accutely aware. b) noone in the FreeBSD/Linux world has taken it upon themselves to care enough to love it and see it through to make it work. I think its c) WE HAVE NO SOURCE TO WORK FROM! Sun doesn't give out its JDK source code freely, they have all sorts of restrictions. If I wanted to port the JDK I can do it, but I need special permission from Sun to distribute it. This Sucks. Especially considering that you could go through a whole lot of work and then have Sun deny you. Some are trying from scratch, a truly masive undertaking given that the current JDK is 20 megs *compressed*. Hungry Hackers has Japhar which is a 1.1.5 JDK and there are others, but it all lags behind. If Sun really wanted to help porters, they could release the JDK source code Freely. They won't. Do not blame the Open Source guys for lack of effort. Where would Perl on VMS be without Peter Prymmer? etc? White Knights are necessary, but Peter Prymmer did not have to rebuild perl from scratch. Being an OS Knight isn't an easy job, but we don't throw roadblocks in their way. Some of us have been bending over backwards to help. Guys like Hungry Hackers have 0 help from Sun. All they've got is a spec. The issue behind platform selection and support is that since Sun is a company out to make money snip That's all prefectly valid. It still means Java doesn't work well on my machine. Java has no platform angels in the corporation or out in the field most likely. Hungry Hackers and Blackdown are two off the top of my head. Blackdown is in a special position in that Sun has granted them permission to use the JDK source code, but nobody else can see it. If I don't have the source code, how am I supposed to fix anything? I can patch something and send it off to Sun, sure, but let's think about a full platform port... Let's say Peter Prymmer decides he wants to port the JDK to VMS (God Help Us ALL). What's his course of action. 0) Consult a psychiatrist. 1) Joins the Sun Developer Community 2) Download a copy of the JDK 3..100) Goes through a massive amount of work to get it working under VMS 101) Trumphantly sends the patches off to Sun. 102a) Sun sets Peter up with a Blackdown-like deal allowing him to distribute his port. **OR** 102b) Sun thanks Peter for his time but isn't going to trouble itself with VMS. **OR** 102c) Sun thanks Peter for his time, but doesn't feel the port is good enough to be blessed. Its that last bit of fuzziness at the end. You could go through that work and still be denied at the end. At least, that's how I'm reading their license. The other problem is steps 3 to 100 must be done in a relative vacuum. I don't believe he'd be allowed to redistribute his patches, so no vmsjava mailing list or community of developers to work with. Of course, he could ask permission from Sun beforehand, but again, this all relies on the good will of Sun (and them trusting Peter, who could be some schmo for all they know). Perhaps more importantly than all this, the spontaneity is lost. I know of many, many porting projects which started out with one guy saying Gee, I wish X worked on my OS and in a flurry of wild patching something is made to work in a few hours/days. Not perfect, but enough to get the snowball rolling. Finally, if the core developers (ie. Sun engineers) are unconcerned with your OS, they're going to keep cranking out platform specific code which you're going to have to keep patching over and over again. At least with perl we've got things like Windows and VMS in the back of our heads when making core patches (and if we don't we'll have Peter BEATING the backs of our heads ;) Thinks either work out of the box or are caught very early on. None of this ports lagging behind a few versions while they fix everything up. Anyhow, this is just the old Open vs Closed source debates rehashed. Except s/Closed/Community License/ -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
Re: [OT] Re: Perl Doesn't Suck
On Sat, Jun 30, 2001 at 01:49:45PM -0700, Stephen Zander wrote: Perl's great blessing is also it's great curse; there's a single implementation and that *implementation* happens to be OpenSource. Try writing a second Perl implementation from scratch. Fortunately, we don't have to. :) Perl 6 should have a more fathomable design, or at least better documented. I don't think it'll ever reach the sort of standards that things like Java and C++ have. Then again, have you LOOKED at the ANSI C++ standard? ;) Were something dreadful to happen to Larry and his estate chose to change the licensing terms of the current *implementation* In that Highly Unlikely event, we can simply fork off the source code from the point where the license changed. License changes are not retroactive. The only restriction is we couldn't call it 'perl' under the AL. I don't think such a thing has ever happened to a major Open Source project, this doesn't worry me. The license squabbling between the various BSD's is similar, but they're all still Open. where would Perl6 go? Same place its going right now, as there's no code. :) -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
Re: Perl Doesn't Suck
On Fri, Jun 29, 2001 at 06:51:33PM -0500, Elaine -HFB- Ashton wrote: *That's their fault. Find a better distribution. There are a lot of Solaris 8 users out there and to have a broken OEM Perl is not optimal. That response would not be well received. If insert vendor name here distributes a broken Perl with insert OS name here, what are we to do about it? Well, Sun has worked with other major OS vendors to make Java work properly so I don't know what the issues are behind Linux and *BSD not doing the same. wonderful reasons why Sun only supports certain OS's snipped That's all lovely, I still don't have a recent version of Java on my machine. I don't expect this situation to really be fixed anytime soon. *As a Solaris gal, this might all seem perfectly sensible. Myself, I'm *doubly screwed running Linux (which is not Windows or Solaris) on a *PowerPC (which is not Intel or Sparc). Sun might have perfectly valid *business reasons for concentrating on Solaris and Windows, but in the *end it still means I'm screwed. There are platforms which are also difficult to install Perl though it has gotten better over the years. I remember when I first installed or rather tried to install perl5 on Solaris when it first came outit was a PITA to say the least. P5P was conceived for just this task to make Perl install and run on a wide variety of platforms since, at the time, the number was few. Nothing installs perfectly on every OS and runs perfectly as well. It such a thing exists, I'll buy stock in the company right now :) Yeah, but Perl does an amazing job of trying. About the only thing I can think that's been so well ported is maybe something like gcc, vi or make. It runs on the Amiga! It supports EBCDIC for god's sake! I think the key difference here is that p5p is committed to trying like hell to get Perl working on pretty much everything, while Sun is only doing the ones it thinks are important and leaving the rest to independent porting operations it gives its blessing, and source code, to (like Blackdown). Yes, you still need a White Knight for your OS, yes things take time to firm up, yes its not perfect, but we're trying and succeeding. Sun isn't even trying. Java's been around long enough and sure as hell has had enough resources poured into it. If they really wanted Java to be truely cross-platform, they'd have done it by now. They don't care. That's fine as a business, but like I said, whatever the reason the end-users are still fucked. *Given that Sun charges $200 per incident for a two day response time *($1600 for four hour reponse) this is not something most people can *afford. Expensive, commercial support, while it is nice for those who *can afford it, is not a general solution. When you have web sties that loose millions of dollars per hour of down time it's not an option not to have support. Sun is a business, Perl is not. People don't answer pagers at 4am for free :) You misread. Commercial support is entirely necessary and justifiable in your case and many others. It must exist. However, you can't hold it up as a good general solution. Advocating, When I had a problem, Sun fixed it right away mumblebecause I pay them lots of money/mumble is cheating. Take any technology, apply lots of money, and it will work wonderfully. It would be neat to have 'make solaris-dist' or something like that for most of the major platforms. ... NAPC sounds cool but I don't know enough about it to say whether or not it will be Enterprise level. Given that Enterprise has pretty much no meaning anymore, I'd say yes. :) Seriously though, NAPC (if it works) is exactly the sort of packaging tool you're looking for. Since NAPC will produce, essentially, a binary package, you can just translate that into a solaris package. Anyhow, I think we've beaten this topic to death. Point is, Perl's installation isn't any worse than Java and possibly better. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One Schwern Unit: a positive but insignificant quantity
Re: Perl, the new generation
On Fri, May 18, 2001 at 11:24:45AM -0400, Stephen P. Potter wrote: You are also saying that OOP is now required, because many/most CPAN modules use OOP. This is a piece of FUD along the lines of inline POD slows code down that keeps people fearful of CPAN and I'd really rather see die. To *use* OO code is a much different (and smaller) beast than *designing* OO code. For most OO CPAN modules, about all you need to know about OO is the syntax of calling a method. This should be obvious just from reading the module docs (assuming its well-documented). In all other respects it works just like its functional equivelent. There are exceptions (such as LWP) but most have simple wrappers (LWP::Simple) and who's to say their function-oriented equivalents would be any less complex? Sean Burke wrote up an excellent article about OO for module users which I thought was on perl.com but I can't find at the moment. Maybe it was in TPJ. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One Follow me to certain death! http://www.unamerican.com/
Re: Perl, the new generation
On Fri, May 18, 2001 at 12:22:56PM -0400, Stephen P. Potter wrote: For example, take a look at Camel1. It was a small book; you could carry it around without building up huge biceps. You could reasonable read it in a couple of days and get started with perl. I tried to get us to maintain that in Camel2, but it grew to almost 700 pages. Camel3 is 1100 pages, about a 3 fold increase from Camel1. I can weightlift with it now. Someone looking at that is going to think they have to know all that to be effective. Programming Perl is a reference manual. It is designed to cover the whole of the language in detail. It will be large. Learning Perl is the tutorial. It is designed to cover just the basics. It will be small. Trying to learn Perl from the Camel is like trying to learn English from the OED. Trying to make Perl easier to learn by cutting features is about as sensible as making English easier to learn by tearing pages out of the OED. The size of the language has little to do with its difficulty, its more about the minimum subset that must be learned to be useful (the *actual* subset, not the perceived). In fact, the Llama 2 (written for 5.004) doesn't cover much of perl5 at all. I don't think it ever mentions OO or references except in passing. Llama 3 should be much the same. What you are worried about is not a language issue, it is a perception and DOCUMENTATION issue. Please stop throwing your wooden shoes in the cogs of progress and start helping. Go to [EMAIL PROTECTED], start up a perlsmall man page. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One How can I stoop so low? Years of practise, that's how. It's been hard going but now I can stoop lower than a pygmy limbo dancer. -- BOFH
Re: Perl, the new generation
On Wed, May 16, 2001 at 11:58:07AM -0400, Adam Turoff wrote: It's not so much that Perl shouldn't have data structures or modules. I think what Stephen is saying (and he's not the only one) is that the bare minimum amount of Perl you *must* know to be productive is increasing. Either that, or we're giving the impression that it's increasing. This may have gotten lost in the noise, so I'll mention it again. Since all the features of perl4 are still in perl5 (mod a few minor differences) it should still be possible to teach perl5 as you did perl4, as a small utility language/shell scripting replacement. Simply ignore anything that might get in the way of someone just wanting to read a log file. We could provide a seperate man page (perlsmall?) which describes this mini-language-within-a-language. It would skip things like OO (or only as much as you need to use the occasional CPAN module), Unicode, odd syntax details, etc... and focus on things like basic regexes, string and file handling, basic data structures, map, grep, etc... In fact, you could start with the perl4 man page (or Camel/Llama 1) as the basis. Seems a lot more productive than just pining about the olden days when men were men, Perl was small and 640K was enough for anyone. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One ...and I pull out the Magnum from under the desk where I keep it in case someone laughs at a joke that's so dry it's got a built in water-fountain, and blow the lot of them away as a community Service. -- BOFH
perlsmall (was Re: Perl, the new generation)
On Tue, May 15, 2001 at 03:01:47PM -0400, Stephen P. Potter wrote: It seems to me that recently (the last two years or so) and especially with 6, perl is no longer the SAs friend. It is no longer a fun litle language that can be easily used to hack out solutions to problems. See, I have a basic problem with this. Whatever you were doing with perl4 ten years ago, you can still do with perl 5.6.1 (mod a few minor differences) by simply ignoring all the new features. Perl can be taught/learned as a small, fun language (where 'fun' is a highly relative term). In fact, there's an O'Reilly book out just for that purpose, Perl For System Administration. While there are arguments about unnecessary language bloat and what should be in the core and what should be relegated to modules (see also, Second System Effect) if you take this too far you wind up with a Luddite philosophy to language design. I don't need feature X, so neither does anyone else! There's little need for a language fork. The simple things will remain simple (and hopefully simpler) and the hard things will remain possible (and hopefully a bit more possible). Perhaps instead of proposing a fork, you could write up a new man page, perlsmall or something, describing just those useful features of Perl as a small utility language (enhanced shell scripting) and ignoring the useless stuff like OO and threads. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One Let's enjoy the traditional custom in Peru of getting leprosy.
SECOND SYSTEM EFFECT!
I'm covered in software engineering books at the moment writing up conference stuff and I happened to crack open a copy of The Mythical Man-Month and felt I should remind everyone about the... -- *** SECOND SYSTEM EFFECT *** -- which I'm sure we all know about but sometimes forget. The general tendency is to over-design the second system, using all the ideas and frills that were cautiously sidetracked on the first one. The result ... is a 'big pile'. -- Fred Brooks Jr, The Mythical Man-Month p 55 This isn't attached to any particular discussion going on at the moment, I just thought it should be shouted loudly every once in a while over the course of Perl 6's design to keep everyone on their toes. I'd recommend everyone who has a copy to just skim through chapter 5 of MM-M once again. PS Someone's going to argue that Perl 6 isn't a second system, its the Nth system. The exact value of N doesn't really matter, we're still very much in danger of the second system effect. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One How can I stoop so low? Years of practise, that's how. It's been hard going but now I can stoop lower than a pygmy limbo dancer. -- BOFH
Re: You will not have to rewrite your Perl 5 programs!
On some date someone wrote: : option in (say) perl5.8 which would allow folk to find typeglobs etc, : and adjust code in advance. It should be possible to do most of this externally as a B module. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One Do not try comedy at home! Milk Cheese are advanced experts! Attempts at comedy can be dangerously unfunny!
Re: Perl, the new generation
On Thu, May 10, 2001 at 12:56:36PM -0400, David Grove wrote: Of course your Perl 5 programs will still work, as long as you convert them to Perl 6. We'll have a parser that will be able to do this. Of course, you will have to write it yourself. I think there's a communications foul-up here. We're definately providing some sort of Perl 5 translator/adaptor system and we're definately writing it. In fact, it was hotly debated on perl6-language just recently exactly how to do it cleanly. Have I missed something? Have you missed something? -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One mendel ScHWeRnsChweRNsChWErN SchweRN SCHWErNSChwERnsCHwERN sChWErn ScHWeRn schweRn sCHWErN schWeRnscHWeRN SchWeRN scHWErn SchwErn scHWErn ScHweRN sChwern scHWerNscHWeRn scHWerNScHwerN SChWeRN scHWeRn SchwERNschwERnSCHwern sCHWErN SCHWErN sChWeRn
Re: Perl, the new generation
On Thu, May 10, 2001 at 11:55:36AM -0700, Larry Wall wrote: If you talk that way, people are going to start believing it. The typical Perl 6 program is not going to look very different from the typical Perl 5 program. The danger of us continually talking about the things we want to change is that people will forget to notice the tremendous amount of stuff that we aren't changing. It might be useful to draw up a list of functions and features which we don't plan on changing? Maybe just run through each Perl 5 man page and highlight everything that will still be the same and post this somewhere? -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One The desired effect is what you get when you improve your interplanetary funksmanship.
Re: Perl, the new generation
On Thu, May 10, 2001 at 04:41:09PM -0400, David Grove wrote: My information on this comes from discussion (asking directly) in undernet #linux. If this is in error, tell it to them. An IRC channel, in ERROR?! On Undernet no less?! THE DEUCE YOU SAY!! ;) Next thing you're going to tell me the commentary on Slashdot isn't totally impartial! Debian? They're not commercial, but they're still a pretty big OS distro; What? You mean they're actually accepting it a year and a half later in a testing version? Debian is historically slow to release 'stable' distributions. The current 'testing' branch has been going on for quite some time. FreeBSD comes to mind, among others. FreeBSD is also historically *very* slow about upgrading perl. They were one of the last hold-outs to upgrading /usr/bin/perl from perl4. Please stop. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One purl Hey, Schwern! THERE IS A HUGE GAZORGANSPLATTEDFARTMONGERING- LIGHTENINGBEASTASAURSOPOD BEHIND YOU! RUN, BEFORE IT GAFLUMMOXES YOUR INNARDLYBITS!
You will not have to rewrite your Perl 5 programs!
I'd just like to make this abundantly clear, since there seems to be some confusion (and hopefully I'm not the one confused). *** You will NOT have to rewrite your Perl 5 programs *** Perl 6 *will* provide a backwards compatible Perl 5 parser. The details are not nailed down, but this definately will happen. I hereby declare that a package declaration at the front of a file unambiguously indicates you are parsing Perl 5 code. If you want to write a Perl 6 module or class, it'll start with the keyword module or class. -- Larry Wall, Apocolypse 1 And yes, there will be something for programs as well. For further details, see: http:[EMAIL PROTECTED]/msg00285.html -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One Let me check my notes...
Traffic lights and language design
needs a few extra lights here and there to make it really work). Yep, my brain is done with this. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One Any sufficiently encapsulated hack is no longer a hack.
Re: ANNOUNCE: smokers@perl.org Discussion of perl's daily build and smoke test
No. This is silly. End of discussion. PS I'm also an active non-smoker. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
ANNOUNCE: smokers@perl.org Discussion of perl's daily build and smoke test
If anyone's not familiar, a daily build and smoke test is the practice of building the entire system and running its tests every night to see if anything was broken durning the day's work. Turn it on, see if it smokes. This reduces the scope of bugs and keeps things from festering. You know the bug was caused within the last day. [EMAIL PROTECTED] is our smoking lounge. Its where people can volunteer machines and clock ticks for running the test, ask for infomration about getting involved, report failures and discuss how to run the test better. If you've got a machine with some spare CPU ticks, and RC5 has gotten old, step forward. The weirder the setup the better. Subscribe to [EMAIL PROTECTED] (or [EMAIL PROTECTED] for help). Archive is at http:[EMAIL PROTECTED]/ -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
Re: Perl-QA needs administrative help
Sorry, I didn't make myself clear on the "mailing list organization" bit. What the job really is, someone to spot out-of-control threads (for instance, the "par" discussion on perl6-language), split off a new mailing list for it (by requesting from Ask), appointing a chair (probably the person who's driving the thread) and then corral everyone there. As a current example, the "todo tests" discussion should probably be split. It also involves nudging off-topic conversations off-list.
RFC - Prototype RFC Implementations - Seperating the men from the boys.
I've an idea to cut down and weed out the huge number of RFCs we have. Its written out below. =pod =head1 TITLE Prototype implementations for RFCs. =head1 VERSION Maintainer: Michael G Schwern [EMAIL PROTECTED] Date: Mon Sep 4 21:11:56 EDT 2000 Version:1 Mailing List: [EMAIL PROTECTED] =head1 ABSTRACT RFCs should be followed by a prototype implementation of their proposal which provides something concrete to develop the RFC from and helps to avoid endless discussion. =head1 DESCRIPTION Its very easy and quick to write an RFC. Its often quite a bit harder to actually do what is proposed. There is also a tendency for endless discussions to come from them. In order to avoid the inertia inherent in the Perl development process, to discourage RFCs which have not been well thought out, and to cut down on the sheer number, it is proposed that each RFC should eventually be accompanyed by a prototype implementation before any decision to include it in Perl 6. Work on such an implementation will rapidly weed out those who wish to work on the proposal and those who wish to simply talk about it. If a person has strong feelings about an RFC or a particular feature of an RFC, their energies can be directed at working on the prototype rather replying to emails about the RFC. One who's opinion is backed up by a well implemented patch will carry more weight than one who merely proposes something without code. In effect, it restores the meritocracy of open source development. The prototype will allow people to actually work with the proposal, coding with and around it in a practical setting. Many things will be revealed during this process, and many issues which were never thought about will come up. It also allows documentation and testing cases to be drawn up Bbefore any code is added to Perl 6. In some cases, the prototype may work out so well that a core patch is not necessary. The prototype would become the implementation, possibly released to CPAN and/or distrubuted with Perl. It is, of course, expected that prototypes may be slower, less portable and more buggy than their eventual complete implementation. It is, after all, a prototype. It doesn't have to be perfect or complete, but it does have to give it a good try. Many existing RFCs are very deficient in their discussion of its implementation. The most common reasons given are either "This should be trivial" or "I an not a Perl core hacker". For the former case, if the implementation is so trivial, the prototype should also be trivial. If that turns out not to be the case, then maybe the RFC wasn't as trivial as originally thought. Provides a good check. In latter case, if the RFC author does not have the necessary time, manpower, brainpower, etc... to implement the RFC then it is their responsibility to find someone who does. This also holds true for the prototype. If the RFC author feels they cannot implement the prototype on their own, they must find people who can. If they can't, then they're not going to be able to find those to implement the actual code either. =head2 Weeding out dead RFCs. An RFC which goes for a period without a prototype, or without any patches to its existing prototype, will be considered "dead in the water." After sending out warnings to the maintainer to get things moving and giving a grace period, the RFC will be moved out of the main RFC archive and into an attic. One the RFC begins motion again, the maintainer can ask to have it reinstanted into the archive. Two special cases exist. An RFC for which no prototype can be written (RFC 16, for example) and an RFC which considers its prototype to be complete. A complete prototype must not only be feature complete, but it must also contain complete documentation and a complete testing suite. =head1 IMPLEMENTATION Prototypes can be written as modules, wrapper scripts around Perl 5, Filter.pm modules, Perl5 core patches, etc... Not every RFC can have a prototype, nor can every feature be implemented, but this is the exception rather than the rule. This will require the Perl 6 code repository to be set up eariler than expected. The RFC archive will have to be expanded to include a link-up between the RFC and its latest prototype. It will also require the RFC librarian to weed out RFCs which have languished for long periods with no prototype. The RFC maintainer will also be the build maintainer of their particular prototype. They ultimately decide which patches go into the main branch of the code. Rival implementations may be maintained as branches by their chief supporter. =head1 EXAMPLES Some examples of RFCs which can have prototypes and that which are exempt. =over 4 =item RFC 1 - Implementation of Threads in Perl This RFC's scope is so wide as to necessitate a complete rewrite of Perl. It would be exempt from a prototype. =item RFC 5 - Multiline Comments for Perl This ca
Re: code repository
On Thu, Sep 07, 2000 at 01:49:36PM -0400, Peter Allen wrote: They have a catchy slogan for it. They call it the test -- code -- design development cycle. That sounds bad. I've heard about this style. Code now, refactor later. Its supposed to avoid the need for sweeping architectural decisions early in the project, allow you to recover from bad design decisions and return flexibilty to old code. It may be good for rapid development projects, but I don't think we should apply it to Perl. We have a very good idea of what our requirements are (especially compared to most software out there), a solid prototype to work from (perl 5), and some very solid ideas of what the architecture should be. Furthermore, I don't think there are any refactoring tools for C. I've only heard of them for Java and Smalltalk (maybe C++). Of course, the design phase is characterized exclusively as 'refactoring'... For the record... "Refactoring" is only one tool used in that design philosophy. Unfortunately, its apporaching buzzword status lately and the test-code-design approach you mentioned and the technique of refactoring are kind of ooozing together in the public's perceptions. I'd like to point out that they are seperate entities. Refactoring is simply the automated alteration of code without effecting its purpose. A simple example would be reversing the order of arguments in a subroutine. A refactoring tool would be able to do this for you automatically and in all code which uses that subroutine. Handy. It does this by defining a set of simple operations which a refactoring tool must be able to perform. From those simple operations, it can do much more complicated things. Unfortunately, Perl's dynamic nature makes most refactoring impossible. Furthermore, refactoring loses much of its power when applied on Open Source libraries since you are no longer in control of all code which uses said library. In a controled environment, you can alter interfaces to your heart's content. With Open Source, if you alter a function's interface you may break the code of hundreds of programs. Still, it has its uses and can be helpful in localized parts of the code. I've been going through the catalog of refactorings and trying to determine what can currently be done in Perl and how much change in Perl it would take to reimplement the rest. It doesn't look good, but I'll publish what I've got once its complete. Martin Fowler wrote a book "Refactoring: Improving the Design of Existing Code" http://www.refactoring.com/ Bill Opdyke's original thesis paper on the subject is here ftp://st.cs.uiuc.edu/pub/papers/refactoring/ Also, don't you want to refer more to 'unit tests', rather than regression testing snip They could be called "Mr. Wosabe tests" for all I care. Terminology was never my strong point (above rant is the rare occasion). :) -- Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED] Just Another Stupid Consultant Perl6 Kwalitee Ashuranse Work like hell, tell everyone everything you know, close a deal with a handshake, and have fun. -- Harold "Doc" Edgerton
