Nathan Torkington wrote:
Alan Burlison writes:
seem a very optimal way to go about it. How about a design document
(format to be decided) and a 'design + commentary' document which is the
design document with the condensed email discussion inserted into it as
the commentary. That way
On Mon, Dec 04, 2000 at 10:08:35PM -0500, Bryan C. Warnock wrote:
Be available. Don't give a task, then disappear until its due, accept it,
then disappear again. Answer questions. Check the work. Give feedback.
This is very important IMHO; especially for apprentices that really
need some
Jonathan Scott Duff [EMAIL PROTECTED] wrote:
On Mon, Dec 04, 2000 at 10:08:35PM -0500, Bryan C. Warnock wrote:
Be available. Don't give a task, then disappear until its due,
accept
it,
then disappear again. Answer questions. Check the work. Give
feedback.
This is very
On Wed, 31 Dec 1969, David Grove wrote:
In order to serve and assist future "apprentices" or maintainers, the
communication between the two should be public (unless private on
purpose), or somehow publicly available. Given the undesirability of
having ten gazillion mailing lists, and likely
On Tue, 5 Dec 2000, Alan Burlison wrote:
How about writing the documents in XML and having a 'perl specification'
DTD?
...
Death to POD!
Can we *please* not re-fight this war? I know you remember the last
couple incarnations of XML VS POD. Just replay them in your mind and
enjoy the show.
"BMK" == Bradley M Kuhn [EMAIL PROTECTED] writes:
BMK If we do this, please also make perl6-internals-design-monitor
BMK or something like that, which is a list that simply redistributes
BMK mail from perl6-internals-design to its subscribers. In other
BMK words, only perl6-internals-design
Simon Cozens writes:
Yes, we should really postpone the inevitable markup language war until
we have something to mark up.
You channeled my very thoughts, Simon.
I say that the person who *does* the work deserves the right to choose
what format it is in. So long as we can make navigable
David Grove writes:
3. We seem to be creating a class system. Nate, this is one that I can see
as a must-be, so I'm not going in _that_ direction. But let's still
consider ourselves equal, regardless of rank, ok? Otherwise, perl 6 is a
wash, because it's just as much about community as it is
Don't miss the point. I'm not proposing to look for masters using
brainbench, but for viable apprentices that way. Basic Perl skill seems a
certian criterium for candidacy, as would basic c skill for some areas.
I've also ranked master there, but only in Perl, not perlguts. I've
proposed using
Today around 11:55am, David Grove hammered out this masterpiece:
: Don't miss the point. I'm not proposing to look for masters using
: brainbench, but for viable apprentices that way. Basic Perl skill seems a
: certian criterium for candidacy, as would basic c skill for some areas.
: I've also
David Grove wrote:
Also, as far as documentation goes, I think it _should_ be written by
apprentices, so that non-masters can understand it too. That's always been
a huge criticism of the perldocs. That's not grunt work. That's proper
allocation of duties to the best suited personnel for the
"Bryan C. Warnock" [EMAIL PROTECTED] wrote:
On Wed, 31 Dec 1969, David Grove wrote:
In order to serve and assist future "apprentices" or maintainers, the
communication between the two should be public (unless private on
purpose), or somehow publicly available. Given the undesirability
Today around 11:06am, David Grove hammered out this masterpiece:
: Does brainbench still have free tests for Perl? Maybe that's
: something to look into, and maybe since it's a purely volunteer
: effort if they are now charging for their perl tests, they might
: make an exception... I'll look
David Grove writes:
What does it take to be considered of "master" status in a certain area
Basically this: if you're good at doing something and want/need
someone to help with it, then you should be able to ask for an
apprentice.
I'd say not to get too hung up on "master" and "apprentice", as
On Wed, 31 Dec 1969, David Grove wrote:
Ok, it sounds like a plan. Where do we start? By creating a registry of
current tasks and masters, then fighting for apprenticeship?
I don't know. I've gotten a few good responses on the general idea and
process, but little-to-no feedback on the
2000-12-05-13:02:56 Nathan Torkington:
I say that the person who *does* the work deserves the right to
choose what format it is in. So long as we can make navigable
webpages out of it, that person can write on a Commodore 64 for
all I care.
Would you accept a restatement of: as long as
Steve Fink wrote:
David Grove wrote:
Also, as far as documentation goes, I think it _should_ be written by
apprentices, so that non-masters can understand it too.
Except it's a particular duty that nobody really likes to perform.
One thing that might be really cool is if there was a
On Tue, Dec 05, 2000 at 11:28:31AM -0800, Nathan Wiger wrote:
One thing that might be really cool is if there was a way to get some
tech documentation apprentices on-board just to specialize in perldocs.
For example, people out of school interested in tech documentation but
needing something
Nathan Torkington [EMAIL PROTECTED] writes:
David Grove writes:
What does it take to be considered of "master" status in a certain area
Basically this: if you're good at doing something and want/need
someone to help with it, then you should be able to ask for an
apprentice.
I'd say not to get
On Tue, Dec 05, 2000 at 11:05:43AM -0800, Steve Fink wrote:
David Grove wrote:
Also, as far as documentation goes, I think it _should_ be written by
apprentices, so that non-masters can understand it too. That's always been
a huge criticism of the perldocs. That's not grunt work. That's
will have to do some proofreading (also tedious) no matter what. If
the
Bah. *I* like proofreading. Certainly for typos and English
construction
if I can forget everything other than the last 2 sentences I read.
Masters have no reason to spellcheck. I mean they'll have to proofread for
Patches welcome.
=head1 Introduction
This is not a design document; it's a meta-design document - that is, it
tells us what things we need to design, the things we need to consider
during the design process of the Perl 6 internals.
It's completely unofficial, it's completely my opinion, it's
On Tue, Dec 05, 2000 at 11:28:31AM -0800, Nathan Wiger wrote:
Anyways, that's just one suggestion. Do I have any idea where to find
these mythical people? No, unfortunately. Perhaps some feelers on
newsgroups might be a good place to start. Personal experience shows
that this could be a
Simon Cozens [EMAIL PROTECTED] wrote:
Patches welcome.
Well, this isn't a patch, but if you really meant patches literally and not
figuratively, I can provide one if you let me know. ;)
Of the suggestions that have been advanced so far, four are worthy of
more consideration: C, C++, Java
Bradley M. Kuhn writes:
Java is portable and gives us OO, but it's slow and ugly.
I am probably the biggest proponent of the "use Java to implement Perl"
camp.
Java is only somewhat portable.
One concern that I have about the data structure design thus far (and I
believe I wrote an RFC
Bennett Todd writes:
Would you accept a restatement of: as long as whatever it is can be
translated into a common format, we can work with it, and the
composition of the actual words is far more important than niggling
over choices in preferred markup style?
Sure, but that begs the question
At 11:12 PM 12/5/00 -0500, Bradley M. Kuhn wrote:
Simon Cozens [EMAIL PROTECTED] wrote:
Of the suggestions that have been advanced so far, four are worthy of
more consideration: C, C++, Java and a specially-designed Perl
Implementation Language. (PIL)
Java is portable and gives us OO,
At 04:29 PM 12/5/00 -0500, Kirrily Skud Robert wrote:
On Tue, Dec 05, 2000 at 11:28:31AM -0800, Nathan Wiger wrote:
Anyways, that's just one suggestion. Do I have any idea where to find
these mythical people? No, unfortunately. Perhaps some feelers on
newsgroups might be a good place to
Kirrily Skud Robert [EMAIL PROTECTED] wrote:
On Tue, Dec 05, 2000 at 11:05:43AM -0800, Steve Fink wrote:
David Grove wrote:
Also, as far as documentation goes, I think it _should_ be written
by
apprentices, so that non-masters can understand it too. That's
always
been
a
29 matches
Mail list logo
