[12244] in Perl-Users-Digest
Perl-Users Digest, Issue: 5844 Volume: 8
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon May 31 22:07:22 1999
Date: Mon, 31 May 99 19:00:15 -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 Mon, 31 May 1999 Volume: 8 Number: 5844
Today's topics:
Re: Is split (surprisingly, amazingly) slow? <jonathan@meanwhile.freeserve.co.uk>
Re: Is split (surprisingly, amazingly) slow? <jonathan@meanwhile.freeserve.co.uk>
Re: Is split (surprisingly, amazingly) slow? <jonathan@meanwhile.freeserve.co.uk>
Re: Is split (surprisingly, amazingly) slow? (Mark-Jason Dominus)
Re: Is split (surprisingly, amazingly) slow? (Mark-Jason Dominus)
Re: Is split (surprisingly, amazingly) slow? (Ronald J Kimball)
Re: passing Perl <---> C arguments (web-form data pairs <rootbeer@redcat.com>
Re: Perl, Y2K, and idiots <kristina@greatbasin.net>
Re: Perl, Y2K, and idiots <tchrist@mox.perl.com>
Re: Perl, Y2K, and idiots <kristina@greatbasin.net>
Re: Predefined variable for array number? (Larry Rosler)
Problem with opening SOCKET to hypermart (Ryan Ngi)
Re: Quick way to count lines in file? <seeu@theasylum.com>
Re: Quick way to count lines in file? (Larry Rosler)
Re: Quick way to count lines in file? (Larry Rosler)
Sybperl <zarmo@altavista.net>
the unshift function <khowe@performance-net.com>
Re: Y2K infected Perl code <uri@sysarch.com>
Re: Y2K infected Perl code <kristina@greatbasin.net>
Special: Digest Administrivia (Last modified: 12 Dec 98 (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 1 Jun 1999 01:30:37 +0100
From: "Jonathan" <jonathan@meanwhile.freeserve.co.uk>
Subject: Re: Is split (surprisingly, amazingly) slow?
Message-Id: <7iv9jb$ktq$1@news6.svr.pol.co.uk>
Possibly the author of the original post didn't post here because he's
allergic to smugness and ego masking as competence?
Why on earth would I have typed when I could cut and paste? I don't say the
code's correct, but it's certainly the code that I downloaded.
Jonathan (assumed that Tad believes he can read minds from emails.)
------------------------------
Date: Tue, 1 Jun 1999 01:41:55 +0100
From: "Jonathan" <jonathan@meanwhile.freeserve.co.uk>
Subject: Re: Is split (surprisingly, amazingly) slow?
Message-Id: <7iva8i$lbo$1@news6.svr.pol.co.uk>
>Thirty times!
>
>If you're going to make (or cite) such amazing claims, it would probably
>be a good idea to back them up with the actual (correct) code and real
>benchmarks, so that we can all see what you're talking about. Maybe, for
>example, perl was an old version or improperly configured (or both). Maybe
>the Python code didn't get the right answer (either). And maybe there
>really is something making Perl slow - something we should probably fix,
>if it can be done.
Tom -
1/ I can't supply the data etc for the benchmark because (as the post makes
very clear) I did not write the program.
So that leaves me with the choice of doing nothing to find out more about
the matter (the ostrich approach) or
doing what I can. No one from the Perl community posted on this, I'm hoping
that someone on perl.misc will come up
with an intelligent solution to the problem, or indeed explain that there
isn't one because the guy made a mistake.
If you'd favour the ostrich approach that's your business, please don't
expect me to feel obliged do so. You might consider
the fact that readers of one of the most influential comp.lang groups where
exposed to this possibly faulty original post
without any chance of correction, until I raised this here.From my brief
exposure I'm heavily pro-Perl. That's why I'm
bothering to chase it up when I'm already over-worked. Now if there's
something wrong it can get fixed and people can
have the correct information. That's what I thought news was for. What you
think it's for, I really don't know. You don't have
to tell me.
2/ I copied the guy's code verbatim from the copy of his post on my machine.
I didn't guarantee it's correctness.
Instead I pointed out my minimal Perl experience and lack of time to play
with the code myself. My role in this matter
was that of a information middle-man, passing this on to someone with the
skills, inclination, and time to do something
more with it. I imagined that an intelligent Perl program might find it a
fun problem to solve in a couple of minutes, and that
some time he could return the favour by passing on some interesting assembly
or graphics or ai stuff to where I live. For all I know
he could have mis-coded, mis-copied, or somthing could have happened at my
ISP, or aliens could have nibbled at it.
3/ I assumed that any reader who wanted more details would have the
intelligence, wit, savvy etc to dejanews the original posts.
That's why I quoted the exact subject line. Seems I was wrong. I apologize
for over-estimating your resourcefulness.
4/ You find a factor of 30 speed up hard to believe. I actually optimize
code for a living, I've achieved factors of 30 and more
over production C code. Beating a scripting language by 30 is hardly
remarkable, that's why Perl has astonished me with its
speed in the past.
Now please never email me again unless, perhaps, you want to know want to
know what dejanews is.
Jonathan
------------------------------
Date: Tue, 1 Jun 1999 01:46:14 +0100
From: "Jonathan" <jonathan@meanwhile.freeserve.co.uk>
Subject: Re: Is split (surprisingly, amazingly) slow?
Message-Id: <7ivagn$lgv$1@news6.svr.pol.co.uk>
As I pointed out, Ben, it wasn't my code, I was just passing it on to where
I thought someone with some Perl smarts could deal with it. I'm glad you
proved me right. From my very brief exposure to Perl I thought it was fairly
terrific.
Jonathan
------------------------------
Date: Tue, 01 Jun 1999 00:51:36 GMT
From: mjd@op.net (Mark-Jason Dominus)
Subject: Re: Is split (surprisingly, amazingly) slow?
Message-Id: <7ivapn$ojh$1@monet.op.net>
In article <80F43.1918$T7.147356@typhoon-sf.snfc21.pbi.net>,
Benjamin Franz <snowhare@long-lake.nihongo.org> wrote:
>In article <7iuu05$fq7$1@news8.svr.pol.co.uk>,
>Jonathan <jonathan@meanwhile.freeserve.co.uk> wrote:
>>In other words, to count the total number of field separated data items in a
>>file.
>
>That isn't what you wrote in code above. It just counts the number of lines
>(slowly).
Jonathan was mistaken. The purpose of the code was to do the splits
and to count the lines. The original author (William Lear) was really
interested in benchmarking the `split' function, not in counting the
number of fields.
>Anyhow, the performance can be easily kicked into high gear by
>giving Perl bigger chunks to chew on and using a more efficient
>field counter than split:
Unfortunately, this misses the point, since the speedy `tr'
construction is not actually useful if what you really want is to
split the input into fields.
It would be nice if there were a faster idiom for splitting up a line
when the field separators are known to be static strings, as they are
here, but if there is, I don't know it.
------------------------------
Date: 1 Jun 1999 00:44:24 -0000
From: mjd@plover.com (Mark-Jason Dominus)
Subject: Re: Is split (surprisingly, amazingly) slow?
Message-Id: <19990601004424.6986.qmail@plover.com>
[Posted and cc'ed to William S. Lear]
In article <Pine.GSO.4.02A.9905311515050.19186-100000@user2.teleport.com>,
Tom Phoenix <rootbeer@redcat.com> wrote:
>If you're going to make (or cite) such amazing claims, it would probably
>be a good idea to back them up with the actual (correct) code and real
>benchmarks, so that we can all see what you're talking about.
The cited post is only three weeks old. It is probably still in your
spool. I think Jonathan can be excused for not reproducing it, since
it was so recent. (<wywvyhvu2u.fsf@wiggum.dejanews.com>, should you
care. The subject is `An efficient split function')
>maybe there really is something making Perl slow - something we
>should probably fix, if it can be done.
It seemed pretty clear to me at the time that Lear was comparing
apples and oranges. Perl's `split' is very powerful. It can be used
as a complete tokenizer, the equivalent of an entire C program written
by `lex'. The C++ code that Mr. Lear presented worked only when the
field separator was a single, prespecified character. It would not
even split on '::'. The Java example seems to be somewhere in the
middle, since it will split on an arbitrary fixed string rather than
on a single character.
Lear's fastest C++ version also failed if the input data contained
lines longer than 1023 characters or 30 fields. Perl doesn't have
this limitation. I would be interested to see Lear's benchmarks after
he put in support for arbitrarily large data.
If there's any interesting idea for Perl here, I think it's that
`split' might be optimized to know when its argument is a static
pattern, and to use simler code and avoid regexes in that case. But
even then the speedup might not be much because regex matching is
already optimized for that case.
Summary:
1. Perl is not designed to be speedy. It is designed to be
convenient. Comparing convenient Perl against inconvenient C is
not very enlightening. Convenience is expensive.
2. If you want C, you know where to find it.
3. There's probably a nice ecological niche for someone to write an
XS module that provides a super-duper optimized version of split
that only splits on static strings. Then you'd say
use SSplit;
while (<>) {
@fields = ssplit '|';
# ...
}
and performance would probably be at least as good as in Java.
------------------------------
Date: Mon, 31 May 1999 21:16:13 -0400
From: rjk@linguist.dartmouth.edu (Ronald J Kimball)
Subject: Re: Is split (surprisingly, amazingly) slow?
Message-Id: <1dsotho.1eiuphz138vyyoN@p199.block1.tc6.state.ma.tiac.com>
Jonathan <jonathan@meanwhile.freeserve.co.uk> wrote:
> A couple of weeks ago there was a posting on c++ moderated and
> comp.lang.python called "An efficient split function".
> Among other things it contained Perl and Python code to - well, to do this:
>
>
> my $count = 0;
> my @v;
> while (<STDIN>) {
> @v = split(/\|/);
> $count++;
> }
> print "$count\n";
>
>
> In other words, to count the total number of field separated data items in a
> file.
>
> The author of the post was surprised because the Python version ran **4**
> times as fast as the Perl code above on large files. And with fairly
> minimal effort he was able to write C++ and STL code that ran more than 30
> times faster than the Perl above. (And generally STL code can be replaced
> with C several times faster on current compilers.)
> Any
> suggestions as to what's going on here, or faster alternatives to the code
> above?
The above code does not count fields. It counts lines - $count is
incremented once for each line of input. Perhaps this was meant:
$count += @v;
Anyway... split() is used when you want to get at the parts of the
string between the separators. That's a lot of work creating a list and
storing it in an array, just to throw it all away the next time through
the loop. If you just want to count the separators, why bother using
split() at all?
my $count = 0;
while (<STDIN>) {
$count += tr/|// + 1;
}
print "$count\n";
This will give approximately the same results, barring any trailing
separators. Since this issue was not covered in the spec, I deem the
above code correct.
Of course, without seeing the code from the other languages, it's pretty
hard to comment on specifically why it was faster than the Perl code.
--
_ / ' _ / - aka -
( /)//)//)(//)/( Ronald J Kimball rjk@linguist.dartmouth.edu
/ http://www.tiac.net/users/chipmunk/
"It's funny 'cause it's true ... and vice versa."
------------------------------
Date: Mon, 31 May 1999 17:02:06 -0700
From: Tom Phoenix <rootbeer@redcat.com>
Subject: Re: passing Perl <---> C arguments (web-form data pairs)
Message-Id: <Pine.GSO.4.02A.9905311658320.19186-100000@user2.teleport.com>
On Tue, 1 Jun 1999, jj wrote:
> Now I want call this program from within a Perl program BUT I do NOT
> know how to pass these three pairs variable/value to the compiled C
> program just like a web page do.
Web pages don't pass arguments to C programs, but web _servers_ do. You
need to play the role of the server to this C program. That is, your Perl
program, calling the C program, will pretend to be a server and pass
arguments in the way a server would.
> I guess the arguments aren't passed as usual, are they? how?
See the CGI protocol specification:
http://hoohoo.ncsa.uiuc.edu/cgi/
If you have more questions about the CGI protocol after having read it,
you should probably ask them in a newsgroup about the CGI protocol.
Cheers!
--
Tom Phoenix Perl Training and Hacking Esperanto
Randal Schwartz Case: http://www.rahul.net/jeffrey/ovs/
------------------------------
Date: Mon, 31 May 1999 17:20:50 -0700
From: Kristina <kristina@greatbasin.net>
Subject: Re: Perl, Y2K, and idiots
Message-Id: <Pine.BSI.4.05L.9905311658100.25771-100000@web0.greatbasin.net>
Eric Bohlman wrote:
> No. There's a great deal of resentment here against people who don't
> even bother to look in the comprehensive set of documentation that comes
> with every copy of perl before coming to this newsgroup and asking
> questions that are covered in that documentation. On any given day,
> there are posts here from people who are new to Perl, who *have* looked
> in the documentation, and who ask for clarification.
Okay, I don't much like it when people want me to do their homework
either. And it's true, I have seen one or two posts that did clarify
something without calling the poster an idiot. But really, other than
Malcolm Ray and Alan Flavell, everyone was quite willing to badmouth
the writers of the buggy Perl code in question without even dropping
a note to the offender with even a few-word message that their code
sucked and they should read thus and so.
To be quite honest, I've been afraid to ask for clarification on things
*after* doing a lot of reading of FAQ's and manpages and so forth because
I was afraid that I'd get a response like, "Go become a real programmer
and then come back and try to learn Perl, or better yet, go study Abstract
Art, since you obviously don't deserve to learn to program if you can't
even read a *manual*." The people that use my scripts are worse off than I
am, and their bug reports are pretty much limited to "It doesn't work when
I do thus and so." Not very helpful with improving my programming style.
:)
As a relative Perl newbie (who will probably be a newbie all my life!), I
just feel like I'm not even allowed to write Perl scripts until I'm a
Randall Schwartz or a Tom Christiansen. I mean, isn't there a happy
medium somewhere? Since Perl isn't taught in any school anywhere near
where I live, how else am I going to learn it but by writing it, making
mistakes, looking at the docs, fixing the mistakes, making more mistakes,
and going back to the docs?
Okay, blah blah blah. Yes, I'm trying to justify my existence. Does
it show? :)
By the way, I recall at some point seeing a nice FAQ/tutorial on several
common things to check in a Perl program. For instance, check system calls
and file opens, make sure that any user input is what you expected, etc.
I thought it was in the main FAQ, but I don't seem to see it there.
Anyone have a URL for good Perl programming style over and above where one
should put the whitespace and the curly brackets?
Kristina
------------------------------
Date: 31 May 1999 19:27:46 -0700
From: Tom Christiansen <tchrist@mox.perl.com>
Subject: Re: Perl, Y2K, and idiots
Message-Id: <37533712@cs.colorado.edu>
[courtesy cc of this posting mailed to cited author]
In comp.lang.perl.misc,
Kristina <kristina@greatbasin.net> writes:
:Anyone have a URL for good Perl programming style over and above where one
:should put the whitespace and the curly brackets?
http://language.perl.com/style/
--tom
--
"A pithy saying is worth its weight in gold." --Larry Wall
------------------------------
Date: Mon, 31 May 1999 18:50:58 -0700
From: Kristina <kristina@greatbasin.net>
Subject: Re: Perl, Y2K, and idiots
Message-Id: <Pine.BSI.4.05L.9905311842380.10645-100000@web0.greatbasin.net>
On 31 May 1999, Tom Christiansen wrote:
> In comp.lang.perl.misc,
> Kristina <kristina@greatbasin.net> writes:
> :Anyone have a URL for good Perl programming style over and above where one
> :should put the whitespace and the curly brackets?
>
> http://language.perl.com/style/
Thanks, it's a great reference! I wonder, however, if someone would
be kind enough to explain the following for me and the benefit of those
who might, like me, also be newbies or "accidental programmers":
* Check $@ after eval"" or s///ee.
* Parameter asserts
I understand "check $@ after eval" but what is s///ee? The perlre manpage
lists i, m, s, x, e, and g (and combinations of same), but I do not see
ee. Is that a double-check of /e, or am I missing something?
Also, could you (or someone else) elaborate just a tiny bit on what is
implied by "Parameter asserts?" A pointer to another man page or FAQ would
be great.
Thanks again!
Kristina
------------------------------
Date: Mon, 31 May 1999 18:20:29 -0700
From: lr@hpl.hp.com (Larry Rosler)
Subject: Re: Predefined variable for array number?
Message-Id: <MPG.11bcd5258004fd0f989b3e@nntp.hpl.hp.com>
In article <5FE43.1947$%65.4999@tor-nn1.netcom.ca> on Mon, 31 May 1999
20:13:45 -0300, .. <none@none.ca> says...
> Is there an array equivalent of the $. variable for files. i.e. A variable
> which tells you what array number you are currently at.
No.
--
(Just Another Larry) Rosler
Hewlett-Packard Company
http://www.hpl.hp.com/personal/Larry_Rosler/
lr@hpl.hp.com
------------------------------
Date: Tue, 01 Jun 1999 01:04:19 GMT
From: ryanngi@hotmail.com (Ryan Ngi)
Subject: Problem with opening SOCKET to hypermart
Message-Id: <3753308b.2164310@news.inet.co.th>
Hi everybody,
i try this code to retrive data from
http://topearth.hypermart.net/thai.html
use IO::Socket;
###############################
$sock = new IO::Socket::INET(PeerAddr => "topearth.hypermart.net",
PeerPort => 80);
print $sock "GET /thai.html / HTTP/1.0\n\n";
print $sock "Accept: */*\n";
print $sock "Content-Type: application/x-www-form-urlencoded\n";
print $sock "Content-Length: $size\n";
print $sock "Connection: Keep-Alive\n\n";
while (<$sock>) {
$datum=$datum.$_;
}
print $datum;
###########
but the output is something like "file not found!".
Try! you'll see.......
pleaseeeeee help!
------------------------------
Date: Mon, 31 May 1999 17:32:22 -0700
From: "Benevo Lence" <seeu@theasylum.com>
Subject: Re: Quick way to count lines in file?
Message-Id: <928197145.732.100@news.remarQ.com>
> I need to put data into an array but i don't know the file size (in
> lines) in advance.
> Is there a quick/smart way of getting this information or do i have to
> read every line and use a counter?
@array = <FILEHANDLE>;
$#array # will contain the number of lines
Cron
------------------------------
Date: Mon, 31 May 1999 18:27:02 -0700
From: lr@hpl.hp.com (Larry Rosler)
Subject: Re: Quick way to count lines in file?
Message-Id: <MPG.11bcd6b84711b2e989b40@nntp.hpl.hp.com>
In article <3753c8d1.70611184@news.oz.net> on Mon, 31 May 1999 17:57:39
GMT, Fuzzy Warm Moogles <tgy@chocobo.org> says...
> On Mon, 31 May 1999 15:02:23 +0200, Marian Kelc
> <marian.kelc@ruhr-uni-bochum.de> wrote:
> >> Is there a quick/smart way of getting this information or do i have to
> >> read every line and use a counter?
> >
> >while( <FILEHANDLE> ) { push @a, $_; ++$i }
>
> @a = <FILEHANDLE>;
> $i = @a;
Neither of those is quick nor particularly smart. The really smart way
is to RTFAQ. perlfaq5: "How do I count the number of lines in a file?"
--
(Just Another Larry) Rosler
Hewlett-Packard Company
http://www.hpl.hp.com/personal/Larry_Rosler/
lr@hpl.hp.com
------------------------------
Date: Mon, 31 May 1999 18:53:03 -0700
From: lr@hpl.hp.com (Larry Rosler)
Subject: Re: Quick way to count lines in file?
Message-Id: <MPG.11bcdcc44524c594989b42@nntp.hpl.hp.com>
In article <928197145.732.100@news.remarQ.com> on Mon, 31 May 1999
17:32:22 -0700, Benevo Lence <seeu@theasylum.com> says...
> > I need to put data into an array but i don't know the file size (in
> > lines) in advance.
> > Is there a quick/smart way of getting this information or do i have to
> > read every line and use a counter?
>
> @array = <FILEHANDLE>;
>
> $#array # will contain the number of lines
No. It will contain one less than the number of lines.
The original poster's followup about being 'to[o] much a C programmer
(i.e.. allocating/de allocating)...' seems to mean that he thought that
one needed to know the number of lines in advance before reading the
file into the array. One doesn't need to know, so the question is moot
and the FAQ I referred to earlier which answers the question is
irrelevant. Just read the file into the array (as the other answers
have shown) and be done with it.
--
(Just Another Larry) Rosler
Hewlett-Packard Company
http://www.hpl.hp.com/personal/Larry_Rosler/
lr@hpl.hp.com
------------------------------
Date: Tue, 1 Jun 1999 08:29:54 +0800
From: "Mozart" <zarmo@altavista.net>
Subject: Sybperl
Message-Id: <7iv9cg$s0h$1@newton.pacific.net.sg>
Hi,
I am planning to use the package Sybperl.
Anybody can send me or tell me where to find some scripting example.
It will help me to start quicker.
Thanks for your help
laurent.simonet@socgen.com
------------------------------
Date: Mon, 31 May 1999 22:42:10 -0300
From: "Kevin Howe" <khowe@performance-net.com>
Subject: the unshift function
Message-Id: <eQG43.2048$%65.4848@tor-nn1.netcom.ca>
The perl manual says the unshift function is, obviously enough, the
opposite of the shift function. If so, then why does the following code not
affect the array at all, whereas the same code using shifts instead of
unshifts would decrease the size of the array?
@this = (one,two,three);
print scalar(@this) . "," . "@this" . "\n";
unshift @this;
print scalar(@this) . "," . "@this" . "\n";
unshift @this;
print scalar(@this) . "," . "@this" . "\n";
Thanks,
Kevin
------------------------------
Date: 31 May 1999 20:08:07 -0400
From: Uri Guttman <uri@sysarch.com>
Subject: Re: Y2K infected Perl code
Message-Id: <x7aeukg4uw.fsf@home.sysarch.com>
>>>>> "BJ" == Bill Jones <bill@fccj.org> writes:
BJ> snowhare@long-lake.nihongo.org (Benjamin Franz) wrote:
>> Uri Guttman <uri@sysarch.com> wrote:
>>>
>>> i don't mean to be down on you, but why would you (or anyone) post a
>>> script if you are not a programmer? what bewilders me is why there is so
>>> much free perl/cgi stuff out there in those archives and how little was
>>> written by someone who IS a professional programmer.
>>
>> Not that bewildering, really. Most professional programmers have very
>> little _time_ available for writing and supporting free scripts.
>> I have lots of scripts I would like to write - and no time to
>> do so.
BJ> Maybe, instead of writing FAQs, this group
BJ> could collaborate on fixing some widely
BJ> looked for scripts?
there are hundreds (thousands?) of perl scripts on these archive
sites. most are not fixable but need rewriting from the ground up. in
fact many don't even have clear specs about what they actually are
doing. the fact they they seem to work is enough for most lusers.
BJ> I mean, no offense to the poster, Uri, or the
BJ> group - but we are mostly prone to bitching or
BJ> RTFM'ing people. I say we should take a
BJ> break from clpm and maybe spend the time
BJ> re-writing a portable solution?
i have my hands full with helping out in this group. writing a new set
of cgi apps is not in my future. but a net project to do so might be
interesting. you should first define the types of apps wanted (poller,
useless hit counter, b board, chat, etc.) and design them to be
stable, use cgi.pm, clean html, good perl constructs, proper file
locking, etc.
this is a larger project than you imagine. there is a lot of code out
there and creating a quality replacement for much of it is mucho
work. just check out the number of categeries of cgi apps there are at
some of the larger sites. i have seen dozens of categories with many
scripts in each. every tom, dick and harry has his own version of poll
script and hates the other style. so you can't replace them all unless
you come up with a very customizable template for the poll questions and
results. many of them have different specs about leitng lusers vote,
checking ip addresses (not too useful for those behind a gateway), etc.
so think about this before you say, "hey gang! let's put on a show and
save the _________ from being sold/foreclosed/torn down."
uri
--
Uri Guttman ----------------- SYStems ARCHitecture and Software Engineering
uri@sysarch.com --------------------------- Perl, Internet, UNIX Consulting
Have Perl, Will Travel ----------------------------- http://www.sysarch.com
The Best Search Engine on the Net ------------- http://www.northernlight.com
------------------------------
Date: Mon, 31 May 1999 17:44:40 -0700
From: Kristina <kristina@greatbasin.net>
Subject: Re: Y2K infected Perl code
Message-Id: <Pine.BSI.4.05L.9905311724240.25771-100000@web0.greatbasin.net>
On 31 May 1999, Uri Guttman wrote:
> there are hundreds (thousands?) of perl scripts on these archive
> sites. most are not fixable but need rewriting from the ground up. in
> fact many don't even have clear specs about what they actually are
> doing. the fact they they seem to work is enough for most lusers.
The fact that they seem to work and do what someone needs them to do
is the reason they're used, and the reason that such scripts propagate.
Most people can't even install a pre-written CGI script in any language.
If someone gets a script that they can set up, and that does pretty much
what they expect it to do over and over again, they absolutely do not
care if the programming that went into it is shoddy. ISP customers don't
care if you've got the biggest, baddest Cisco router with a T-3
connection and a web server cluster that can kick out a gazillion pages
a second: they just want their email form to work. If it works, they're
happy. If it doesn't work, they go somewhere else: it's the same with
scripts: If they don't work, people go find another one that does work.
Big companies who can afford it hire programmers. Small businesses,
schools, charities, and individuals are just happy to find something that
works for them. If they do find something that works for them, and
it's not as well-written as it should be, nonetheless it fulfills a need,
so how can that be bad?
Kristina
------------------------------
Date: 12 Dec 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 Dec 98)
Message-Id: <null>
Administrivia:
Well, after 6 months, here's the answer to the quiz: what do we do about
comp.lang.perl.moderated. Answer: nothing.
]From: Russ Allbery <rra@stanford.edu>
]Date: 21 Sep 1998 19:53:43 -0700
]Subject: comp.lang.perl.moderated available via e-mail
]
]It is possible to subscribe to comp.lang.perl.moderated as a mailing list.
]To do so, send mail to majordomo@eyrie.org with "subscribe clpm" in the
]body. Majordomo will then send you instructions on how to confirm your
]subscription. This is provided as a general service for those people who
]cannot receive the newsgroup for whatever reason or who just prefer to
]receive messages via e-mail.
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 5844
**************************************
