Russ Allbery writes:
I also think this may well be a good place to apply one of the ideas of XP
(Extreme Programming, a fairly flexible small-group software design
methodology), namely to write test cases *first* in many cases before
writing the code, and to seriously consider trying to write
Michael G Schwern writes:
There's one solution, now that we have a nifty source control stuff.
Branch like mad! Feature creep should be discouraged, but if a group
wants to go off and work on something which isn't going to make it
into the next release they can branch and play.
That
So we're three weeks away from the end of this. I've been thinking
about where we went right and where we went wrong (and in particular,
what I would do differently if I had it to do again).
The biggest thing is that I underestimated the volume of traffic. I
never thought there'd be so many
I know it seems at first like a lot of mindless paperwork, but it will
serve to make us agree on what we're doing and how we're going to do
it. I resisted all this at first, too, but the chaos of this
brainstorming phase will kill us if it persists into design and
implementation.
I've got some
J. David Blackstone writes:
Wait. Does a good idea have to go away simply because the person
who originally proposed it no longer has interest? What if several
people are interested, but the original author has totally skipped out
on Perl6 development, and the other interested people
Mike Lacey writes:
one of the purposes of perl6-meta is to keep us crazies out of the way of
the developers hope so anyway
Oh no, I'm busted! :-)
Nat
Steve Fink writes:
I just don't know if I'd bother to switch to Perl6 for a 10% speedup
Speed will *not* be the only reason to switch to perl6. It will (might)
have:
- bytecode compilation
- compile-time checking
- a rational stdlib
- vastly simpler extension mechanism
You can focus on
We have just finished using RFCs for brainstorming. They served
several purposes:
- to provide a common reference point for discussion
- to make people think through their suggestions (the hit-and-miss
IMPLEMENTATION section)
- to document the results of the discussion (not always
I'd like a volunteer to research and HTMLify the reading list. I
collected everyone's books (and will add my list when I get back to
the house). I just need someone to dig up ISBN numbers, Amazon links,
and HTMLify it all into submission.
Mail me direct if you want to volunteer. Thanks,
Nat
Uri Guttman writes:
that resonates with MMM totally. look at the surgical team approach as
well but updated. each group has a lead and a 2nd (and possibly 3rd) in
charge. others in the group do work on various parts under control of
the group leaders. support types like QA, version control,
David Grove writes:
I'm wondering how different this is from the current setup.
Currently there's the pumpking and the pumpking decides when to
release a new version of Perl. This exposes the pumpking to all sorts
of allegations, and potentially exposes Perl to being bought out.
When no
David Grove writes:
I'm not sure that unanymity wouldn't be going overboard for Perl,
Except that it's not unanimity of individuals, who are cantankerous
and troublesome, but unanimity of teams. Each team has the moderating
influences of three people to try to reach consensus. The release
David Grove writes:
If I understand correctly, large teams would have a small team of
"control" (bad word, but I don't know how else to put it) with a
team manager for that team, and small teams (like the ones with two
or three members, that have been pointed out) would be their own
David Grove writes:
That's fine, you've been patient, considerate, understanding, and extremely
helpful. You deserve a nap... or a beer, your choice.
Having done what they said couldn't be done (making David Grove happy
with Perl) I'm off for a Guinness!
Nat
(and then a nap :-)
http://www.technetcast.com
Nat
Whoops, I misread the mp3 player. Not 1:26, that's the total length.
1:02 is where I was when I stopped.
Ugh, transcription is hard says typist Barbie.
Nat
(my apologies for the delay in sending this)
Software Project Survival Guide
by Steve McConnell
Published by Microsoft Press.
Takes you step by step through the project, and each chapter ends
with a checklist of things that should be happening and things
that shouldn't. Quite detailed,
Here's a quote from Jim McCarthy's "Dynamics of Software Development"
that seems relevant given the recent fracas on perl6-language-regexp:
Someone once asked me, "What's the hardest thing about software
development?"
I didn't hesitate. "Getting people to think."
Believe it or not, most
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
Dan Sugalski writes:
I've been thinking since I sent my last mail on this that we might actually
want to leave the two (PDD RFC) separate. Keep on with the RFCs for
'external' things, and PDD for the actual internals implementation of things.
Ultimately, I think we're going to need at
Here's a program I use to count messages in my mailfile:
#!/usr/bin/perl -w
while () {
if (($who) = /^From\s+\S+\s+\S+\s+(\S+\s+\S+)/) {
@r = reverse split ' ', $who;
$r[0] = sprintf(%02d, $r[0]);
$count{@r}++;
}
}
foreach (sort keys %count) {
printf(%s:
Stephen P. Potter writes:
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
Stephen P. Potter writes:
| You don't need to know any of the modules in CPAN to use perl, but once
| you learn how to use search.cpan.org, your productivity will most
| probably increase dramatically. Just like knowing how to use the
| documentation will make you more productive.
The
Stephen P. Potter writes:
Objection, your honor! This is a logical extention of part of the
discussion. If we're discussing what is wrong with perl5 to make perl6
better differentiating between philosophies is quite on target.
The corner of the discussion about search.cpan.org and broken
Stephen P. Potter writes:
Atoms- Unicode. If everything is Unicode, you're going to have to grok
Unicode (at least tangentally) to be able to use perl.
Others have well dealt to this.
RFC 161- Everything becomes an object. Filehandles are more object
oriented in Perl6, and the special
Kirrily 'Skud' Robert writes:
I would like to set up a perl6-modules to discuss this topic, which I
believe is separate from the question of what goes into the standard
library.
After talking with Skud, it sounds like it's not yet perl6 specific.
I'd suggest a
[EMAIL PROTECTED]
list for
26 matches
Mail list logo
