Re: Perl, the new generation
Hmmm...ok, on thinking about it, I generally agree with you. There is only one point that I would debate (and, as you'll see, there's a solution for that one, too): On Wed, 16 May 2001, Nathan Torkington wrote: > 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 the high end of a > language that beginners don't need to know. 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? < ACTION = &insert($tongue, $cheek)> Imagine the following conversation: JAPH: Here's a list of all the features in Perl. It may look overwhelming, but don't worry...you don't need to know all of them until later. Beginner: GAACKK!!! < /ACTION> Actually, something like what Randal was recently talking about, with the llama (i.e., introduction, small subset, whathaveyou) probably addresses this concern. We just have to make sure to point everyone at that document as soon as possible upon their entry into Perl. Dave
Re: Perl, the new generation
On Wed, 16 May 2001, Nathan Torkington wrote: > 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. For the record, the original post in this sequence came from David Grove, not from me (David Storrs). My response to David was an attempt at *preventing* a downhill descent...which is why Simon's comment, which came off feeling abrasive to me, bothered me. You're right; I should have refrained from sarcasm and simply asked Simon to please not treat my concerns so dismissively. > It sounds like the concern is that each new version of Perl adds > features, which programmers use. To be able to maintain or extend > code, you need to know those features. Thus, the core knowledge for > survival in Perl, is ever-growing. This is what I understood to be David Grove's point (David, please correct me if I have misunderstood). I don't know if I agree with this (I also may not have the background to answer it, since I didn't come on until 5.x), but I do feel, as I said before, that the language is sufficently large that it is hard to hold in one's head and that making it significantly larger would be a cause for concern. Other people may disagree with me on this; it's only my opinion. > In some ways I agree with this. In particular, the growing number of > modules with an OO interface means that knowing how to use objects is > more and more important. This is true, but it could be taken as a counterargument...if there is a growing number of OO modules, that is because a growing number of Perl programmers are accustomed to, and make use of, OO techniques. [single programmer doesn't need advanced features, teams are not used for solving small problems so it is reasonable that they need advanced stuff] > So I guess I don't see it as that big a problem. Am I missing > something? Well...I'm not sure my concerns are well enough defined to be convincing, but I'll try to lay them out: 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. 2) If the language is so big that you can't hold all of its features in your head, then those extra features might as well not exist. Now, after all of the above discussion, I should just say that I'm not convinced that Perl is too big (I think it's _big_, which is different from _too_ big), or that anything that we are adding is going to _make_ it too big. I'm simply trying to point out one side of the argument. Dave Storrs
Re: Perl, the new generation
On Wed, 16 May 2001, Simon Cozens wrote:
> On Wed, May 16, 2001 at 11:14:57AM -0700, Dave Storrs wrote:
> > afraid of, and to express your concerns about it. However, the way that
> > you chose to do that ("Once quick and dirty dies, Perl dies.") implies
> > that the only thing that Perl is good for is q-n-d
>
> A veritable lesson in logic! Here's an equivalent statement.
> "Once all the oxygen suddenly disappears from the atmosphere,
> humanity is wiped out".
< SARCASM=EXTREME>
Thank you for your courteous response. I tried very hard to write
that email in a rational, logical way, and I'm very glad to see that see
people respond in kind.
< /SARCASM
> That naturally suggests that the only thing humanity is good for is is
> respiring oxygen, right? And it's an almost *exactly* equivalent statement,
> because it's almost as likely that Perl will stop being good for quick 'n'
> dirty stuff as all the oxygen dropping out of the atmosphere.
Oddly enough, you've just restated my exact point...just in a way
which, to me at least, seems much more combative.
Dave Storrs
Re: Perl, the new generation
On Wed, 16 May 2001, Adam Turoff wrote: > On Wed, May 16, 2001 at 08:57:42AM -0700, Peter Scott wrote: > > It doesn't look to me like the amount of Perl one needs to know to achieve > > a given level of productivity is increasing in volume or complexity at > > all. What it looks like to me is that there are additional features being > > added which enable one to achieve greater levels of productivity and > > performance if one wants to learn them. > > Who *wants* to be unproductive? I think Peter's point is that you can at least maintain your current level of productivity without doing anything but that, if you take the time to learn the new features, your productivity might go up...not necessarily, since the new features may not help with what your doing, but maybe. (Peter, I'm putting words in your mouth, so correct me if I'm wrong.) Dave
RE: Perl, the new generation
On Wed, 16 May 2001, David Grove wrote:
> For me, it's the bare minimum amount of Perl you must *use* to be productive
> that I see increasing in our plans and discussions. I'm afraid of Perl
> turning into a verbose monstrosity to please verbosity addicts of languages
> whose only point of advocacy is Perl FUD. Once quick and dirty dies, Perl
> dies.
Several thoughts for you, David. All of these should be taken
from the perspective of someone who cut his teeth on 5.x and has never had
to deal with the (joys|differences|horrors) of 4.x.
1) I agree that Perl is a big language and it's hard to hold it in
your head. I frequently find that some bit of it that I haven't used in a
while has fallen out and I need to go read up on it again.
2) Respectfully, I don't think that we can accurately say that the
minimum amount of Perl needed in order to be productive is increasing; we
haven't finished defining P6 yet, so how can we know this?
3) You have every right to be afraid of anything you want to be
afraid of, and to express your concerns about it. However, the way that
you chose to do that ("Once quick and dirty dies, Perl dies.") implies
that the only thing that Perl is good for is q-n-d, and this is simply not
the case. I have written enterprise-quality code, for large systems, in
Perl, and I will absolutely defend Perl's ability on that playing
field.
4) While your concern is well taken, I think you are doing
yourself a disservice by using such inflammatory language...it makes me
(and probably others) focus more on your tone than on your point.
Dave Storrs
Re: perl5 to perl6
(I think I've got the attributions right.)
On Fri, 11 May 2001, Jarkko Hietaniemi wrote:
> On Fri, May 11, 2001 at 05:02:39PM +, [EMAIL PROTECTED] wrote:
> > Nathan Torkington <[EMAIL PROTECTED]> writes:
> >
> > Speaking as someone that has often had to work on C, Perl, Verilog and VHDL
> > at the same time I can say that clearly visible differences are not without
> > merit.
>
> 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";
Actually, I recently bamboozled my boss with something
similar. We were having a "weird code" contest, where he would scribble
down something and ask what it did and then it was my turn. We had been
doing all the examples in C++, and then I said:
"Ok, this one has a nasty trick to it, but once you see the trick
it's easy. What does this do?"
And I showed him the following:
while(<>) {
print;
}
When he couldn't get it, I told him what it did and asked him to
explain how it worked. When he couldn't, I reminded him that there was a
"nasty trick" and told him that the trick was that it wasn't C++ code, it
was Perl code.
Dave
Re: Perl Apprenticeship Program
On Tue, 5 Dec 2000, 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 > > Except it's a particular duty that nobody really likes to perform. Which Actually, I kinda like it. If someone is willing to answer my questions so that I understand what it is I'm documenting, I'm willing to do a good chunk of the documentation. I'm currently working on some docs on handling binary data in Perl (with pack, unpack, vec, etc) that I intend to submit to perl.com. Dave
Perl apprenticing
I've tried to snip as much as possible without fouling up attributions. If I failed, my apologies. On Thu, 30 Nov 2000, Dan Sugalski wrote: > >At 11:47 AM 11-30-2000 -0500, Bryan C. Warnock wrote: [...is there a place where Perl Apprentice-wannabes can sign up with a Perl Master...?] > Not at the moment, at least not formally. Want to set something up? (And > yes, I'm serious. A good master/apprentice thing would help a lot of folks, > I think) I would be very interested in an apprenticeship, if such a thing were to be set up--and I'd be willing to help set up the infrastructure. However, we should move carefully, because it could be a very good thing or a very harmful thing depending on how we implement it. So, are other people actually interested in this, at least enough to open a new thread on it? Dave Storrs
Re: Critique available
On Thu, 2 Nov 2000, David Grove wrote:
> Censorship, the type the I've opposed in the Perl community, is that which
> provides the benefit of false impressions (a.k.a. marketing by fraud by
> ommission of the truth) for the procurement of the almighty dollar.
> I'm not suggesting censorship. I'm questioning O'Reilly's position.
With all due respect, David, that's not what censorship
means. Censorship is simply the act of deleting material which is
considered, in the judgement of the censor, sensitive or harmful. It has
nothing NECESSARILY to do with the almighty dollar, and stating that it
does is simply clouding the issue.
This thread has gone on for a long time, and is starting to repeat
itself...could we please let it go?
Dave Storrs
RE: Continued RFC process
On Mon, 9 Oct 2000, Nathan Torkington wrote: > Closed-for-posting mailing lists that are publically readable is the > best suggestion we've had to meet these ends so far. > > Anyone have better suggestions? I don't know that this is _better_, but...perhaps we could have the lists that you suggest, but also have separate, publicly postable, lists where anyone could comment. If one person from the design committee would be willing to read these public lists and interact with the people there, saying "that's a good idea, we'll use it" or (probably more common) "we'd like to do that, but we can't for reasons XYZ," that would go a long way towards making the community feel invovled. Perhaps this duty could rotate, so that various design-committee voices would be heard on the outside. Dave
Re: Continued RFC process
Is anyone here familiar with the behind-the-scenes process and politics of the Linux development community? If I understand it correctly (and I'm not sure I have the details right), when Linux was being developed, Linus came up with a skeletal OS based off of MINIX, then he turned it loose. People volunteered bits of code which Linus integrated into the OS. As the thing snowballed, Linus couldn't handle the volume, so he chose a group of lieutenants who also had commit authority. Now, I'm not sure where the planning came from...was there a specific website or elist or whatever where Linus said "ok, we'd like a TCP/IP stack that has the following interface?" Or what? Whatever they did worked, and I haven't heard anything to suggest that the Linux community feels excluded...is there some way we can duplicate/adapt their process so that we can simultaneously put to rest both David Grove's concerns about elitism and Dan Sugalski's concerns about lack of planning? Dave
Re: Request for Clarification: RFC Statuses
On Mon, 18 Sep 2000, Adam Turoff wrote: > Background: RFCs should be in development until frozen or retired. > > A status change from "Frozen" to "Retired" may be acceptable. Such > > So, what's everyone else think? I really don't want to write up > an RFC about this. :-) My thoughts: - an RFC should start with a status of "developing", and only the author should set the status to frozen/retired (which I assume is how it is now) - an RFC should only go to retired if it becomes clear, from significant discussion, that the idea is best left undone; once this has been determined, there is no reason to continue updating it, because the idea isn't going to go forward. Braincycles are a scarce resource; devote yours elsewhere. - an RFC should only go to frozen if it becomes clear, from significant discussion, that the idea is good, is desired by a reasonable fraction of the community, and has been refined about as far as it can be. If someone suggests a small incremental improvement, fine, incorporate it and leave it marked "frozen"; if the change is not minor, return the status to "developing" so that more discussion can follow. Or better yet, mark it status as "developing for next week" to show that it is once again up for review, but that it will be returned to "frozen" at a definite time if no discussion springs up. Just my log(e**2) cents worth, Dave
Re: The Future - grim.
Well, THAT was certainly specific, insightful, politely phrased, and filled with pertinent advice on how to remedy the problem! Alan, you're right about certain things...it's important that talented, experienced people have the final say over the final product. However, most of the problems in every field of human endeavor come down to the fact that there just aren't very many talented, experienced people. What that means is that we take our top people, enshrine them as design gods, approvers of submitted code, and coders of RHP (Really Hard Problems), and then we allow as many enthusiastic people as possible to try to solve the less hard problems...the best of these attempts gets used, the rest get thrown out by the top people. Yes, it's a lot of work for them and no, it's not really what anyone would choose in an ideal world, but it's proven to work...unless, of course, you'd call Linux a "slow motion train wreck." The other reason to do it this way is that if we DON'T let new (== "less experienced") people help out, how are they ever going to get more experienced at the problems that we need solved? And if the pool of available experienced people never grows, how is Perl supposed to survive? Dave (PS: I do not by any stretch of the imagination include myself in the list of "top people.") On Sun, 10 Sep 2000, Alan Burlison wrote: > Nathan Torkington wrote: > > > We're lucky to have the experience of Chip to draw upon (he's already > > blazed some of the trails we'll be turning into fully-paved four-lane > > highways with Waffle Houses and Conocos), as well as a lot of people > > who've worked with perl5. They know what works and what doesn't, > > and experience is going to be invaluable in something as complicated > > as a Perl interpreter. > > Unfortunately the greatest volume on the various p6 sublists tends to be > coming from the least experienced people. The comments based on common > sense and long experience tend to be lost in the hubbub of uninformed > noise. In retrospect I think the various sublists should have been > moderated and read-only, and have been populated with the handful of > people who understand most about a given area - and no, I don't include > myself in that list of people, although I would have liked to have > listened in. > > The whole p6 process is more bizarre than bazaar, and I really can't see > how on earth a useful product is going to come out of it. Interest and > enthusiasm are great attributes, but in the end are no substitute for > knowledge and experience. If p6 is to be successful it needs to be > carefully designed and meticulously implemented. To do this > successfully it will need rigorous selection of the people carrying out > the work. This will inevitably mean that some people will be left on > the sidelines, and when that happens a lot of the current enthusiasm > will I fear turn to bitterness and disillusionment. > > I feel it is grossly unfair to carry on this pretence of development by > brownian motion any longer, and that it is about time that the p6 core > developers (you know who you are!) started to be honest about this. A > lot of people will inevitably be disappointed when their enthusiastic > contributions are discarded, and I have seen absolutely no discussion of > the process by which RFCs will be accepted or rejected (and saying > 'Larry will do it' isn't good enough). I've seen endless and > stultifying discussions of code repository tools, but very little talk > of project teams and deliverables. > > The most difficult part of this process is sorting out the human issues, > not the technical issues, but that is the very area that seems to have > received least discussion. The body of code that comes out at the end > of the process is nothing like as important as the group of people who > are responsible for giving birth to it, but at the moment the focus and > priorities seem to be completely awry. > > I'm sure the immediate response to my comments is that I'm being > unnecessarily pessimistic, and indeed I hope I am. However, past bitter > experience tells me that I'm probably at least partly correct, so please > don't discard my comments out of hand. > > I'm sorry but I really can't stomach watching this slow motion train > wreck any longer, so good luck and goodbye. > > Alan Burlison >
