The PDD PDD.
Self-referencing definitions - it's a bit like time travel. This was originally submitted back in December, but I never saw it show up, and didn't see it in the archives, so I'm going to throw it to the meta list for hacking before there are a slew of PDDs floating around. (I'm withholding the attachment, which is a skeleton PDD.) =head1 TITLE Perl Design Documents =head1 VERSION =head2 CURRENT Maintainer: Bryan C. Warnock [EMAIL PROTECTED] Class: Meta PDD Number: TBD Version: 2 Status: Proposed Last Modified: 9 February 2001 PDD Format: 0 Language: English =head2 HISTORY v1 created on 7 Dec 2000 by BCWarnock [EMAIL PROTECTED] =head1 CHANGES Merged Ipddfield.txt attachment. Reproposed. =head1 ABSTRACT This document defines a standard format for documenting Perl development decisions - the how and why of Perl internals, as well as the surrounding ethos and culture of the development community. This document identifies Perl Design Document Format 1. =head1 DESCRIPTION One of the shortcomings of most long-term development and maintenance efforts - and Perl has been no exception - is the lack of readily available documentation describing the rationale behind many of the implementation decisions. News archives and mailing archives are becoming increasingly difficult to find random information in, particularly with the myriad lists that Perl 6 begot. Although there will always be decisions which are obvious due to a lack of alternatives, many design decisions may have multiple technically feasible solutions. Why X instead of Y? Why this instead of that? Is the decision based on an obscure bit of technical arcana? Is the decision based on Perl culture, which itself is a product of many of the undocumented decisions made before? Or is the decision truly a toss-up, with a solution picked pseudo-randomly? A Perl Design Document (PDD) is a readily available record of the Perl community's thought process in regards to a specific structure related to Perl development. As such, it serves three major purposes. =over 4 =item 1 A clear indication of the direction of current development. A PDD provides a road map from abstraction to implementation of an idea. =item 2 An historical record of the rationale behind the decision. A PDD provides context to future developers, who may not have been familiar with the original discussion, but are currently involved with the resultant implementation. =item 3 An historical technical and cultural perspective for future development work. Re-implementation or even tangential tasks need only address what has changed since the original PDD. =back It is not a vehicle for brainstorming or creating a wish-list. PDDs are reserved for a concrete snapshot of what Bis, and what Bwill be. =head1 IMPLEMENTATION All newly created PDDs will adhere to the PDD standard current as of the time of proposal. In the absence of an accepted standard, the PDD will be written in the last generally accepted format, and will indicate the SIPDD Format as 0. (See LVERSION|"VERSION:".) All existing PDDs will adhere to the PDD standard current as of the time of resubmission. Existing PDDs need not be modified and resubmitted Bsolely for the purpose of adhering to a PDD format change. =head2 FORMAT All PDDs will be written in POD parseable by the current stable release of Perl. Although XML is a viable solution and has its vocal supporters within the Perl community, POD is still the traditional documentation language for All Things Perl, and PDDs have yet to reach the level of complexity that requires some of XML's more powerful capabilities, particularly at a trade-off to the legibility of POD's simplicity. All PDDs will be written in English. British, American, or Other is the choice of the author. Translation to other languages, like all Perl documentation, is encouraged. (See SL"PDD TRANSLATIONS".) All PDDs will contain the following information: =over 4 =item TITLE: A short, general description of a specific area within Perl. For instance, "Sorting" vice "Sorting with a Heap Sort". PDDs should be limited to a specific area of Perl - in the above case, sorting - but should be broad enough to include the reasons for and against any specific implementation that may be discussed. Historical perspectives can be contrasted and compared through archived versions of a PDD, vice multiple searches through archived versions of In number of PDDs. =item VERSION: Contains current and selected historical metadata on the PDD itself. =over 4 =item CURRENT: Contains the following information, current as of the date of submission. =over 4 =item Maintainer Required. The name and current email address for the POC of the PDD. This is to whom questions, comments, and patches are generally addressed. =item Class Required. The area of Perl the PDD covers. This allows related PDDs to be logically grouped. The current list of
Art Of Unix Programming on Perl
Eric Raymond's book-in-development ``The Art of Unix Programming'' says this about the future of Perl: Perl usage has grown respectably, but the language itself has been stagnant for two years or more. Bah. Looks like my Perl5-Porters summaries have been completely in vain. :) The past two years have seen extensions to the language, its portability and its internals. We've added full Unicode support, a new threading model that allows fork emulation on platforms like Windows which don't support fork, (further carrying Unix concepts everywhere we go) new syntax features such as lexical warnings, lvalue subroutines, weak references, and other bits and pieces. Many hundreds of lines of documentation have been written or revised. We've had new hardware support, including another four supported platforms, (bringing the total to, what, must be about 82 by now?) plus large file and 64-bit support. And the user base keeps growing. I'm not sure "stagnant" is the best choice of word to describe that. Perl's internals are notoriously grubby; it's been understood for years that the language's implementation needs to be rewritten from scratch, but an attempt in 1999 failed and another seems presently stalled. If that other is Perl 6, I don't think we're stalled, are we? Language design is waiting on Larry to produce the spec, and internals design is going on quietly but steadily. We're in the design stage. That'll probably last a while because scripting languages and interpreters aren't easy things to design, and are even harder to get right. Perhaps we're not giving the right impression. Hey, brian, aren't you supposed to be preventing this from happening? Simon -- An ASCII character walks into a bar and orders a double. "Having a bad day?" asks the barman. "Yeah, I have a parity error," replies the ASCII character. The barman says, "Yeah, I thought you looked a bit off." -- from Skud
Re: Art Of Unix Programming on Perl
On Friday 09 February 2001 14:06, Simon Cozens wrote: I'm not sure "stagnant" is the best choice of word to describe that. It used to be that feeping creaturism was the scourge - folks clamoring for a little stability in their tools and products. Now it seems what was once "stability" is now "stagnatation." Microsoft's PR department just earned their paychecks. More, more, more useless things. -- Bryan C. Warnock [EMAIL PROTECTED]
Re: Art Of Unix Programming on Perl
Dan Sugalski [EMAIL PROTECTED]: Yes, but you see, we're not generating code. All the rest of the stuff is irrelevant, and Real Hackers don't need to design--it's all self-evident. Besides, you only need to design if you're building one of those Cathedral thingies, and we all know how bad those are. (If you need to reach higher, the correct method is, of course, to add another layer of tents on top of the previous one) The obvious and cutting rejoinder for me to make would be: "Hey. If I believed this, I'd still be writing Perl." But that's a cheap shot, and Larry Wall and I are homies, and I don't really believe it anyway (well, not *much*...). So instead I'll ask you gentlemen to enlighten me. Larry actually invited me to join the Perl6 design list (if only as the doomed futile token voice for LISPy minimalism) and I tried to, but there was some kind of ugly technical snafu with Skud's listserv and I couldn't get signed on. What *is* going on over there, anyway? It is unfortunately true that the effort looks stalled from the outside. I'd be happy to revise that opinion if there are whitepapers or design notes or a Wiki or something I could look at. Anyway, worry not, I don't expect the book to complete for a year. You have plenty of time to change my mind. And I still wouldn't mind contributing to the design. (Cripes. I only dissed Perl mildly. I gave Java a much rougher time and basically consigned Tcl to an early grave -- but no flamage from *those* guys...) -- a href="http://www.tuxedo.org/~esr/"Eric S. Raymond/a The right of self-defense is the first law of nature: in most governments it has been the study of rulers to confine this right within the narrowest limits possible. Wherever standing armies are kept up, and when the right of the people to keep and bear arms is, under any color or pretext whatsoever, prohibited, liberty, if not already annihilated, is on the brink of destruction." -- Henry St. George Tucker (in Blackstone's Commentaries)
Art of Unix Programming on perl
Eric Raymond's book-in-development ``The Art of Unix Programming'' says this about the future of Perl: Perl usage has grown respectably, but the language itself has been stagnant for two years or more. Bah. Looks like my Perl5-Porters summaries have been completely in vain. :) yeah, he's full of BS here.. Perl's internals are notoriously grubby; it's been understood for years that the language's implementation needs to be rewritten from scratch, but an attempt in 1999 failed and another seems presently stalled. If that other is Perl 6, I don't think we're stalled, are we? Language design is waiting on Larry to produce the spec, and internals design is going on quietly but steadily. We're in the design stage. That'll probably last a while because scripting languages and interpreters aren't easy things to design, and are even harder to get right. yeah well, sometimes I think that things *are* stalled. For example, I'm trying to both update my last book (and perhaps write a new one) and its kind of difficult to start let alone convince an editor to put the effort in if you don't even have a spec to work from. And lacking a spec, a status would be nice. Last time I heard, larry was going to be working on 'chunks of RFCs at a time' and posting the results of those for digestion. What happened to that? The last thing posted was Dec 20th on the subject. Is there a place for statuses that I'm unaware of? Ed
Re: Art Of Unix Programming on Perl
On Fri, 9 Feb 2001, Eric S. Raymond wrote: [...] minimalism) and I tried to, but there was some kind of ugly technical snafu with Skud's listserv and I couldn't get signed on. listserv? We use ezmlm around here. :) If you still want to join in then look at http://dev.perl.org/ - http://dev.perl.org/lists and http://archive.develooper.com/ ... we are currently in waiting-for-Larry mode on the language design and I don't think anyone would claim that it could be done any faster if we tried to make language _decisions_ on the mailinglists so that's just kinda how it is. -- ask bjoern hansen - http://ask.netcetera.dk/ more than 70M impressions per day, http://valueclick.com
