Re: Critique available
At http://www.perl.com/pub/2000/11/perl6rfc.html, Mark-Jason Dominus wrote: There are a lot of people around who do have some understanding of the Perl internals. An RFC author who knows that he does not understand the internals should not have a lot of trouble finding someone to consult with, to ask basic questions like ``Do you think this could be made to work?'' As regex group chair, I offered more than once to hook up RFC authors with experienced Perl developers. As an RFC author and persistent discutant, I always assumed that all/most/many of such qualified internals folks would be reading the perl6 lists, and would squawk when appropriate. Translation issues were frequently ignored. Larry has promised that 80% of Perl 5 programs would be translatable to Perl 6 with 100% compatibility, and 95% with 95% compatibility. Wadr to Larry, those numbers are meaningless at this stage, let alone when he said it. I don't think Hitler was invoked at any point in the discussion. Well, you invoke Hitler when you're talking about people; you invoke Java when you're talking about programming languages. And IIRC, Java was invoked several times. :-) -- John Porter
Re: Critique available
Simon Cozens wrote: On the whole, driving a spike between language and internals by giving them separate lists was not a good idea. Nominally. But how many internals experts actually subscribed to the one and not the other? -- John Porter
Re: Critique available
Bennett Todd wrote: Java is crappy engineering with superb marketing, This is so wide of reality, I conclude that you don't know the first thing about Java. a good choice when you want or expect your project to fail and you are hunting for a way to have someone else to blame for it. Perl is _lousy_ for those tasks. I disagree. The vendor can *always* be blamed. :-) -- John Porter
Re: Critique available
David Grove wrote: Ok, Visual Basic then. Really? Let's see: If [Visual Basic] is well-suited to their needs, as they see those needs, then [migrating to it from perl] is a good thing. Specifically anybody whose needs could be adequately met by [Visual Basic] would certainly be seriously dissatisfied with perl, they're as close to opposite languages as I can think of, in many ways. Nope, not quite the same. -- John Porter
Re: C Sharp?
David Grove wrote: Isn't C# (C Sharp) a Microsoft-owned language that is (currently) available only on Win2k (though apparently targeted for crossplatform)? After Larry said he was thinking of making parts of Perl 6 in C#, I went on a studying rampage. I find nothing for anything except Win2k. Can someone provide links to compilers or resources for non-Win32/Win2k C#? I have heard (via a presumably reliable source) that MicroS..t has contracted Corel to port C# to linux. -- John Porter
Re: Transcription of Larry's talk
David Grove wrote: but then, proper japanese is read top to bottom, right to left... sounds like forth befunge. http://www.zebra.net/~dm/funge/spec98.html -- John Porter
Re: Transcription of Larry's talk
Simon Cozens wrote: "Now, we have to start over from scratch". That's INTERCAL. http://www.mail-archive.com/perl6-language@perl.org/msg00517.html -- John Porter
perl should optimize for extreme cases (was Re: [FWP] Wanted - Have = Need)
[Warning - mailing list violently altered!] John Carter wrote: On Fri, 13 Oct 2000, John Porter wrote: As a concrete example, perl's data structures are always managed in memory; while things like sort and merge have been written to utilize on-disk buffers when necessary. (Hmm... smells like an RFC...) I would assume that perl uses glibc's qsort routine. That would be great for perl6; but current perls implement a custom sort routine. The bigger issue, which I think is RFC-worthy, is that perl ought, if possible, to optimize for extreme cases by doing, e.g., disk caching, the way unix sort does. This could be controlled by pragmata, if it was deemed not useful as a default. -- John Porter By pressing down a special key It plays a little melody
Re: Continued RFC process
J. David Blackstone wrote: I'm talking a pair of lists for each working group/committee/whatever-you-want-to-call it. Hm, kinda like the clp.misc/clp.moderated duality... -- John Porter
Re: Now and then
David Grove wrote: No two or more members of a single company on (QA Team|Any Team)? If any team, for the purpose of development, it's not entirely logical/feasable, is it? I think it's not feasible generally. Maybe if you tighten up your definition of "single company". For example, I work for a company with over 35000 employees all over the country. Who knows how many of them would want to participate in p6 development? It shouldn't matter, because my company has no interest in the direction p6 takes, and would never, ever meddle in the way you fear. Also, your limit of 2 per committee doesn't make much sense, since a committee might only have 3 members, in which case 2 is a majority. Make strict minority is a better spec. -- John Porter
Re: Update on Larry's talk
Nathan Torkington wrote: won't be able to make many conclusive pronouncements in his talk. I'll make sure his talk is available for all to read once it's given. Uh, what talk is that? -- John Porter
Re: Request for Clarification: RFC Statuses
Jeremy Howard wrote: how is Larry being fed these RFCs? Is he being sent a list of 'Frozen' RFCs, as they freeze. That would seem to make sense, since then he can review the finished documents as soon as they're ready. 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. -- John Porter We're building the house of the future together.
Re: RFC - Prototype RFC Implementations - Seperating the men from the boys.
Michael G Schwern wrote: Chaim Frenkel wrote: At this point, I think this is too strong. My understanding of Larry's intention is that we are now brainstorming. Brainstorming can not work if folks will pre-filter their ideas. Part of the effect is a half-baked idea on another member of the brainstorming group. (I've seen some of the effect in Damian's responses) "RFCs should be *FOLLOWED BY* a prototype implementation" "...each RFC should *EVENTUALLY* be accompanyed by a prototype implementation" I'm not stating that each RFC should come with a prototype, but that one should be forthcoming as part of its development process. "If the RFC author feels they cannot implement the prototype on their own, they must find people who can. If they can't then they're not going to be able to find those to implement the actual code either." If you can't find the tuits to write the prototype, how are you going to find them to write the implementation? No. You can not oblige the RFC maintainer to write the prototype or cat-herd someone else into it. The vast majority of RFC authors (myself included) would simply not be up to such an order. Instead, it should be the WG lead's responsibility to ensure that each accepted RFC gets a prototype (*EVENTUALLY*), assigning an implementor if necessary. -- John Porter We're building the house of the future together.
Re: Perl 6 announcement list
Nathan Torkington wrote: 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. Isn't there a perl-announce? Or only perl5-announce? -- John Porter
