Re: Proposed RFC for matrix indexing and slicing
At 08:28 PM 8/31/00 -0700, Nathan Wiger wrote: >Larry Wall wrote: > > > > More generally, for all X, I wouldn't mind > > if Perl became the language of choice for X. > >Who wouldn't! > >But I think that would probably have to be, "if Perl became the language >of choice for X - 1". > >Perl's gotta be written in something, after all... ;-) Other than the bootstrap issue and the speed issue, what's wrong with that? I'd rather write a parser in perl than pretty much anything else. (Well, OK, maybe SNOBOL, but...) Most C compilers are written in C, and if we can get perl emitting native code... Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Proposed RFC for matrix indexing and slicing
Larry Wall wrote: > > Karl Glazebrook writes: > : I have a lot of respect for Larry, but as a scientist I distrust all this > : deference to one single authority. > > Well, sure, but someone still has to decide who gets the grants. :-) But it's not always the same person. > : I don't know if Larry has any experience in scientific programming of the > : sort PDL tries to address. > > All the more reason to write good RFCs. I like to think I'm pretty > sharp, and can at least fake a good understanding of math. On the > subject of experience I can tell you that I've gone so far as to solve > simultaneous equations with matrices. But I will guarantee you that if > you can't make me understand what you want, you won't be able to make > most Perl programmers understand it. If it comes down to that, I can > at least get you some syntactic relief, but I certainly won't go as far > as to inflict higher math on the average programmer. Perl has always > been intended to be a multi-paradigmatic language, which means I don't > mind supporting theoretical abstractions as long as they don't get in > the way of mere mortals. The plan is not to inflict higher map but to provide some simply multidimensional array conveniences - compactly stored arrays, which can be manipulated en masse arithmetically (@a * 3 or equivalent), and a convenient multidimensional slicing notation. Given that most of the scientific stuff can be done in modules. > That being said, I wouldn't mind if Perl became the language of choice > for scientific programming. More generally, for all X, I wouldn't mind > if Perl became the language of choice for X. Me too Karl
Re: Proposed RFC for matrix indexing and slicing
Larry Wall wrote: > > More generally, for all X, I wouldn't mind > if Perl became the language of choice for X. Who wouldn't! But I think that would probably have to be, "if Perl became the language of choice for X - 1". Perl's gotta be written in something, after all... ;-) -Nate Of course, writing Perl in Perl would be pretty cool.
Re: Proposed RFC for matrix indexing and slicing
Karl Glazebrook writes: : I have a lot of respect for Larry, but as a scientist I distrust all this : deference to one single authority. Well, sure, but someone still has to decide who gets the grants. :-) : I don't know if Larry has any experience in scientific programming of the : sort PDL tries to address. All the more reason to write good RFCs. I like to think I'm pretty sharp, and can at least fake a good understanding of math. On the subject of experience I can tell you that I've gone so far as to solve simultaneous equations with matrices. But I will guarantee you that if you can't make me understand what you want, you won't be able to make most Perl programmers understand it. If it comes down to that, I can at least get you some syntactic relief, but I certainly won't go as far as to inflict higher math on the average programmer. Perl has always been intended to be a multi-paradigmatic language, which means I don't mind supporting theoretical abstractions as long as they don't get in the way of mere mortals. That being said, I wouldn't mind if Perl became the language of choice for scientific programming. More generally, for all X, I wouldn't mind if Perl became the language of choice for X. Larry
Re: Proposed RFC for matrix indexing and slicing
Nathan Torkington wrote: > I'm all for taking proposals on a particular subject (e.g., the PDL > multidim matrix suggestions, or the lvalue subs suggestions) and > giving the list a week to boil them down to one RFC that recommends an > implementation and says what was rejected and why. ok > > the final decision should not be in the hands of one person. > > I can't imagine this happening. Perl's been well-served by Larry's > taste and design sense, and (especially given the huge number of ideas > and the diversity of thought that has gone into them :-) I > (personally) would be wary of turning over some or all of the reins to > anyone else. > > Nat I have a lot of respect for Larry, but as a scientist I distrust all this deference to one single authority. I don't know if Larry has any experience in scientific programming of the sort PDL tries to address. Karl
Re: Proposed RFC for matrix indexing and slicing
(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? > > subgroups should iron out there differences among themselves and come up > with a coherent set of proposals. I think it's pretty obvious that many people don't have the language design skills do this. We have a lot of people who are making suggestions, but I'll start programming in Python if they're making decisions about what goes into Perl. (That's bluntly stated and perhaps harsh, but I certainly feel that mob rule is very unwise in this case). I'm all for taking proposals on a particular subject (e.g., the PDL multidim matrix suggestions, or the lvalue subs suggestions) and giving the list a week to boil them down to one RFC that recommends an implementation and says what was rejected and why. > the final decision should not be in the hands of one person. I can't imagine this happening. Perl's been well-served by Larry's taste and design sense, and (especially given the huge number of ideas and the diversity of thought that has gone into them :-) I (personally) would be wary of turning over some or all of the reins to anyone else. Nat
