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
Bryan C. Warnock writes:
> What are we going to do with the myriad mailing lists the RFC process
> spawned? Are they going to be recycled come design/implementation time, or
> are they closed/dead/gone. http://dev.perl.org/lists has them all listed as
> "current" (even though deadlines ex
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
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:
> | 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.
>
> Th
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 7
Dave Storrs writes:
> While it may be true that beginners don't need to use a particular
> feature--or even know about it--how will they know that until they have
> studied it?
Documentation. A curriculum, roadmap, suggested path, whatever. Nate
Wiger's working on a man page to explain
Dave Storrs writes:
> 1) One of the great strengths of Perl is that its learning curve
> is very shallow but very long. Adding more stuff to the language makes
> the curve steeper, because you need to hold more in your head as you learn
> it.
I see those as orthogonal. I can add more to t
Dan Sugalski writes:
> People think they *must* know all the core bits of a language, and they
> think that consists of all the stuff we ship with perl. (And, let's face
> it, we ship a *lot* of stuff with perl) It's like you're not allowed to
> know only a part of a language anymore--that's so
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 Rig
Dave Storrs writes:
> < SARCASM=EXTREME>
Everyone, please try to stop the downhill descent of the conversation.
This is not just Dave, but others in the thread too.
I'm trying to understand what people fear, and why they fear it, so
that I know how to respond. Ridiculing, inflaming, or exaggera
Stephen P. Potter writes:
> 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. It is now (becoming) a full featured
> language, quit
Stephen P. Potter writes:
> This is quite a simple little script. The majority of the changes
> that are being talked about won't ever show up in this. It'd be
> nice if you could show something a little more complex.
The point I was making is that the perl4 stuff won't change
significantly.
T
Jarkko Hietaniemi writes:
> Yea, verily. I have more than once stared for more seconds than I
> care to admit being completely baffled at why my C compiler doesn't
> appreciate
>
> print "foo = $foo\n";
If I had a dollar for every time I've put $ on C variables, I'd have
enough to buy Wil
Chaim Frenkel writes:
> Those are all major typo inducing changes.
>
> You'll need alternative micro-code loads for your fingers, when
> switching between clients and when editing scripts that pre-date Perl
> 6.
So we can't change Perl, because changes have to be learned?
So now the changes are
Nathan Torkington writes:
> Here's a program I use to count messages in my mailfile:
My point being that perl6 is not a bizarre froofroo language bearing
no relationship to perl5, and that all the good stuff from perl5 will
be alive and kicking in perl6. I think a lot of the panic
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(
Michael G Schwern writes:
> 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?
Damian's converted a program from the Cookbo
Michael G Schwern writes:
> 5.6.0 style was jarring enough (and fairly well justified). Its been
> so long since we've had an integer increment that it should be fairly
> shocking.
And we can always think of a scheme for codenames, and have that
scheme be the theme for perl6.
Hmm, if perl5 was
What bothers me about the idea of reopening the RFC proces is that the
RFCs we have are already overwhelming. I think one reason we haven't
seen anything from Larry yet is that the RFCs cover an enormous area,
but in a disconnected and difficult to summarize and use form.
I don't think there's a
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 l
Bryan C. Warnock writes:
> Ask, all, are we reusing perl6-rfc as the submittal address, or will there
> be a new one (perl-pdd)?
I'm in favour of renaming to reflect the new use of the list. Dan?
Nat
Kirrily Skud Robert writes:
> Wasn't he meant to be keeping us up to date with snippets of what he's
> doing/thinking about? I recall Nat posting a couple of months ago that
> he'd talked to Larry and Larry had said he'd do this.
I think the problem is that the RFCs aren't really a list of the
t
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 pe
Simon Cozens writes:
> I did say that I retracted my remarks.
Just speaking for myself, I'd rather see an apology. A retraction
is impersonal, but an apology implies you regret it.
If I appear to be hounding you about it, it's because I'm appalled. I
expect sensitivity and courtesy from everyo
Simon Cozens writes:
> > okay. i quit.
>
> Well, hm. I'd rather we actually made something positive out of this.
Apologizing would be a good place to start. As many folks have
pointed out, it's hard to find capable intelligent volunteers.
And you just chased one away, a reprehensible act of de
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 peopl
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
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
Nice. An apprentice is an administrative assistant with a career
path. If people are happy to do this, we'd be happy to use them. The
chairs proved weak at reporting on their list's activities (I know I
was) so being able to delegate that to someboy who wanted to do it and
help, would be good.
Filipe Brandenburger writes:
> I want to contribute to the Perl 6 effort, with ideas
> and mainly with coding in C/C++.
Thanks for your interest. Here's the current state of play:
Larry is putting together, at Larry speed :-), an idea of what the
language will look like (all preliminaries show
David Grove writes:
> I'm not suggesting censorship. I'm questioning O'Reilly's position.
I don't think this has anything to do with O'Reilly--Mark wrote the
article, and it's on perl.com because of that. Our rebuttal will
also go there. O'Reilly hasn't got anything to gain by putting the
artic
Simon Cozens writes:
> On Thu, Nov 02, 2000 at 02:01:45PM +, David Grove wrote:
> > Absolutely and double the vulgarity. I can't imagine that the article was
> > posted at all. Several of us (you guys) have _some_ pull at O'Reilly...
> > please suggest that the article be pulled.
>
> Of cour
John Porter writes:
> David Grove wrote:
This branch of the discussion is getting us nowhere fast.
Nat
Simon Cozens writes:
> > http://www.perl.com/pub/2000/11/perl6rfc.html
>
> Agree 100% to every point.
I don't. A constructive critique of the Perl 6 RFC process might be
useful. This onslaught of negativity is not.
The Perl 6 RFC process got people talking about the future, and we
hav
(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, an
Nicholas Clark writes:
> (and it would show off the Unicode abilities of perl if keywords were
> aliasable into the alphabet of your choice. But there might be a price
> to pay in script maintainability.)
Damian has modules to support Klingon constants and keywords.
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
[I have to wake up in about 4 hours, so this is all you get, the
first 1h26m of the talk, loosely transcribed and not proofread]
As I look around here, I see a lot of yougn faces. Almost too young.
I like you. I always planned to stay young all my life. I've always
been blessed with a face tha
http://www.technetcast.com
Nat
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 :-)
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
> "con
Buddha Buck writes:
> >Uh, what talk is that?
>
> The talk he is giving on 14 October, where he was supposed to reveal the
> direction of Perl 6.
Yup, Larry's giving a keynote at the Atlanta Linux Showcase on Friday.
He was going to use his keynote to announce his draft design for
perl6, but th
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
man
Larry tells me he's still reading the RFCs, and so won't be able to
make many conclusive pronouncements in his talk. He will, however, be
detailing the process by which he's making decisions and some of his
thoughts on the possible directions it could go.
I'll make sure his talk is available for
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 singl
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
Nathan Torkington writes:
> Mail me direct if you want to volunteer. Thanks,
We have a winner! No more calls, please.
Thanks,
Nat
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
Dan Sugalski writes:
> "General consensus" is best, but that can't be guaranteed. "Consensus of
> the ruling council" is more attainable, but there's that whole "ruling
> council" thing to contend with. "What Larry says" is best, but what happens
> if he doesn't, or gets hit by a bus at some po
I think we're talking about two different periods of development here.
The immediate question facing us is how to structure software design.
This is different from the ongoing maintenance of Perl.
We want and need a small group to design perl6 correctly. I can't see
this working any other way.
David Grove writes:
> There has to be some kind of middle ground we can find, no?
Nobody's suggesting complete quiet.
What we're seeing is the fundamental conflict of:
- the need for a coherent design meaning that very few people control
the design
- the need for openness and public involve
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 effective
Bradley M. Kuhn writes:
> It seems to me that the perl6-internals, perl6-qa, and perl6-licenses groups
> should be able to produce additional RFCs after this. Of course, the
> Language will be frozen, but these three groups may need to remain fluid
> after the 14 October 2000 annoucement.
I thin
Adam Turoff writes:
> From this point forward, no new RFCs will be accepted until the RFC
> submission process is reopened. Any new RFCs that are submitted
> during this review phase will be held in limbo until new submissions
> start up again.
When were you thinking the RFC process would reopen
I talked with Larry about schedule. I'd been under the impression he
was going to produce a draft language spec on October 1, and the final
on October 14. He set me straight: draft on October 14 (his keynote
to the Atlanta Linux Showcase), no deadline yet for final spec.
So we have until Octobe
Adam Turoff writes:
> I want to assert to the reader that there have been no substantive
> changes since v3 if an RFC was frozen at v3, but is currently v5.
>
> A "Frozen Since: v3" attribute should make this apparent.
Sure. And rather than rediddling all the other RFCs, only introduce
this whe
Adam Turoff writes:
> >From here on out, Frozen RFCs shall remain Frozen. Should the maintainer
> wish to clarify them after they have been frozen, the version number
> will increment by some fractional value (.01?), and a
> "Clarified: DD MMM " header will be added to the metadata.
>
> Obj
Piers Cawley writes:
> The idea here is to allow people to get ideas on the lists in a rough
> form where they can get some initial comments (which may blow the
> 'real' RFC out of the water...). There should be some very strict
> rules about how soon the 'real' RFC arrives though.
Why do you nee
Simon Cozens writes:
> I know, I know, but someone has to push things to a conclusion or the talking
> will never stop.
>
> There'll *always* be more worthy ideas. Do we suspend coding indefinitely?
I'd already started the discussion moving towards closing down the RFC
process, in an earlier me
John Porter writes:
> I for one hope he's not doing that, because it would tend to favor
> ideas that made it Frozen status sooner. I don't believe the temporal
> aspect of these things is relevant at all.
I'm not feeding Larry anything. He's been watching discussions as
RFCs evolve, and is wel
Simon Cozens writes:
> (The deadline for collecting ideas passed two weeks ago. Why is this all
> still going on?)
What deadline are you talking about?
Nat
Chaim Frenkel writes:
> We are not at that stage yet.
>
> There are too many new things that are _supposed_ to interact to
> bother with a prototype. It doesn't do any good, until the language
> is nailed down.
That's no argument against prototyping, though. Prototype one feature
and then you
Mark-Jason Dominus writes:
> I think it would be a step in the right direction if the WG chairs
> actually required RFC authors to maintain their RFCs.
In preparation for the end-run of RFCing, how about we compile a list
of "developing" RFCs that haven't been touched in more than a week,
and con
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 an
Steve Fink writes:
> I just wonder if a 10% improvement on some benchmark is worth writing a
> new language for. A 100% improvement on a single "representative
> real-world task" would be a lot more persuasive. But much more
> convincing would be allowing perl to be embedded as a scripting languag
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
Michael G Schwern writes:
> There's a good chunk of people who are working on things for
> YAPC::Europe at the moment and Sept 25th happens to coincide with
> about when everyone will be staggering back. To avoid having to
> choose between spending the next week working on YAPC or working on
> Pe
Larry's going to release a draft of his langauge decisions on the 1st
of October.
My plan to prevent a flood of 100 new RFCs on September 30:
- deadline for new RFCs of Sep 25. After that, only discussion of
old ones.
- send mail to existing authors of "developing" RFCs telling them
t
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 d
J. David Blackstone writes:
> I think the success criteria on http://dev.perl.org/pm/pos.html
> should be more measurable.
You're right. I was happy to have simply avoided "better" and "good",
the classic unmeasurable words :-) I kept "faster" and "easier", two
similarly unpinnable words, th
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 p
Thanks for that grim view, Alan. I've been looking around for someone
to act as the Devil's Advocate and say what might go wrong, so I was
happy to see this.
Your message seems to have two points: that the current brainstorming
phase is so chaotic that it's hard to see how anything good can come
Chaim Frenkel writes:
> Would it be worthwhile to 'waste' some time on writing caller and callee
> stubs? This would flesh out the final api and give the module writers
> something of an environment to work with?
Yes, I'm appalled I forgot this. It's part of what I've been thinking
about.
By ha
This will ultimately go in a more detailed version of the Roadmap,
but here's my current thinking on what comes next. Be warned, it's
written as a braindump.
Larry releases his draft language design, an overview of what will be
in the language and what it will look like. There'll be some
clarif
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 RFC
Michael G Schwern writes:
> In effect, instead of having one development track, we could have many
> development tracks, each focused on a single feature, or small group
> of features. This should make work easier, because on each track only
> one thing is changing, so its easier to track down ne
Michael G Schwern writes:
> Could we split this off into a working group and mailing list seperate
> from perl6-meta?
Sure. I'm going to set an aggressive schedule for the decision,
though, because this has all the hallmarks of a religious war. Let's
work through the problems now and be forced
Adam Turoff writes:
> 3) Those developers prefer Perforce and should not be forced
> to use CVS because non-committers prefer it.
>
> Is there anything more to be said about Perforce vs. CVS that *isn't* FUD?
You make it sound like we've decided on Perforce. Dan, how about you
sk
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 divi
Michael G Schwern writes:
> 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.
Well, yes, but a
John Porter writes:
> > > i think we should have some sort of end user announcement list. a lot of
> > > people are being asked to be kept up to date on Perl 6, but they aren't
> > > the types to want to wade through development discussions or
> > > announcements.
>
> Isn't there a perl-announce
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 wr
Michael G Schwern writes:
> Its not entirely clear if you're advocating we wait for this Perforce
> replacement before instituting a cannoical Perl 6 repository, or just
> mentioning it.
Mentioning it, and I had been opening discussion on instituting it.
> If its the former, then as a rule of th
brian d foy writes:
> i think we should have some sort of end user announcement list. a lot of
> people are being asked to be kept up to date on Perl 6, but they aren't
> the types to want to wade through development discussions or
> announcements.
>
> thoughts?
Yes. I hadn't envisaged the she
Ask Bjoern Hansen writes:
> the perl-qa people have some code they need to manage in a
> repository of some kind. For now I have directed them to
> SourceForge, but I have a 100 users license for perforce I got for
> perl, so if we can get a quick consensus that we might want to make
> a perl6 cod
(moved to -meta)
Karl Glazebrook writes:
> > > Yes. And for the record I also think the current approach of lets
> > > generate ten million RFCs and Uncle Larry knows best is nuts.
> > > There are already too many RFCs on this topic alone to grasp coherently.
> > Do you have a better suggestion?
[EMAIL PROTECTED] writes:
> The way people seem to be showing the status of RFCs is by putting
> "Status: foo" up near the maintainer info etc. This makes good sense.
> Can this be reflected in the sample RFC and the instructions and so on?
I've been asking Adam to do this, but I suspect he's ra
88 matches
Mail list logo
