[10175] in Perl-Users-Digest
Perl-Users Digest, Issue: 3768 Volume: 8
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun Sep 20 21:08:53 1998
Date: Sun, 20 Sep 98 18:01:26 -0700
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Sun, 20 Sep 1998 Volume: 8 Number: 3768
Today's topics:
Re: Perl & Java - differences and uses <uri@sysarch.com>
Re: Perl & Java - differences and uses <david@algonquin.net>
Re: Perl & Java - differences and uses <bjohnsto_usa_net@my-dejanews.com>
Re: Perl & Java - differences and uses (Sam Holden)
Re: Perl & Java - differences and uses <zenin@bawdycaste.org>
Re: Perl & Java - differences and uses <zenin@bawdycaste.org>
Re: Perl & Java - differences and uses <zenin@bawdycaste.org>
Re: Perl & Java - differences and uses (David Formosa)
Problems running this script. <imran@netwave.ca>
Re: Problems running this script. (Matthew Bafford)
Re: Problems running this script. <ajohnson@gpu.srv.ualberta.ca>
Special: Digest Administrivia (Last modified: 12 Mar 98 (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 20 Sep 1998 19:13:38 -0400
From: Uri Guttman <uri@sysarch.com>
Subject: Re: Perl & Java - differences and uses
Message-Id: <x7pvcqwf6l.fsf@sysarch.com>
>>>>> "GR" == George Reese <borg@imaginary.com> writes:
GR> In comp.lang.java.programmer Patricia Shanahan <pats@acm.org> wrote:
GR> : In any case, those aspects of programming that have been reduced to
GR> : algorithms are not what programmers should be spending their time
GR> : doing. There is a natural progression:
GR> : 1. Algorithms are identified for doing aspect A of programming.
GR> : 2. The algorithms for doing A are incorporated into software tools.
GR> : 3. A stops being a everyday part of programming, and the size and
GR> : difficulty of programs that are considered writable is increased so
GR> : that programming is right at the limit of what programmers can do,
GR> : even without having to worry about A.
GR> This is false because the algorithm is described in human language,
GR> something a computer is incapable of understanding. And we have yet
GR> to find a way to describe these algorithms in a form the computer can
GR> understand. It is totally false to believe that because an algorithm
GR> exists for doing X that a computer can do X.
another reason not to hire you. if it is an algorithm and it works it
can be programmed. it may be a pig but on a turing compatible system it
can be done.
in fact algorithms are not usually descibed in english but in pseudo
code or some formal language. these can easily be converted to working
code by your drones.
but you recently stated that programmers do only the grunt work and
designing the objects and names was the job of the analysts and higher
ups. sound like they have the same issues programmers had. idiots make
idiotic decisions at any level. i said that the design was all freedom
and you responded by pushing that to a higher level. opposite of
sweeping it under the rug.
so my main point is that OO does not remove any of the need for
creativity from software engineering. it just relocates and renames
it. you can't get great code form a bank of drone programmers if their
designers don't know what they are doing. and even then you have no
guarantee of the quality of the code. i will take the small team who
decide how they want to work and with what paradigm over any large scale
team with methodology restrictions.
i am currently working on a large project with 1 other person. it is a
mutlithreaded high speed server (can't say more here). it is in
plain C with no objects. it has an event engine with a tested and simple
API and we will get it out the door faster and better than any team of
drones you could ever get, with whatever OO design you could give them.
the most famous case of hundreds of drones doing a project is OS360 as
written about in the mythical man month. OO would NOT have helped them at
all.
design methodologies does not equal good design. humans are still in
charge at all levels and make human choices which are by definition
subject to individual tastes, and that means it is art. you cannot
design around that except by not hiring drones.
uri
--
Uri Guttman ----------------- SYStems ARCHitecture and Software Engineering
Perl Hacker for Hire ---------------------- Perl, Internet, UNIX Consulting
uri@sysarch.com ------------------------------------ http://www.sysarch.com
The Best Search Engine on the Net ------------- http://www.northernlight.com
------------------------------
Date: Sun, 20 Sep 1998 18:57:30 -0000
From: "David Barnes" <david@algonquin.net>
Subject: Re: Perl & Java - differences and uses
Message-Id: <6u44ll$h0j$1@ash.prod.itd.earthlink.net>
But the difficulty in reading Perl scripts, or its lack of beauty, needs to
be considered a problem to be addressed. The time I waste figuring out
someone else's script is completely unproductive time. I would rather have a
programmer using his or her concentration figuring out how to solve a
problem, rather than figuring out a Perl script.
Larry Wall wrote in message <6tuctq$d8l@kiev.wall.org>...
>
> "It is amazing how complete is the delusion that beauty is goodness."
> -- Leo Tolstoy
>
>Larry
------------------------------
Date: 20 Sep 1998 23:46:49 GMT
From: "bjohnsto_usa_net" <bjohnsto_usa_net@my-dejanews.com>
Subject: Re: Perl & Java - differences and uses
Message-Id: <01bde4f0$f5e743e0$LocalHost@lhodgkiss>
Zenin <zenin@bawdycaste.org> wrote in article
<906114693.419028@thrush.omix.com>...
<snip connection pooling>
> Aka, an application server.
Aka 1/100 of the application servers I have seen.
[snip]
> : They add a massive memory and speed overhead,
>
> Funny, mine (in Perl) run in under 10 Megs and handle 5k
> clients with typical requests.
There is a difference between a three tiered
architecture and an off the shelf application server.
One is an architecture decision which can work around problems with the
default database connection model and the power of HTML clients.
The other is a bloated piece of expensive junkware.
What you describe seems more like the former.
[snip problems with application server]
> This sounds like you're simply running shit software. This isn't a
> problem with application servers as a design, just your judgement
> for picking this software.
Since the alternatives were not much better, I was quite lucky that I never
had to use my judgement, and someone else saddled the organization with
junkware. I just came along later and try not to complain because that
just would make me look bad in the eyes of those who made the decision.
I agree that better choices of application server may be possible.
However after reading the photo.net description of the Netscape application
server I realize that worse choices are also possible.
I have looked at the alternatives. They all seem massively inferior to the
web servers (Apache + Mod Perl, AOL server, IIS + ASP, Anything + servlets)
, or what I could write myself.
> Huh? Are you not contradicting yourself here?
Yes I was. Here is what I meant to say.
Systems based on application servers I have used perform significantly
worse than a well designed product based on cheap, well understood,
industry standard products.
This is all overhead in the junkware, a null page is slow, a simple, one
way, database call is slower than the same call in an interactive tool.
> >snip<
>
> It's an issue of what you want the system to do and how well. Sure,
> if everything you're looking for is just a click away you're best
> bet is NT. If you're like most of the rest of the planet however,
> you'll likely have custom needs that require going beyond the pretty
> buttons, at which point NT becomes much, much harder to work with
> not to mention that many times what you really want is simply not
> possible.
I agree. I expect to make the leap to Unix sometime. I feel
that I will be moving away from the market which seems to be heading
towards NT.
There is no business requirement that NT has ever stopped me from
meeting (Except maybe reliability but that one seems to have been solved
for my purposes).
> $ perl foo.pl
> Found 1, Timeleft 0
> $ perl foo.pl < /dev/null
> Found 3, Timeleft 0
Perl does seem to work better with Unix.
[snip perl scales from one liners to large apps, from glue to apps]
I learned perl because of testimonials from those using if for CGI.
I use it works better with text than anything else, has a good set of
libraries and fits in well with a command line (-e flag, args, stdin etc).
> While Python wants to live completely on its own (for better or
> worse) both syntax and functionality wise (its closest relative
> is ABC), Perl maintains links to both the scripting/h world and
> the application world with both syntax and functionality.
> Java
> followed a similar route, but since it never wanted to be used
> for ad-hoc scripting it only need to maintain links to the main
> application languages of the would, most all based in C syntax,
> for good or bad.
I already knew C, and C++ when I learned Java.
Almost everything about Java seemed comletely natural, like someone had
taken C++ and made modules and classes work the way they obviously should.
The only thing I found strange was the linkage between source file names
and paths and class and module names. This is because I had never written
code in a file with a name longer than 8.3.
Java was simple beacuse it removed features.
I have not looked at python. I heard from friends using it a few years
back that it was free, more productive than C++ and used indenting to group
statements instead of {}.
It sounds pretty good.
Perl on the other hand was pretty foreign to me.
It allows literal strings to span lines, has defaults for everything, has
suffix control structures, functions accept arguements without naming them
and a million many strange things.
I still have not had to use any comlicated dereferencing but I it seems
unclear.
Perl seems to have features for everything.
> I guess a better question is where the user is comming from, and
> what ties they want to keep. If they have been using C and C like
> languages, they likely have also been using shells or tcl for the
> lighter glue work. Jumping into Perl for such a user would
> arguably be nearly transparent (glue sed with C and you've got the
> bulk of Perl), as was the case for me and many people I've led to
> Perl (yes, even the "line noise" made perfect sense to use at first
> site without needing to look nearly anything up). Such a user
> would also likely still keep C and the shells in there tool box
> for a number of reasons. Because of this, keeping the same family
> of syntaxes helps a lot when jumping between languages a lot and
> trying to maintain code in all of them at once.
Not me. I found perl to be a relevation.
I had very little sed, a very small touch of shell, but plenty of C.
> Now, if the user wasn't already familiar and comfortable with C
> style languages or the shells, Python would arguably be easier
> to pick up from scratch then Perl. If the user wasn't going to
> need to use C style languages (C, Java et al) or the shells and
> Unix tools (sed, awk, etc) then there would be little reason to
> shy away from Python for language jumping argument.
I tend to find that I am jumping syntaxes all the time.
C/C++, VBA, Java, PL/SQL, HTML/JavaScript, Perl and others.
Perl is the only one which uses object->{"variable_name"}.
The others all seem to like object.variable_name.
I seem to get used to it.
> I personally think these are much better issues to look at then
> the simply inflammatory "such as such language isn't maintainable"
> crap. Of course Perl and C are maintainable "in the large", or I
> and many others wouldn't have a job. I'll tell ya, I've had far
> more problems with archaic systems like raw RCS when working with
> many programmers on the same project then I've ever had with any
> language (I try to push everyone to CVS now BTW), and don't even
> get me started about makefiles.
Some environments (commercial Application Servers in particular, early
versions of SQL windows and many others) have devious ways to kill reuse
and make large systems fail.
Perl is fortunately not one of them.
> So what if only experienced <insert language> programmers can
> maintain <insert language> code with ease. Anyone that picked
> Joe Programmer with zero <insert language> experience to work
> on a project writen in <insert language> that was large enough
> to be an example of "programming in the large", should be fired
> plain and simple. How anyone can think that a language should
> allow any random monkey to sit down and write applications in it
> without looking at the manual is beyond me.
Strong compile time type checking does help catch some classes of bugs.
If a programer was to lazy to type -w in a large well tested project and if
some later programmer does, usually some latent bug is found.
When projects are converted to ANSI C, and prototypes for functions are
added many bugs get found.
Most large C++ programs have memory leaks.
There is no substitute for good design, good documentation, excellent
execution and good testing. Good systems can be written in assembler. But
a language/environment can help correctness, maintainability, and
development time.
> -Zenin (zenin@archive.rhps.org) From The Blue Camel we learn:
Brendan Johnston
------------------------------
Date: 21 Sep 1998 00:38:41 GMT
From: sholden@pgrad.cs.usyd.edu.au (Sam Holden)
Subject: Re: Perl & Java - differences and uses
Message-Id: <slrn70b80g.3u7.sholden@pgrad.cs.usyd.edu.au>
On Sun, 20 Sep 1998 17:29:46 GMT, George Reese <borg@imaginary.com> wrote:
>In comp.lang.java.programmer Patricia Shanahan <pats@acm.org> wrote:
>: In any case, those aspects of programming that have been reduced to
>: algorithms are not what programmers should be spending their time
>: doing. There is a natural progression:
>
>: 1. Algorithms are identified for doing aspect A of programming.
>
>: 2. The algorithms for doing A are incorporated into software tools.
>
>: 3. A stops being a everyday part of programming, and the size and
>: difficulty of programs that are considered writable is increased so
>: that programming is right at the limit of what programmers can do,
>: even without having to worry about A.
>
>This is false because the algorithm is described in human language,
>something a computer is incapable of understanding. And we have yet
>to find a way to describe these algorithms in a form the computer can
>understand. It is totally false to believe that because an algorithm
>exists for doing X that a computer can do X.
Which part of term algorithm do you not understand???
Here's a few comments defining or describing what an algorithm is. I choose
Knuth since I think you will have to agree he is one of the founding fathers
of computer science and of algorithms in particular...
'To me the word algorithm denotes an abstract method for computing some output
from some input, while a program is the embodiment of a computational method
in some language... Of course is I am pinned down and asked to explain more
precisely what I mean by these remarks, I am forced to admit that I don't know
any way to define any particular algorithm except in a programming language.'
-- Donald E. Knuth (Communications of the ACM, vol. 9, num, 9, Sept 1966
'Algorithms are abstract computational procedures for transforming information'
-- Donald E. Knuth
'An algorithm is a set of rules for getting a specific output from a specific
input. Each step must be so precisely defined that it can be translated into a
computer language and executed by a machine.'
-- Donald E. Knuth
'The distinguishing feature of an algorithm is that all vagueness must be
eliminated; the rules must describe operations that are so simple and so well
defined that they can be executed by a machine.'
-- Donald E. Knuth
So if you 'have yet to find a way to describe these algorithms in a form the
computer can understand' then it is not an algorithm, it is a vague description.
For example... 'sort this' is a vague description.
'Sort this by using comparison operations' is a vague description.
'Sort this using merge sort' is a vague description, unless a 'set of rules'
in which 'each step must be so precisely defined that it can be translated
into a computer language and executed by a machine' exists and is labelled
'merge sort' - in which case the statement is an algorithm
--
Sam
Of course, in Perl culture, almost nothing is prohibited. My feeling is
that the rest of the world already has plenty of perfectly good
prohibitions, so why invent more? --Larry Wall
------------------------------
Date: 20 Sep 1998 23:28:13 GMT
From: Zenin <zenin@bawdycaste.org>
Subject: Re: Perl & Java - differences and uses
Message-Id: <906333974.234073@thrush.omix.com>
George Reese <borg@imaginary.com> wrote:
>snip<
: Design and naming things should be the result of a repeatable and
: structured process. That is what OO methodologies are.
Naming identifiers has *nothing* to do with OO in particular.
Even inside strict OO methodologies, there are many sub-designs
that can be implemented.
: Formatting is a function of standard programming practices, or, better
: yet, a well structured language like python.
IYO...
: Algorithms should be the result of proven design patterns.
: Otherwise, you are just talking voodoo.
And those proven algorithms you praise so highly come from where,
a bible? Handed down from the gods like so much babble?
What if there does not currently exist an algorithm to solve the
problem you are working on? Oh my, you might just have to think for
yourself...
: You have a real problem with identity of things. No freedom is not
: the same thing as being automatically generatable.
But it's damn close.
: You don't even know what freedom is.
>snip<
: You need to go back and learn what a structured process is.
And how did "structured process" get formed? Because someone
had the freedom to think for themself.
--
-Zenin (zenin@archive.rhps.org) From The Blue Camel we learn:
BSD: A psychoactive drug, popular in the 80s, probably developed at UC
Berkeley or thereabouts. Similar in many ways to the prescription-only
medication called "System V", but infinitely more useful. (Or, at least,
more fun.) The full chemical name is "Berkeley Standard Distribution".
------------------------------
Date: 21 Sep 1998 00:13:42 GMT
From: Zenin <zenin@bawdycaste.org>
Subject: Re: Perl & Java - differences and uses
Message-Id: <906336702.177777@thrush.omix.com>
George Reese <borg@imaginary.com> wrote:
>snip<
: Unfortunately, you have not in any way demonstrated that my belief in
: OO lacks coherent reasoning.
If OO is infact the end-all, be-all computer science methodology
of choice, pray tell why is your beloved Python written in C?
--
-Zenin (zenin@archive.rhps.org) From The Blue Camel we learn:
BSD: A psychoactive drug, popular in the 80s, probably developed at UC
Berkeley or thereabouts. Similar in many ways to the prescription-only
medication called "System V", but infinitely more useful. (Or, at least,
more fun.) The full chemical name is "Berkeley Standard Distribution".
------------------------------
Date: 21 Sep 1998 00:02:02 GMT
From: Zenin <zenin@bawdycaste.org>
Subject: Re: Perl & Java - differences and uses
Message-Id: <906336002.347798@thrush.omix.com>
George Reese <borg@imaginary.com> wrote:
>snip<
: Who do you think will solve the puzzle first?
And just which of your gods was it that passed down this particular
algorithm to the people?
: My money is on the "drone" armed with the algorithm.
My associate, Guito, would like to see you in his office. :-)
: Names are hugely important and are very much a result of the OO A&D
: process.
And now your OO gods created the names as well as the algorithms...
: Specifically, the names are determined at design time before
: any programmer gets involved
So, only pointy haired managers are enlightened enough to pass down
the words of your gods.
: based upon what those terms mean in the
: business for which those names have real world referents.
huh...?
: You are again confusing functionality with freedom. And you are also
: making assumptions about me personally which you are not qualified to
: make.
However, your own words are giving them quite a lot of information
to work from.
: Try supporting your arguments on their merits and not based on
: personal attacks on me.
Agreed. Of course, you might also try supporting your arguments on
their merits instead of hoping OO dogma will save you. Hint: it
won't.
: Multiple search algorithms are about multiple kinds of functionality,
: not multiple means of expression.
More importantly however, they are pure examples of freedom in
programming.
>snip<
: I do not talk as if methodology is THE answer.
Funny, you could have fooled most of us...
>snip<
: However, it does largley take away for the need of any creativity at
: the programmer level.
You live a small, sheltered, and drab life...
: Most creativity is required at the architecture, A&D, and UI design
: levels.
Of course. However, much of this ends up at the prorammer level
no matter how hard you try not to, just as it should be.
A good design is key, but it is not the whole. There is a point
at which you start to over-design and micro manage the project.
You can not design every line of code before handing it over to
the programer or you quickly result in diminishing returns. And
never forget that no matter how god-like of a designer one might
be, one can never think of every single problem that might come
up. You can not have the programmers running back to the designers
every time they find they need a new variable and what should it
be named...?
: : i am free to laugh at your religious stance behind the OO shield.
:
: It is a good rhetorical device to take a belief which I will affirm
: (that OO is important) and then dismiss that belief as religious.
The belief is not religious, only your blind faith it it is.
: After all, a religious belief is one without reason behind it.
Religion has quite a bit of reason behind it. Much of it is not
logical however, which is what brings your comments to mind.
: The world has not arrived at OO software engineering yet, so I fail to
: see how you can dismiss it as failed.
The world has not arrived at Esperanto or NewSpeek either.
Of course OO has not failed. Nore however, has it given any reason
to most people that it should replace everything else before it.
--
-Zenin (zenin@archive.rhps.org) From The Blue Camel we learn:
BSD: A psychoactive drug, popular in the 80s, probably developed at UC
Berkeley or thereabouts. Similar in many ways to the prescription-only
medication called "System V", but infinitely more useful. (Or, at least,
more fun.) The full chemical name is "Berkeley Standard Distribution".
------------------------------
Date: 21 Sep 1998 10:38:34 +1000
From: dformosa@zeta.org.au (David Formosa)
Subject: Re: Perl & Java - differences and uses
Message-Id: <6u476a$pl3$1@godzilla.zeta.org.au>
In <36052F08.3D3283BE@acm.org> Patricia Shanahan <pats@acm.org> writes:
>Come the next paradigm shift I plan to do exactly what I did in the
>1970's for structured programming, and in the 1990's for OO - wait for
>languages tuned to the new paradigm to become reasonably mainstream
>and then learn a few of them along with their underlying concepts.
That is cause an option, however I consider it more usefull to allow
the better paradine to be used as much as possable within the old frame-
work.
If I was programing in say Basic (cough splatter) I would still make use
of structured thechneeks even though the dialect I'm useing dosn't support
it. I'm not going to write spaggetty code just because the languge I'm
useing dosn't provide a few utility keywords to make my life easyer.
Indeed if perl didn't have its OO frame work it would be still possable
to write OO code in it.
>Generally, new programming paradigms quietly incorporate anything that
>worked from the old one anyway.
Partly, however often a paradine has a "Pure" langage that uses that one
system totaly without depeanding on what came before, for OO it is smalltalk
for functional programming it is pure-lisp, I don't beleave that there was
ever a pure meta-programing langage but I don't think it would make sence.
>I would expect the next big thing to include O-O but go beyond it in
>some as yet unknown way.
Of cause, when I was learning Modula-2 (A structured language with support
for ADT) I recall saying to a frend how close this was to OO. I would
expect that the next thing will simmerly be like this.
------------------------------
Date: Sun, 20 Sep 1998 18:13:24 -0400
From: Imran Zalfackruddin <imran@netwave.ca>
Subject: Problems running this script.
Message-Id: <36057E03.1AE8CB2@netwave.ca>
I have lookd at this script for a LONG time and I cant get the syntax
error that perl is reporting. I am running perl 5.004.
When I try to run the script I get "Syntax error at line 38, near "(" "
and "Syntax error at line 40, near "}". Please HELPPPPP.
This is the part that produces the error.
------------------------------------------------------------
#!/usr/local/bin/perl -w
$ENV{"PATH"} = "bin:/usr/bin:/usr/ucb:/export/scripts";
umask(022);
$| = 1;
($0 == 0) || die "Must be running as root";
$datadir = "/scripts/data/";
$homedir = "/home/";
$datafile = $datadir."passwd.O";
$database = $datadir."passwd.dbm";
# use dbm module
use Fcntl;
use DB_File;
#use POSIX;
#use SDBM_File;
#tie(%pass, SDBM_File, $database, O_RDWR|O_CREAT, 0666);
#my %New;
chdir "$datadir";
#----------------------------------------------------------------------#
# Need to create two Dbm files for lookup - Load the passwd with the old
# password from this system and use it to compare from master to see if
# new users need their web stuff setup on current machine
#----------------------------------------------------------------------#
tie %pass, DB_File, $datadir.$database, O_RDWR|O_CREAT, 0700,$DB_HASH;
#dbmopen (%pass,$database,700) || die "cant open dbm file";
open(PASSWD,"$datafile") || die "Cant open passwd file";
While (<PASSWD>)
{
chop;
($login,$passwd,$uid,$gid,$comment,$dir,$shell) = split(/:/,$_,7);
$pass{$login} = "${passwd}:${uid}:${gid}:${comment}:${dir}:${shell}";
}
#
# Close dbm file and input file
#
untie %pass;
close (PASSWD);
------------------------------
Date: Sun, 20 Sep 1998 18:29:57 -0400
From: dragons@scescape.net (Matthew Bafford)
Subject: Re: Problems running this script.
Message-Id: <MPG.106f4bf0c4f63e399896b0@news.south-carolina.net>
In article <36057E03.1AE8CB2@netwave.ca> on Sun, 20 Sep 1998
18:13:24 -0400, Imran Zalfackruddin (imran@netwave.ca) pounded in
the following text:
=> I have lookd at this script for a LONG time and I cant get the syntax
=> error that perl is reporting. I am running perl 5.004.
=> When I try to run the script I get "Syntax error at line 38, near "(" "
=> and "Syntax error at line 40, near "}". Please HELPPPPP.
=> This is the part that produces the error.
=>
=> [SNIP]
=>
=> While (<PASSWD>)
^
s/While/while/;
:)
=> {
=> chop;
=> ($login,$passwd,$uid,$gid,$comment,$dir,$shell) = split(/:/,$_,7);
=> $pass{$login} = "${passwd}:${uid}:${gid}:${comment}:${dir}:${shell}";
=>
=> }
=> [SNIP]
At least that's the obvious error.
--Mattgew
------------------------------
Date: Sun, 20 Sep 1998 17:35:26 -0500
From: Andrew Johnson <ajohnson@gpu.srv.ualberta.ca>
Subject: Re: Problems running this script.
Message-Id: <3605832E.49757A67@gpu.srv.ualberta.ca>
Imran Zalfackruddin wrote:
>
> I have lookd at this script for a LONG time and I cant get the syntax
> error that perl is reporting. I am running perl 5.004.
[snip]
> While (<PASSWD>)
'while' ne 'While'
regards
andrew
------------------------------
Date: 12 Jul 98 21:33:47 GMT (Last modified)
From: Perl-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Special: Digest Administrivia (Last modified: 12 Mar 98)
Message-Id: <null>
Administrivia:
Special notice: in a few days, the new group comp.lang.perl.moderated
should be formed. I would rather not support two different groups, and I
know of no other plans to create a digested moderated group. This leaves
me with two options: 1) keep on with this group 2) change to the
moderated one.
If you have opinions on this, send them to
perl-users-request@ruby.oce.orst.edu.
The Perl-Users Digest is a retransmission of the USENET newsgroup
comp.lang.perl.misc. For subscription or unsubscription requests, send
the single line:
subscribe perl-users
or:
unsubscribe perl-users
to almanac@ruby.oce.orst.edu.
To submit articles to comp.lang.perl.misc (and this Digest), send your
article to perl-users@ruby.oce.orst.edu.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
To request back copies (available for a week or so), send your request
to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
where x is the volume number and y is the issue number.
The Meta-FAQ, an article containing information about the FAQ, is
available by requesting "send perl-users meta-faq". The real FAQ, as it
appeared last in the newsgroup, can be retrieved with the request "send
perl-users FAQ". Due to their sizes, neither the Meta-FAQ nor the FAQ
are included in the digest.
The "mini-FAQ", which is an updated version of the Meta-FAQ, is
available by requesting "send perl-users mini-faq". It appears twice
weekly in the group, but is not distributed in the digest.
For other requests pertaining to the digest, send mail to
perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
sending perl questions to the -request address, I don't have time to
answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V8 Issue 3768
**************************************
