RFC: Community Education Page
Hmmm...This doesn't seem to have particularly grabbed the popular imagination among the Perl6 crowd. Let me ask something a little more concrete and see if that gets us to ignition, otherwise it's probably not feasible. Assume that I'm going to create, host, and maintain a small website that explains where Perl6 stands and how it got there. The message of this site is essentially marketing (oh no, he used the M- word!!!). The message is: - We are a serious project, not a toy or a research effort - We can be counted on to release a 1.0 in a reasonable timeframe, - We can solve real problems in ways that are better than anything else out there Here are some questions I would need help answering (many of them are restatements of each other): - Why are we creating a new language? - Why should people be interested in Perl6 when (Python | Ruby | Java | C# | $other_language) already exists and probably fills their needs? - What are the major new features that we want to include? - Continuations - Coroutines - Redefinable language grammars - Regexen that are a grammar as opposed to a minilanguage - MMD - Junctions - ??? - Why do we want each of these features, beyond Because it's shiny? - Having any one of the above features would probably be a good thing. Is there extra leverage to getting 2+ of them in combination? E.g. does all(continuations, MMD) give you a 2x multiplier in terms of any(expressiveness, power, Anything) over just one(contininuations, MMD)? - The initial estimate for how long it would take was one year for design, 2-3 years for implementation. We're now at five years and still doing design. What happened? - Why should people regard us as anything other than vaporware? - What real, useful projects are being done in Perl6 right now? - What real, useful *commercial* projects are being done in Perl6 right now? - Other questions that might be useful? --Dks
RFC: Community education page
I was chatting with a P6 person the other day (who can remain nameless unless he chooses to identify himself). He made the following observation: Every time we're lambasted for how long Perl 6 is taking I remind myself that Short Term Thinking is the norm now. I think there are a couple of reasons for this lambasting, and the more important (and remediable) one is lack of education on the part of the baster. They don't understand : (A) how hard it is to design a language; and, (B) how much progress really has been made. I'd like to propose that there be a single web page (or maybe a small wiki, but one page might be preferable) somewhere that could be pointed at to show just how much has been done. It could list all the CPAN modules in the Bundle::Perl6 module (are those all Perl6 modules explicitly or are some of them support framework?), all the sites where Pugs has been deployed in production (I gather there are some?), any non-toy / non-arcane projects that are being worked on in Perl6, etc. I suppose it could also list the various language implementations that are targetting Parrot, but that's much less impressive to the common hacker who just wants to get work done, and not terribly relevant to the question Why is __Perl6__ taking time?. Also, the page should talk about why it is difficult to do what is being done. Ask the reader questions: You want to support continuations / have coroutines / embedd yacc in your language / whatever. How do you do it? Then offer up an analysis of various design choices that were considered and rejected and why. In particular, since the average person probably thought of the naïve answer, shoot big holes in that one. That way they sit up and say Oh. Hmm, I guess this really is kinda hard. I see this as a small effort towards community outreach, where community is both the existing Perl people and the wider Internet. I volunteer to create the page, host it, and maintain it, but I would need help gathering the information in the first place. And if the Perl6 community doesn't think it's a good idea, then I won't bother. Comments? --Dks
Re: RFC: Community education page
On May 4, 2006, at 10:59 AM, [EMAIL PROTECTED] wrote:
On Thu, May 04, 2006 at 10:44:29AM -0400, David K Storrs wrote:
Also, the page should talk about why it is difficult to do what is
being done. Ask the reader questions: You want to support
continuations / have coroutines / embedd yacc in your language /
whatever. How do you do it? Then offer up an analysis of various
design choices that were considered and rejected and why.
I think this will see a lot of use, not just in terms of people really
outside the perl6 project, looking at it, and wondering what's
taking so
long, but also people on the semi-inside, trying to remember things
like
I'm sure there's a reason other then C if condition_without_parens
{block} that we can't have C %foo {'bar'} DTRT, but I can't
remember it, which certianly happens to me fairly often.
Also, as a checklist for proposals. If you're thinking of proposing
something, go look there. If it's already there, do you have any
new pros
to put against the existing cons?
-=- James Mastros
That's an advantage I hadn't thought of.
We'd have to be careful to keep it brief, though. The whole point is
that this is supposed to be a single page that can be read in a
reasonable period of time (~10 mins). It's supposed to answer one
question: Why should I still be excited about Perl6 even though
it's taking longer than was expected?, not a horde of questions like
why were coroutines implemented that way? and such.
--Dks
Re: A proposition for streamlining Perl 6 development
On Feb 7, 2006, at 5:33 PM, Allison Randal wrote: Parrot, on the other hand, has noticeably gained momentum the past 6 months or so. AFAICT, this is largely due to the fact that we're close enough to finished that we can see the light at the end of the tunnel, and because Pugs reminded us to hold on to our sense of fun. First off, I'm just a lurker on the lists and I don't spend tuits hacking Perl6, Parrot, or pugs. Also, I'm definitely behind on the SOTA as far as P6 goes so, hopefully, nothing that I say below is outright wrong. If it is, apologies. I know that, over the last year or so, I've been feeling fairly exhausted with Perl6--as all large projects do, it takes a long time and, while it's going on, it's hard to see the progress that is being made. I follow the lists, but I haven't done any Parrot or pugs hacking, so I didn't really have a practical sense of where things stood. It seemed like a never ending treadmill, and I've been reading the lists in a more and more casual way as tuits and energy flag. Well, after this exchange I decided to check out the state of things, and I was very pleasantly surprised. IIRC, $Larry said that he would define the language in terms of the chapters from the Camel book, with the Synopses being the definitive version of the AES triad for a particular chapter. So, here are the Synopses that are written and in the repository at https://svn.perl.org/perl6/doc/trunk/design/syn/ # S01.pod # S02.pod # S03.pod # S04.pod # S05.pod # S06.pod # S07.pod Not actually here because formats have been removed, but I'm including it in the complete section. # S09.pod # S10.pod # S11.pod # S12.pod # S13.pod # S17.pod Not complete, just lists topics to cover # S29.pod Not complete, just a pointer to So, if @Larry precisely followed the Camel, here's what's left (sorted by my opinion of its likelihood of being written): Synopsis Topic Will it be written? (Just IMO) --- - S14.pod Tied variables ? S25.pod Portable Perl Maybe--probably just a tweak of P5 version S19.pod The CLI Probably not S20.pod The Debugger Probably not S22.pod CPAN Probably not S26.pod POD Probably not S24.pod Common Practices No S27.pod Perl CultureNo S08.pod ReferencesYes S15.pod Unicode Yes S16.pod IPC Yes S18.pod Compiling Yes S21.pod Internals and ExternalsYes S23.pod Security Yes S28.pod Reference; Special Names Yes S30.pod Reference; The Standard Perl Library Yes S31.pod Reference; Pragmatic Modules Yes S32.pod Reference; Standard ModulesYes S33.pod Reference; Diagnostic Messages Yes My reasoning: - S14: I'm not clear on whether tied variables have gone the way of formats. - S25: Portable Perl, it's unclear how much the elements addressed therein would change from Perl5 to Perl6, so it might not be necessary to rewrite this beyond a few tweaks to the P5 version (like deleting the section on XS). - The ones labelled Probably not are (arguably) not properly part of the language but part of the toolkit around it. As such, they don't really need to be included in the language spec. YMMV. - S24: There can't really be any Common Practices until some time after 6.0.0 is released, so that's a No. - S25: Perl Culture is definitely not part of the language design. - S08: More and more elements are being given first-class status and auto-referencing behaviors. Once something is first-class and can smartly manage its own (de)referencing, there is no real need for user-level operators to do it. However, we still need defined semantics for how it all works under the hood, so we need a Synopsis. - S15, S16, S18, S21, S23: I thought these were a pretty clear call for gotta have a spec. - S28, S30-33: The Reference Synopses are simply compilations of information that is designed elsewhere so
Re: A proposition for streamlining Perl 6 development
On Feb 7, 2006, at 6:51 PM, David K Storrs wrote: I'd say that qualifies as light at the end of the tunnel indeed! Forgot to say...all of this was was predicated on the idea that the code can't really be written until the spec is done. Once the spec is complete (even if not totally frozen), it becomes much easier to produce the code. Also, simply having the complete spec is a pretty major milestone that would be worth a lot of spirit uplifting points. --Dks
Re: split on empty string
On Jan 18, 2006, at 1:18 AM, Jonathan Scott Duff wrote: On Tue, Jan 17, 2006 at 12:35:57PM -0500, Mark Reed wrote: On 2006-01-17 12:24 PM, Gaal Yahas [EMAIL PROTECTED] wrote: [split on empty string] doesn's seem to be specced yet. I would prefer the current pugs behavior; it's consistent with the general case, in which a string which does not match the splitting regex results in a single-item list containing the original string. This is the Python behavior. I find the Perl5 (and, surprisingly, Ruby) behavior rather counterintuitive. FWIW, I agree with Mark. -Scott Just to show opposite, I've always found that behavior (i.e. returning the original string unchanged) confusing. Csplit works based on sequential examination of the target string to locate matching substrings on which to split. There is a matching empty string substring between every character. Naturally, what you get back is an array of characters. Plus, it's a useful idiom. --Dks
