Two Quick Things
1) As a wonderful example of Warnock's Dilemma, I asked for some temporary volunteers to do the Perl 6 summaries while I was otherwise occupied. Your patience is commendable - no one offered. So I'll resume with next week's summary, but I'm afraid I won't be backfilling. 2) Apocalypse and Exegesis 3 were expected five weeks ago. Where are we now? -- Bryan C. Warnock [EMAIL PROTECTED]
Perl 6 summaries
Duty calls. Can someone pick up the summary for this and the next couple of weeks? Email Simon for details. Thanks, -- Bryan C. Warnock [EMAIL PROTECTED]
Perl 6 summaries?
I know Simon's on the road. I know Simon's connection is sporadic. I don't know what Simon is actually checking. Maybe news. Dunno. Mumkin he's ignoring me? I'm thinking he's just busy, busy, busy, because well, Simon is usually busy, busy, busy. Warnock's Dilemma strikes again Anyway, I can't seem to get to Simon. I can't seem to post to perl6-digest. I can't even seem to get help from perl6-digest. Yes, I'm using the netthink address, and not perl.org. (I'm sending and receiving mail elsewhere, and the last I checked, I'm subscribed under *two* addresses. I've received no response for my post, or my query. If you have, can you let me know?) Believe it or not, I really *am* still doing the Perl 6 summaries. Well, physically, I'm still doing them. I haven't been told to stop yet, so I keep plugging away. I know it's been 5+ weeks since a Perl 6 digest has hit the streets, and there have been Perl 5 digests during that time, so where is 6? I don't know. But I do spool them off my home account. http://members.home.com/bcwarno/Perl6/digests/ There are two out there since the last one that I've seen come across, or get posted elsewhere. Of course, this is probably an impractical posting - if folks wanted the summary, why would they be subscribed to an actual list? But if you are, there you go. And Simon, if you're out there, I'm looking for you. (Or did I miss something?) -- Bryan C. Warnock [EMAIL PROTECTED]
Re: Perl, the new generation
On Wednesday 16 May 2001 15:32, Nathan Torkington wrote: Bryan C. Warnock writes: I think the biggest fear isn't that Perl is going to grow out of its niche, but that it's going to outgrow it. It's great that Perl has been able to expand to be so many things to so many people, but not at the expense of forgetting its roots - of the whole Right Tool / Right Job that it came from. In that case, how exactly has it forgotten its roots? I mean, in what way is it not as useful as it was before? Nat Sorry. I didn't mean to imply that it had, only that it seems the largest fears center around that it will. Certainly, we are doing our best to keep Perl Perl. But in the process of overruning enemy camps, are we leaving our own camp unguarded? One of the nice things about early Perl 5 (I'm sorry - I was crawling through mud for most of Perl 4) is that Perl was an additive language. You had simple concepts to accomplish simple tasks. As the tasks got more complex, you could add more complex concepts onto your simple knowledge base to accomplish them. Of course, when writing RFCs, no one (except for Keep Perl Perl) really addressed what is right with Perl, or Why Things Were Good. People addressed ways that Perl *could* be improved, with the hopes that Larry would be able to differentiate between 'what would make a better language', and 'what would make Perl better'. Those are two orthogonal concepts, when you think about it. So, in reading the RFCs, and in discussions centered around make a better language, Perl - at least, the old, simple Perl - has seemingly become a subtractive language. (Everything's an object, use warnings and strict by default, etc, etc) Perl would have a much higher barrier to entry for what used to be a simple task. What previously required the bare minimum of Perl knowledge to do, would now require more complex conceptual issues, if only to determine what extraneous features can be removed or hidden, and how to do that. -- Bryan C. Warnock [EMAIL PROTECTED]
Meta-help on development of perl
So sad. Does anyone have any advice/warstories on meshing the perl development/maintenance you do with your company attempting to levy a broad creation and property rights agreement on you? Replies off-list are welcome, as this is arguably off-topic. If you've only got "Find a new company" as a suggestion, withhold your email - I'm considering it. Thanks, -- Bryan C. Warnock [EMAIL PROTECTED] ^ (To be fair, this is currently in the "working" stage, so please hold judgement in reserve.)
Re: Not revisiting the RFC process (was: RFC 362...)
On Thursday 22 February 2001 17:12, Dan Sugalski wrote:
PDDs are for internals pretty much exclusively. If it doesn't involve the
implementation or design of the low-level guts of perl, it doesn't belong
in a PDD. Which isn't to say it has to all be C and bit-level things--the
parser wedges that can be written in perl would be specified in perl, of
course.
Some random stranger should be able to take all the 'standard' PDDs
(however they're marked) and build a perl interpreter/compiler. That's
the
plan, at least.
I still think it's possible (and desirable) to have PDD that handles
language issues. We should certainly scope out beforehand exactly what the
semantics of construct foo should be, even if it's just a BNC description
and a quick explanation of how it behaves in void, scalar, and list context.
A lot of times this doesn't necessarily condense to the necessary bit
twiddles. Much of what Larry delivers, I imagine, will be of this scope.
A PDD like this a) provides an upfront idea of what the internals guys are
supposed to produce. ("I didn't know that foo could take a block") and b)
provide a jumpstart to the perl6 deliverable documentation.
I think this is what Nathan was labelling a PLD, but I said in my other
thread, I think a single vehicle can (and should) handle them both.
Then again, you may be considering that as internals anyway.
Many of the meta- items that will be Informational probably won't be
internally-oriented, either, but I don't think that should stop us from
documenting them. IMO, the decision is how deliberate the segregation of
the different areas. Internals, language, and meta PDDs, while curently in
a single PDD bucket, are sub-classed as such. This allows both a
comprehensive list (of PDD 0 - PDD X) as well as secondary collation by
groups. We could just as easily create PDDs, PLDs, PMDs, as well, but
it's harder to handle a comprehensive list that way. You either have
independent numbering schemes, which could lead to confusion, or a single
numbering scheme, which begs the question of why seperate them in the first
place.
--
Bryan C. Warnock
[EMAIL PROTECTED]
Re: State of PDD 0
On Tuesday 20 February 2001 21:45, Adam Turoff wrote:
PDDs, like the RFCs that preceded them, will need to serve multiple
purposes. One of them will be to catalog (and *name*) ideas that
keep coming up, including the bad ideas (like the |||= operator)
that we're tired of discussing. I don't think anyone expects each
of N PDDs to get us 1/Nth closer to Perl6.
Except it may be possible to keep the RFC structure for the "we're NOT"
historical section. I would much rather have a clean section on "This Is
Perl" than to wade through N + X documents just to glean the N clues that
I'm after.
Some PDDs, especially Informational and possibly Experimental,
might need to precede knowledgeable discussion. If so, then
Standards-track need to have the requirement that they summarize
some amount of discussion on the list(s), and that requirement is
enforcable (i.e., no PDDs out of left field).
Well, we could move to a sponsorship-type model. Since you need a WG Chair
to move it past proposal stage, simply make that a requirement for that
stage too. In order to submit a Standards-track Proposal, you need a WG
Chair, etc, to sponsor it.
That would also allow several people to put together differing proposals
for the times that we don't have prior discussion. Dan, for instance,
could call for proposals for locality handling, and several folks could
write their own comprehensive (ie, no hand-waving "and {poof} magic
happens") PDD of how to implement it. Only one need be accepted, the
others can be archived with all the other Proposals for historical purposes
- that was the whole point in not numbering Proposals in the first place.
But that seems to be merging again with the RFC process - so maybe not.
Of course, if we put too much structure in place, no one will use it, and
we'll either see more non-experimental Experimental PDDs, or no PDDs at all.
That's a good idea, but I'm not entirely convinced that it's the
only one, the fairest one or the most practical one.
I'm all ears. Er... eyes.
--
Bryan C. Warnock
[EMAIL PROTECTED]
Re: RFC 362 - revisiting the RFC process (was Warnings, strict, and CPAN)
On Tuesday 20 February 2001 16:51, Dan Sugalski wrote: Honestly, the PDDs are for the stuff that was implemented, not the stuff that was decided. Or, more clearly, PDDs describe the implementation or proposed implementation at the internals level. RFCs are for language-level features. It should sort of do both. Okay, maybe arbitrary language decisions needn't be P?Dd, but there should be some documented consensus, even for a language feature, of what is (or will be), if only to give the developers a clear target to shoot for. We should have PDDs on garbage collection and memory allocation (I know, I know--I'm working on it! :). We should not have PDDs on, say, currying. Well, a well-designed spec on currying language would certainly help with development of the internals to handle currying. It would also provide a nice starting point for the currying documentation. Lest the architect say, "Build me a house", and then complain that we don't match the plans he never gave us. -- Bryan C. Warnock [EMAIL PROTECTED]
Re: State of PDD 0
On Tuesday 20 February 2001 18:17, Dan Sugalski wrote: Ultimately, I think we're going to need at least three different types of documentation: * internals design documents (PDDs) * language design documents (PLDs?) * change requests, once we've got something to change (PCRs) That works. I rather like it, and I expect once we get a working perl 6, we probably won't need to freeze things either--worst case we mark a proposed document irrelevant or something of the sort. Well, there's also Meta stuff for discussion that we should probably document as well. As much as I disliked RFC, I also disliked PDD, as it 'sounds' internal. But do we create a new category for every new area we attempt to document, or do we change the name to reflect something more generic? (The PDD has a Class field to distinguish between internals, meta, and language already.) If we go with mulitple documents, is the numbering scheme concurrent? I'm also thinking heavily about change requests, and whether they should be separate, or a stage beyond Standard. Pros and cons welcome. -- Bryan C. Warnock [EMAIL PROTECTED]
Re: This week on the perl6 mailing lists
On Tuesday 13 February 2001 21:32, Nathan Torkington wrote: David L. Nicol writes: Is there a budget? Apprenticeship makes all kinds of sense when there is actually a money flow into the guild; the carrot of eventual credentials is too weak for me and many lesser poetasters. Could O'Reilly and Microsoft divert some funds to actually paying people for helping out? That would change the ball game something massive I can't speak the final word for O'Reilly, but I can say that we're already paying Larry's salary and have basically told him that his most important job is Perl6. Until that shows fruit, we'd be very unlikely to tip more money in the way of perl6. Good luck getting blood from a ston^W^W^W^W money from Microsoft :-) Particularly after this: http://news.cnet.com/investor/news/newsitem/0-9900-1028-4825719-RHAT.html?tag=ltnc -- Bryan C. Warnock bwarnock@(gtemail.net|capita.com)
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
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: Critique available
- Original Message - From: "Nathan Torkington" [EMAIL PROTECTED] Not only is it wrong, it's also hurting our chances. When an article in perl.com is so overwhelmingly negative about the work so far, do you think that stirs confidence in what we're doing? Do you think that people will read the article and think "yeah, I want to write code for *that* project". Will they think "I'm looking forward to perl6!" No, of course they won't. They'll think "it's a typical Perl fuckup". That may be understating the case. I'm currently working on (with?) a product that relies heavily on perl (5.005), both as a support language and an embedded language. It's not a perfect fit, but it was the best fit at the time. With mixed messages about 5.6, an ultimate migration to 6 which may scare away extended development with perl 5.8, and a indefinite development period on 6 itself, how many people are going to start hedging their bets and investigating other non-perl solutions to their problems? Perl 6, if the general direction of the RFCs hold true, will be a much better fit for this company and their product. Can they wait? *Will* they wait? I know they've already started some migration to Java and Python. I'm all for the truth - nothing worse than a room full of "our shit don't stink" marketers - but let's not scare folks away, either.
Re: Update on the RFC Process
On Tue, 03 Oct 2000, Simon Cozens wrote: On Tue, Oct 03, 2000 at 04:06:00PM +0100, Piers Cawley wrote: Personally I'm betting that the volume we've seen on -language will pale into tiny insignificance compared to the volume on -internals once Larry has made his announcement. I doubt it; I think we've a lot of people who want to talk about how Perl should be. I don't think we'll have *that* many people when it comes to actually trying to implement those ideas. Particularly since -internals will... er, should be focused on one direction, vice the pell-mell that -language has been. Discussions will also require some deeper supporting arguments - something more than "It'll be cool" or "I want it that way" - which should also help reduce traffic. (Other than requests for more information or explanation, which, I sincerely hope, will be tolerated and answered, as opposed to ignored or flamed. Hint hint.) -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: The Future - grim.
On Thu, 14 Sep 2000, Steve Fink wrote:
Alan Burlison wrote:
Having done so I have been very happy to see the wide consensus
that seems to be appearing.
Huh? I'd say quite the opposite. I expected more. There are many, many
people who use perl. Anybody who uses anything will come up with ways to
improve it (though many improvements aren't.)
{snip}
The noise in discussions is harder. I don't mind it much, though,
since I scan the author names and skip discussions that aren't
inherently interesting and don't contain people I recognize and
respect.
You'd be happier if more people (more unknowns, as it were, as most of
the established community is here already) had more things to say, but
you'll filter out discussions by people you don't recognize?
(I understood your point. This was just an interesting way of
presenting it.)
--
Bryan C. Warnock
([EMAIL PROTECTED])
