Luser Perl code
Seagull
lest I be tempted to go out to the floor and shoot someone.
Today, I am looking at luser Perl code. Lots of it.
Let me share with you some of the gems I have found (actual variable
names have been changed to protect the guilty):
1. $today=`date "+%m/%d/%y"`;
2. @results= `grep $pattern $file`;
3. system "mv $file1 $file2";
4. print "[line 1 of text]\n";
print "[line 2 of text]\n";
print "[line 3 of text]\n";
print "[line 4 of text]\n";
print "\n";
print "[Start a new paragraph]\n";
# ... and on line this for about 20 lines ...
5. exec $program, @arguments;
if ( $? > 0 ) { # <-- this one is my favorite
print STDERR "exec failed\n";
}
6. system "rm -f $filename";
7. open(FILE, "-|") || exec "ls", '-lt', $file;
$_= <FILE>
close FILE;
/(\S+\s+){4}((\S+\s+){3})/i && ($datemod= $2);
And this is the _working_ code that I have come across. You should
see some of the crap that makes absolutely no sense.
Cheers,
-+JLS
--
sea...@netcom.com \ carpe cavy!
sea...@aracnet.com \
http://www.aracnet.com/~seagull \ (seize the guinea pig!)
Steve VanDevender
> It's a good thing our company doesn't allow firearms in the building,
> lest I be tempted to go out to the floor and shoot someone.
>
> Today, I am looking at luser Perl code. Lots of it.
>
> Let me share with you some of the gems I have found (actual variable
> names have been changed to protect the guilty):
>
> 1. $today=`date "+%m/%d/%y"`;
>
> 2. @results= `grep $pattern $file`;
>
> 3. system "mv $file1 $file2";
Actually, I wrote a perl script with constructs rather like that
once. It was because I had originally written a very nice little
Bourne shell script to do a particular task, was ready to install
it on the system, and then had the pointy-haired luser admin at
the time _insist_ (and sadly, in a committee meeting, where the
committee was supposed to be reining in the PHLA's luserish
tendencies -- it's a loooong story) that it had to be in perl
instead. Never mind that I already had the /bin/sh version
working perfectly. Never mind that no matter how you sliced it,
doing it in perl would be slower and more bloated. It had to be
in perl.
So I did a nearly mechanical translation of the /bin/sh script
into perl, and installed it to meet the ridiculous requirement.
Now that the organization in question is long rid of the PHLA,
and the new sysadmin crew is into doing things like archiving
source and revision tracking, I got to put this script into RCS
with some very interesting change comments, carefully duplicating
the history of it being a nice little /bin/sh script, then a
crock of a perl script, then the nice little /bin/sh script
again, which is also installed for system use now.
But the last time I made indirect reference to the PHLA (I
believe using the phrase "hippie pothead from another universe")
here in the Monastery an absolute fsckhead dweeb tried to bring
this up as an argument against me in some random flamewar, even
though I did not mention the PHLA by name or give any explicit
clues as to who it was.
Suffice to say that these days our organization refers to
artifacts from the PHLA's rein as PHLAperl (he wrote perl that is
even worse than the cited examples) and PHLAos (his seriously
broken configuration of SunOS). Except PHLA is replaced with his
name.
--
Steve VanDevender "I ride the big iron" http://jcomm.uoregon.edu/~stevev
ste...@efn.org PGP key fingerprint=929FB79734DF8CC0 210DA447510FF93B
"bash awk grep perl sed df du, du-du du-du,
vi troff su fsck rm * halt LART LART LART!" -- the Swedish BOFH
Stephen Edwards
: once. It was because I had originally written a very nice little
: Bourne shell script to do a particular task, was ready to install
: it on the system, and then had the pointy-haired luser admin at
: the time _insist_ (and sadly, in a committee meeting, where the
: committee was supposed to be reining in the PHLA's luserish
: tendencies -- it's a loooong story) that it had to be in perl
: instead. Never mind that I already had the /bin/sh version
: working perfectly. Never mind that no matter how you sliced it,
: doing it in perl would be slower and more bloated. It had to be
: in perl.
And you _do_ know why that is don't you?... why, so your PHLA could go to
his PHLA associates, take his wank out, whip it around, and proclaim in an
ever-so-manly-voice(tm) "yeah, we do all that with perl"... "yeah, we're
so incredibly 'l33t. If you like, I can show you how to chew that
bubblegum in a more efficient manner!"
Most PHLs are highly impressed with techie-weenie-21stcenturydigitalboy
words.
: Suffice to say that these days our organization refers to
: artifacts from the PHLA's rein as PHLAperl (he wrote perl that is
: even worse than the cited examples) and PHLAos (his seriously
: broken configuration of SunOS). Except PHLA is replaced with his
: name.
Hmmm... phonetically, PHLA can sound like "flaw".
[] Footnote server is currently down...
--
.-----.
|[_] :| Stephen S. Edwards II | http://www.primenet.com/~rakmount
| = :| Support the shareware authors... register your software!
| | Please send all flames, trolls, and complaints to /dev/toilet.
|_..._| LUSER: I have a problem. ADMIN: Keep talking... I'm reloading.
Edward J. Powell
: It's a good thing our company doesn't allow firearms in the building,
: lest I be tempted to go out to the floor and shoot someone.
:
: Today, I am looking at luser Perl code. Lots of it.
:
: Let me share with you some of the gems I have found (actual variable
: names have been changed to protect the guilty):
{snip}
I should post the abortion of a working Perl script that I congealed out
of recycled bits from /dev/null[1] sometime... it works. I don't know how
or why, but it works.
I'll freely admit that I've used exec("mv $blah1 $blah2"); and exec("rm -f
$blah"); before. Forgive me, Larry Wall, that in thy light you may shine
upon me, and grant me the wisdom to be a better programmer...
[1] AKA my brain.
--
Ed Powell -- Twilight Zone Reject
http://www.visi.com/~epowell Finger for PGP public key
"When SysAdmins Attack!" This Sunday, on Fox.
Lars Balker Rasmussen
> I'll freely admit that I've used exec("mv $blah1 $blah2"); and exec("rm -f
> $blah"); before.
But that's terminally stupid, Ed!
--
Lars Balker Rasmussen "Woo hoo!?"
Michael Turner
Lars Balker Rasmussen <la...@rasmussen.org> wrote:
>epo...@visi.com (Edward J. Powell) writes:
>> I'll freely admit that I've used exec("mv $blah1 $blah2"); and
>> exec("rm -f $blah"); before.
>
>But that's terminally stupid, Ed!
Not a WISE thing to do with the provisions that are in perl already.
Not to mention the possible corruption of the path. I'm sure that if
you ASCII'ed you'd GETTY a reasonable ANSI on the best way to do it.
--Michael Turner
mtu...@netapp.com
David Jacoby
>: Let me share with you some of the gems I have found (actual variable
>: names have been changed to protect the guilty):
>I'll freely admit that I've used exec("mv $blah1 $blah2"); and exec("rm -f
>$blah"); before. Forgive me, Larry Wall, that in thy light you may shine
>upon me, and grant me the wisdom to be a better programmer...
I also admit that I've used most, if not all of those constructs. Before I
learned about localtime(time), I did the most stupid script based on
$date = `date` ;
Parsing it down to mmm/dd/yyyy was so horrible and so stupid, I kick myself
whenever I look back on it.
--
Dave Jacoby I wish I could give brother Bill his big thrill
jacoby at ecn.purdue.edu I would set him in chains at the top of the hill
http://purdue.org/~jacoby/ Then send out for some pillars and Cecil B. Demille
Father. Guitarist. Geek. He could die happily ever after - Bob Dylan
Martin J. Laubach
>learned about localtime(time), I did the most stupid script based on
>$date = `date` ;
I sincerely hope you haven't ever used what I stumbled upon lately:
$str = "foo XXX bar";
$str =~ s/XXX/$something/;
print $str;
$str =~ s/$something/XXX/;
Aaaarghhhhhhhhhhh!
mjl
Seagull
:
: I also admit that I've used most, if not all of those constructs.
I think that we all need a little perspective on it, though. I mean,
it's one thing to use $date= `date` when yhou are juyst learning the
language and writing your very first perl scripts.[1]
It's another thing entirely when the authors in question have the
Camel book, have written several score Perl scripts and _still_ churn
out code like: system "rm $file".
Cheers,
-+JLS
[1] Though to be smug, I can't say that I've ever done anything as
stupid as check the exit condition of a failed "exec". :)
David Jacoby
>: I also admit that I've used most, if not all of those constructs.
>I think that we all need a little perspective on it, though. I mean,
>it's one thing to use $date= `date` when yhou are juyst learning the
>language and writing your very first perl scripts.[1]
>It's another thing entirely when the authors in question have the
>Camel book, have written several score Perl scripts and _still_ churn
>out code like: system "rm $file".
Well, I've used that, or something enough like it as to not matter,
recently enough to not really want to get into it. Of course, most of
my perl work is CGI, with mail filtering, mail sending and TK being
occasional sidelines. File manipulations beyond read, write and
append were not what I know, although I've been having fun with directory
handles lately. Tried to write an 'rgrep' for the web directories,
but decided that iterative approach was far simpler. But the specific
thing was "I don't want to type rm (or whatever) a lot of times, but
I don't want to find out the real perl way to do it. I wanna get the
fscking thing done before my next class."
I knew it was wrong but I did it anyway. Which means I'm evil, not crazy.
christian mock
> Let me share with you some of the gems I have found (actual variable
> names have been changed to protect the guilty):
>
> 1. $today=`date "+%m/%d/%y"`;
This is just stupid.
It's bad when you run across something like:
require 'cgi-lib.pl'; # cgi-lib.pl installed in the cgi-bin directory
%vars = parse_cgi(); # or whatever the function name is
if(%vars{"TEMPLATE"}) {
$file = %vars{"TEMPLATE"};
} else {
$file = "/path/to/default";
}
open(F, $file); # what about ||die ?
while(<F>) {
# fill in template...
print;
}
http://server/cgi-bin/stupid.cgi?TEMPLATE=/etc/passwd anyone? I mean,
the idea that the Internet is a scary place with lotsa bad people is
new for "HTML programmers", or what?
ciao,
cm.
--
christian mock @ home in vienna, austria
sind fremdcancels strafbar? -> http://www.tahina.priv.at/bincancel/
Those silly RFCs are all that separate us from the animals!
-- Kevin Rodgers in a.r.e
Stephen Harris
: It's bad when you run across something like:
This is not bad programming - it's just inexperience. Typically code
such as:
: if(%vars{"TEMPLATE"}) {
: $file = %vars{"TEMPLATE"};
: } else {
: $file = "/path/to/default";
: }
would appear more commonly as
$file=$TEMPLATE_DIR."/".%vars{"TEMPLATE"};
Of course, this is where the inexperience shows up. I had to teach an ex
cow-orker this (he was slightly annoyed when I found 3 security holes in his
program that he'd spent 2 days on, but he did learn the lesson).
: open(F, $file); # what about ||die ?
Yeah right, "die" in a CGI. Ha! "Server Error" anyone?
--
rgds
Stephen
Alexander Schreiber
Re: Luser Perl code:
Indeed. How about some kind of graceful exit - like calling a sub which prints
an error message, closes the HTML-Stream and exits cleanly ?
If this is UI to you then _you_ are the one needing a LART applied.
Regards,
Alex.
--
------------------------------------------------------------------------------
EMail : a...@informatik.tu-chemnitz.de | WWW : http://www.tu-chemnitz.de/~als
If privacy is outlawed, only outlaws will have | Ceterum censeo Parva Mollia
privacy. (Philip Zimmerman, author of PGP) | esse delendam.
Abigail
<URL:news:72t2d1$tm3$1...@nebula.mpn.com>:
++ christian mock (c...@tahina.priv.at) wrote:
++
++ : It's bad when you run across something like:
++
++ This is not bad programming - it's just inexperience. Typically code
++ such as:
++
++ : if(%vars{"TEMPLATE"}) {
++ : $file = %vars{"TEMPLATE"};
++ : } else {
++ : $file = "/path/to/default";
++ : }
++
++ would appear more commonly as
++ $file=$TEMPLATE_DIR."/".%vars{"TEMPLATE"};
But that still has all the signs of "I don't know Perl".
++ Yeah right, "die" in a CGI. Ha! "Server Error" anyone?
use CGI::Carp;
Abigail
--
What's that '%' there doing?
Georg Bauer
Stephen Harris <sw...@mpn.com> wrote:
>cow-orker this (he was slightly annoyed when I found 3 security holes in his
>program that he'd spent 2 days on, but he did learn the lesson).
What's new about -T? It's not as if there is no way to tell perl to barf at
you in problematic code-sections ... (yes, you have to fix those situations
yourself, no, just using /.*/ as a regexp to check isn't the way to go ...)
>Yeah right, "die" in a CGI. Ha! "Server Error" anyone?
What's wrong with use CGI::Carp?
Oh, and please tell me: why cgi-lib.pl? Does he still use rocks to make fire?
bye, Georg
Jonathan H N Chin
>In article <seagullF...@netcom.com>, Seagull <sea...@netcom.com> wrote:
>> 1. $today=`date "+%m/%d/%y"`;
>This is just stupid.
Hmmm.
This must be the `hubris' that Perl programmers are told to strive for.
What's stupid about it?
It is one concise line of source. It is simple to understand.
Presumably it does the job it is supposed to do.
What happened to the Perl motto "there's more than one way to do it"?
I wrote a functional printer accounting system in Perl with not much
more exposure to the language than having read the first chapter of
"Programming Perl". (I still haven't read much more than that.)
Sure, it could have been more efficient. For example, I used a homebrew
flat-file database that I read into a hash each time the program ran
instead of tieing a dbm because I didn't know the facility was available.
So what? The accounting machine had memory to spare and CPU cycles to burn.
Some years ago, I wrote a Bourne shell script to mung a password file.
Eventually the password file got too big and the script blew up due to
an arbitrary size limit in awk or sed. So I used s2p (or was it a2p?)
to convert the script to Perl. I could have rewritten it from scratch,
but why bother? It worked well enough as is. Running s2p took seconds,
and doing a simple sanity check on the result not much longer.
Isn't one of the tenets of Perl programming supposed to be laziness?
-jonathan
--
Jonathan H N Chin, 1 kyu | deputy computer | Newton Institute, Cambridge, UK
<jc...@newton.cam.ac.uk> | systems mangler | tel/fax: +44 1223 335986/330508
"respondeo etsi mutabor" --Rosenstock-Huessy
Jonathan H N Chin
>christian mock (c...@tahina.priv.at) wrote:
>: It's bad when you run across something like:
>This is not bad programming - it's just inexperience. Typically code
>such as:
>: if(%vars{"TEMPLATE"}) {
>: $file = %vars{"TEMPLATE"};
^ ?
>: } else {
>: $file = "/path/to/default";
>: }
>would appear more commonly as
> $file=$TEMPLATE_DIR."/".%vars{"TEMPLATE"};
^ ?
I'm not sure what your point is: Both pieces of code are broken, and the
second example doesn't implement the same algorithm as the first anyway.
(Unless $TEMPLATE_DIR magically turns into "" when $vars{TEMPLATE} exists,
and "/" *always* magically turns into "", which doesn't seem likely.)
>: open(F, $file); # what about ||die ?
>Yeah right, "die" in a CGI. Ha! "Server Error" anyone?
<deviladvocate>Why not? It is a server error.</deviladvocate>
Josh Brandt
In article <jc254.9...@newton.newton.cam.ac.uk>,
>This must be the `hubris' that Perl programmers are told to strive for.
>What's stupid about it?
Well, among other things, it's slow, insecure, and redundant.
>What happened to the Perl motto "there's more than one way to do it"?
"...but some of them are better than others."
>Isn't one of the tenets of Perl programming supposed to be laziness?
Yeah, but it's nice to see _good_ code, too. You do it right the first time,
and you don't have to go back and fix it afterward.
Josh
--
...said it was heaven just to breathe your air Severed Heads
J. Brandt - mu...@sidehack.gweep.net
Josh Brandt
>>Yeah right, "die" in a CGI. Ha! "Server Error" anyone?
>
><deviladvocate>Why not? It is a server error.</deviladvocate>
Yeah? Troubleshoot it.
Or, better yet, make sure that if your customers see "Server Error" on your
web page when they're playing with your form, they don't assume your a bunch
of idiots. Much better to have the _realize_ there's an error, and deal with
it accordingly, perhaps saying something like "There has been an error in
the blah subroutine, opening $file. The administrator has been contacted
about this, and will take care of it accordingly" or something like that.
I mean, gosh, you can be a lazy bastard all you want in secret, but if your
code stinks and you _look_ like a lazy bastard, it's your own fault.
Josh
code ethic.
Seagull
: c...@tahina.priv.at (christian mock) writes:: >
: >This is just stupid.
:
: Hmmm.
: This must be the `hubris' that Perl programmers are told to strive for.
: What's stupid about it?
It spawns two processes: /bin/sh and date.
: It is one concise line of source. It is simple to understand.
: Presumably it does the job it is supposed to do.
:
: What happened to the Perl motto "there's more than one way to do it"?
The perl motto you quote, presumably, refers to actually using the
tools of the language, not bastardizing the shell because you're too
lazy to look up functions in the camel book.
: Sure, it could have been more efficient. For example, I used a homebrew
: flat-file database that I read into a hash each time the program ran
: instead of tieing a dbm because I didn't know the facility was available.
: So what? The accounting machine had memory to spare and CPU cycles to burn.
This is a completely different argument. If you want to write
inefficient Perl, that's no big deal. Small and medium data files are
hardly ever worth the effort to optimize for speed since the run time
is negligeale, anyway. But what we're talking about above is using
the shell to do something that Perl knows how to do, and a lot more
efficiently. There are all kinds of things wrong with the above
construct, not the least of which is you don't know where 'date' is
coming from (unless the author bothered to set $ENV{PATH}, which in
this case, (s)he didn't).
: to convert the script to Perl. I could have rewritten it from scratch,
: but why bother? It worked well enough as is. Running s2p took seconds,
: and doing a simple sanity check on the result not much longer.
:
: Isn't one of the tenets of Perl programming supposed to be laziness?
Laziness, yes. Stupidity, no.
Remember, you're still quoting examples of using native perl. Running
a2p to convert a sed script to perl still gives you perl, whether or
not it's efficient code. But again, we're talking about using the
shell. Imagine, instead of running a2p or s2p, that you write a perl
script that did this:
system "awk -e $file '{whateve code...}'";
Would you call _that_ efficient? Would you call it acceptable
programming? Now imagine that some code in a loop. Now imagine that
loop being _within_ a loop.
Scared yet? You should be...we really had a piece of code that did
this, written by a sysadmin, and running out of cron every _hour_ on
one of our administration machines. It didn't take long for us to
discover this code...less than three hours after the cron job first
ran, in fact. Something about those huge spikes in CPU usage gave it
away.
Josh Brandt
...where date can be the first thing in your path named "date."
Make of that what you will.
>efficiently. There are all kinds of things wrong with the above
>construct, not the least of which is you don't know where 'date' is
>coming from (unless the author bothered to set $ENV{PATH}, which in
>this case, (s)he didn't).
Yeah, what you said. 8)
>Scared yet? You should be...we really had a piece of code that did
>this, written by a sysadmin, and running out of cron every _hour_ on
>one of our administration machines. It didn't take long for us to
>discover this code...less than three hours after the cron job first
>ran, in fact. Something about those huge spikes in CPU usage gave it
>away.
Heh. I could tell stories, but I think I already have... 8)
Josh
"and let's write it as a daemon!"
Erik
jc...@newton.cam.ac.uk (Jonathan H N Chin) writes:
>>> 1. $today=`date "+%m/%d/%y"`;
>
>>This is just stupid.
>
> Hmmm.
> This must be the `hubris' that Perl programmers are told to strive for.
> What's stupid about it?
Well, other than using localtime() would be cleaner, and avoid the system
call (I like to avoid system calls whenever possible), you're not calling
"date" with an absolute path.
So, to make things clearer:
NEVER *WHAM* ASSUME *WHAM* ANYTHING *WHAM* ABOUT *WHAM* YOUR
*WHAM* ENVIRONMENT *WHAM*
Particularly if this is called in a CGI script. And I'm at a loss as to
why a luser would even know Perl is useful for anything outside of CGI.
Oh, and it's also got a y2k problem (at least it does on linux). Maybe
capitalizing one of those letters would help.
--
Erik Nielsen, Cyberhighway Internet Services NOC
Perhaps they will have to outlaw sending random lists of words. fee fie
foe foo
-- Larry Wall in <1997103119...@wall.org>
Stephen Harris
: In <72trcf$crs$1...@client3.news.psi.net> abi...@fnx.com (Abigail) writes:
: >++ christian mock (c...@tahina.priv.at) wrote:
: >++ $file=$TEMPLATE_DIR."/".%vars{"TEMPLATE"};
: >But that still has all the signs of "I don't know Perl".
: Especially since perl 5 gives an error when you try the above :)
Hey, it was cut'n'paste from the original. I used my own routines and
would have used $in{'TEMPLATE'} myself.
: >++ Yeah right, "die" in a CGI. Ha! "Server Error" anyone?
: Personally I prefer to use my own sub-routine which can be called in the
: same way as die(). This is so that I can do the right thing like pulling in
Off the top of my head....
sub error # ()
{
local($msg)=@_;
&header("Error") unless $header_sent;
print "Something screwed up: $msg";
&footer;
exit;
}
open(...) || &error("Can not open file: $!");
I don't use CGI.pm or anything like that. Don't like the concept of
$c->h1("header") rather than print "<h1>header</h1>". So I do it myself with
my own CGI parsing routines.
--
rgds
Stephen
Peter da Silva
>It spawns two processes: /bin/sh and date.
Why does it spawn /bin/sh?
--
In hoc signo hack, Peter da Silva <pe...@baileynm.com>
`-_-' "Heb jij vandaag je wolf al geaaid?"
'U`
"Tell init(8) to lock-n-load, we're goin' zombie slaying!"
Ernst Jan Plugge
> In article <seagullF...@netcom.com>, Seagull <sea...@netcom.com> wrote:
> >: >> 1. $today=`date "+%m/%d/%y"`;
>
> >It spawns two processes: /bin/sh and date.
>
> Why does it spawn /bin/sh?
Because the string between ` and ` contains shell metacharacters.
Y.T.,
Ernst Jan Plugge - r...@dds.nl
--
Jonathan H N Chin
>Jonathan H N Chin <jc...@newton.cam.ac.uk> wrote:
>>>> 1. $today=`date "+%m/%d/%y"`;
>>What's stupid about it?
>Well, among other things, it's slow, insecure, and redundant.
slow != stupid.
Insecure? Yes, there is that. The first thing I saw about the line was
that the command had a relative path. I assumed the path would be set
somewhere. Apparently it isn't. This is a problem.
Redundant? How so? I wrote previously:
|>It is one concise line of source. It is simple to understand.
Show me a similarly simple one-liner Perl equivalent.
Hmmm. Now that I've hunted through "Programming Perl", I see strftime(3)
is available if one knows about the POSIX module--but it's not listed in
the index. So I guess a more PC equivalent of the above could be:
$today = POSIX::strftime("%m/%d/%y\n", localtime(time()));
Going the other way, when attempting to reduce the size of the PostScript
letterhead that gets tacked on the top of lots of our correspondence,
although I replaced a huge outline font, that someone had thoughtfully
inlined into it, by:
gsave .1 setlinewidth 12 H 129 123 m 1 1 1.4 v */x currentpoint/y e d d/c
( )d/S(UNIVERSITY OF CAMBRIDGE)d/dx 440 124 - S w p - S l 1 - v d S{c 0 3
2 roll : c false charpath stroke/x x dx + c w p + d x y m}forall grestore
where, among other things:
/-{sub}/+{add}/*{scale}/:{put}/?{findfont}/={setfont}
/d{def}/e{exch}/l{length}/m{moveto}/p{pop}/v{div}/w{stringwidth}
/F{? e scalefont =}/H{/Helvetica F}15{def}repeat
since I only have dealings with PostScript about once a year, coming back,
now that we want to modify it, and trying to figure out what it does was
not entirely obvious[1]. Sometimes squashing code can be taken too far...
>Yeah, but it's nice to see _good_ code, too. You do it right the first time,
>and you don't have to go back and fix it afterward.
If you know how to do it right, it's probably not your first time.
"The pursuit of perfection often impedes improvement" --George Will
I forget who said that one should expect to write a program three times.
(And what the reasoning was. Something along the lines of: "Do it once;
Second time, do it right; Third time, automate it", IIRC)
-jonathan
[1] I am reminded of the story of the mathematics professor. He writes
a paper containing: "It is obvious that <some result>". Some time
later, he has forgotten the derivation so he sits down to work it
out again. It takes him many hours, but he does indeed eventually
manage to prove that the result is obvious.
Peter da Silva
Ernst Jan Plugge <r...@dds.nl> wrote:
>On 18 Nov 1998 18:23:41 GMT, Peter da Silva <pe...@baileynm.com> wrote:
>> >: >> 1. $today=`date "+%m/%d/%y"`;
>> >It spawns two processes: /bin/sh and date.
>> Why does it spawn /bin/sh?
>Because the string between ` and ` contains shell metacharacters.
How does it know? Not all shells have the same metacharacters.
This is an example of why I like <UI> more than perl. In <UI> if you want it
to run a shell, you call "sh -c" explicitly.
Nik Clayton
>This is not bad programming - it's just inexperience. Typically code
>such as:
>
>: if(%vars{"TEMPLATE"}) {
>: $file = %vars{"TEMPLATE"};
>: $file = "/path/to/default";
>: }
>
>would appear more commonly as
> $file=$TEMPLATE_DIR."/".%vars{"TEMPLATE"};
I would hope not. IDTTMWYTIM.
In a previous life^Wjob (Stephen knows what I'm talking about) I had the
misfortune of maintaining code from one Avxbf Qenxbf, better known
(I believe) as the author of yngrk2ugzy. I've never seen the code for
yngrk2ugzy, and I'm prepared to believe it's a shining work of genius.
This, however, was not.
I'm not sure which concerned me more. The gratuitous use of Perl 4 and
Perl 5 idioms in the same programs (sometimes within the same statement)
or the casual disregard for such fundamentals as "race conditions and
how to avoid them".
Wrote my first piece of Perl in anger for the first time in 2 months the
other. Certainly felt good to tap out "#!/env/perl" and watch the syntax
colouring kick in. Like I was back with an old friend. . .
Possibly I need to get out more.
N
--
C.R.F. Consulting -- we're run to make me richer. . .
Ernst Jan Plugge
> In article <slrn756cr...@eco248.eco.rug.nl>,
> Ernst Jan Plugge <r...@dds.nl> wrote:
> >On 18 Nov 1998 18:23:41 GMT, Peter da Silva <pe...@baileynm.com> wrote:
> >> Why does it spawn /bin/sh?
>
> >Because the string between ` and ` contains shell metacharacters.
>
> How does it know? Not all shells have the same metacharacters.
*shrug*. It prolly knows the most common /bin/sh's meta chars. Should
be a reasonably useful approximation of what's desired. It might even
try to find out at ./configure time.
> This is an example of why I like <UI> more than perl. In <UI> if you want it
> to run a shell, you call "sh -c" explicitly.
Yes, but perl can usually make that decision for you. You just tell it
what to do, and it (tries to) figure out the proper way to do it.
I agree with your argument, but I understand perl's approach as well.
Brandon S. Allbery KF8NH
+-----
| In article <72v3bd$n...@web.nmti.com>,
| : >: >> 1. $today=`date "+%m/%d/%y"`;
| : >It spawns two processes: /bin/sh and date.
| man 2 system.
+--->8
s/2/3/
--
brandon s. allbery [os/2][linux][solaris][japh] all...@kf8nh.apk.net
system administrator [WAY too many hats] all...@ece.cmu.edu
carnegie mellon / electrical and computer engineering KF8NH
Kiss my bits, Billy-boy.
Mark Lowes
Martin J. Laubach <m...@emsi.priv.at> wrote:
[...]
> I sincerely hope you haven't ever used what I stumbled upon lately:
>
> $str = "foo XXX bar";
>
> $str =~ s/XXX/$something/;
> print $str;
> $str =~ s/$something/XXX/;
*choke* *rofl*
Oh dear....
Mark
--
Mark Lowes Home: <ham...@wibble.org> Work: <ma...@ftech.net>
Webmaster, Listmaster, bofh and fluffy cuddly person.
http://hamster.wibble.org/ http://www.wibble.org/
Abigail
<URL:news:72v3bd$n...@web.nmti.com>:
++ In article <seagullF...@netcom.com>, Seagull <sea...@netcom.com> wrote:
++ >: >> 1. $today=`date "+%m/%d/%y"`;
++
++ >It spawns two processes: /bin/sh and date.
++
++ Why does it spawn /bin/sh?
Because there's a space in `date "+%m/%d/%y"`. Perl *needs* the shell to
do interpolation, splitting things up into parameters, etc.
Abigail
Stephen Harris
: (I believe) as the author of yngrk2ugzy. I've never seen the code for
: yngrk2ugzy, and I'm prepared to believe it's a shining work of genius.
It is very very messy. But it works, which is the main evaluation criteria.
: I'm not sure which concerned me more. The gratuitous use of Perl 4 and
: Perl 5 idioms in the same programs (sometimes within the same statement)
That's for a good reason actually. At the time, perl 4 was still the
standard version. We had only just installed perl5, and Avxbf Qenxbf was
really trying hard to learn the new stuff. Also, at the point we handed
the code over to you (I assume you are talking about "Meta"), Avxbf was
in the middle of a rewrite. Heh, Meta was _always_ in the middle of a
rewrite. Later, a newer cow-orker rewrote the code in a more modular
manner, totally using libraries (use MPN::Meta).
Avxbf never was a good programmer, but he's a better programmer than a lot
of people I've seen.
: or the casual disregard for such fundamentals as "race conditions and
: how to avoid them".
That (also) was his lack of experience, and (partially) design. He grew up on
a LISP engine with minimal Unix experience. He hacked out perl code assuming
single user. So the "design" phase said "we only run our own code, or
trusted other code. No lusers have interactive access so most security
race conditions are ignorable." The biggest race condition left in the
code was then CSV file locking. Which broke occaisionally. Heh, the spec
was for a 100->1000 entries. They reached 100,000 before breaking, so don't
bitch too much :-) Of course, we now have "use MPN::Lock" to solve this :-)
Not that I'm defending him, but considering the work load he was under,
and the lack of resources we had, any code was better than none :-)
PS: will we see you at ASRlon next month?
--
rgds
Stephen
Seagull
:
: Show me a similarly simple one-liner Perl equivalent.
What is this obsession with one-liners? Elegant == short?. One line
== good? I would hate to make such a generalization. Code should be
readable first, and work second. Why? Because unreadable working code
is useless when the author gets hit by a truck and you have to maintain
it. Unless you are really looking for super-efficient execution, why
make life hard on your co-workers?
Just because something can be done in one line, that doesn't mean that
it should be. Perl is great for obfuscated code that can be condensed
to one line. But I'd much rather read four lines of code that make
sense at first glance.
Saying $today=`date +"%m/%d/%y"` is lazy and stupid. Lazy, because
perl can do it internally, even without the POSIX module (though you
get to do it in one line instead of two). It's stupid because it
wastes CPU time that is best spent elsewhere.
Cheers,
-+JLS
Calle Dybedahl
> This must be the `hubris' that Perl programmers are told to strive for.
> What's stupid about it?
I'll have to agree with you here. It looked to me rather like
beginner-level Perl, the sort of code one writes just after starting
to learn the language. As one learns more, one writes more efficient
and, hopefully, cleaner code. But even with a minimal knowledge of
Perl, you can write something that *works*, and that has to be the
primary criteria.
--
Calle Dybedahl, qdt...@esavionics.se, http://www.lysator.liu.se/~calle/
Mediocre minds think alike.
Arthur Hagen
> I'm not sure which concerned me more. The gratuitous use of Perl 4 and
> Perl 5 idioms in the same programs (sometimes within the same statement)
> or the casual disregard for such fundamentals as "race conditions and
> how to avoid them".
Seen majordomo?
> Possibly I need to get out more.
Why? It's friggin cold outside!
--
*Art
Jonathan H N Chin
>: >>>> 1. $today=`date "+%m/%d/%y"`;
>: Show me a similarly simple one-liner Perl equivalent.
>What is this obsession with one-liners? Elegant == short?. One line
>== good? I would hate to make such a generalization. Code should be
>readable first, and work second. Why? Because unreadable working code
>is useless when the author gets hit by a truck and you have to maintain
>it. Unless you are really looking for super-efficient execution, why
>make life hard on your co-workers?
One simple, easy to understand line is virtually guaranteed to be more
simple and more easy to understand than a whole bunch of simple, easy
to understand lines. I am not saying obfuscate to achieve shortness.
Short code is less effort to read because there is less of it.
Why is this hard to understand?
>Just because something can be done in one line, that doesn't mean that
>it should be. Perl is great for obfuscated code that can be condensed
>to one line. But I'd much rather read four lines of code that make
>sense at first glance.
It takes longer and more effort to read four lines than to read one.
If something can be expressed *simply* in one line, why use four?
I find it very hard to believe you consider the quoted example to not
"make sense at first glance".
>Saying $today=`date +"%m/%d/%y"` is lazy and stupid. Lazy, because
>perl can do it internally, even without the POSIX module (though you
>get to do it in one line instead of two). It's stupid because it
>wastes CPU time that is best spent elsewhere.
Not lazy. Perhaps naive.
The introduction to "Programming Perl" states:
|>Most important, you don't have to know everything there is to know about
|>Perl before you can write useful programs. You can learn Perl "small end
|>first". You can program in Perl Baby-Talk, and we promise not to laugh.
|>[...] Any level of language proficiency is acceptable in Perl culture.
|>We won't send the language police after you. A Perl script is "correct"
|>if it gets the job done before your boss fires you.
You're not laughing, true. You are sneering and insulting.
Not stupid either. If CPU efficiency is such an issue, why program in
Perl in the first place? It is inherently slower than assembly or even C
(although it is getting better).
I don't regularly program in Perl. I don't see an obvious way, using
built-in functions/operators, to do an equivalent to the example that
is as clear and concise as either (a) invoking date(1), or (b) calling
strftime(3) in some other way. The only thing that springs to my mind is:
($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime(time);
$today = join "/", $mon+1, $mday+1, "$year\n";
I find this a lot less clear and a lot less concise.
It violates Ockham's Razor.
And what if the date was desired in the form "Thu, Jan 1 1970"?
Converting numbers to relevant strings would be even more complicated.
Laying aside the security problem, which I have acknowledged, and the issue
of efficiency, which I consider to be of secondary importance in most cases,
I still consider the original code (or even the POSIX equivalent, which
addresses both those issues) to be superior to the two lines above.
But apparently your two (four?) line implementation is much more clear and
concise ("readable") than any of these forms. Please show me it.
-jonathan
Charlie Stross
on 18 Nov 98 12:01:14 GMT,Jonathan H N Chin
the supplicant <jc...@newton.cam.ac.uk> implored:
>c...@tahina.priv.at (christian mock) writes:
>>In article <seagullF...@netcom.com>, Seagull <sea...@netcom.com> wrote:
>
>>> 1. $today=`date "+%m/%d/%y"`;
>
>>This is just stupid.
>
>Hmmm.
>This must be the `hubris' that Perl programmers are told to strive for.
>What's stupid about it?
use Time::CTime;
my $today = strftime("%m/%d/%y", localtime(time()));
* doesn't invoke an external binary
* doesn't make implicit assumptions about the operating system it's running on
* doesn't make assumptions about the command syntax of an external program
* doesn't let some sneaky cracker slip a trojan binary called 'date' in
your path
Need I go on?
Your technique is fine for a quick hack, on a machine you are certain (heh!)
is secure. However, if you use perl as if it's bash, don't be surprised when
you get the performance of bash and the portability of bash and the security
of bash.
>Isn't one of the tenets of Perl programming supposed to be laziness?
Yes, but not _that_ kind of laziness.
-- Charlie
Felix von Leitner
> Let me share with you some of the gems I have found (actual variable
> names have been changed to protect the guilty):
> 1. $today=`date "+%m/%d/%y"`;
A friend of mine recently did something he called "incremental
programming". It started kind of like this:
$bla=`cat data|sed 's/ \+\$//'|awk -F: {print $5}`;
You don't want to know the rest of it.
Felix
Abigail
MCMXCIII in <URL:news:jc254.9...@newton.newton.cam.ac.uk>:
++ mu...@sidehack.sat.gweep.net (Josh Brandt) writes:
++ >Jonathan H N Chin <jc...@newton.cam.ac.uk> wrote:
++
++
++ >Well, among other things, it's slow, insecure, and redundant.
++
++ Redundant? How so? I wrote previously:
++
++ |>It is one concise line of source. It is simple to understand.
++
++ Show me a similarly simple one-liner Perl equivalent.
$today = do {local $" = "/"; "@{[(localtime)[3..5]]}\n"};
$today = (join q q/q => (localtime) [3, 4, 5]) . "\n";
Abigail
Charlie Stross
<abi...@fnx.com> wrote:
>++ Show me a similarly simple one-liner Perl equivalent.
>
>
> $today = do {local $" = "/"; "@{[(localtime)[3..5]]}\n"};
>
> $today = (join q q/q => (localtime) [3, 4, 5]) . "\n";
Ahem.
Evidently time_t is not your friend today[1].
-- Charlie
[1] see below ...
[charlie@public /tmp]$ date '+%d/%m/%y'
19/11/98
[charlie@public /tmp]$ perl -e 0 -d
Loading DB routines from perl5db.pl version 1.0401
Emacs support available.
Enter h or `h h' for help.
main::(-e:1): 0
DB<1> $today = (join q q/q => (localtime) [3, 4, 5]) . "\n";
DB<2> print $today
19/10/98
Jonathan H N Chin
>++ >>>> 1. $today=`date "+%m/%d/%y"`;
>++ |>It is one concise line of source. It is simple to understand.
>++ Show me a similarly simple one-liner Perl equivalent.
> $today = do {local $" = "/"; "@{[(localtime)[3..5]]}\n"};
> $today = (join q q/q => (localtime) [3, 4, 5]) . "\n";
Neither is as simple to understand `at a glance' as the initial line.
Neither even produces equivalent output to the initial line, even if
you re-order the slice.
If your examples are so simple, how did the errors creep in so easily?
So you have failed. Oh the embarrassment!
My two line attempt had an obiwan error too, but I don't claim to be
able to program Perl especially competently.
For simplicity and clarity, not to mention flexibility, strftime(3),
however one invokes it, is still the way to go.
-jonathan
PS. AFICT, the `Time::CTime' someone mentioned is not part of the Perl5
distribution. Neither is it mentioned in `Programming Perl', nor even
in the more recent `Perl Cookbook'. And anyway, it was just used as
yet another way to call strftime(3).
Peter da Silva
>> This is an example of why I like <UI> more than perl. In <UI> if you want it
>> to run a shell, you call "sh -c" explicitly.
>Yes, but perl can usually make that decision for you. You just tell it
>what to do, and it (tries to) figure out the proper way to do it.
If I'm writing code that's going to be exposed to hostile fingers, I want
to tell the fucker what to do and have it get out of my bloody way and just
do what I say. I don't trust Perl. It's got WAY too much gratuitous cute
crap to be exposed, the way it is, in CGI and the equivalent.
</rant>
Peter da Silva
Dave Brown <dagb...@csclub.uwaterloo.ca> wrote:
>In article <72v3bd$n...@web.nmti.com>,
>: >: >> 1. $today=`date "+%m/%d/%y"`;
>: >It spawns two processes: /bin/sh and date.
>: Why does it spawn /bin/sh?
>man 2 system.
man 3 system
man 2 fork
man 2 pipe
man 2 exec
Charlie Stross
the supplicant <jc...@newton.cam.ac.uk> implored:
>PS. AFICT, the `Time::CTime' someone mentioned is not part of the Perl5
> distribution. Neither is it mentioned in `Programming Perl', nor even
> in the more recent `Perl Cookbook'. And anyway, it was just used as
> yet another way to call strftime(3).
CPAN is your friend.
If you don't know about CPAN you are doomed to keep on reinventing wheels.
-- Charlie
Seagull
:
: $today = do {local $" = "/"; "@{[(localtime)[3..5]]}\n"};
:
: $today = (join q q/q => (localtime) [3, 4, 5]) . "\n";
Won't work. Month has the range 0-11. :( You need two lines to
increment the month by one and leave the others alone.
Seagull
:
: I'll have to agree with you here. It looked to me rather like
: beginner-level Perl, the sort of code one writes just after starting
: to learn the language.
Which would be a valid excuse if it were true. :) This code was not
written by a beginner.
Ben Coleman
>I forget who said that one should expect to write a program three times.
Bill Gates?
Ben
--
Ben Coleman NJ8J http://bcoleman.home.mindspring.com/
"I think the US Government has been going about this all wrong. It's not
the DoJ that needs to investigate Microsoft; this is a job for the DEA."
Anthony DeBoer
Peter da Silva
>concise ("readable") than any of these forms. Please show me it.
clock format [clock seconds] -format "%d/%m/%y"
Seagull
:
: One simple, easy to understand line is virtually guaranteed to be more
: simple and more easy to understand than a whole bunch of simple, easy
: to understand lines. I am not saying obfuscate to achieve shortness.
: Short code is less effort to read because there is less of it.
: Why is this hard to understand?
Who said I couldn't understnad you? My point is only that simple code
isn't always one-line code. And good code isn't always one-line code.
Calling a shell unnecessarily is not good code. Simple, maybe. Good,
no way.
: It takes longer and more effort to read four lines than to read one.
: If something can be expressed *simply* in one line, why use four?
: I find it very hard to believe you consider the quoted example to not
: "make sense at first glance".
I never said it didn't make sense. What I said is that the code
sucks. By your argument, it's okay to spawn a shell when the code is a
lot easier than doing it in Perl. So why bother writing in Perl in
the first place? Let's just say:
@results= `grep $pattern $filename`;
because it's "easier to read" and "one line". You certianly can't do
the above in native Perl in one line. Obviously the above must be
"better", right? Right?
: Not lazy. Perhaps naive.
Lazy. If you don't take the time to do it native when a reasonable native
solution exists, and you take the easy way out, it's lazy. Definitely
naive.
: You're not laughing, true. You are sneering and insulting.
The last I knew, this was ASR. Sneering and insulting are part of the
newsgroup culture.
But I also have to support this crappy code and fix it when it breaks.
The `date` call wasn't the onlt example I provided, you know. And we
_do_ send the Perl police after people who write code that is so
woefully inefficient that it causes _noticeable_ performance problems
on the machine. Like, say, sucking the contents of a 100+ MB file into
an array. Don't laugh: I've seen people write code like this, too, and
then wonmder why their machine starts swapping.
: Not stupid either. If CPU efficiency is such an issue, why program in
: Perl in the first place? It is inherently slower than assembly or even C
: (although it is getting better).
You can do the same stupid things in C that you do in Perl. The point
isn't high efficiency, but _reasonable_ efficiency. We shouldn't
waste CPU if we can help it, but a couple cycles here and there won't
kill you (unless that job is running on 1000 machines several times a
day...oops). However, we shouldn't suck all available CPU out of the
system, either, just because you can't write reasonable code. You are
right: saying `date` isn't going to be painful, but other commands
might, especially if they get enclosed in a loop. Believe me: I have
seen it, and it makes you want to tear your hair out.
: But apparently your two (four?) line implementation is much more clear and
: concise ("readable") than any of these forms. Please show me it.
I was speaking hypothetically: one line is not always better than three
or four. I can't give you an example for this particular form of date
because strftime is the way to go, and it can do it clearly in one line,
and is musch better than calling `date` (even you can see that). But
when is more than one line better? When you need to do more than one
thing with the result:
($day, $mon, $year)= (localtime)[3..5];
$today= join ('/', ++$mon, $day, $year);
I still have $today as before, but now I also know each component of
the date, too, and can use that later on.
Seagull
:
: If I'm writing code that's going to be exposed to hostile fingers, I want
: to tell the fucker what to do and have it get out of my bloody way and just
: do what I say. I don't trust Perl. It's got WAY too much gratuitous cute
: crap to be exposed, the way it is, in CGI and the equivalent.
Perl is kinda funky that way, isn't it? Fortunately, using the list
form of system or exec will give you precise control of what happens on
an external process. Combine that with $ENV{PATH} and the -T option,
and you can keep Perl under reasonably tight reigns.
Peter da Silva
Abigail <abi...@fnx.com> wrote:
>Because there's a space in `date "+%m/%d/%y"`. Perl *needs* the shell to
>do interpolation, splitting things up into parameters, etc.
Why?
Jonathan Guthrie
> On 18 Nov 98 20:15:01 GMT, Jonathan H N Chin wrote:
>>I forget who said that one should expect to write a program three times.
> Bill Gates?
No. I believe that the idea in question comes from _The Mythical Man-Month_ by Fred
Brooks. The actual quote is, "Plan to throw one away, you will anyhow."
Sean McAfee
>: $today = do {local $" = "/"; "@{[(localtime)[3..5]]}\n"};
>: $today = (join q q/q => (localtime) [3, 4, 5]) . "\n";
>Won't work. Month has the range 0-11. :( You need two lines to
>increment the month by one and leave the others alone.
Not quite...
$today = (join q q/q => sub { $_[1]++; @_ } -> ((localtime) [3, 4, 5])) . "\n";
--
Sean McAfee | GS d->-- s+++: a26 C++ US+++$ P+++ L++ E- W+ N++ |
| K w--- O? M V-- PS+ PE Y+ PGP?>++ t+() 5++ X+ R+ | mcafee@
| tv+ b++ DI++ D+ G e++>++++ h- r y+>++** | umich.edu
Erik
cha...@antipope.org (Charlie Stross) writes:
> use Time::CTime;
> my $today = strftime("%m/%d/%y", localtime(time()));
Too long.
my $today = strftime("%m/%d/%y",localtime);
works just as well.
And the stupid thing STILL has a y2k problem.
--
Erik Nielsen, Cyberhighway Internet Services NOC
When you need a helpline for breakfast cereals, it's time to start thinking
about tearing down civilisation and giving the ants a go.
-- Chris King in a.s.r.
John Stott
>On 18 Nov 98 20:15:01 GMT, Jonathan H N Chin wrote:
>
>>I forget who said that one should expect to write a program three times.
>
>Bill Gates?
Fred Brooks warns of the dangers of the second attempt to write an OS,
and advises hiring people who have done two already.
Daniel R Barlow
christian mock <c...@tahina.priv.at> wrote:
>It's bad when you run across something like:
>
>require 'cgi-lib.pl'; # cgi-lib.pl installed in the cgi-bin directory
You could stop right there, in fact. That statement holds without
seeing the rest of the post.
-dan
Steve Willoughby
>>concise ("readable") than any of these forms. Please show me it.
>clock format [clock seconds] -format "%d/%m/%y"
Hey, no fair gloating with Tcl in a discussion about Perl lusers :) I teach
Perl programming (how did I get roped into that one?) at work, and several
times during the classes as I'm explaining some of Perl's inane bits of
syntax I have to resist the urge to say how much cleaner and clearer Tcl
could render the same thing. Of course, there are bits of Perl which are
arguably easier/cuter than Tcl, but YMMV as always.
I'd say more, but that would probably just start a holy war. Actually, maybe
that would be fun...
--
Steve Willoughby * Intel PMD | Gouge my eyes with shards of glass, Impale me
st...@ichips.intel.com | once or twice, No torture could indeed be worse,
Unix Systems Administration | Than songs from Girls of Spice.
and Security | -- Moonshadow of Ragnarok
Seagull
:
: Not quite...
:
: $today= (join q q/q => sub { $_[1]++; @_ } -> ((localtime) [3, 4, 5])) . "\n";
^^^^
I dunno if using a ; counts as one line. :) And I'll let _you_
support this code. :)
christian mock
> : open(F, $file); # what about ||die ?
>
> Yeah right, "die" in a CGI. Ha! "Server Error" anyone?
well, OK, usually with my scripts it goes
open(F, $file) || &bailout("open $file: $!");
and actually, "sub bailout" is one of the first things I write in all
my CGIs[0], and, surprise, it wraps the message in HTML and exits.
cm.
[0] code reuse? WTF do you mean by "code reuse"? like I did have time
to design something and not just hack along when I did lotsa silly
little CGIs.
--
christian mock @ home in vienna, austria
sind fremdcancels strafbar? -> http://www.tahina.priv.at/bincancel/
Those silly RFCs are all that separate us from the animals!
-- Kevin Rodgers in a.r.e
christian mock
Abigail <abi...@fnx.com> wrote:
> But that still has all the signs of "I don't know Perl".
[...]
> What's that '%' there doing?
ummm, gotta run my perl-related posts thru "perl -cw" in the future...
ciao,
cm.
Nix
> Nik Clayton (n...@nothing-going-on.demon.co.uk) wrote:
>
> : (I believe) as the author of yngrk2ugzy. I've never seen the code for
> : yngrk2ugzy, and I'm prepared to believe it's a shining work of genius.
>
> It is very very messy. But it works, which is the main evaluation criteria.
I have never been able to get it to work. On *any* system.
The damn thing can't even HTMLise its own manual.
Buggy/brittle as hell, IMHO.
obGrumble: flu. argh argh kill evil influenza viruses. Kill all.
--
`Of course, most of us aren't using Fujitsu Eagles anymore, so we
don't really need to optimize this case.' - Mitchell Blank Jr., on
linux-kernel
Christian Bauernfeind
Is this drifting towards the Godel Escher Bach thread?
Testing tools by turning them onto themselves?
Let's see:
gcc - check
perl - might be interesting
emacs - I don't doubt it for a second[1]
Any more?[2]
Christian
[1] What does TECO do in TECO?
[2] On a slightly broader scale, Unix was self-hosting within a few years.
Anybody got an idea what the Redmond Abomination is built on?
--
Christian Bauernfeind
Not speaking for Siemens
Not even working for IBM
e-mail: v2ba...@fishkill.ibm.com
Christian Bauernfeind
This is the "Second System Effect" and his other important statement
besides "Build one to throw away".
Interesting contradiction until you realize that he counts the prototype
to be thrown away as zero. The first system is the one he wants.
The second is the one that we always end up with.
The third one is a rare gem indeed, since we spent all our development
funds on marketing the second system, and besides, who would want it
anyway when we can just bump up the version number by several dozen
and sell it again to everybody who bought the first five incarnations.
... my take on TMMM. YMMV
Christian
Nik Clayton
>Nik Clayton (n...@nothing-going-on.demon.co.uk) wrote:
>
>: (I believe) as the author of yngrk2ugzy. I've never seen the code for
>: yngrk2ugzy, and I'm prepared to believe it's a shining work of genius.
>
>It is very very messy. But it works, which is the main evaluation criteria.
>
>: Perl 5 idioms in the same programs (sometimes within the same statement)
>
>That's for a good reason actually. At the time, perl 4 was still the
>standard version. We had only just installed perl5, and Avxbf Qenxbf was
>really trying hard to learn the new stuff. Also, at the point we handed
>the code over to you (I assume you are talking about "Meta"), Avxbf was
>in the middle of a rewrite. Heh, Meta was _always_ in the middle of a
>rewrite. Later, a newer cow-orker rewrote the code in a more modular
>manner, totally using libraries (use MPN::Meta).
I'm thinking of the user management stuff. Although whoever decided to
use CSV files should have been shot as well.
>Avxbf never was a good programmer, but he's a better programmer than a lot
>of people I've seen.
I've always wondered how much the pointy hairs actually paid for that code.
>: or the casual disregard for such fundamentals as "race conditions and
>: how to avoid them".
>
>That (also) was his lack of experience, and (partially) design. He grew up on
>a LISP engine with minimal Unix experience. He hacked out perl code assuming
>single user. So the "design" phase said "we only run our own code, or
>trusted other code. No lusers have interactive access so most security
>race conditions are ignorable." The biggest race condition left in the
>code was then CSV file locking. Which broke occasionally.
Just to keep the audience up to speed, we are here talking about a
user registration system for a pretty busy web site that wrote user
registration to one flat CSV file. It didn't try and do locking (advisory
or otherwise) before trying to write to this file.
Every now and then two (or more) people would try and register at the same
time.
>Heh, the spec
>was for a 100->1000 entries. They reached 100,000 before breaking, so don't
>bitch too much :-)
Not at I^3. It went to about 45,000 or so users before my rewrite kicked
in. I was quite proud of that. Properly designed, properly documented,
properly OO, lots of reusable components which should now be finding their
way onto CPAN, and it was a seamless transition when we went from one
backend database format to another (I had to change ~ 30 lines in ~ 6000
as I recall).
>Of course, we now have "use MPN::Lock" to solve this :-)
There should be a ::Mutex object on CPAN from me about now (or soon anyway).
>PS: will we see you at ASRlon next month?
Possibly. If the organiser would care to mail me details, since I managed
to miss the announcement, I'd be grateful.
Any monks going to the FreeBSD UK gathering in Oxford this Saturday? More
details at <URL:http://www.originative.co.uk/FreeBSD.htm>.
N
--
C.R.F. Consulting -- we're run to make me richer. . .
Nik Clayton
>
>In article <slrn756lf...@catkin.nothing-going-on.org>, n...@nothing-going-on.demon.co.uk writes:
>> I'm not sure which concerned me more. The gratuitous use of Perl 4 and
>> Perl 5 idioms in the same programs (sometimes within the same statement)
>> how to avoid them".
>
Yes. It is to my shame that I volunteered to help with coding Majordomo 2,
got quite into it, then suddenly found my free time massively curtailed.
Stephen Harris
: I'm thinking of the user management stuff. Although whoever decided to
: use CSV files should have been shot as well.
That was me, for another very very excellent reason. The database was
_append_ only, by design! We had it in writing from your ex-boss that this
database was just to be used to register people. Updates were not needed.
Now, I happen to believe that a CSV file is the simplest method of storing
append-only (and read, of course) data.
Of course, Avxbf didn't understand CSV files properly, so his code to try
and extract a row based on column search criteria was utterly messy. And
when he went to a dozen different CSV files for different authentication
areas, trying to keep those in sync... well, I just gave up. He was the
programmer, after all :-)
Remember, at this time there was no light-weight database that I would have
trusted and that you guys could have afforded (Postgres too slow, msql not
reliable over a crash) and you couldn't afford Oracle at that time ;-)
I still use CSV files for this sort of thing, on _small_ sites.
: >Avxbf never was a good programmer, but he's a better programmer than a lot
: >of people I've seen.
: I've always wondered how much the pointy hairs actually paid for that code.
They didn't pay anywhere near what they should have done. Your ex-boss
tried to weasel out of the contract. We almost sued and had you shut down,
but "company re-organisations" meant that a new PHB at our end just wanted
to wash his hands of it, so you survived...
: user registration system for a pretty busy web site that wrote user
: registration to one flat CSV file. It didn't try and do locking (advisory
See above. Also remember, even your ex-boss (with all the wonderful plans
she had) didn't expect registrations to get that high...
: or otherwise) before trying to write to this file.
Well, 2 days after the first collision, he added a wrapper call to
procmail's lock routines... as I said, inexperience. heh, this is the
same guy that setup his own workstation (with dodgy SIMMS) to be the NIS+
and main NFS server. My first year was spent making the _servers_ be the
servers :-)
: >was for a 100->1000 entries. They reached 100,000 before breaking, so don't
: >bitch too much :-)
: Not at I^3. It went to about 45,000 or so users before my rewrite kicked
The code scaled to 100K, because we tested it at that after the first few
collissions...
: in. I was quite proud of that. Properly designed, properly documented,
: properly OO, lots of reusable components which should now be finding their
Hahaha. OO perl. Yeah, right. Perl 5's OOness can be, at best, called
wannabe.
: way onto CPAN, and it was a seamless transition when we went from one
: backend database format to another (I had to change ~ 30 lines in ~ 6000
: as I recall).
One thing I did teach Avxbf - modularise your code... He didn't quite
get it, mixing global, local, pass-by-reference, pass-by-value and really
wierd stuff all that the same time, but the "database" backend was
sufficiently seperate.
: Possibly. If the organiser would care to mail me details, since I managed
: to miss the announcement, I'd be grateful.
Not fixed yet, but prob Thu 3 (maybe Wed 2) at Prince of Wales, off
Drury Lane.
--
rgds
Stephen
Ben Coleman
>Ben Coleman <bcol...@mindspring.com> wrote:
>> On 18 Nov 98 20:15:01 GMT, Jonathan H N Chin wrote:
>>>I forget who said that one should expect to write a program three times.
>> Bill Gates?
>No. I believe that the idea in question comes from _The Mythical Man-Month_ by Fred
>Brooks. The actual quote is, "Plan to throw one away, you will anyhow."
Not that M$ doesn't have its own version of this(e.g., a Microsoft
product doesn't approach sufficient(for lusers) mediocrity until the
third release).
Peter Corlett
> christian mock (c...@tahina.priv.at) wrote:
>: open(F, $file); # what about ||die ?
> Yeah right, "die" in a CGI. Ha! "Server Error" anyone?
Depends. We had luserboy programmer for a while, and I had the
pleasure of him for a while. I was determined he wasn't going to fsck
up my work, so I did the hard stuff (a server) and handed him a code
fragment for the client (a CGI script).
Code fragment went along the lines of:
# Some stuff
kill `cat $pidfile`, 'HUP' or die "Shouldn't happen: $!";
# More stuff
You may shoot me for the abuse of cat. The process it was signalling
either existed, or the system was fscked, in which case, I *want* a
500 and something in the logs rather than the script plough on
regardless.
"Magically", the code changed to:
kill 'cat $pidfile', 'HUP' or print "Shouldn't happen: $!";
Despite three days of "testing", luserboy didn't notice that the
signal hadn't happened, and the data was stale since the daemon
didn't know it was meant to update it.
It also ploughed through other bits of error trapping, determined to
output any old crap as long as it didn't 500. Shame it usually did
anyway.
You'll be pleased to know that luserboy became one of Maggie's
Millions from that job.
--
Peter Corlett, Moseley, Birmingham, England. Tel. +44 7050 603311
Russell Van Tassell
Erik <e...@cyberhighway.net> wrote:
>In article <slrn7586be....@cs.ed.datacash.com>,
> cha...@antipope.org (Charlie Stross) writes:
>> use Time::CTime;
>> my $today = strftime("%m/%d/%y", localtime(time()));
>
>Too long.
>my $today = strftime("%m/%d/%y",localtime);
>works just as well.
>
>And the stupid thing STILL has a y2k problem.
Where's the Y2K problem? Oops... that might be useful information.
Let's just say that I disagree that the problem exists... as long as
you don't mind offsets, I guess. *smirk*
Ewen McNeill
>Abigail (abi...@fnx.com) wrote:
>: $today = do {local $" = "/"; "@{[(localtime)[3..5]]}\n"};
>:
>: $today = (join q q/q => (localtime) [3, 4, 5]) . "\n";
>
>Won't work. Month has the range 0-11. :( You need two lines to
>increment the month by one and leave the others alone.
$today = do {my @A=(localtime)[3..5]; @A[1]++; local $"="/"; "@A\n"};
At the loss of a little readability, you can even have a 4 digit year:
$today = do {my @A=(localtime)[3..5]; @A[1]++;@A[2]+=1900;local $"="/";"@A\n"};
or
$today = do {local($",@A)=("/",(localtime)[3..5]); @A[1]++;@A[2]+=1900;"@A\n"};
Ewen
--
Ewen McNeill, ew...@naos.co.nz
Rico Jansen
>:
>: Not quite...
>:
>: $today= (join q q/q => sub { $_[1]++; @_ } -> ((localtime) [3, 4, 5])) . "\n";
> ^^^^
>
>I dunno if using a ; counts as one line. :) And I'll let _you_
>support this code. :)
Yup, especially on platform/country combinations where the day abbreviation is 2
letters instead of 3, for example here in the Netherlands they pull that stunt
occasionely.
--
Rico Jansen (ri...@vpro.nl)
http://james.vpro.nl/ James a Webserver in Java.
"You call it untidy, I call it LRU ordered" -- Daniel Barlow
Joseph Zeff
>Like, say, sucking the contents of a 100+ MB file into
>an array. Don't laugh: I've seen people write code like this, too, and
>then wonmder why their machine starts swapping.
Years ago, I worked at a place where BASIC could use disk files as
arrays. The previous mis-programmer had done a bubble-sort on one of
these arrays, swapping elements as needed. Doing this on a 350
element array took an hour. I changed it to a shell-sort on pointers,
rebuilding the array at the end. Three minutes.
------------------------------------------------------------
Joe Zeff Earthlink Network
jo...@earthlink.net Senior Support JOAT
(800) 395-8410
"Computers work in strange and wonderful ways,
their marvels to avoid performing."
------------------------------------------------------------
James Richmond
>
(vast ammounts of stuff deleted)
>
>Perl is *not* some sort of elegant thing. It never has been, and never
>will be. It's accurately described as the Swiss Army Chainsaw of unix
>scripting.
>
>Yes, you can do elegant things with it if you try, but for the most
>part, it's just "a pretty good tool for most jobs". It doesn't and
>*shouldn't* try to be the *best* tool for almost any job, because that's
>impossible.
Yes, perl is a pretty good hammer for a widely varying selection of
thumbs. Or in the case of the unpleasant task I faced yesterday, a pretty
good simulation of the Peneus and Alpheus rivers washing out Augeas'
cattle yards. Unfortunately since I was compensated it doesn't count as
one of my ten labors.
ObRecovery: Going to see King Lear tonight: ahh Shakespeare, bloody
Shakespeare.
Jim
Peter da Silva
>:$today= (join q q/q => sub { $_[1]++; @_ } -> ((localtime) [3, 4, 5])) . "\n";
>I dunno if using a ; counts as one line. :) And I'll let _you_
>support this code. :)
Back when strings were real strings, and not common pointers to read-only
memory, and the 'stringize' operation hadn't been invented. Ken Arnold used
to write C like this:
#define ctl(c) ("^"[1]=('c'),"")
I recall a masterpiece in curses.h with at least five separate assignments
to strings. Well, it worked on the PDP-11.
Peter da Silva
Steve Willoughby <st...@ichips.intel.com> wrote:
>pe...@baileynm.com (Peter da Silva) writes:
>>Jonathan H N Chin <jc...@newton.cam.ac.uk> wrote:
>>>But apparently your two (four?) line implementation is much more clear and
>>>concise ("readable") than any of these forms. Please show me it.
>>clock format [clock seconds] -format "%d/%m/%y"
>Hey, no fair gloating with Tcl in a discussion about Perl lusers :)
I suppose it would be only fair to dig up some stuff my Tcl lusers do.
To be honest, if Perl lost about 90% of the redundant syntax I think I'd
like it quite a lot. But there's damn little chance of THAT happening.
Peter da Silva
Thorfinn <thor...@tertius.net.au> wrote:
>In alt.sysadmin.recovery, on 19 Nov 1998 16:17:16 GMT
>Peter da Silva <pe...@baileynm.com> wrote:
>>In article <72viep$lmf$2...@client3.news.psi.net>,
>>Abigail <abi...@fnx.com> wrote:
>>>Because there's a space in `date "+%m/%d/%y"`. Perl *needs* the shell to
>>>do interpolation, splitting things up into parameters, etc.
>>Why?
>Because, if perl doesn't use the shell to do it, it will be done
>differently to the way people expect.
The way people expect is the wrong thing to do in a perl script.
>Inconsistent interfaces suck.
What does THAT have to do with Perl?
Look, it's more important that the interface be consistent with the local
context than the global one. And if Perl had a syntactic context to be
consistent with the problem would be obvious. As it is Perl is nothing
BUT inconsistent interfaces.
>Yes, you can do elegant things with it if you try, but for the most
>part, it's just "a pretty good tool for most jobs". It doesn't and
>*shouldn't* try to be the *best* tool for almost any job, because that's
>impossible.
And as a result, it's not the best tool for any job at all. Particularly
not the job that seems to be its most popular application, cgi scripting.
If you want to call the shell, then you should parse it a list of "/bin/sh",
"-c", and the command. That way you know what shell is going to be running
the command, too.
jf...@acm.dot.org
> Yes, perl is a pretty good hammer for a widely varying selection of
> thumbs. Or in the case of the unpleasant task I faced yesterday, a pretty
> good simulation of the Peneus
Yow. I parsed that sentence to that point and thought "This is getting
dangerously close to TTTSNBN..." But then I realized that perl just wouldn't
make a very good sex toy[1].
JF
[1] Though I'm sure there's some joke to be made with the fact that the Kama
Sutra is available for the Palm Pilot...
[inf] Sorry for the dual post, but if you got the first you need to fix your
news server.
--
Justin Ferguson "...By the looks of it, this guy couldn't reproduce
jferg AT (acm.org himself if he had an installation wizard."
OR usgs.gov - Andreas Skau in the Scary Devil Monastery
OR umr.edu) Speaking not for ACM, USGS, UMR, CC or anyone but myself.
Desperately Seeking Cluedom
>In article <steve.9...@ichips.intel.com>,
>Steve Willoughby <st...@ichips.intel.com> wrote:
>>pe...@baileynm.com (Peter da Silva) writes:
>>>clock format [clock seconds] -format "%d/%m/%y"
>>Hey, no fair gloating with Tcl in a discussion about Perl lusers :)
>I suppose it would be only fair to dig up some stuff my Tcl lusers do.
python!
*duck-and-run*
honestly, though, if a script wasn't A) really simple, in which case I'd
write it in zsh, or B) set itself up to just *cry out* for a while(<>)
loop, then I'd do it properly and write it in python.
--
"A thing is not necessarily true because a man dies for it."
-- Oscar Wilde
Nik Clayton
In article <732a5s$jff$2...@nebula.mpn.com>, Stephen Harris wrote:
>Nik Clayton (n...@nothing-going-on.demon.co.uk) wrote:
>
>: I'm thinking of the user management stuff. Although whoever decided to
>: use CSV files should have been shot as well.
>
>That was me, for another very very excellent reason. The database was
>_append_ only, by design! We had it in writing from your ex-boss that this
>database was just to be used to register people.
You mean you had a spec? Bastards denied all knowledge of it when I rolled
up my sleeves and went to reimplement it. I spent a good three or four
weeks trying to get everyone around a table to get a spec out before I
started writing new code.
Not that it helped much of course.
A *dbm format would have been nice though. While the database may have
been append only, you needed to read through the first column fairly
frequently.
Ouch. I'd almost forgotten that bit -- the DBM files the webserver used
and the CSV files weren't kept in sync. They weren't even relatively
close together in the code. It was something like
[ code to update dbm files used by webserver ]
. . . lots of other stuff . . .
[ finally update the CSV files as well ]
Of course, if the program died for some reason in between those two points,
you suddenly had users on the site that you didn't know about.
It's not been long enough. I can almost, but not quite, laugh about this.
>Now, I happen to believe that a CSV file is the simplest method of storing
>append-only (and read, of course) data.
I can probably forgive you that Data::Dumper hadn't been written at the
time.
>Of course, Avxbf didn't understand CSV files properly,
?? HTF can you not understand a CSV file? It's the single simplest file
format known to man.
"OK, if you're so smart -- you tell us what colour it should be"
>: >Avxbf never was a good programmer, but he's a better programmer than a lot
>: >of people I've seen.
>
>: I've always wondered how much the pointy hairs actually paid for that code.
>
>They didn't pay anywhere near what they should have done. Your ex-boss
>tried to weasel out of the contract. We almost sued and had you shut down,
>but "company re-organisations" meant that a new PHB at our end just wanted
>to wash his hands of it, so you survived...
I think I started there as that was starting. FWIW, the owner of banton.org
departed much earlier this year. Blabes is back to the US soon (how he
kept calm I'll never know). They've still got a couple of clueful people,
but they're disappearing rapidly.
>: user registration system for a pretty busy web site that wrote user
>: registration to one flat CSV file. It didn't try and do locking (advisory
>
>See above. Also remember, even your ex-boss (with all the wonderful plans
>she had) didn't expect registrations to get that high...
<chortle> I'd never heard them described as 'wonderful' before.
>: or otherwise) before trying to write to this file.
>
>Well, 2 days after the first collision, he added a wrapper call to
>procmail's lock routines... as I said, inexperience. heh, this is the
>same guy that setup his own workstation (with dodgy SIMMS) to be the NIS+
>and main NFS server. My first year was spent making the _servers_ be the
>servers :-)
>
>: >was for a 100->1000 entries. They reached 100,000 before breaking, so don't
>: >bitch too much :-)
>
>: Not at I^3. It went to about 45,000 or so users before my rewrite kicked
>
>The code scaled to 100K, because we tested it at that after the first few
>collissions...
Possibly depending on your definition of 'scaled'. The locking we had
didn't work, which is why I had to rewrite it.
>: in. I was quite proud of that. Properly designed, properly documented,
>: properly OO, lots of reusable components which should now be finding their
>
>Hahaha. OO perl. Yeah, right. Perl 5's OOness can be, at best, called
>wannabe.
Done properly, there's nothing wrong with Perl's OO. You just need to design
it properly. Perl just (IMHO) lets you get away with a bad design longer
than other OO objects, postponing the inevitable rewrite.
>: Possibly. If the organiser would care to mail me details, since I managed
>: to miss the announcement, I'd be grateful.
>
>Not fixed yet, but prob Thu 3 (maybe Wed 2) at Prince of Wales, off
>Drury Lane.
Sounds do-able. Cheers.
Brandon S. Allbery KF8NH
+-----
| Now, if we want to talk about tools of desperation, Expect is about as
| desperate as they get. Just the other day, I had to use Expect to
| send a password to the 'kas' command in AFS. Turns out, on the Solaris
+--->8
Try an Expect script to generate host keys on the fly and generate a srvtab.
| [1] Transarc system programmers could really use a good LARTing or
| two. Instead of providing a -pipe option (like 'uss') for sending
+--->8
I think that might be the fault of the code they "inherited" (ahem) from us.
(Well, editorial "us" --- I wasn't involved, nor was the ECE department.)
| the password by STDIN (which shouldn't be necessary, anyway), they
| give you a nice command line switch called '-password_for_admin'.
+--->8
Not the only command with that particular peculiarity. Great fun considering
that Solaris, being a System V derivative, saves the first 80 characters of
argv[] in the ublock and you can't change them without <UI deleted>.
--
brandon s. allbery [os/2][linux][solaris][japh] all...@kf8nh.apk.net
system administrator [WAY too many hats] all...@ece.cmu.edu
carnegie mellon / electrical and computer engineering KF8NH
Kiss my bits, Billy-boy.
Quentin Stephens
>Jonathan H N Chin (jc...@newton.cam.ac.uk) wrote:
>:
>: >>>> 1. $today=`date "+%m/%d/%y"`;
>:
>: slow != stupid.
>:
>: Show me a similarly simple one-liner Perl equivalent.
>
>What is this obsession with one-liners? Elegant == short?. One line
>== good?
Work == first
qts
Usenet readers please reverse the elements of my given address to get my real one
Seagull
: By proclamation of Peter da Silva <pe...@baileynm.com>:
: >
: >I suppose it would be only fair to dig up some stuff my Tcl lusers do.
:
: python!
:
: *duck-and-run*
Expect!
*duck-and-cover*
Now, if we want to talk about tools of desperation, Expect is about as
desperate as they get. Just the other day, I had to use Expect to
send a password to the 'kas' command in AFS. Turns out, on the Solaris
2.5.1 build of 'kas', that the "password:" prompt won't accept STDIN--
you get a "can't read password from terminal reading password" error.
This made it difficult to, say, make changes to a large number of user
accounts without having to enter the admin password, oh, a couple of
hundred times[1]. The solution was to write a wrapper in Expect.
You know you are dealing with quality software when your only option
is to fool the program into thinking that a real, live person is typing
characters on a keyboard while sitting in front of a terminal. :(
Now _that's_ desperation.
Cheers,
-+JLS
[1] Transarc system programmers could really use a good LARTing or
two. Instead of providing a -pipe option (like 'uss') for sending
the password by STDIN (which shouldn't be necessary, anyway), they
give you a nice command line switch called '-password_for_admin'.
Guess what the argument is? [2]
[2] Security? What's that?
Ryan Tucker
>[1] Though I'm sure there's some joke to be made with the fact that the Kama
> Sutra is available for the Palm Pilot...
I'd ask for UI, but it'd make people keep playing with my Palm III.
People tend to put it down real fast when they see the collection of FAQ's
on board.
Then again, most people just aren't interested in improving their fellatio
skills. -rt
--
Ryan Tucker <rtuck...@ttgcitn.com> http://www.ttgcitn.com/~rtucker/
GSM/VM/Fax: +15157712865 Box 57083, Pleasant Hill IA 50317-0002
"personally, i think revelations is the result of john meeting some local
magic mushrooms and having a good old fashioned metaphysical experience."
Peter da Silva
Desperately Seeking Cluedom <a...@au.edu.usyd.lab.ea> wrote:
>python!
An object-oriented cross between BASIC and COBOL. Joy.
Stephen Harris
: [ This should probably switch to e-mail soon ]
Actually, I've decided to do just that. My latest was far too long, far
too boring for most people here, and would probably send people to sleep...
--
rgds
Stephen
ric
> "Ben Coleman" <bcol...@mindspring.com> wrote:
>
> >On 18 Nov 98 20:15:01 GMT, Jonathan H N Chin wrote:
> >
> >>I forget who said that one should expect to write a program three times.
> >
> >Bill Gates?
>
> Fred Brooks warns of the dangers of the second attempt to write an OS,
> and advises hiring people who have done two already.
naive question:
Isn't NT Cutler's second OS after VAX/VMS?
--
'ric
Joseph Zeff
(Ryan Tucker) wrote:
>Then again, most people just aren't interested in improving their fellatio
>skills. -rt
Gung ernyyl fhpxf, qbrfa'g vg?
Arthur Hagen
In article <36610f25...@news.earthlink.net>, jo...@corp.earthlink.net writes:
> On 21 Nov 1998 02:34:29 GMT, rtucker+f...@katan.ttgcitn.com
> (Ryan Tucker) wrote:
>
> >Then again, most people just aren't interested in improving their fellatio
> >skills. -rt
>
> Gung ernyyl fhpxf, qbrfa'g vg?
Uhm, no. That's the point.
--
*Art
Brandon S. Allbery KF8NH
+-----
| In article <slrn75bro...@noether.geekgirl.depressed.net>,
| Desperately Seeking Cluedom <a...@au.edu.usyd.lab.ea> wrote:
| >python!
|
| An object-oriented cross between BASIC and COBOL. Joy.
You'd prefer VisualAge COBOL?
Jeffrey M. Vinocur
Joseph Zeff <jo...@corp.earthlink.net> wrote:
>On 21 Nov 1998 02:34:29 GMT, rtucker+f...@katan.ttgcitn.com
>(Ryan Tucker) wrote:
>
>>Then again, most people just aren't interested in improving their fellatio
>>skills. -rt
>
>Gung ernyyl fhpxf, qbrfa'g vg?
(Is there anyone who doesn't reflexively toggle rot13? [1])
[1] And no, those of you who can read it without don't count.
I have a feeling that some people here can.
--
Jeff Vinocur : je...@foad.org ::: Kirrily 'Skud' Robert in the Monastary:
"I managed to out-cool even the disgustingly cool people normally found
at the cafe I went to, without trying. I'm assuming it was the IETF
draft I was reading, because nothing else really accounts for it."
Chris Adams
>== good? I would hate to make such a generalization. Code should be
>readable first, and work second. Why? Because unreadable working code
>is useless when the author gets hit by a truck and you have to maintain
>it. Unless you are really looking for super-efficient execution, why
>make life hard on your co-workers?
I have to agree with you on this. Watching the increasingly snarled bits of
Perl flying back here is really making me wonder why people get so religious
about Perl advocacy. In what possible way[1] is any of these lines
$today = do {local $" = "/"; "@{[(localtime)[3..5]]}\n"};
$today = (join q q/q => (localtime) [3, 4, 5]) . "\n";
$today = do {my @A=(localtime)[3..5]; @A[1]++; local $"="/"; "@A\n"};
$today = do {my @A=(localtime)[3..5]; @A[1]++;@A[2]+=1900;local
$"="/";"@A\n"};
$today = do {local($",@A)=("/",(localtime)[3..5]);
@A[1]++;@A[2]+=1900;"@A\n"};
better than, say, COBOL's "ACCEPT today FROM DATE"? I can tell you which one
I'd prefer to have to maintain. Unless anyone is still working over a
teletype or has a typing impediment, I think the time spent on clarity at the
expense of maintainability is a terrific savings versus the time spent fixing
someone's cute trick.
[1] Other than Perl-programmer job security. . .
Alan J Rosenthal
>jc...@newton.cam.ac.uk (Jonathan H N Chin) writes:
>> This must be the `hubris' that Perl programmers are told to strive for.
>> What's stupid about it?
>
>I'll have to agree with you here. It looked to me rather like
>beginner-level Perl, the sort of code one writes just after starting
>to learn the language. As one learns more, one writes more efficient
>and, hopefully, cleaner code. But even with a minimal knowledge of
>Perl, you can write something that *works*, and that has to be the
>primary criteria.
So what you're saying is that Perl is programming for dummies?
void
wrote:
>
>(Is there anyone who doesn't reflexively toggle rot13? [1])
I always forget that my newsreader can do that, so I use the standalone
program included with my operating system.
--
Ben
"You have your mind on computers, it seems."
Peter Corlett
[...]
> So what you're saying is that Perl is programming for dummies?
Maybe so, but there are some really experienced dummies out there. I
have programmers that now refuse to go anywhere near my code. I
haven't even sunk into the depths of double-indirect references and
XSUBs.
--
Peter Corlett, Moseley, Birmingham, England. Tel. +44 7050 603311
Arthur Hagen
> (Is there anyone who doesn't reflexively toggle rot13? [1])
>
> [1] And no, those of you who can read it without don't count.
> I have a feeling that some people here can.
First you learn some common words, like "furrfu", "gung" and "Neg".
Then you know what "fur" and "ur" means too. And you pick up more
common words, and more combinations. After a while you seldom have to
guvax what a letter converts to.
--
*Art
Stephen Harris
: Maybe so, but there are some really experienced dummies out there. I
: have programmers that now refuse to go anywhere near my code. I
To keep to subject...
I worked for a small department of VBC where we did "internet stuff".
Y'know, HTML, CGI, Perl... Next door to us was another department where
they wanted to do internet stuff. So they did HTMl and came to us for
anything better. Now boss of that department[1] went to an Oracle presentation
and learned all about Oracle and Oracle Web Application Server et al. He
made presentation to his boss[2]. Argument: hey, only two people in the
company [3] know perl, whereas we have another department[4] who know oracle,
so we must use oracle on the web. Bwahaahaha.
Years pass... conclusion: No one in department[4] really knows oracle - they
have contractors. Of the people[3] one[5] still works in the whole company
and is best programmer there[6]. My department closed down and now I work
for department[4][5]. Boss[2] moved on. Boss[1] spends all his money on
contractors. Web site down more than it is up. I laugh.
My code works. I could teach any Uni graduate in months (hey, they'd already
know perl!) my methodology CHEAPER than what they pay their consulatants.
I sit back and laugh.
Life can be fine at times :-)
[1] Slightly PHB
[2] Very PHB
[3] Me and cow-orker
[4] Systems. PHB[2] was also in control of this department.
[5] Me
[6] I am not a programmer! I'm a sysadmin!
--
rgds
Stephen
Joe Thompson
jc...@newton.cam.ac.uk (Jonathan H N Chin) wrote:
[on a line of perl that called "date" externally]
> Laying aside the security problem
There's the problem right there. This is why, when my SO said something
about using ICQ or Instant Messenger to talk in real-time, I thwacked her
via e-mail (she's not experienced in issues of open standards, let alone
system administration and security)
*Never* allow your system security to be compromised. At all. Period.
If you know of a security hole in a system, your choices are 1) fix it, 2)
shut off whatever service is providing the hole. "Lay it aside" IS NOT A
FSCKING OPTION IN SECURITY POLICY.
This message has been brought to you by phf and tftpd. -- Joe
--
Joe Thompson | http://kensey.home.mindspring.com/
$spam$@orion-com.com | O- He-Who-Grinds-the-Unworthy
Charlottesville, VA | "I'd like to take this time to formally
thank you for bringing back a lot of bad memories." -- ADB on ASR
Chris Adams
>>about Perl advocacy. In what possible way[1] is any of these lines
>[...snip more than one way to do it...]
>>
>>better than, say, COBOL's "ACCEPT today FROM DATE"? I can tell you which one
>I would think that it's the fact that in COBOL you had to write many
>pages of wordy headers BEFORE you could write the line above, whereas
>with Perl at least you could get to the required statement in a minimal
>amount of typing.
??? I suppose a one-line variable declaration would be many pages if you used
a large enough font size. I'd also note that the added time documenting
things isn't exactly a total waste...
>ObASR: I just remind myself that all systems suck and all languages are
>evil. Apart from that it's just a matter of personal preference.
Yeah - "Which sucks least for what I'm trying to do now?"
Brandon S. Allbery KF8NH
+-----
| Calle Dybedahl <qdt...@esb.ericsson.se> writes:
| >I'll have to agree with you here. It looked to me rather like
| >beginner-level Perl, the sort of code one writes just after starting
| >to learn the language. As one learns more, one writes more efficient
| >and, hopefully, cleaner code. But even with a minimal knowledge of
| >Perl, you can write something that *works*, and that has to be the
| >primary criteria.
|
It can be --- until you run into the BPerlScriptFH. Which you will likely
do rather quickly if you spend any significant time with Perl unless you
code in a cave.