Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!ncar!csn!cherokee!flash!rampson From: rampson@flash (Michael T. Rampson) Newsgroups: comp.lang.perl Subject: Re: Ruminations on the future of Perl Message-ID: <1991Jun28.174023.24431@cherokee.uswest.com> Date: 28 Jun 91 17:40:23 GMT References: Sender: news@cherokee.uswest.com (Telegraph Row) Reply-To: rampson@flash (Michael T. Rampson) Organization: US West Advanced Techonologies Lines: 104 Nntp-Posting-Host: flash.uswest.com In article , worley@compass.com (Dale Worley) writes: > I've been giving some thought to the future of Perl. Of course, these > comments are a mite arrogant, but at least they may help Larry plan. > > Probably the best thing for the long-run health of Perl (although the > worst for everybody now involved with it) is to scrap it and redesign > (and reimplement) it from the ground up. Having implemented and used > Perl, we now know *what it should have been*. I don't have any major problems with Perl. What do you envision that it should have been? > > In my opinion, Perl's biggest weaknesses are (1) its syntax is > fantastically complex (consider the multiple meanings of / and $), and > (2) it is a collection of features more than a coherent language for > expressing algorithms. I think that 'fantasically complex' is too strong (IMHO), although I readily admit that it's syntax does have a few quirks that take some getting used to. It's syntax is closely related to C, csh, awk and sed (with regards to regex) so it doesn't take too long to start doing something useful with perl. Of course, as you want to do more and more complex things with perl, you have to delve deeper into perl. > > However, rebuilding Perl is quite impractical. Not only would it > involve an enormous amount of work, all existing Perl code would have > to be rewritten. Which means that you are basically talking about implementing another language (if existing code is going to have to re-written) unless your thinking about some kind of transition ala C-> ANSI-C. > > The other idea I have for the future of Perl is that it is now > undergoing the transition from a "program" to a "program product". > This means that the users are demanding that it be much more reliable, > understandable, and portable than ever before. And, as Brooks noted, > it takes about three times as much effort to produce a program product > as to produce a program. (Consider the number of bugs and > difficulties that version 4 is having, because of the number of users > exercising it.) Where is all of this effort going to come from? Can > we really expect Larry to devote the rest of his life to maintaining > Perl? The number of bugs isn't really all that suprising considering that basically larry is mostly doing all of the work and he has no real test organization to help him out other than his unit tests and his user community. I don't think we can really expect larry to devote the rest of his life to maintaining perl. I some point he is going to have enough of perl and either someone else is going to have to pick it up, or he is going to have to make arrangements with FSF to pick up M&E on perl. As a member of this user community, I think in the near future, larry is going to have to ask us for help, or we should volunteer our help to larry. > > In order for Perl to take its rightful place as a standard Unix tool, > it needs to become a product. However, I can't see how to finance the > large amount of work that is going to be necessary on a continuing > basis. > I beleive the original intent of perl was to be more functionally oriented instead of being some general elegant language. The idea being that perl could replace all of your csh, sh, awk, sed, etc scripts with one tool that could do all of these things, thus simplifing maintenance by only have to know one tool, and speediup execution by not having to spawn off other processes to do awk, sed, etc. To extend the functionality even further, include OS calls so you didn't have to write C programs on top of writing perl, losing some in speed, but gaining maintainability in that you still only needed to know one tool to get even more work accomplished, more quickly. Perl has been a godsend to my organization and group where we had an SCM (Software Configuration Management) tool set written in csh, ksh, sed, awk, etc. By rewriting in perl, we have since improved maintainability of the toolset dramatically, letting us add even more functionality. It has also sped up our build process dramatically seeing speed ups from 3 time faster on most tools, upto 30 time faster on others (especially tools that were made up of csh and awk scripts, all of the time was spent firing up awk to do parsing on strings and lines). I'd like to extend my thanx to larry (and randal) for all of the hard work they have put in to provide a tool that has saved me and my company countless hours. sincerely, Mike Rampson __ The objective of all dedicated employees should be to thoroughly analyze all situations, anticipate all problems prior to their occurrence, have answers for these problems, and move swiftly to solve these problems when called upon. However, When you are up to your ass in alligators it is difficult to remind yourself your initial objective was to drain the swamp. rampson@uswat