FAQ 4.16: Does Perl have a year 2000 problem? Is Perl Y2K compliant?
fin...@ts.co.nz
> Perl is just as Y2K compliant as your pencil--no more, and no
less.
> Can you use your pencil to write a non-Y2K-compliant memo? Of
> course you can. Is that the pencil's fault? Of course it isn't.
Unfortunately, many of the Y2K problems in Perl applications *is* the
fault of the language.
For those of you wanting to know more about the Perl Y2K booby-trap code
problem, check out:
http://www.y2kinfo.com/journal/features/0499_amona.html
You may also be interested in reading about just how stupidly defensive
many programmers can be on this subject - the Perl newsgroup has
provided some excellent examples for my article which can be accessed at
URL:
http://www.y2kinfo.com/journal/features/0599_amon.html
I was informed that Perl wasn't used for anything critical anyway and
that the worst that can be expected is a year value of 19100 instead of
2000 on a web page, unlike C and Java which are used for more important
applications. Because of this I had stopped debating this issue on the
Perl newsgroup so havn't posted anything since last year. However,
the arguments are still raging and it seems that some programmers are
using Perl for more important functions.
Unfortunately, C and Java also have the Y2K booby-trap problem.
Jocelyn Amon
--
Financial Solutions Limited
http://www.ts.co.nz/~finsol/
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
Uri Guttman
>> Perl is just as Y2K compliant as your pencil--no more, and no
f> less.
>> Can you use your pencil to write a non-Y2K-compliant memo? Of
>> course you can. Is that the pencil's fault? Of course it isn't.
f> Unfortunately, many of the Y2K problems in Perl applications *is* the
f> fault of the language.
perl has nothing to do with it. it is defined by the struct tm in the
libc library. perl just follows that convention. if you can't read the
man pages, get out of the programming pool.
you don't get the separation of the language from the application do
you? the language can't be not y2k compliant since it just returns a
well defined value for the year which can be properly converted to a 4
digit year. the application (written by an idiot) is broken. so stop
spreading fud about this.
f> http://www.y2kinfo.com/journal/features/0499_amona.html
your article is useless. it mentions tutorials which are mostly
crap. there is no booby trap, only booby programmers. the year value is
correctly documents in the libc man pages where you should be reading if
you use that localtime function.
f> You may also be interested in reading about just how stupidly defensive
f> many programmers can be on this subject - the Perl newsgroup has
f> provided some excellent examples for my article which can be accessed at
f> URL:
f> http://www.y2kinfo.com/journal/features/0599_amon.html
stay in new zealand. your fud is more helpful there. your examples are
not even real quotes, just your edited fud.
f> I was informed that Perl wasn't used for anything critical anyway and
f> that the worst that can be expected is a year value of 19100 instead of
f> 2000 on a web page, unlike C and Java which are used for more important
f> applications. Because of this I had stopped debating this issue on the
f> Perl newsgroup so havn't posted anything since last year. However,
f> the arguments are still raging and it seems that some programmers are
f> using Perl for more important functions.
perl is used for many critical projects and the y2k nature is dependent
on the programmer, not the language. don't you get that? this is not
shuffling the blame but understanding the cause. you flame about elitism
but that is the issue. those who rtfm grok the year value. those who
don't are doomed by y2k.
i hope you are not using perl for anything since that would ruin my
sense of elitism. if you can use my language than either it is too easy
for you or i am not that much a better programmer. since i know you
don't understand y2k at all and i do, it must be you don't use perl
which is fine with me. so stay out of this newsgroup and spread fun in
some redmondware group where that practice is allowed.
f> Unfortunately, C and Java also have the Y2K booby-trap problem.
so doeas every language that use c like libraries. so does any language
with a moron using it (like most newbies out there). so do you. so does
everyone. y2k is as much a human problem as a programming problem.
f> --== Sent via Deja.com http://www.deja.com/ ==--
f> ---Share what you know. Learn what you don't.---
well you didn't share what you know. you just showed us what you don't.
uri
--
Uri Guttman ----------------- SYStems ARCHitecture and Software Engineering
u...@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
Tom Christiansen
Cursed by that miserable piece of crap, Mozilla/4.05 [en] (Win95; I),
fin...@ts.co.nz writes in comp.lang.perl.misc:
In comp.lang.perl.misc, fin...@ts.co.nz writes:
:
:> Perl is just as Y2K compliant as your pencil--no more, and no
:less. [YOUR NEWSREADER MISWRAPPED THIS. STOP IT!]
:> Can you use your pencil to write a non-Y2K-compliant memo? Of
:> course you can. Is that the pencil's fault? Of course it isn't.
:
:Unfortunately, many of the Y2K problems in Perl applications *is* the
:fault of the language.
Oh great -- I've got deja lu, and get to read about Fear and Ugliness and
Deception for the second time. Either your newsreader, your newsserver,
or your wetware is broken. Or some combination of these.
You appear to have accidentally re-posted the same article more than once.
If this was intentional, I don't know why you did that. If it wasn't
intentional, this was probably because of a bug in the news posting
software. Web browsers masquerading as lame excuses for real newsreaders
are notoriously bad in the area. Netscape 2.0 had claimed to have fixed
it, but folks continued to see problems from it, and further fixes were
applied for the 3.0 version. If you used Netscape to post this article
and it was version 3.0 or later, I suggest you report the bug to them.
Otherwise, I would try to get that version. While using an "internet
browser" as though it were a newsreader is a lose-lose siutation, Netscape
has done far more right than any other browser, especially lately.
In the best of all possible worlds, I would urge you to contact the
author or vendor of the software you used to post your message and
explain to them that they're sending out duplicate messages. If I knew
their email address, I would even do it myself. I surely hope you paid
no money for this thing.
You may well wish to cancel your spurious extra posting(s). If you
don't know how to do this, you shouldn't be using Usenet at all.
--tom
--
X-Windows: The Cutting Edge of Obsolescence.
--Jamie Zawinski
Tom Christiansen
In comp.lang.perl.misc, Uri Guttman <u...@sysarch.com> writes:
:perl has nothing to do with it. it is defined by the struct tm in the
:libc library. perl just follows that convention. if you can't read the
:man pages, get out of the programming pool.
She obviously can't. She calls "CGI" a programming language. And she
reposts duplicate articles -- see her duplicate posting for my reply.
And she uses MS-HTML, which is illegal from the point of view of any
standards body. I call that three strikes.
She's a FUD monger, although this time it's not just Fear, Uncertainty,
and Doubt -- it's also Fear, Ugliness, and Deception.
--tom
--
"If Dennis Ritchie were the man who developed Modula-2 then C would be long forgotten."
--Tarjei Jensen
Ilya Zakharevich
<u...@sysarch.com>],
who wrote in article <x7btfc7...@home.sysarch.com>:
> f> Unfortunately, many of the Y2K problems in Perl applications *is* the
> f> fault of the language.
>
> libc library. perl just follows that convention.
Perl decided to follow a stupid convention, thus Perl has everything
to do with the fact that the year-return of Perl's localtime has a
brain-dead semantic.
> there is no booby trap, only booby programmers.
Get real! Suppose that localtime() were called s6s5a45fa54f(), and
dump() was called s6s5e45fa54f(). Would not you call such a language
booby-trapped?
I did not read the "critique" you are refering to, but a fact is a
fact: there is no legal usage of $y = (localtime)[5] except as
$y % 100;
and
1900 + $y;
Having localtime() return 1900 + $y would save *a lot* of frustration,
since it is much harder to get *false expectations* how one can use
$y. Quoting Larry, "that's linguistic" in designing programming
languages.
Humans *are* fallible, and one tells good programming languages from
bad programming (or scripting) languages by how much attention they
pay to the fact that programmers are humans. Some sides of Perl are
quite good in this regard. Some other sides of Perl are abyssmal in
this regard. Deciding on which side (localtime)[5] is left as an
exersize to the reader.
Hope this helps,
Ilya
fin...@ts.co.nz
tch...@mox.perl.com (Tom Christiansen) wrote:
> [courtesy cc of this posting mailed to cited author]
>
Tom
I don't know why deja news decided to post twice but I must have you
riled - you come across like a techno-crazed twit! Are you so besotted
with Perl that you will clutch at any straw to defend it - even by
attempting to descredit me by attacking my choice in newsgroup
technology? Come on, Perl is just another programming language - time
you got in touch with the real world.
Jocelyn Amon
--
Financial Solutions Limited
http://www.ts.co.nz/~finsol/
--== Sent via Deja.com http://www.deja.com/ ==--
Uri Guttman
IZ> [A complimentary Cc of this posting was sent to Uri Guttman
IZ> <u...@sysarch.com>],
IZ> who wrote in article <x7btfc7...@home.sysarch.com>:
f> Unfortunately, many of the Y2K problems in Perl applications *is* the
f> fault of the language.
>>
>> perl has nothing to do with it. it is defined by the struct tm in the
>> libc library. perl just follows that convention.
IZ> Perl decided to follow a stupid convention, thus Perl has everything
IZ> to do with the fact that the year-return of Perl's localtime has a
IZ> brain-dead semantic.
but it is a known convention which is not y2k buggy. rtfm is still
important whenever you use any library call. localtime is a fairly
complex call regarding the return data. assuming year means what you
would like is stupid. is sunday 0 or 1, is the minth number 1 or 0
based. those are the same as the year being offset by 1900.
>> there is no booby trap, only booby programmers.
IZ> Get real! Suppose that localtime() were called s6s5a45fa54f(), and
IZ> dump() was called s6s5e45fa54f(). Would not you call such a language
IZ> booby-trapped?
no, only something a language mother could love. :-)
and perl has local which is as bad a name as yours!
IZ> I did not read the "critique" you are refering to, but a fact is a
IZ> fact: there is no legal usage of $y = (localtime)[5] except as
IZ> $y % 100;
IZ> and
IZ> 1900 + $y;
and $y is perfectly fine if you want a value offset by 1900. it could be
modified later as long as that is known.
IZ> Having localtime() return 1900 + $y would save *a lot* of frustration,
IZ> since it is much harder to get *false expectations* how one can use
IZ> $y. Quoting Larry, "that's linguistic" in designing programming
IZ> languages.
so write your own module and overload localtime. be our guest. i write
subs to read/write a file for me. if i write a sub to handle a call to
localtime i woul ddo what is needed. if i did it a lot i would make a
module. that is what an api is, it is. nothing more, nothing less. if it
has the functionalilty you want but not the interface, then you write
your own interface. what do you think x widgets and perl/tk is? just a
better api over a fixed and obscure and dificult api.
IZ> Humans *are* fallible, and one tells good programming languages from
IZ> bad programming (or scripting) languages by how much attention they
IZ> pay to the fact that programmers are humans. Some sides of Perl are
IZ> quite good in this regard. Some other sides of Perl are abyssmal in
IZ> this regard. Deciding on which side (localtime)[5] is left as an
IZ> exersize to the reader.
not at all. it is well defined and fully functional which is all i want
at a minimum from an api. when you don't have either (like winblows)
then things realy suck. writing a better interface for an existing api
is trivial and not as critical except when it save lots of work like the
widget ones i mentioned. and i am not just refering to layering like
widgets do over x. a proper layered api over localtime would handle the $y at
such a low level it would never matter what localtime returned. the fact
that we call localtime directly and not a module means that api/layer is
not desired by the perl community. if it were then all would be told not
to call localtime but some module. for example i never use socket
directly. i use IO::Socket since it does the connect and ip address
munging in a value added api. i have done that myself in c and i still
use those routines since i use my connect all the time and the low level
socket work is a minor pain. localtime is not as painful.
hope this clears up the api confusion for you. api's EXIST as they
are. you can always write one above it it you don't like it. you just
don't change the lower one from its specification. that is the rule.
hymie!
il...@math.ohio-state.edu (Ilya Zakharevich), who said:
>I did not read the "critique" you are refering to, but a fact is a
>fact: there is no legal usage of $y = (localtime)[5] except as
>
> $y % 100;
>
>and
>
> 1900 + $y;
#!/usr/bin/perl -w
print "Here is my perl script to tell you how many years have passed since\n";
print "1 Jan 1900.\n";
$y = (localtime)[5];
print "\n$y years have passed since 1 Jan 1900.\n";
exit 0;
..hymie! http://www.smart.net/~hymowitz hy...@lactose.smart.net
===============================================================================
I gotta get my life some writers. -- Calvin (Bill Watterson)
===============================================================================
Ilya Zakharevich
who wrote in article <x77lq07...@home.sysarch.com>:
> IZ> Perl decided to follow a stupid convention, thus Perl has everything
> IZ> to do with the fact that the year-return of Perl's localtime has a
> IZ> brain-dead semantic.
>
> but it is a known convention which is not y2k buggy. rtfm is still
> important whenever you use any library call.
rtfm is useless if there is no way to internalize the knowledge, so
that it stays for long. This is why I use a word "stupid". This is a
question of psychology, not logic.
> and perl has local which is as bad a name as yours!
Note also how long did it take to realize that the "correct" name
should be `save' (I do not think I saw it before the last year).
> IZ> I did not read the "critique" you are refering to, but a fact is a
> IZ> fact: there is no legal usage of $y = (localtime)[5] except as
>
> IZ> $y % 100;
>
> IZ> and
>
> IZ> 1900 + $y;
>
> and $y is perfectly fine if you want a value offset by 1900. it could be
^^^^^
> modified later as long as that is known.
No. It *should* be modified later. (The only exception is when you
take a difference of two years, but this will work with a "4-digit"
year without any change.)
> IZ> Having localtime() return 1900 + $y would save *a lot* of frustration,
> IZ> since it is much harder to get *false expectations* how one can use
> IZ> $y. Quoting Larry, "that's linguistic" in designing programming
> IZ> languages.
>
> so write your own module and overload localtime.
Why? I do not think I used (localtime)[5] once in my life. I'm
discussing the *language*. It has some mis-designed sides indeed.
> IZ> Humans *are* fallible, and one tells good programming languages from
> IZ> bad programming (or scripting) languages by how much attention they
> IZ> pay to the fact that programmers are humans. Some sides of Perl are
> IZ> quite good in this regard. Some other sides of Perl are abyssmal in
> IZ> this regard. Deciding on which side (localtime)[5] is left as an
> IZ> exersize to the reader.
>
> not at all. it is well defined and fully functional which is all i want
> at a minimum from an api.
We use Perl, which lifts the treashold a lot. We are not satisfied by
a Turing-completeness, thank you.
> hope this clears up the api confusion for you.
Thank you, *I* have no confusion. *You* had confusions that Perl's
APIs have non faults, and I hope I cleared this for you.
> api's EXIST as they are. you can always write one above it it you
> don't like it. you just don't change the lower one from its
> specification. that is the rule.
If the API is designed well, you do not *need* to change it or work
around it. In fact you not even *wish* to change it. ;-)
Ilya
Blackmo
Geekforming?
Nerdcontrails?
blackmo
Ilya Zakharevich wrote in message
<7i9koj$hpv$1...@mathserv.mps.ohio-state.edu>...
Uri Guttman
IZ> <u...@sysarch.com>],
IZ> who wrote in article <x77lq07...@home.sysarch.com>:
IZ> Why? I do not think I used (localtime)[5] once in my life. I'm
IZ> discussing the *language*. It has some mis-designed sides indeed.
it wasn't a misdesign, but a pass through of an existing and stable design.
IZ> We use Perl, which lifts the treashold a lot. We are not satisfied by
IZ> a Turing-completeness, thank you.
so consider localtime to be a library call (like many of the libc
derived calls) and not part of the language. as you have stated many
time there is no proper definition of Perl so localtime is not specified
but it is dependent on the underlying libc struct tm.
>> hope this clears up the api confusion for you.
IZ> Thank you, *I* have no confusion. *You* had confusions that Perl's
IZ> APIs have non faults, and I hope I cleared this for you.
i never said it had no faults. i said it was well defined in the case of
localtime and it has always been that way. so a stable api is well
defined and that is better than a dynamically moving one that keeps
fixing older and poorer api designs. i will take stable over constant
change any time.
>> api's EXIST as they are. you can always write one above it it you
>> don't like it. you just don't change the lower one from its
>> specification. that is the rule.
IZ> If the API is designed well, you do not *need* to change it or work
IZ> around it. In fact you not even *wish* to change it. ;-)
face reality, ilya. perl's api IS. it exists. it is not pining for the
fjords! it has not met its maker! (larry, perl. perl, larry. now they
have met :-)
you don't go around fixing things which work and many programs depend
upon. fixing localtime will break too many programs and fix only those
which were written by idiots who didn't rtfm.
so either write a wrapper and make it into a module that will save all
our souls or leave it alone. perl itself is y2k compliant as much as
anything it relies upon is compliant. the rest of the time the
programmer is not y2k compliant and they will crash on 1/1/100.
Chris Nandor
# I don't know why deja news decided to post twice but I must have you
# riled - you come across like a techno-crazed twit! Are you so besotted
# with Perl that you will clutch at any straw to defend it - even by
# attempting to descredit me by attacking my choice in newsgroup
# technology? Come on, Perl is just another programming language - time
# you got in touch with the real world.
The bottom line is you are ignorantly attacking the language for working
properly. Perhaps /you/ should get in touch with this "real world" you
speak of. Like that silly bit about taking "years since the year 1900" to
mean "last two digits of the year." There is no way the first can mean
the second. Not in English, anyway.
It is telling that you say "I was informed that Perl wasn't used for
anything critical anyway." I do not mean offense here, but you are
obviously unqualified to be writing articles about this issue if you don't
know what Perl is used for, and your editor/publisher should be taken to
task for letting you write for that publication.
--
Chris Nandor mailto:pu...@pobox.com http://pudge.net/
%PGPKey = ('B76E72AD', [1024, '0824090B CE73CA10 1FF77F13 8180B6B6'])
Sitaram Chamarty
<fin...@ts.co.nz> wrote:
>In article <3747...@cs.colorado.edu>,
> tch...@mox.perl.com (Tom Christiansen) wrote:
I think the lady means "that real world in which "consultants" can
make lots of moolah by spreading unnecessary FUD about Y2K, and
where they (as well as trial lawyers) are panicking at the thought
of NOTHING major happening, and trying their damnedest to make hay
before the sun starts shining again".
>with Perl that you will clutch at any straw to defend it - even by
>attempting to descredit me by attacking my choice in newsgroup
>technology? Come on, Perl is just another programming language - time
Jocelyn: when a "consultant" like you does not know or choose to
use a proper newsreader, and instead uses dejanews/Netscape, Tom
DOES have a point.
I dont know what services you sell, but if I saw a carpenter
trying to use a saw where a chisel is more appropriate, I would
not hire him for anything more than making a bird house. Perhaps
not even that.
It follows therefore, that you are not qualified to pass judgement
or even make comments about that which you do not understand. Oh,
and I notice you still havent fixed your web page to remove the
claim that CGI is a language, thus dooming your reputation in the
eyes of every knowledgeable visitor to your pages.
Tom's tone may offend, but he almost always has a point.
Bill Jones
Chamarty) wrote:
> On Sun, 23 May 1999 04:34:13 GMT, fin...@ts.co.nz
> <fin...@ts.co.nz> wrote:
>>In article <3747...@cs.colorado.edu>,
>> tch...@mox.perl.com (Tom Christiansen) wrote:
>>technology? Come on, Perl is just another programming language - time
>>you got in touch with the real world.
>
<snip>
>
> Tom's tone may offend, but he almost always has a point.
Scary, huh?
-Sneex- :]
______________________________________________________________________
Bill Jones Data Security Specialist http://www.fccj.org/cgi/mail?dss
______________________________________________________________________
We are the CLPM... Lower your standards and surrender your code...
We will add your biological and technological distinctiveness to
our own... Your thoughts will adapt to service us...
...Resistance is futile...
Jacksonville Perl Mongers
http://jacksonville.pm.org
j...@jacksonville.pm.org
fin...@ts.co.nz
pu...@pobox.com (Chris Nandor) wrote:
> In article <7i80g6$kao$1...@nnrp1.deja.com>, fin...@ts.co.nz wrote:
>
> It is telling that you say "I was informed that Perl wasn't used for
> anything critical anyway." I do not mean offense here, but you are
> obviously unqualified to be writing articles about this issue if you
don't
> know what Perl is used for, and your editor/publisher should be taken
to
> task for letting you write for that publication.
>
Of course Perl, like most programming languages, is used for many
types of applications, some critical, some not. I used this as an
example of one the many stupid comments I receive from programmers who
think their limited view of computing, based on their limited
experience, applies to the rest of the world. The comment was from a
Perl programmer and in his limited experience that was true. Many Perl
programmers think the mis-use of localtime is a non-issue
because, based on their limited experience, it does not occur or, if it
does, it cannot cause any problem worthy of consideration.
The frequent raising of this issue by programmers who have only just
discovered this problem would indicate that there are still many who
have yet to discover that the localtime year value in 2000 will be '100'
and not '00' as many have assumed.
A very common way for programmers to learn a programming language,
beyond their first, is to maintain an existing application in that
language and make logical assumptions about instructions based on how
they are used within the code. Right or wrong, that is the reality. If
Perl is your one and only language then you have probably learnt it at
an academic institution and most likely referred to the manual on a
frequent basis.
If I saw localtime used in a program to format and output the value
YYMMDD, I would be unlikely to check the manual just to be sure that YY
was 'years since 1900' and not the last two digits of the year. I would
probably only see a need for this if I was familiar with one of the very
few languages that handle the year value in this way (i.e. C and Java).
Otherwise, I would not have any reason to expect anything but 00 for the
year 2000.
Your ignorance of the potential seriousness of this aspect of
the Y2K problem would indicate that you are unqualified to judge whether
or not I have the qualifications to write on this subject.
fin...@ts.co.nz
> make lots of moolah by spreading unnecessary FUD about Y2K, and
> where they (as well as trial lawyers) are panicking at the thought
> of NOTHING major happening, and trying their damnedest to make hay
> before the sun starts shining again".
>
We computer people don't need Y2K to make money. Many of us Y2K
programmers would rather be doing something a bit more interesting than
looking at badly written bug-riddled code. It is my belief that any
programmer with a conscience should be concentrating on Y2K work -
however boring they might find it. Unfortunately, it doesn't pay any
more money than writing new exciting whizz-bang programs! And we get
less kudos and no ego-boosting feed-back from the users.
> >with Perl that you will clutch at any straw to defend it - even by
> >attempting to descredit me by attacking my choice in newsgroup
> >technology? Come on, Perl is just another programming language - time
>
> Jocelyn: when a "consultant" like you does not know or choose to
> use a proper newsreader, and instead uses dejanews/Netscape, Tom
> DOES have a point.
>
> I dont know what services you sell, but if I saw a carpenter
> trying to use a saw where a chisel is more appropriate, I would
> not hire him for anything more than making a bird house. Perhaps
> not even that.
I have more important things to do than spending my time searching for
the ultimate newsreader. Deja News works just fine for me and,
obviously, for many others.
>
> It follows therefore, that you are not qualified to pass judgement
> or even make comments about that which you do not understand. Oh,
> and I notice you still havent fixed your web page to remove the
> claim that CGI is a language, thus dooming your reputation in the
> eyes of every knowledgeable visitor to your pages.
>
Whether a method of instructing a computer can be deemed a programming
language, scripting language, interface language, job control language
or some other esoteric jargon you would care to name, is a grey area
that I don't wish to debate. The fact is that CGI shares the same Y2K
booby-trap problem as Perl. Fixing Y2K problems is more important than
playing stupid semantics.
Sam Holden
>
>Whether a method of instructing a computer can be deemed a programming
>language, scripting language, interface language, job control language
>or some other esoteric jargon you would care to name, is a grey area
>that I don't wish to debate. The fact is that CGI shares the same Y2K
>booby-trap problem as Perl. Fixing Y2K problems is more important than
>playing stupid semantics.
Perl doesn't have a Y2K booby-trap problem. I guess you mean localtime as
used by people who can't read. In that case how does CGI have one? Care
to name where in the CGI spec you find this Y2K problem? You can;t
because you obviously have no idea what CGI is, since if you did you'd
know it can not possibly have a Y2K problem of the kind you mean.
I guess HTTP has a Y2K problem too. And NNTP, since they are closer to CGI
than perl is.
It would be good to learn something before you make a statement that you
word as 'The fact is that CGI...'.
CGI is not a language. Don't pretend it is. It makes you look stupid.
--
Sam
The very fact that it's possible to write messy programs in Perl is also
what makes it possible to write programs that are cleaner in Perl than
they could ever be in a language that attempts to enforce cleanliness.
--Larry Wall
Tom Christiansen
In comp.lang.perl.misc, fin...@ts.co.nz writes:
:The fact is that CGI shares the same Y2K
:booby-trap problem as Perl.
It's clever statements like this one that obliterate any shred of
credibility you pretend to have. There is no programming language called
"CGI". You're making this all up, and you look ridiculous. Have you
ever bothered to read the *real* CGI spec? You should. This is even
worse than guessing what localtime() does without reading its spec.
Now you posit a complete language that isn't even there.
Now, go away, kid, and learn something before you embarrass yourself
again. Lately you can't even open your mouth but to change feet.
--tom
--
"My mom's been pretty busy lately. Why don't you call my dad?"
- Chelsea Clinton to her School Nurse
fin...@ts.co.nz
tch...@mox.perl.com (Tom Christiansen) wrote:
> [courtesy cc of this posting mailed to cited author]
>
> In comp.lang.perl.misc, fin...@ts.co.nz writes:
> :The fact is that CGI shares the same Y2K
> :booby-trap problem as Perl.
>
> It's clever statements like this one that obliterate any shred of
> credibility you pretend to have. There is no programming language
called
> "CGI". You're making this all up, and you look ridiculous. Have you
> ever bothered to read the *real* CGI spec? You should. This is even
> worse than guessing what localtime() does without reading its spec.
> Now you posit a complete language that isn't even there.
>
> Now, go away, kid, and learn something before you embarrass yourself
> again. Lately you can't even open your mouth but to change feet.
>
> --tom
Tom, thought you may be interested to know that I'm not the only
mis-guided soul using the term "programming language" to describe CGI
for expedience.
Check out these two URL's.
http://www.net-ads.com/development/CGI.html
Using CGI & Perl
CGI, or Common Gateway Interface, is a programming language that allows
webmaster to add various interactive features to their websites,
including search engines, free-4-all links pages, clocks, counters,
bulletin boards and more. Using CGI, it is also possible for webmasters
to manage their own advertising inventory by rotating and tracking
banner adviews ...
http://www.itknowledge.com/reference/dir.programminglanguages.perlandcgi
.html
Programming Languages: Perl & CGI
CGI Developers Guide
This book is one of the first books to provide comprehensive information
on developing with CGI (Common Gateway Interface). It covers many of the
aspects of CGI including, interactivity, performance, portability, and
security. After reading this book, the reader will be able to write
robust, secure, and efficient CGI programs.
CGI Manual of Style
CGI is the programming language that allows for accountability on the
Web. This book will help programmers learn the fundamentals behind CGI -
showing how to program the included samples, what to watch out for, and
how to achieve effective scripting. Progressing from easy samples to
more advanced, this book provides users with the skills they need to
provide accountability on their Web site.
Special Edition Using Perl 5 for Web
Programming
With a review by Tom Christiansen ...
Hey, you're famous - this page references your very own self! Perhaps
you need to re-educate these poor folks as well. I'm sure the world will
be a better place once you have eradicated this most serious of
transgressions.
You efforts to educate me in the correct means of using news groups and
the terminology that should be used is, I'm sure, of a greater
importance to the computing world than Y2K awareness.
BTW, while you're checking out URL's, how does the Perl code at these
sites look to you? It doesn't look kosher to me but then I don't claim
to be a Perl expert.
www.hollycole.com/WWWboard/wwwboard.html
# get information
local($string) = @_;
($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) =
localtime(time);
# calculate useful values
$cent = ($year < 70) ? 20 : 19;
$lyear = $year + $cent*100;
http://www2s.biglobe.ne.jp/~j_okada/free_cgi/j_diary/regist.txt
if ($year > 97) { $year = "19$year"; }
else { $year = "20$year"; }
if (!open (DB, "$data_dir/$year$mon\.dat")) {
http://www.linguistic-funland.com/scripts/RemindMe/remindmecgi.txt
if($data{'Year'} eq "Not Selected"){
($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst)=localtime(time);
if($year !~ /0/){
$form_year = "19$year";
}
else{$year = "20$year";}
}
else {
$form_year = $data{'Year'};
Jerome O'Neil
> Many Perl
> programmers think the mis-use of localtime is a non-issue
> because, based on their limited experience, it does not occur or, if it
> does, it cannot cause any problem worthy of consideration.
We don't think it's a non-issue. We just don't think it's a perl
issue. It's a programmer issue.
> If I saw localtime used in a program to format and output the value
> YYMMDD, I would be unlikely to check the manual just to be sure that YY
> was 'years since 1900' and not the last two digits of the year. I would
> probably only see a need for this if I was familiar with one of the very
> few languages that handle the year value in this way (i.e. C and Java).
> Otherwise, I would not have any reason to expect anything but 00 for the
> year 2000.
>
> Your ignorance of the potential seriousness of this aspect of
> the Y2K problem would indicate that you are unqualified to judge whether
> or not I have the qualifications to write on this subject.
If you are checking a language for bugs, and you don't know the
language, you are clearly unqualified to to write on the subject. That
is clearly the case.
--
Jerome O'Neil, Operations and Information Services
Atrieva Corporation, 600 University St., Ste. 911, Seattle, WA 98101
jer...@atrieva.com - Voice:206/749-2947
The Atrieva Service: Safe and Easy Online Backup http://www.atrieva.com
Jerome O'Neil
> playing stupid semantics.
While musing further:
> Your ignorance of the potential seriousness of this aspect of
> the Y2K problem would indicate that you are unqualified to judge whether
> or not I have the qualifications to write on this subject.
Please, show us your qualifications by posting some Y2K brokeness in
CGI. Then, show us how we might fix it.
Afterwards, I'm sure you will realize your gross incompetence, and go
back to the human resources department where you belong.
Tom Christiansen
In comp.lang.perl.misc, fin...@ts.co.nz writes:
:In article <374d...@cs.colorado.edu>,
:CGI, or Common Gateway Interface, is a programming language that allows
:CGI is the programming language that allows for accountability on the
There are idiots everywhere. What's your point?
--tom
--
"... the whole documentation is not unreasonably transportable in a
student's briefcase." - John Lions describing UNIX 6th Edition
Bill Jones
<tch...@mox.perl.com> wrote:
> [courtesy cc of this posting mailed to cited author]
>
> In comp.lang.perl.misc, fin...@ts.co.nz writes:
> :In article <374d...@cs.colorado.edu>,
> :CGI, or Common Gateway Interface, is a programming language that allows
>
> :CGI is the programming language that allows for accountability on the
>
> There are idiots everywhere. What's your point?
What I find most fascinating about this
"CGI Programming Language" is the GET and PUT.
Sometimes, the POST is good as well!
/^Humor$/
-Sneex- :]
______________________________________________________________________
Bill Jones Data Security Specialist http://www.fccj.org/cgi/mail?dss
Need to get started in Perl? See http://jacksonville.pm.org/Letter.cgi
Russ Allbery
> Tom, thought you may be interested to know that I'm not the only
> mis-guided soul using the term "programming language" to describe CGI
> for expedience.
Do you use the term "cat" to describe dogs for expedience too?
"Hey, all these other people are illiterate, so obviously it's okay that I
am too! And I can't be bothered to read the documentation for anything
before actually using it, so it all sucks!"
Pathetic.
Please go bother religious extremists, isolationists, food hoarders, or
someone else whose grasp of technical problems equals your own and get the
hell out of technical newsgroups until you've actually learned a
programming language.
--
#!/usr/bin/perl -- Russ Allbery, Just Another Perl Hacker
$^=q;@!>~|{>krw>yn{u<$$<[~||<Juukn{=,<S~|}<Jwx}qn{<Yn{u<Qjltn{ > 0gFzD gD,
00Fz, 0,,( 0hF 0g)F/=, 0> "L$/GEIFewe{,$/ 0C$~> "@=,m,|,(e 0.), 01,pnn,y{
rw} >;,$0=q,$,,($_=$^)=~y,$/ C-~><@=\n\r,-~$:-u/ #y,d,s,(\$.),$1,gee,print
Bob Shair
fin...@ts.co.nz wrote:
> Whether a method of instructing a computer can be deemed a programming
> language, scripting language, interface language, job control language
> or some other esoteric jargon you would care to name, is a grey area
> that I don't wish to debate. The fact is that CGI shares the same Y2K
> booby-trap problem as Perl. Fixing Y2K problems is more important than
> playing stupid semantics.
>
Jocelyn (dear fellow Deja-News user),
It's not clear to me what you're suggesting.
If you're trying to point out that many Perl programs will break
because real-world programmers fail to understand localtime(),
thanks. They will. One already has at one of my clients.
It's of value to point this out.
If you're suggesting that Perl should unilaterally change the behaviour
of localtime() to (1) break all the code which was written properly, and
(2) deviate from the behaviour used by other Unix and C programming
environments... Nah, you CAN'T be suggesting that.
localtime() is Broken-as-Designed, but it's part of the environment.
--
Bob Shair
Bob Shair Consulting
Champaign, Illinois
Sent via Deja.com http://www.deja.com/
Tom Christiansen
In comp.lang.perl.misc, fin...@ts.co.nz writes:
:> There are idiots everywhere. What's your point?
:That's my point exactly. Idiot's or not
Case in point. Now, I distinctly recall advising you, in effect,
that 'twould be better to keep one's mouth shut and be believed
a fool than to open and remove all doubt. You lose, again.
--tom
--
"Just because something is obviously happening doesn't mean something obvious
is happening." --Larry Wall
Uri Guttman
f> You may have missed my posting today where I gave examples of Y2K broken
f> code, so I have included them below. These examples are in Perl but
f> similar examples can be found in Java and several other languages
f> frequently used for CGI programming. I targetted localtime in Perl as it
f> appears to be the most frequently found Y2K problem within CGI routines.
f> If Perl code can be infected with Y2K problems, then so can CGI routines
f> - deny that if you can!
you are a raving lunatic (to say it mildly). so fucking what if cgi
routines and perl routines can be infected with y2k. that is the
programmers problem and not the language's. and again as so many of us
have told you. CGI has NO Y2K PROBLEM!!!!! it can't as it is an api which
use NO DATE INFORMATION EVER!!!! get it? it CANNOT HAVE A Y2K PROBLEM
any more than a pencil could.
and also perl does not have a y2k problem either. bad perl programmers
who don't rtfm have the problem.
f> http://www.hollycole.com/WWWboard/wwwboard.html
f> http://www2s.biglobe.ne.jp/~j_okada/free_cgi/j_diary/regist.txt
f> http://www.linguistic-funland.com/scripts/RemindMe/remindmecgi.txt
f> These examples only took 10 minutes to find on the internet using an
f> AltaVista advanced search on 'perl' and looking for 'localtime near 19
f> and localtime near 20'.
and are they respected perl hackers or some wannabe's like matt and
selena who post broken code for fun and profit? we constantly slam most
public archives of perl scripts since they are so bad. i once looked for
a simple voting/poll script to use and i found a mess of them. not one
was written in any semblence of good perl style or even decent
programming. most copied the same broken cgi code from matt and kept
spreading that virus. i couldn't in browse any of code i found
without causing a major case of intestinal cramping.
f> These web pages are provided by their authors so that the code can be
f> copied and pasted into new or existing programs.
hey and their reader are idiots. there are hundreds of these sites
around. why don't you spend your extra free time and find those sites,
fix their y2k bugs and send the patched code to their authors. i am sure
they and the world will be so grateful to you that you will be awarded
the nobel prize in good deed doing.
f> As for how to fix it - that's the easy part. The hardest part is
f> getting programmers to realise that there is a problem in the first
f> place. With all this denial from programmers such as yourself, it is
f> not surprising that many of us are still blissfully unaware that we may
f> have serious problems in our code.
we (who is we?) don't deny anything abiot y2k. we just say we know how
to program around the issue correctly. the fact that many programmers
out there don't know how to do that is not our problem. we can't police
all perl hackers (what an interesting thought! knock! knock! who is
there? tom c. and i have come to remove perl from your pc as you have
been propogating bad coding style and you cut and pasted bad cgi parsing
code from matt). perl is free and open and any moron can try to destroy
the world with it. stick that in your didgereedoo and smoke it!
and remember 40 million frenchmen CAN be wrong. CGI is not a language
and IT CANNOT HAVE A Y2K PROBLEM!!! PERIOD!!!
(to my loyal fans out there, i apologize for the yelling if it hurts
your ears (eyes?). but i had to vent my anger at this kiwi fruit.)
TRG Software : Tim Greer
>
> Whether a method of instructing a computer can be deemed a programming
> language, scripting language, interface language, job control language
> or some other esoteric jargon you would care to name, is a grey area
> that I don't wish to debate. The fact is that CGI shares the same Y2K
> booby-trap problem as Perl. Fixing Y2K problems is more important than
> playing stupid semantics.
>
When someone asks you what language you program in, do you tell them "I
program in computers."?
When someone asks what language is affected by the Y2K issue, do you
tell them "variables won't work anymore."?
CGI is *not* an issue at all. If the computer is capable of running past
that year, then the CGI interface won't fail to work -- as everyone here
has been stated, that CGI is *not* a language, and this "it's a gray
area" is pathetic.
Perhaps you create CGI applications in a certain language, but you use a
computer to run it and create it and possibly compile it (if not
interpret it), so do you consider the hard drive used to run a CGI
application a programming language too? There's not much of a
difference. You're way in over your head here.
--
Regards,
Tim Greer: chatm...@chatbase.com / soft...@linkworm.com
Chat Base: http://www.chatbase.com | 250,000+ hits daily Worldwide!
TRG Software: http://www.linkworm.com | CGI scripting in Perl/C, & more.
Unix/NT/Novell Administration, Security, Web Design, ASP, SQL, & more.
Freelance Programming & Consulting, Musician, Martial Arts, Sciences.
Chris Torek
(Tom Christiansen) writes:
>> There are idiots everywhere. What's your point?
In article <7ikrh1$kmd$1...@nnrp1.deja.com> Jocelyn Amon <fin...@ts.co.nz> writes:
>That's my point exactly. Idiot's [sic] or not, don't expect perfection from
>programmers, we're only human.
If Ms Amon's point is, indeed, that "there are idiots everywhere,
hence it would be better if languages were designed to be idiot-proof,
so that programmers could not shoot themselves in the foot with
them", she has not made it very well. But it is a *valid* point:
I agree that language designers should strive to define their
languagess in such a way that common mistakes tend to be avoided.
On the other hand, I think history shows that no one has any idea
which mistakes will *be* common until it is too late. Furthermore,
I suspect that if one could somehow go back in time (say, to the
1970s) and change some of the design decisions of any given language,
having decided today (in 1999, in "present-day future") that those
decisions led to common mistakes, one would, upon returning to an
alternate-future 1999, find that the altered language led to equally
many mistakes. Those mistakes would simply be of another nature.
In other words, while "strive to idiot-proof the world" is a noble
goal, we seem only to find that, the more we fool-proof something,
the more foolish people become. There is some sort of Law of
Conservation of Human Error: people make as many mistakes as they
can tolerate, and the harder it is to make mistakes, the more work
and/or less training people will apply, until they make the same
number of mistakes.
>It is particularly likely mistakes will be made when a programming
>language such as Perl, is so easy to mis-use.
Perhaps the reason Perl is so easy to mis-use is that it is so easy
to *use*. In other words, it "attracts the bigger idiots". Suppose
Perl had defined its localtime() so that the returned year was
"year AD". I would bet that many of these same people writing
broken Perl scripts today (i.e., failing to use "$year + 1900" to
obtain a four-digit year) would be writing other broken scripts,
perhaps using "$year - 1900" to extract the last two digits of the
year for human consumption.
--
In-Real-Life: Chris Torek, Berkeley Software Design Inc
El Cerrito, CA Domain: to...@bsdi.com +1 510 234 3167
http://claw.bsdi.com/torek/ (not always up) I report spam to abuse@.
TRG Software : Tim Greer
> Your ignorance of the potential seriousness of this aspect of
> the Y2K problem would indicate that you are unqualified to judge whether
> or not I have the qualifications to write on this subject.
>
"Oh boy, oh boy" (Best Rainman impression).
Set your computer date to 1970 when the new year comes and shut up.
You're embarrassing yourself. A 3 year old telling me how I don't know
how to program when they've never seen a computer, doesn't mean much to
me, or anyone else in this group, other then the fact that it's good for
a chuckle. :-)
fin...@ts.co.nz
Jerome O'Neil <jer...@atrieva.com> wrote:
<SNIP>
>
> Please, show us your qualifications by posting some Y2K brokeness in
> CGI. Then, show us how we might fix it.
>
> Afterwards, I'm sure you will realize your gross incompetence, and go
> back to the human resources department where you belong.
>
http://www.hollycole.com/WWWboard/wwwboard.html
# get information
local($string) = @_;
($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) =
localtime(time);
# calculate useful values
$cent = ($year < 70) ? 20 : 19;
$lyear = $year + $cent*100;
http://www2s.biglobe.ne.jp/~j_okada/free_cgi/j_diary/regist.txt
if ($year > 97) { $year = "19$year"; }
else { $year = "20$year"; }
if (!open (DB, "$data_dir/$year$mon\.dat")) {
http://www.linguistic-funland.com/scripts/RemindMe/remindmecgi.txt
if($data{'Year'} eq "Not Selected"){
($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst)=localtime(time);
if($year !~ /0/){
$form_year = "19$year";
}
else{$year = "20$year";}
These examples only took 10 minutes to find on the internet using an
AltaVista advanced search on 'perl' and looking for 'localtime near 19
and localtime near 20'.
Try it sometime for a close view of programming in the real world. Try
it with 'getyear' as well for some Java and Javascript examples. Try it
with '19' and notice how many of these web pages have been created this
year. These programmers are still hard-coding 19 for the century in
1999!
These web pages are provided by their authors so that the code can be
copied and pasted into new or existing programs.
As for how to fix it - that's the easy part. The hardest part is
getting programmers to realise that there is a problem in the first
place. With all this denial from programmers such as yourself, it is
not surprising that many of us are still blissfully unaware that we may
have serious problems in our code.
For anyone interested in what the booby trap code problem is, check out
the following links.
http://www.y2kinfo.com/journal/features/0499_amona.html
http://www.y2kinfo.com/journal/features/0599_amon.html
Jocelyn Amon
--
Financial Solutions Limited
http://www.ts.co.nz/~finsol/
I R A Aggie
<7ikjh9$f3r$1...@nnrp1.deja.com> wrote:
+ If you're suggesting that Perl should unilaterally change the behaviour
+ of localtime() to (1) break all the code which was written properly
Causing an even larger Y2K-ish problem...
James
fin...@ts.co.nz
> There are idiots everywhere. What's your point?
> --tom
>
That's my point exactly. Idiot's or not, don't expect perfection from
programmers, we're only human. Ask any user who has to put up with our
arrogance, ego, bugs, delays, budget over-runs, optimism (based on
wishful thinking not past experience) and our inability to communicate
and understand their needs. Or do you live in a different world?
It is particularly likely mistakes will be made when a programming
language such as Perl, is so easy to mis-use. We need to be working
actively on Y2K awareness, not denial, if we are going to mitigate some
of the worst eventualities.
Lane Core Jr.
On Fri, 28 May 1999 01:12:09 GMT, fin...@ts.co.nz wrote:
>As for how to fix it - that's the easy part. The hardest part is
>getting programmers to realise that there is a problem in the first
>place. With all this denial from programmers such as yourself, it is
>not surprising that many of us are still blissfully unaware that we may
>have serious problems in our code.
One of the biggest Y2K problems is that professionals have been more
interested in (1) denying that there is a Y2K problem within their
realm of expertise, or (2) doing quick-and-dirty research directed
more at demonstrating that there is no Y2K problem in their realm of
expertise than at determining whether or not there is a problem.
I believe that those attitudes largely account for the situation
described in "A Curious Shift in Y2K Compliance"
http://year2000.dci.com/Articles/9905263.htm.
---------------------------------------------------------------------------
Mr. Lane Core Jr. elc...@sgi.net http://users.sgi.net/~elcore/elc_y2k.htm
---------------------------------------------------------------------------
"More software projects have gone awry for lack of calendar time than for
all other causes combined". Frederick P. Brooks, _The Mythical Man-Month_
Eric Bohlman
: Tom, thought you may be interested to know that I'm not the only
: mis-guided soul using the term "programming language" to describe CGI
: for expedience.
: Check out these two URL's.
: http://www.net-ads.com/development/CGI.html
: Using CGI & Perl
: CGI, or Common Gateway Interface, is a programming language that allows
: webmaster to add various interactive features to their websites,
: including search engines, free-4-all links pages, clocks, counters,
: bulletin boards and more. Using CGI, it is also possible for webmasters
: to manage their own advertising inventory by rotating and tracking
: banner adviews ...
The description is simply wrong. "It's on the Web, so it *must* be right!"
: http://www.itknowledge.com/reference/dir.programminglanguages.perlandcgi
: .html
: Programming Languages: Perl & CGI
: CGI Developers Guide
: This book is one of the first books to provide comprehensive information
: on developing with CGI (Common Gateway Interface). It covers many of the
: aspects of CGI including, interactivity, performance, portability, and
: security. After reading this book, the reader will be able to write
: robust, secure, and efficient CGI programs.
This hardly amounts to calling CGI a programming language. The book is
specific to a particular programming language (Perl) and therefore is
correctly categorized as a book on "programming languages" even though it
only deals with a particular application of that programming language.
The mere fact that word A appears near word B in no way implies that "A
isa B." You're engaging in something akin to fundamentalist prooftexting.
: CGI Manual of Style
: CGI is the programming language that allows for accountability on the
: Web.
This is PHB-speak.
This book will help programmers learn the fundamentals behind CGI -
: showing how to program the included samples, what to watch out for, and
: how to achieve effective scripting. Progressing from easy samples to
: more advanced, this book provides users with the skills they need to
: provide accountability on their Web site.
: Special Edition Using Perl 5 for Web
: Programming
: With a review by Tom Christiansen ...
Nothing about this implies that CGI is a programming language.
: You efforts to educate me in the correct means of using news groups and
: the terminology that should be used is, I'm sure, of a greater
: importance to the computing world than Y2K awareness.
"Never knew we were living in a world with a mind that could be so sure"
-- Silverchair, "Anthem for the Year 2000"
: BTW, while you're checking out URL's, how does the Perl code at these
: sites look to you? It doesn't look kosher to me but then I don't claim
: to be a Perl expert.
: www.hollycole.com/WWWboard/wwwboard.html
: # get information
: local($string) = @_;
: ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) =
: localtime(time);
: # calculate useful values
: $cent = ($year < 70) ? 20 : 19;
: $lyear = $year + $cent*100;
So Daniel Johns should have titled his song "Anthem for the Year 10100"?
: http://www2s.biglobe.ne.jp/~j_okada/free_cgi/j_diary/regist.txt
: if ($year > 97) { $year = "19$year"; }
: else { $year = "20$year"; }
: if (!open (DB, "$data_dir/$year$mon\.dat")) {
Or the more prosaic "Anthem for the Year 19100"?
: http://www.linguistic-funland.com/scripts/RemindMe/remindmecgi.txt
: if($data{'Year'} eq "Not Selected"){
: ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst)=localtime(time);
: if($year !~ /0/){
: $form_year = "19$year";
: }
: else{$year = "20$year";}
: }
How about "Anthem for the Year 20100"? Sounds a little hard to sing.
Let's see...
1999, 20100, 20101, 20102, 20103, 20104, 20105, 20106, 20107, 20108, 20109,
20110, 19111, 19112, 19113, 19114, 19115, 19116, 19117, 19118, 19119,
20120, 19121 ....
This script must have been written by a member of the Campaign for
Non-Monotonic Time.
So far, the only point you've been able to make is that Perl is a poor
programming language for people who don't understand programming to write
production code in. I should certainly hope so. I've lost my "Murphy's
Law and its Corrolaries" book, so I can't identify the author, but someone
once said "Design a system that can be used by idiots and only an idiot
would want to use it." Perl's lack of training wheels is not a weak
point of the language. Perl's comprehensive documentation is a strong
point of the language. It is not Perl's fault that a historical
coincidence resulted in a bunch of pseudo-anti-structuralist "artiste"
poseur wannabes (the "HTML is DTP" crowd) trying to write Perl code as if
Perl were a purely artistic medium in which there were no rules.
I R A Aggie
<7il1nh$a...@elf.bsdi.com> wrote:
+ In article <7ikrh1$kmd$1...@nnrp1.deja.com> Jocelyn Amon
<fin...@ts.co.nz> writes:
+ >It is particularly likely mistakes will be made when a programming
+ >language such as Perl, is so easy to mis-use.
+ Perhaps the reason Perl is so easy to mis-use is that it is so easy
+ to *use*.
Time for a Wall-ism...
Many computer scientists have fallen into the trap of trying to define
languages like George Orwell's Newspeak, in which it is impossible to
think bad thoughts. What they end up doing is killing the creativity
of programming.
-- Larry Wall
James
J. Moreno
> In article <374D5A6E...@atrieva.com>,
> Jerome O'Neil <jer...@atrieva.com> wrote:
> <SNIP>
> >
> > Please, show us your qualifications by posting some Y2K brokeness in
> > CGI. Then, show us how we might fix it.
> >
> > Afterwards, I'm sure you will realize your gross incompetence, and go
> > back to the human resources department where you belong.
> >
> You may have missed my posting today where I gave examples of Y2K broken
> code, so I have included them below. These examples are in Perl but
> similar examples can be found in Java and several other languages
> frequently used for CGI programming. I targetted localtime in Perl as it
-snip-
The key is "CGI programming" not "programming in CGI" -- what is being
requested of you is for you to program in "CGI" and show a Y2K problem.
Not, repeat NOT, use perl, c, pascal, java, smalltalk, applescript,
effiel, lisp, or any other language to write a cgi *program* that has a
Y2K problem.
Programming is incredibly detail oriented, and this isn't a small or
unimportant detail. I wrote in another post that people "think" there
is a Y2K problem in perl because their brain shuts down when seeing a
year value using 2 digits. Your site has a similar problem -- it has
stupid, blindly obvious mistakes; people see these mistakes and they
stop reading for information and blow you off as an idiot, just as if
you'd said "green peas vegetables have a Y2K boobytrap".
So, on <http://www.y2kinfo.com/journal/features/0499_amona.html> (please
include the brackets next time), you should /remove/ "CGI" from the
line:
Perl, MacPerl, CGI using localtime
In fact what you should do is rewrite that as:
Perl (all implementations including MacPerl and ActivePerl) using
localtime
I would also suggest not referring to it as a "booby-trap", because
while that is accurate (it only catches the boobies), it's a bit
insulting. Instead you should say there is a potential "gotcha" with
localtime (javascripts inconsistent usage on the other hand sounds like
a real problem -- if what you are saying is accurate, which based upon
your calling "CGI" a programming language I'm not willing to stipulate).
With these and a few other changes that page could be marginally useful
-- it doesn't really say much that is applicable to an experienced
programmer (they will be aware of the issues surrounding their
languages), but its not a bad introduction to the neophyte.
--
John Moreno
fin...@ts.co.nz
original decision to return the value 100 for the year in the year 2000.
The creators of Perl had the opportunity to avoid this silliness but
chose, for who knows what reason, not do so. The same problem occurred
in Javascript and the language was changed in an attempt to 'fix' it.
This has caused an even greater problem with different versions doing
things differently.
My only aim in continuing this debate is to raise awareness that this is
a very real problem in Perl code, that Perl code is just as susceptible
to Y2K as any other language, that no language is immune and that all
applications need to be checked for Y2K problems.
Perl code is just as likely to have Y2K problems as any other language
and perhaps because of the booby trap code problem, more so.
Why does the Perl community persist in denying that their applications
could have Y2K problems instead of doing more to get the message out
that the code needs to be checked. The stance that the Perl developers
disputing this are taking is illogical, irresponsible and could cause
serious problems for the organisations that continue to use the Perl
code that remains unchecked.
Uri Guttman
f> Why does the Perl community persist in denying that their applications
f> could have Y2K problems instead of doing more to get the message out
f> that the code needs to be checked. The stance that the Perl developers
f> disputing this are taking is illogical, irresponsible and could cause
f> serious problems for the organisations that continue to use the Perl
f> code that remains unchecked.
do you understand english? we DO NOT DENY that perl applications can
have y2k problems. what we are also telling youis to differentiate the
programming lanaguge perl from perl applications. perl has no y2k
problem, some perl applications have the problem. so it is up to the
programmer to resolve the bug, not the language.
do you get it? please respond to this message so i know you read it. the
language and its applications are different! a pencil is not a book. a
pencil is not libelous but a book can be. same for perl and its
applications reagrding y2k. what about this do you not grasp.
and if organizations want to continue to use perl, they should check
their APPLICATIONS for y2k bugs and not perl itself. and that includes
checking CPAN modules since they are not part of the perl distribution.
so stop calling us illogical and irresponsible. perl hackers are generally
very logical (they chose a good language to develop in) and responsible
(since perl puts the onus of responsibility back into the hands of the
programmer and not by using some language syntax manacles).
so spread your fud elsewhere as you have not shown either trait in this
thread.
David Cantrell
enlightened us thusly:
> javascripts inconsistent usage on the other hand sounds like
>a real problem
It certainly is. The main problem I've come across is that
originally, the spec was that for dates in the 20th century (actually
1900-1999 but ...) years were two digits, and any other date from
CE100 onwards used three or four digit years. They changed this
later. Many people - myself included - ended up with code being
broken and not realising it. I'd tested it for Y2K compliance
originally and didn't realise that it was no longer compliant.
Grumble. Mutter.
[Copying newsgroup posts to me by mail is considered rude]
--
David Cantrell, part-time Unix/perl/SQL/java techie
full-time chef/musician/homebrewer
http://www.ThePentagon.com/NukeEmUp
Eric Bohlman
: Why does the Perl community persist in denying that their applications
: could have Y2K problems instead of doing more to get the message out
: that the code needs to be checked. The stance that the Perl developers
: disputing this are taking is illogical, irresponsible and could cause
: serious problems for the organisations that continue to use the Perl
: code that remains unchecked.
What the Perl community persists in denying is that Perl the language
has built-in Y2K problems. The Perl community unanimously affirms that
Perl code written by people who make guesses about what kind of data
localtime() returns, rather than inspecting the documentation for
localtime(), is very likely to have Y2K problems. The Perl community
vehemently denies that any of the following should be design goals for Perl
the language:
1) Making it impossible to write incorrect code. A programming language
in which it is impossible to write incorrect code is like a natural
language in which it is impossible to make a false statement; it's a
meaningless concept.
2) Making it easy for people to write code without understanding the
language. Perl was not intended to be a teaching language. There's a
tradeoff between ease of learning and ease of use, and Larry chose to
resolve it in favor of ease of use. Since this had the effect of making
the initial learning curve steeper, the Perl community came up with a
truly excellent documentation package that enables the Perl learner to
help him/herself up the learning curve if he/she is willing to put in the
effort.
Perl was developed well before the WWW explosion resulted in lots of "Web
page designers" deciding that they had to be able to write CGI code in
order to stay competitive. The Perl community has (rightly IMHO) shown
little interest in trying to make the language more "accessible" to
people who simply want to claim credentials as fast as possible without
doing their homework.
There is a view, frequently and sometimes unfairly attributed to
Microsoft, that a computer program, language, etc. should be designed so
that a newbie can make full use of it *while remaining a newbie*; that no
learning should be required. This is *not* part of the Perl philosophy,
which holds that learning the language increases one's power.
Lane Core Jr.
>so fucking what if cgi
>routines and perl routines can be infected with y2k. that is the
>programmers problem and not the language's.
same with cobol.
same with any language.
so it's still a problem.
so, like, what's your point?
Sitaram Chamarty
>In article <slrn7klkcn....@diac.com>,
> sit...@diac.com (Sitaram Chamarty) wrote:
>>
>> I think the lady means "that real world in which "consultants" can
>> make lots of moolah by spreading unnecessary FUD about Y2K, and
>> where they (as well as trial lawyers) are panicking at the thought
>> of NOTHING major happening, and trying their damnedest to make hay
>> before the sun starts shining again".
>>
>So, you work for nothing do you? When do you get your sainthood?
I dont make money by spreading FUD, anyway. The worst thing that
I anticipate with Y2K is a run on the bank's ATMs caused by fears
stoked by people like you. But that's not Perl-related.
>I have more important things to do than spending my time searching for
>the ultimate newsreader. Deja News works just fine for me and,
>obviously, for many others.
Using inefficient tools is bad enough. Justifying it is even
worse. When will you realise that a "workman is only as good as
his tools".
dejanews is a fine service - I have no complaints about it if it
is used by lay people. My wife - who doesnt do anything with
computers, or perhaps a lawyer, or a doctor, etc., etc - are ALL
eminent candidates for this fine service. Especially if used
sparingly. [All this applies to using dejanews as a "newsreader"
for regular news reading, not the occasional search.]
If *this* is your profession, however, you'd better have the right
tools. With automatic threading, scoring, (or at least killfiles
- I can see mine is going to be added to soon ;-), and so on, it's
just a far more *efficient* use of my time.
The couple of hours or so I spent configuring slrn have long since
been repaid. This is true with almost any tool that you use
frequently, laying waste to your silly "I have more important
things..." argument.
Going back to my carpenter - I havent met one that said "I dont
have the time to go finding the ultimate tool kit - I'll just use
this saw for everything I have to do".
I hope that was clearer, although I'm fast beginning to suspect it
won't be.
>Whether a method of instructing a computer can be deemed a programming
>language, scripting language, interface language, job control language
>or some other esoteric jargon you would care to name, is a grey area
>that I don't wish to debate. The fact is that CGI shares the same Y2K
>booby-trap problem as Perl. Fixing Y2K problems is more important than
CGI is a protocol. It does not define ANYTHING to do with dates.
Absolutely nothing. Even if, in a moment of insanity, I were to
accept that Perl has a problem, that still does not translate to
CGI. You can do CGI with ANY language. So - in your "real
world", pick a language that doesnt have Y2K "booby-traps", use it
for CGI, and see - in a flash of blinding insight - the stupidity
of what you just said.
>playing stupid semantics.
or drawing stupid conclusions.
>---Share what you know. Learn what you don't.---
Hey - I think dejanews is trying to tell you something :-)
Sitaram Chamarty
>Tom, thought you may be interested to know that I'm not the only
>mis-guided soul using the term "programming language" to describe CGI
>for expedience.
You may have used it for "expedience" to start with - although I
doubt that. But you cannot hide behind that word now, after
arguing vociferously with everyone here that it *is* indeed a
language. A full paragraph is not "expedient" in any way.
Give it up, sister!
Bob Trieger
elc...@sgi.net (Lane Core Jr.) wrote:
>On 27 May 1999 22:47:28 -0400, Uri Guttman <u...@sysarch.com> wrote:
>
>>so fucking what if cgi
>>routines and perl routines can be infected with y2k. that is the
>>programmers problem and not the language's.
>
>same with cobol.
>same with any language.
>so it's still a problem.
>so, like, what's your point?
It's not still a problem if you don't have a retard writing your code
for you!
Lane Core Jr.
Important question, then: how big an "if" is that? :-)
Jonathan Stowe
> On 27 May 1999 22:47:28 -0400, Uri Guttman <u...@sysarch.com> wrote:
>
>>so fucking what if cgi
>>routines and perl routines can be infected with y2k. that is the
>>programmers problem and not the language's.
>
> same with cobol.
> same with any language.
Not entirely true - there are languages with a DATE type that is completely
transparent to the programmer:
database tdcusers
define day1 date,
day2 date,
diff integer
main
let day1 = arg_val(1)
let day2 = arg_val(2)
let diff = day2 - day1
display diff
end main
sys0001 [figment] $ ttest "25/12/1999" "10/01/2000"
16
For example.
> so it's still a problem.
> so, like, what's your point?
>
I love it when it when a crosspost goes bad ...
I think that uri's point is that basically if someone is too dumb to have
read and understood the documentation for the localtime function then its
basically tough shit - it is not a problem with Perl its a problem with
the meatware.
/J\
--
Jonathan Stowe <j...@gellyfish.com>
Malcolm Ray
>You may have missed my posting today where I gave examples of Y2K broken
>code, so I have included them below. These examples are in Perl but
>similar examples can be found in Java and several other languages
>frequently used for CGI programming. I targetted localtime in Perl as it
>If Perl code can be infected with Y2K problems, then so can CGI routines
>- deny that if you can!
>
>http://www.hollycole.com/WWWboard/wwwboard.html
> local($string) = @_;
> ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) =
>localtime(time);
> # calculate useful values
> $cent = ($year < 70) ? 20 : 19;
> $lyear = $year + $cent*100;
>
>if ($year > 97) { $year = "19$year"; }
> else { $year = "20$year"; }
> if (!open (DB, "$data_dir/$year$mon\.dat")) {
>
>if($data{'Year'} eq "Not Selected"){
> ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst)=localtime(time);
> if($year !~ /0/){
> $form_year = "19$year";
> }
> else{$year = "20$year";}
>
>AltaVista advanced search on 'perl' and looking for 'localtime near 19
>and localtime near 20'.
>
>Try it sometime for a close view of programming in the real world. Try
>it with 'getyear' as well for some Java and Javascript examples. Try it
>with '19' and notice how many of these web pages have been created this
>year. These programmers are still hard-coding 19 for the century in
>1999!
I'm willing to bet that those programmers also fail to check the
return value of opens. It's also quite likely that their code
is non-portable. I'm willing to bet that those two examples above
which contain $yday and $isdst never use those variables, and they're
only there because the programmers cut-and-pasted the localtime call
without thinking. Ditto the superfluous arguments to localtime.
There are lousy programmers around - film at 11.
Programming should not be done by guesswork. Let's imagine that
perl never had localtime in its current form. Instead, it had a
function called current_time. Same semantics, except that the year
is returned in the way you'd seem to prefer. So I copy a call to
it into my program, without reading the documentation:
my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = current_time;
print "Date is $mday/$mon/$year\n";
Hang on, why does it say the current month number is 8, when it
should obviously be 9? Amazingly, some programmers fail to spot this,
and some who do turn up on clpm asking whether it's a bug, so let's
modify current_time further to return a 1-based month number. Now,
what's $isdst? The name suggests that it's related to daylight saving
time, and, sure enough, I get the value 1, and DST is currently active.
Must be 'hours after GMT', I suppose, so let's do this:
my $rfc822_timezone = 'GMT +0' . $isdst . '00';
Works for me. Would it work in a different timezone? Would you know?
Under what circumstances would it fail? What if I want the time in GMT?
I'm not going to read the docs and find a suitable function, of course,
so I guess I'd have to do this:
my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = current_time;
$hour -= $isdst;
Would that be ok? Always?
A lot of lousy code will fail in about six months' time. A lot of lousy
code will fail gracelessly at some indeterminate time in the future when
a file it needs isn't there or has the wrong permissions. A lot of
lousy CGI code will fall in a heap if a form variable it was expecting
is missing or contains shell metacharacters. A lot of lousy code will
fail miserably if run on a different platform, or under a differently-
configured web server. None of these are the fault of the language.
--
Malcolm Ray University of London Computer Centre
I R A Aggie
<7iljav$554$1...@nnrp1.deja.com> wrote:
+ to Y2K as any other language, that no language is immune and that all
+ applications need to be checked for Y2K problems.
Of course. I don't think anyone has objected to that. The devil
is in the details, and the details in programming is the actual
implementation. If it isn't right...well...it ISN'T RIGHT.
+ Perl code is just as likely to have Y2K problems as any other language
+ and perhaps because of the booby trap code problem, more so.
More than, say, C/C++ under unix?
+ serious problems for the organisations that continue to use the Perl
+ code that remains unchecked.
If those organizations are concerned about their perl code, I can come
up with a fee scale and check it for them. Until then, it is their
problem, not mine.
Unlike what seems like most of the rest of the planet, I've actually
read both 'perldoc -f localtime' and the man page for the C library
localtime. I *know* what localtime returns for a year, and I know what
an "offset" means, and how to deal with it...
James
Benjamin Franz
I R A Aggie <fl_a...@thepentagon.com> wrote:
[snip]
>read both 'perldoc -f localtime' and the man page for the C library
>localtime. I *know* what localtime returns for a year, and I know what
>an "offset" means, and how to deal with it...
What it means is 'Broken-As-Designed'. I've thought long and hard about
year-1900. And it comes down to "It's a hack to allow programmers too
lazy or ignorant to do the right thing to screw up with official sanction."
I couldn't come up with even *one* good use of 'year-1900' being
done _correctly_ that wasn't identical in complexity with using
'year'. Need 2 digit dates? To be Y2K compliant you need %100 in
both cases. Need the difference between two dates? Identical. Need
four digit dates? Hmmm...Seems y-1900 is _slightly_ more complex.
The *only* thing y-1900 wins on is: How many years since 1900?
A remarkably *useless* thing in general.
So what exactly is the benefit of y-1900? It allowed programmers
to _pretend_ to be programming correctly when in fact they were
screwing up horribly *and didn't even save any memory*. A 16 bit
signed int can hold up to _at least_ 32767 on any system I've heard
of. One gets you twenty that the justification of y-1900 amounted
to nothing more than "We already stored 2-digit dates in our fixed
size record databases and it would cost money to fix it right now.
This puts off when we have to _fix_ the problem with a bit of
smoke and mirrors to hide the _existance_ of the problem."
Broken-As-Designed.
Perl doesn't have any direct Y2K problems (although its POD system
does) - but it without question greased the rails (following in C's
footsteps) for *programmers* to have Y2K problems.
--
Benjamin Franz
Erik van Roode
Alcoholics claim they don't have a problem with alcohol.
So someone who claims not to have a problem with alcohol is an alcoholic.
Ofcourse, any reasonably intelligent person can sees the flaw in this logic.
Ignorant programmers claim they don't have problems with century bugs.
Programmers who claim they don't have problems with century bugs are ignorant.
Same reasoning ...
Besides, what's the problem with 1999->2000 transition anyway. I have power
failures every few weeks anyway, a small icestorm leaves people without power
for weeks, airports seem to shut down due to computer problems on a regular
basis. The first time I drive in a car all traffic lights shut down. A hospital
in DC had computer problems because the floppy drives were full (I think the
'floppy' part was a typo though ;)
Erik van Roode
Tad McClellan
: In article <374d...@cs.colorado.edu> tch...@mox.perl.com
: (Tom Christiansen) writes:
: >> There are idiots everywhere. What's your point?
: In article <7ikrh1$kmd$1...@nnrp1.deja.com> Jocelyn Amon <fin...@ts.co.nz> writes:
: >That's my point exactly. Idiot's [sic] or not, don't expect perfection from
: >programmers, we're only human.
: Perhaps the reason Perl is so easy to mis-use is that it is so easy
: to *use*. In other words, it "attracts the bigger idiots".
Yes!
And there, ladies and gentlemen, is the short version of
many frequently recurring threads on clpmisc. e.g.:
newbies newsgroup
works command line, but not as CGI
use function without reading about function
syntax error
file locking
etc ...
[
Not to imply that folks who participate in such threads are idiots.
I'm just agreeing that Perl has a greater proportion of less
skilled programmers than languages that have a higher barrier
to entry in the first place.
]
Random .sig file quote for sure!
--
Tad McClellan SGML Consulting
ta...@metronet.com Perl programming
Fort Worth, Texas
docd...@clark.net
>>On 27 May 1999 22:47:28 -0400, Uri Guttman <u...@sysarch.com> wrote:
>>
>>>so fucking what if cgi
>>>routines and perl routines can be infected with y2k. that is the
>>>programmers problem and not the language's.
>>
>>same with cobol.
>>same with any language.
>>so, like, what's your point?
>
>for you!
>
And is it a problem if you have, say, a McCracken writing code which
*must* ( = 'will not get into Prod if it doesn't') adhere rigidly to specs
written by a 'retard'?
DD
Jerome O'Neil
> Jerome O'Neil <jer...@atrieva.com> wrote:
> > Please, show us your qualifications by posting some Y2K brokeness in
> > CGI. Then, show us how we might fix it.
> You may have missed my posting today where I gave examples of Y2K broken
> code, so I have included them below.
I think I understood it quite clearly. You posited:
__QUOTE__
The fact is that CGI shares the same Y2K booby-trap problem as Perl.
Fixing Y2K problems is more important than playing stupid semantics.
_/QUOTE__
And I'm still waiting to see some Y2K broken CGI code.
> These examples are in Perl but
> similar examples can be found in Java and several other languages
> frequently used for CGI programming.
Just a side note: Java is rarely used for CGI. Not that it can't be,
but experienced coders know the pros and cons, and use better tools for
that particular job.
> I targetted localtime in Perl as it
> appears to be the most frequently found Y2K problem within CGI routines.
> If Perl code can be infected with Y2K problems, then so can CGI routines
> - deny that if you can!
I'm still waiting to see this CGI language you keep going on and on
about.
As far as the code below goes, all it does is prove my point. There are
lots of bad programmers out there. Abuse of perl's functions isn't any
indicator of it's quality.
<Bad perl snipped>
> These examples only took 10 minutes to find on the internet using an
> AltaVista advanced search on 'perl' and looking for 'localtime near 19
> and localtime near 20'.
So? You're making my case again. Bad programmers are everywhere.
> Try it sometime for a close view of programming in the real world.
I don't have to go any farther than my desk for a close view of
programming "in the real world." It is apparent, though, that you do.
>These programmers are still hard-coding 19 for the century in 1999!
Those fools! They must not know that localtime() is well defined and
clearly documented!
> These web pages are provided by their authors so that the code can be
> copied and pasted into new or existing programs.
I think they are provided so ex-HR "computer experts" can parade around
as "Y2K consultants." When you've been in this business for a while,
you learn to spot the bovine stool artists quickly. You should consider
yourself so marked.
> As for how to fix it - that's the easy part.
Tell us, then. How do we fix that which is not broken.
> The hardest part is
> getting programmers to realise that there is a problem in the first
> place. With all this denial from programmers such as yourself, it is
> not surprising that many of us are still blissfully unaware that we may
> have serious problems in our code.
Who is 'we'? I haven't seen one line of *your* code. And I'm very
excited to see this CGI language I've heard you talk so much about.
> For anyone interested in what the booby trap code problem is, check out
> the following links.
Obviously they will trap the boobies.
--
Jerome O'Neil, Operations and Information Services
Atrieva Corporation, 600 University St., Ste. 911, Seattle, WA 98101
jer...@atrieva.com - Voice:206/749-2947
The Atrieva Service: Safe and Easy Online Backup http://www.atrieva.com
Jonathan Stowe
Sorry, are you saying that you have seen a specification for a *Perl*
program that prescribes the use of: $year = '19' . $year ? Whoaaa .
Sitaram Chamarty
<eboh...@netcom.com> wrote:
>order to stay competitive. The Perl community has (rightly IMHO) shown
>little interest in trying to make the language more "accessible" to
>people who simply want to claim credentials as fast as possible without
>doing their homework.
Yes. Even as late as 2 years ago, Perl (and Linux - in this
context they are related) used to "keep the riffraff out" - as
someone's tagline said :-)
Sadly, this is not true any more. It's nice that the quantity of
interest has gone up, but that usually means quality goes down!
>There is a view, frequently and sometimes unfairly attributed to
>Microsoft, that a computer program, language, etc. should be designed so
>that a newbie can make full use of it *while remaining a newbie*; that no
>learning should be required. This is *not* part of the Perl philosophy,
>which holds that learning the language increases one's power.
And increasing one's power (should) always imply increasing one's
responsibility, too.
Sitaram Chamarty
<fl_a...@thepentagon.com> wrote:
>Time for a Wall-ism...
>
>Many computer scientists have fallen into the trap of trying to define
>languages like George Orwell's Newspeak, in which it is impossible to
>think bad thoughts. What they end up doing is killing the creativity
>of programming.
"It is impossible to make anything foolproof because fools are so
ingenious" - I forgot who
"Make a system that any fool can use, and only fools will use it"
- I again forget who ;-)
I hope Jocelyn's next flight is on a plane that has been
"fool-proofed" so much that the airline lets anyone fly it ;-)
Happy landings, Jocelyn!
Tony
<Snip all sorts of relevent and interesting stuff to alow for some
flippancy>
:->
:->There is a view, frequently and sometimes unfairly attributed to
:->Microsoft, that a computer program, language, etc. should be designed so
:->that a newbie can make full use of it *while remaining a newbie*; that no
:->learning should be required. This is *not* part of the Perl philosophy,
:->which holds that learning the language increases one's power.
:->
Wow yes, you could have Visual P++ as part of DevStudio, it would have
funny animated characters to guide you through regular expressions.
Various things of interest would turn funny colours and it would ping
at you if you used localtime() wrong.
The second release would of course then store all the pre-code code in
a completely different format from the first so that it would take
twice as long as starting again to get it working again.
Subsequent releases would fail entirely to produce code on anything
but the newest machines, and all three would require huge great
run-time libraries to give you the correct error message when it fell
over coughing and weezing.
--
From Tony Kennick aka Gonzo The Great
http://missy.shef.ac.uk/users/old-firm/
Gonzo: Slang for "the last man standing
at a drinking marathon"
I R A Aggie
<snow...@long-lake.nihongo.org>, in
<nEx33.1997$kd5.2...@typhoon-sf.snfc21.pbi.net> wrote:
+ In article <slrn7kt73u....@thepentagon.com>,
+ I R A Aggie <fl_a...@thepentagon.com> wrote:
+ >read both 'perldoc -f localtime' and the man page for the C library
+ >localtime. I *know* what localtime returns for a year, and I know what
+ >an "offset" means, and how to deal with it...
+ What it means is 'Broken-As-Designed'.
Yeah, well, as the saying goes: you're a day late and a dollar short.
I'm not going to argue that it may have been easier all around to just
return the Fully Qualified Year Number (FQYN) -- it would. The opportunity
to do that is *gone*. Ultimately, we have to deal with what IS.
+ Perl doesn't have any direct Y2K problems (although its POD system
+ does) - but it without question greased the rails (following in C's
+ footsteps) for *programmers* to have Y2K problems.
*shrug* Another design desicision -- emulate libc calls, a good call
IMHO. "Fix" the underlying libc and you've "fixed" perl, too. Have you
submitted a patch to GNU libc?
Whoa. Brain{storm|fart}. Anyone up for localtime2[*]? Then the
documentation can say "Use localtime2(), do not use localtime(), as it
is a dead, camel-bitten flea carcass".
James
[*] -- call it what you will...
docd...@clark.net
No, I am not saying that at all... in response to the assertion that there
is no difficulty if one does not have a 'retard writing code' I asked what
happens if the person writing code is not a 'retard' but the specs demand
certain standards be adhered to.
My apologies for the obscurity, I hope this clarifies matters.
DD
Lane Core Jr.
<gell...@gellyfish.com> wrote:
>In comp.lang.perl.misc Lane Core Jr. <elc...@sgi.net> wrote:
>> On 27 May 1999 22:47:28 -0400, Uri Guttman <u...@sysarch.com> wrote:
>>
>>>so fucking what if cgi
>>>routines and perl routines can be infected with y2k. that is the
>>>programmers problem and not the language's.
>>
>> same with cobol.
>> same with any language.
>
>Not entirely true - there are languages with a DATE type that is completely
>transparent to the programmer:
Yes, I should have said, not "any language", but "not just perl".
>I love it when it when a crosspost goes bad ...
>
>I think that uri's point is that basically if someone is too dumb to have
>read and understood the documentation for the localtime function then its
>basically tough shit - it is not a problem with Perl its a problem with
>the meatware.
Yeah, but it's still a problem. :-(
Tom Christiansen
In comp.lang.perl.misc,
docd...@clark.net () writes:
:happens if the person writing code is not a 'retard' but the specs demand
:certain standards be adhered to.
Have you considered toiling under a slightly less mind-numbingly
fascist regime?
--tom
--
"It's later than you don't think." --Larry Wall
Scott McMahan
> program that prescribes the use of: $year = '19' . $year ? Whoaaa .
The nice thing about Open Source is, you can always hack
the interpreter to change any string concatenation of
a three-digit number to the literal "19" to be an addition.
Problem solved.
Scott
Uri Guttman
IRAA> *shrug* Another design desicision -- emulate libc calls, a good call
IRAA> IMHO. "Fix" the underlying libc and you've "fixed" perl, too. Have you
IRAA> submitted a patch to GNU libc?
that ain't gonna happen!
IRAA> Whoa. Brain{storm|fart}. Anyone up for localtime2[*]? Then the
IRAA> documentation can say "Use localtime2(), do not use localtime(), as it
IRAA> is a dead, camel-bitten flea carcass".
write a module and use it. even overload localtime if you wish (i
wouldn't). localtime is well defined and y2k compliant. its users may
not be either one.
Scott McMahan
> Besides, what's the problem with 1999->2000 transition anyway.
I quit worrying about Y2K when I went to Wal-Mart and tried
to purchase a book which had NATIONAL BESTSELLER written on it.
The book wasn't in their computer system! At that point, I
pretty much decided that no one would even notice Y2K disruptions.
Scott
docd...@clark.net
Tom Christiansen <tch...@mox.perl.com> wrote:
> [courtesy cc of this posting mailed to cited author]
>
>In comp.lang.perl.misc,
> docd...@clark.net () writes:
>:happens if the person writing code is not a 'retard' but the specs demand
>:certain standards be adhered to.
>
>Have you considered toiling under a slightly less mind-numbingly
>fascist regime?
Why yes, I *have* considered such things. My considerations, however, do
not have any effect on situations like these which exist, in my
experience, in a goodly number of environments.
Please be so kind, then, as to address the situation posed and not my
responses to it... what happens if a person writing code is not a 'retard'
but the specs demand the adherance to certain standards?
DD
Tad McClellan
: fin...@ts.co.nz wrote:
: : Why does the Perl community persist in denying that their applications
: : could have Y2K problems instead of doing more to get the message out
: : that the code needs to be checked. The stance that the Perl developers
: : disputing this are taking is illogical, irresponsible and could cause
: : serious problems for the organisations that continue to use the Perl
: : code that remains unchecked.
: What the Perl community persists in denying is that Perl the language
: has built-in Y2K problems. The Perl community unanimously affirms that
: Perl code written by people who make guesses about what kind of data
: localtime() returns, rather than inspecting the documentation for
: localtime(), is very likely to have Y2K problems.
The Perl community believes:
There are no y2k issues with "perl code".
There are very likely to be y2k issues with "Perl code".
If you cannot get the distinction between those (after maybe
seeing qq/What's the difference between "perl" and "Perl"/
in Perl FAQ part 1), then give up as you are just too silly
to be taken seriously.
If you can get the distinction, then you should be able to see
that we are agreeing with you, and you can stop following up.
... unless you think that there *are* issues with "perl code"...
fin...@ts.co.nz
Jonathan Stowe <gell...@gellyfish.com> wrote:
> In comp.lang.perl.misc Lane Core Jr. <elc...@sgi.net> wrote:
> > On 27 May 1999 22:47:28 -0400, Uri Guttman <u...@sysarch.com> wrote:
> >
> >>so fucking what if cgi
> >>routines and perl routines can be infected with y2k. that is the
> >>programmers problem and not the language's.
> >
> > same with cobol.
> > same with any language.
>
> Not entirely true - there are languages with a DATE type that is
completely transparent to the programmer:
>
>
> I love it when it when a crosspost goes bad ...
Lane's point still holds - a programmer can create Y2K problems in COBOL
and in Perl. Just because a particular language makes this particularly
easy to do (as with Perl and as with languages that have non-compliant
components) doesn't change the fact.
Y2K problems can occur in applications written in any programming
language and all programming languages can be used to write non-Y2K
problem applications.
> I think that uri's point is that basically if someone is too dumb to
have read and understood the documentation for the localtime function
then its basically tough shit - it is not a problem with Perl its a
problem with the meatware.
> /J\
> --
> Jonathan Stowe <j...@gellyfish.com>
Tough shit for who? Just think about it. Who is going to suffer from all
this denial and ignorance the most? There is certainly a problem Perl
developers if they can be so blase about the consequences of Y2K
problems within the organisations which use the Perl progranmming
language.
Jocelyn Amon
--
Financial Solutions Limited
http://www.ts.co.nz/~finsol/
Sent via Deja.com http://www.deja.com/
Larry Rosler
Scott McMahan <sc...@aravis.softbase.com> says...
Barf bag provided? (I'll supply the smiley that you forgot. :-)
--
(Just Another Larry) Rosler
Hewlett-Packard Company
http://www.hpl.hp.com/personal/Larry_Rosler/
l...@hpl.hp.com
I R A Aggie
<x7btf5h...@home.sysarch.com> wrote:
+ >>>>> "IRAA" == I R A Aggie <fl_a...@thepentagon.com> writes:
+ IRAA> *shrug* Another design desicision -- emulate libc calls, a good call
+ IRAA> IMHO. "Fix" the underlying libc and you've "fixed" perl, too. Have you
+ IRAA> submitted a patch to GNU libc?
+ that ain't gonna happen!
Yah, I know, that's why I can suggest it with a straight face...
+ write a module and use it.
Hmmm...'use Date::Localtime;'.
James
Ilya Zakharevich
<l...@hpl.hp.com>],
who wrote in article <MPG.11b88d13c...@nntp.hpl.hp.com>:
> > The nice thing about Open Source is, you can always hack
> > the interpreter to change any string concatenation of
> > a three-digit number to the literal "19" to be an addition.
> > Problem solved.
>
> Barf bag provided? (I'll supply the smiley that you forgot. :-)
In your infinite wisdom you may be interested to know that 5.00558 may
contain code not *that* dissimilar to the above suggestion.
Ilya
Stefaan A Eeckels
elc...@sgi.net (Lane Core Jr.) writes:
> On 28 May 1999 12:04:34 +0100, Jonathan Stowe
> <gell...@gellyfish.com> wrote:
>
>>read and understood the documentation for the localtime function then its
>>basically tough shit - it is not a problem with Perl its a problem with
>>the meatware.
>
Toyota to kill a couple of pedestrians it is *your* problem,
not Toyota's.
--
Stefaan
--
PGP key available from PGP key servers (http://www.pgp.net/pgpnet/)
___________________________________________________________________
Perfection is reached, not when there is no longer anything to add,
but when there is no longer anything to take away. -- Saint-Exupéry
Stefaan A Eeckels
docd...@clark.net () writes:
>
> Please be so kind, then, as to address the situation posed and not my
> responses to it... what happens if a person writing code is not a 'retard'
> but the specs demand the adherance to certain standards?
should be changed. If management is not prepared to accept
corrections to erroneous standards, get the hell out before the
joint goes bankrupt :-)
Larry Rosler
In article <7imvcs$eho$1...@mathserv.mps.ohio-state.edu> on 28 May 1999
20:47:24 GMT, Ilya Zakharevich <il...@math.ohio-state.edu> says...
> [A complimentary Cc of this posting was sent to Larry Rosler
> <l...@hpl.hp.com>],
> who wrote in article <MPG.11b88d13c...@nntp.hpl.hp.com>:
> > > The nice thing about Open Source is, you can always hack
> > > the interpreter to change any string concatenation of
> > > a three-digit number to the literal "19" to be an addition.
This must mean 'an addition of 1900'. Ye gods!!!
> > > Problem solved.
> >
> > Barf bag provided? (I'll supply the smiley that you forgot. :-)
>
> In your infinite wisdom you may be interested to know that 5.00558 may
> contain code not *that* dissimilar to the above suggestion.
As history has shown you to be incapable of humor, Ilya, I must take you
seriously.
I thought that DWIMming was based on syntactic analysis. Applying it to
the contents of string literals takes it to new heights (depths?).
s?printf '...19%d...', ..., $year, ...;
will be next, I presume? That is the most likely manifestation of this
problem.
Trying to eliminate programmer bugs by fixing them 'under the covers'
seems inane, if not downright malicious.
--
(Just Another INFINITELY WISE Larry) Rosler
docd...@clark.net
Stefaan A Eeckels <Stefaan...@ecc.lu> wrote:
>In article <KrB33.129$K2....@iad-read.news.verio.net>,
> docd...@clark.net () writes:
>>
>> Please be so kind, then, as to address the situation posed and not my
>> responses to it... what happens if a person writing code is not a 'retard'
>> but the specs demand the adherance to certain standards?
>If said standards mandate the introduction of bugs, then they
>should be changed.
This, in a nutshell, is the heart of many Y2K flaws; that which 'should
have been' was not 'that which was'.
>If management is not prepared to accept
>corrections to erroneous standards, get the hell out before the
>joint goes bankrupt :-)
Ahhhh, but remember... *every* shop will state, at some point, 'Well, what
you says might have merit but we cannot do it that way... Things Are
Different Here.'
... and, of course, if Tings Are Different everywhere then Things Are The
Same everywhere.
DD
TRG Software : Tim Greer
>
> In article <374d...@cs.colorado.edu>,
> tch...@mox.perl.com (Tom Christiansen) wrote:
>
> > There are idiots everywhere. What's your point?
> >
> That's my point exactly. Idiot's or not, don't expect perfection from
> programmers, we're only human. Ask any user who has to put up with our
> arrogance, ego, bugs, delays, budget over-runs, optimism (based on
> wishful thinking not past experience) and our inability to communicate
> and understand their needs. Or do you live in a different world?
You say "we" and "our", as if you knew what you were talking about,
which you obviously do not. Try not to "group" yourself in with the rest
of us who *do* know what they are talking about. I'm sorry that you
found some misleading info somewhere at some point, but you are now (and
have been) being told by "experts" (yes, the *real* one's!), that your
assumptions are not correct.
>
> It is particularly likely mistakes will be made when a programming
> language such as Perl, is so easy to mis-use.
Perhaps without proper knowledge, which needs to be obtained in the
proper manner, from a reliable source. Hence your confusion from the
lack of a proper source at some point.
> We need to be working
> actively on Y2K awareness, not denial, if we are going to mitigate some
> of the worst eventualities.
My point yet again about you and your "assumptions". This is *not* an
issue, but your belligerent naive-ness is.
--
Regards,
Tim Greer: chatm...@chatbase.com / soft...@linkworm.com
Chat Base: http://www.chatbase.com | 250,000+ hits daily Worldwide!
TRG Software: http://www.linkworm.com | CGI scripting in Perl/C, & more.
Unix/NT/Novell Administration, Security, Web Design, ASP, SQL, & more.
Freelance Programming & Consulting, Musician, Martial Arts, Sciences.
TRG Software : Tim Greer
>
> You may have missed my posting today where I gave examples of Y2K broken
> code,
Not in CGI. :-) Wait, what was your point?
> so I have included them below. These examples are in Perl but
> similar examples can be found in Java and several other languages
> frequently used for CGI programming. I targetted localtime in Perl as it
> appears to be the most frequently found Y2K problem within CGI routines.
> If Perl code can be infected with Y2K problems, then so can CGI routines
> - deny that if you can!
I won't deny anything. I admit you're unqualified to make such
statements.
If you're going to try and prove a point, by going to Matt's Script
archive, then you may as well zip up the entire site and get it over
with. Posting examples of some bad code, doesn't help. I can do a search
and find poorly written code in 95% of the Perl scripts available on the
Net and show you plenty of them that won't work *now*, or after the Y2K
issue. it's due to "poor programming", "bad code", and has nothing to do
with the Y2K issue, other then the people were clueless that wrote that
code, and further, because they have other poorly written parts of code
in the script, doesn't mean it's a Y2K problem either. Are you talking
about a program that functions based on the year, etc., or are you
talking about a program that PRINTS the date? Do you see the difference?
Any programmer that has any clue of what he's doing, isn't going to get
into that situation. Any bad programmer will get themselves into a bug
ridden situation anyway, no matter what year it is.
You haven't been proving any good points. Just drop it and stop
"denying" that there's some urgent underlying problem, simply because
you want people to believe it.
The PROBLEM with Y2K, is how people react about it. You have the choice
as an individual to completely panic, or remain calm and use your head.
If you choose the latter, then you'll see there's nothing to panic
about. People cause riots, not computers. Oxygen is still going to be
available to all humans to breath, your dog will still bark, things
won't "explode", your car will still steer, your shoes will still tie.
Do you think hospitals run their life support systems on a Windows
machine? Do you think traffic lights run on a PC? What is wrong with
you? There's quite obviously a few problems that will happen, but
nothing catastrophic -- not unless everyone decides to assume the worst
and panic about everything. Anyone with a normal grasp of reality and
common sense, will know this is more of a hoax then anything else.
So, spare me little snippets of poorly written code. I can only assume
that those programs were written to only be in use for so long, and
believe me, that was a mistake already. Find a more reliable source to
make examples from, because I could write a program in any language you
like (for CGI or not), and have them all break at the Y2K, or run past
the Y2K. It's a choice of good or bad programming. Any program worth
anything, or any critical program isn't going to have those sort of
"gotcha's".
bj
> Please be so kind, then, as to address the situation posed and not my
> responses to it... what happens if a person writing code is not a 'retard'
> but the specs demand the adherance to certain standards?
Please be so kind to supply an example of such a spec. While the
standards may be truely stupid in a broader context, producing code
that performs according to the spec is by definition correct code.
For example, if the spec states that 2 digit "year" fields must be
used then there must be an expectation and presumably a stated
requirement for what is required 7 months from now. If the spec calls
for "00", then it ain't broken.
Are you saying that you have a standard that states you must take the
output of the years field in localtime and concatenate it to "19" to
produce a correct 4 digit date?
puzzled,
bj
Tom Christiansen
In comp.lang.perl.misc,
fin...@ts.co.nz writes:
:Just because a particular language makes this particularly
:easy to do (as with Perl and as with languages that have non-compliant
:components) doesn't change the fact.
Can you open your mouth for any other purpose than to spread fear,
uncertainty, and doubt -- or just plain lies, as in this case?
Perl has no non-compliant component. It has non-compliant progammers.
So does any langauge.
THERE IS NO SOLUTION. If it had always been 4 digits, people would
have just subtracted 1900 to get that 2-digit year which people
adore printing, and then they still would be wrong. And for the
same reason: they neglected to
READ
THE
FUCKING
MANUAL
I am convinced that you are too dim to understand any of this.
--tom
--
Mister Catbert, the company is trying to force me to use a different kind
of computer. You're the human resources directory. what are you doing
to sop this religious persecution?! What every happened to "Diversity"??
The longer you verk here, diverse it gets. next. --Scott Adams, "Dilbert"
Tom Christiansen
In comp.lang.perl.misc,
l...@hpl.hp.com (Larry Rosler) writes:
: s?printf '...19%d...', ..., $year, ...;
:will be next, I presume?
Yup, remarkably enough. Check out the p5p archives for discussion of the same.
Feel free to kibbitz^Wcontribute.
--tom
--
"The road to hell is paved with melting snowballs."
--Larry Wall in <1992Jul2.2...@netlabs.com>
docd...@clark.net
Oh dear, my apologies... I had expanded upon a posting which I found in
comp.software.year-2000 which had referred to the 'person writing the
code' as a 'retard'; it now becomes that the author might not have been
referring to 'coders' but to Perl-slingers. It was wrong of me,
obviously, to conclude that a 'person writing the code' might be writing
anything *but* Perl... say, BAL, FORTRAN or COBOL.
DD
Alastair
>Lane's point still holds - a programmer can create Y2K problems in COBOL
>and in Perl.
True.
>Just because a particular language makes this particularly
>easy to do (as with Perl and as with languages that have non-compliant
>components) doesn't change the fact.
Easy? Not if you have a a clue. After all, when you use a particular function or
programming contsruct, you read the manual. If you don't, you deserve the
consequences.
>Y2K problems can occur in applications written in any programming
>language and all programming languages can be used to write non-Y2K
>problem applications.
True.
>> I think that uri's point is that basically if someone is too dumb to
>have read and understood the documentation for the localtime function
>then its basically tough shit - it is not a problem with Perl its a
>problem with the meatware.
>> /J\
>> --
>> Jonathan Stowe <j...@gellyfish.com>
>
>Tough shit for who? Just think about it. Who is going to suffer from all
>this denial and ignorance the most? There is certainly a problem Perl
>developers if they can be so blase about the consequences of Y2K
>problems within the organisations which use the Perl progranmming
>language.
Eh? You just said that it's a potential problem with *any* programming language.
Therefore I'd say the programmer is the one needing to take care - in the usual
way. RTFM.
End of story.
--
Alastair
work : alas...@psoft.co.uk
home : alas...@calliope.demon.co.uk
Sam Holden
Some people would have read the subject and made a reasonable guess...
Though cross posting always confuses the hell out of every one...
--
Sam
PC's are backwards ... throw them out! Linux is ok though.
--Rob Pike (on the subject of CR/LF etc)
Jerome O'Neil
> Oh dear, my apologies... I had expanded upon a posting which I found in
> comp.software.year-2000 which had referred to the 'person writing the
> code' as a 'retard'; it now becomes that the author might not have been
> referring to 'coders' but to Perl-slingers. It was wrong of me,
> obviously, to conclude that a 'person writing the code' might be writing
> anything *but* Perl... say, BAL, FORTRAN or COBOL.
<From way off yon in c.l.p.m>
Well, if the shoe fits...
:-)
--
Jerome O'Neil, Operations and Information Services
Atrieva Corporation, 600 University St., Ste. 911, Seattle, WA 98101
jer...@atrieva.com - Voice:206/749-2947
The Atrieva Service: Safe and Easy Online Backup http://www.atrieva.com
Larry Rosler
In article <374f...@cs.colorado.edu> on 28 May 1999 16:37:07 -0700, Tom
Christiansen <tch...@mox.perl.com> says...
> In comp.lang.perl.misc,
> l...@hpl.hp.com (Larry Rosler) writes:
> : s?printf '...19%d...', ..., $year, ...;
> :will be next, I presume?
>
> Yup, remarkably enough. Check out the p5p archives for discussion of the same.
> Feel free to kibbitz^Wcontribute.
You are right -- it is remarkable, in fact, incredible. At least it is
labeled Y2K_HACK :-).
All the tests seem to focus on '19%02d' and none mention '19%.2d' which
is equivalent and (in some cases, though not in this) superior. Perhaps
someone will note that and include it. Not me, though -- I don't have
more than the 24 hours a day or so that I seem to spend in the
comp.perl... newsgroups, mostly this one. Maybe if/when I retire from
my full-time job.
--
(Just Another Larry) Rosler
docd...@clark.net
Sam Holden <sho...@cs.usyd.edu.au> wrote:
>On Fri, 28 May 1999 22:27:15 GMT, docd...@clark.net <docd...@clark.net> wrote:
>>In article <op1wvxs...@newbridge.com>, bj <br...@newbridge.com> wrote:
>>>
>>>Are you saying that you have a standard that states you must take the
>>>output of the years field in localtime and concatenate it to "19" to
>>>produce a correct 4 digit date?
>>
>>comp.software.year-2000 which had referred to the 'person writing the
>>code' as a 'retard'; it now becomes that the author might not have been
>>referring to 'coders' but to Perl-slingers. It was wrong of me,
>>obviously, to conclude that a 'person writing the code' might be writing
>>anything *but* Perl... say, BAL, FORTRAN or COBOL.
>
... and others would realise that after a few responses a thread can be
rather... tangentially related to the subject.
>
>Though cross posting always confuses the hell out of every one...
You mean this *isn't* where I can get binaries of a naked platypus?
DD
docd...@clark.net
Jerome O'Neil <jer...@atrieva.com> wrote:
>docd...@clark.net wrote:
>> Oh dear, my apologies... I had expanded upon a posting which I found in
>> comp.software.year-2000 which had referred to the 'person writing the
>> code' as a 'retard'; it now becomes that the author might not have been
>> referring to 'coders' but to Perl-slingers. It was wrong of me,
>> obviously, to conclude that a 'person writing the code' might be writing
>> anything *but* Perl... say, BAL, FORTRAN or COBOL.
>
>
>Well, if the shoe fits...
Well, I write code, sure... as for my own retardation I'll opine no
opinions. Consider Wittgenstein's question of 'Imagine a parrot saying 'I
don't understand a word i say', is there Truth there?'... imagine a retard
saying 'I am/am not a retard'...
DD
Ilya Zakharevich
> > In your infinite wisdom you may be interested to know that 5.00558 may
> > contain code not *that* dissimilar to the above suggestion.
>
> As history has shown you to be incapable of humor, Ilya,
Sorry to see you in the camp of the people who need smilies to
recognize humourous posts.
> I must take you seriously.
> I thought that DWIMming was based on syntactic analysis. Applying it to
> the contents of string literals takes it to new heights (depths?).
>
> s?printf '...19%d...', ..., $year, ...;
>
> will be next, I presume?
This is not "next". This is exactly what the next version of Perl may
detect (given that $year comes from localtime()).
Ilya
fin...@ts.co.nz
tch...@mox.perl.com (Tom Christiansen) wrote:
> [courtesy cc of this posting mailed to cited author]
>
> In comp.lang.perl.misc,
> :happens if the person writing code is not a 'retard' but the specs
demand
> :certain standards be adhered to.
>
> Have you considered toiling under a slightly less mind-numbingly
> fascist regime?
>
> --
Tom's right here - for once! Most IT departments allow programmers to do
whatever they like in programs. 99.99% of the time if we don't like the
spec we do what we like - who looks at our code anyway?
Can't tell me programmers 'were made to do it that way'. That excuse
for Y2K botch ups looks lame to me. We prima donnas have always been
able to do pretty much anything we like with the code. Can't see any
manager telling a programmer what to do and run the risk of him/her
quitting in a huff! Or worse still, coming back at them with some techno
rave guaranteed to make no sense, therefore making them look stupid.
Which is of course the whole intention. Good trick that - if the
non-initiated look like they are grasping a little of the techno stuff,
turn up the jargon knob enough notches to really confuse them.
No, you're right Tom - if the spec is stupid or we just plain don't like
it, we can still do it however we like - and no-one is ever going to
know. And chances are if and when they do find out, we'll be long gone.
So, DD, your workplace must be in the minority. What, you get specs?
They actually specify what is to happen at code level? Maybe you even
have standards? And there's someone around to police them? They actually
look at your code?
Of the 100 or so work environments I have programmed in I can't even
think of one that has been so draconian. You are most unfortunate!
Guaranteed your creative abilities won't be stifled in your next job.
Unless you are extremely unfortunate.
Jonathan Stowe
> In article <374e...@newsread3.dircon.co.uk>,
> Jonathan Stowe <gell...@gellyfish.com> wrote:
>> In comp.lang.perl.misc Lane Core Jr. <elc...@sgi.net> wrote:
>> > On 27 May 1999 22:47:28 -0400, Uri Guttman <u...@sysarch.com> wrote:
>> >
>> >>so fucking what if cgi
>> >>routines and perl routines can be infected with y2k. that is the
>> >>programmers problem and not the language's.
>> >
>> > same with cobol.
>> > same with any language.
>>
>> Not entirely true - there are languages with a DATE type that is
> completely transparent to the programmer:
>>
> <SNIP - geek stuff>
Oh I am sorry but if you are going to get involved in a thread like this
with real programmers, real analysts and real engineers then you are going
to have to deal with it.
Oh and it was Informix 4GL not really a great favourite with the 'Geek' set.
>>
>> I love it when it when a crosspost goes bad ...
>
And I mean this most sincerely folks: the poor people in
comp.software.year-2000 must be wondering what they done to deserve it.
> Lane's point still holds - a programmer can create Y2K problems in COBOL
> and in Perl. Just because a particular language makes this particularly
> easy to do (as with Perl and as with languages that have non-compliant
> components) doesn't change the fact.
>
I'm afraid your logic has confounded me there. The second sentence doesnt
seem to belong in the same paragraph as the first.
Asserting that a language makes it easy to create Y2K problems is totally
bogus. Programming is not supposed to be easy. Programmers are supposed
to know what they are doing; they are supposed to read the documentation.
You might as well be ranting on in comp.lang.c about 'The core dump problem
and programmer denial' for all its value.
> Y2K problems can occur in applications written in any programming
> language and all programming languages can be used to write non-Y2K
> problem applications.
>
Sure if the person writing those programmes is inept, if they havent paid
a bit of notice what the documentation says about date handling or perhaps
worse they didnt understand or chose to ignore it. In the aforementioned
Informix 4GL they would have to go out of their way to do so of course
because of the DATE type - an Informix installation need be configured
once and it will cause all date representaions with two digit years to
be thrown out as an invalid date format (right or wrong who knows ?).
Thinking about it where did this $year = '19' . $year originate anyhow ?
Who here, in the abscence of the documentation of course, seeing that
localtime returned a 2 digit year would have prepended the century rather
than add 1900 even in total ignorance of what it actually was, because it
is after all a number rather than a string.
>> I think that uri's point is that basically if someone is too dumb to
> have read and understood the documentation for the localtime function
> then its basically tough shit - it is not a problem with Perl its a
> problem with the meatware.
>> /J\
>> --
>> Jonathan Stowe <j...@gellyfish.com>
It really is rather lame to quote peoples signatures unless you have
some point to make thereof.
>
> Tough shit for who? Just think about it. Who is going to suffer from all
> this denial and ignorance the most?
Er. People, Consultants like you have no contribution to make but to
snipe from the sidelines whilst the real programmers get on and do their
work properly as they always have done. People who got whipped up into
a financial feeding frenzy by all of the hype over the so called
'Millenium Bug' and figured they'd cash in too only to discover all the
really juicy targets had all been covered. Baby you just bombed the
Chinese Embassy.
Neither I nor any of the other contributors to this newsgroup are denying
that there are 'programs' out there that have made incorrect use of the
year value as returned by localtime: but we also know of other 'programs'
which run the risk of failing *every time they are run* because their
authors had failed to consult the documentation or understand it: do we
see a great community hand wringing for this latter group as you seem
to suggest we should for the former? I dont own a hair shirt, but if
I did I certainly wouldnt have any intention of wearing it just because a
programming language that I use is misused by others.
And believe neither I nor the majority of Perl Programmers are going to
get upset when some Script Kiddies guestbook or discussion board ceases
to work at the beginning of January next year.
> There is certainly a problem Perl
> developers if they can be so blase about the consequences of Y2K
> problems within the organisations which use the Perl progranmming
> language.
>
And what, pray tell, are we supposed to do about it ? Form the 'Perl
Localtime Abuse Cabal Action Team' (PLACATE for all of you who like
acronyms) put on ski masks, kick down the door of Matt Wrights bedroom
and fix all of his scripts before Big Ben rings twelve ? Come over all
Perl-O-Cop : 'You-Have-Two-Hundred-and-Twenty-One-Days-to-make-your-code
compliant' ? Hey, we could change the Artistic Licence to contain a
clause that makes it illegal to run perl against code that misuses
localtime() and take all those nasty perps to court. Come on, tell us
what *you* think we should be doing about it - given that every last one
of us (that is professional programmers not the others) is sure that we
have not created nor maintain any code that perpetuates misuse of date
values in Perl or at least certainly know what to be fixed.
But the worrying thing here is I still dont know where you are coming from.
/J\
--
Jonathan Stowe <j...@gellyfish.com>
Some of your questions answered:
<URL:http://www.btinternet.com/~gellyfish/resources/wwwfaq.htm>
Hastings: <URL:http://www.newhoo.com/Regional/UK/England/East_Sussex/Hastings>
Chris Nandor
# In article <slrn7klkcn....@diac.com>,
# sit...@diac.com (Sitaram Chamarty) wrote:
# >
# > I think the lady means "that real world in which "consultants" can
# > make lots of moolah by spreading unnecessary FUD about Y2K, and
# > where they (as well as trial lawyers) are panicking at the thought
# > of NOTHING major happening, and trying their damnedest to make hay
# > before the sun starts shining again".
# >
# So, you work for nothing do you? When do you get your sainthood?
I work for nothing. I spend hundreds of hours a year programming cool
stuff for other people because that's what I like to do. I don't expect
sainthood, just a simple "thank you" now and again. Though sometimes I
feel guilty for expecting that, but no one is perfect.
# Whether a method of instructing a computer can be deemed a programming
# language, scripting language, interface language, job control language
# or some other esoteric jargon you would care to name, is a grey area
# that I don't wish to debate. The fact is that CGI shares the same Y2K
# booby-trap problem as Perl. Fixing Y2K problems is more important than
# playing stupid semantics.
That is a completely ignorant statement. CGI has no Y2K problem. CGI
doesn't have any date functions or data structures. It cannot create or
return a date. CGI cannot have Y2K problems. It is only an interface.
That's like saying my computer screen has Y2K problems. It is not "stupid
semantics", it is just plain stupid.
In article <7ikqh8$jv4$1...@nnrp1.deja.com>, you wrote:
# If Perl code can be infected with Y2K problems, then so can CGI routines
# - deny that if you can!
There is no such thing as a CGI routine, though. Never has been, never
will be.
And of course, you still maintain that Perl has Y2K problems when it
doesn't. Only programmers of Perl (and every other language) have Y2K
problems.
You can claim that localtime() returning years since 1900 is a design
flaw, I suppose, but that's useless to do, as it cannot be changed and
doesn't help anything to call it a flaw, and it is perfectly compliant
with the available standards. Certainly, there is no evidence to prove it
is a flaw, all it is is an opinion. A valid opinion, I suppose, but only
an opinion, not a fact. It is good to let people know that localtime()
returns years since 1900, for those that don't already know it, but to
blame it on Perl or its very clear and accessible documentation is wrong.
In article <7imt5t$3ep$1...@nnrp1.deja.com>, fin...@ts.co.nz wrote:
# Lane's point still holds - a programmer can create Y2K problems in COBOL
# and in Perl. Just because a particular language makes this particularly
# easy to do (as with Perl and as with languages that have non-compliant
# components) doesn't change the fact.
There is nothing non-compliant about Perl. Stop lying. There is no
recognized standard that says all years must be returned in years since
year 0. In fact, it is the other way around: Perl is compliant with the
recognized standards that call for it to return years since 1900.
# Tough shit for who? Just think about it. Who is going to suffer from all
# this denial and ignorance the most? There is certainly a problem Perl
# developers if they can be so blase about the consequences of Y2K
# problems within the organisations which use the Perl progranmming
# language.
Who's blase about it? We tell people how to program properly. We tell
them to read the docs, give them examples of what to do and what not to
do. In our own programs, we program properly and in our organizations we
make sure others do, too, when it is possible to do so. After all that,
if people refuse to read the docs, refuse to think properly, refuse to
code properly ... it's just not something I or most reasonable people are
going to stay up worrying about. Some things are out of my control, and
the stupidity of other people is one of them.
--
Chris Nandor mailto:pu...@pobox.com http://pudge.net/
%PGPKey = ('B76E72AD', [1024, '0824090B CE73CA10 1FF77F13 8180B6B6'])
Jonathan Stowe
Awesome. Does this mean that perl will keep track of the source of the
value of each variable in order to prevent possible mis-use of that value?
Unless I miss something that means that the concept of variable will be
expanded to keep track of whatever the RHS of an assigment was. But
how can that work to include any lvalue such as substr() ? Or have I
just been negligent in not reading p5p ?
Chris Nandor
# Lane's point still holds - a programmer can create Y2K problems in COBOL
# and in Perl. Just because a particular language makes this particularly
# easy to do (as with Perl and as with languages that have non-compliant
# components) doesn't change the fact.
Flexible languages are inherently more broken! Woop! And because I can
easily crash my computer with C, C is broken, too.
Perl doesn't just have Y2K problems, though. It has compiler problems.
Witness this perfectly good code:
if ($x == 1)
print $x;
perl reports that this obviously proper code has syntax errors! If code
this simple doesn't compile, it must be the language's fault.
I mean, I know the documentation says this is wrong, but we don't trust
documentation, because "we are accustomed to writers of technical manuals
giving obscure explanations instead of simple answers."
This syntax is very standard, and doesn't work in Perl, so Perl must be
non-compliant and broken.
Ilya Zakharevich
<gell...@gellyfish.com>],
who wrote in article <7iopen$2i2$1...@gellyfish.btinternet.com>:
> >> I thought that DWIMming was based on syntactic analysis. Applying it to
> >> the contents of string literals takes it to new heights (depths?).
> >>
> >> s?printf '...19%d...', ..., $year, ...;
> >>
> >> will be next, I presume?
> >
> > This is not "next". This is exactly what the next version of Perl may
> > detect (given that $year comes from localtime()).
> >
>
> Awesome. Does this mean that perl will keep track of the source of the
> value of each variable in order to prevent possible mis-use of that value?
Each value? Why? Just mark a year returned from localtime() by
attaching a MAGIC. (But this is not how the currently available patch
is implemented - this were just my old only-20%-serious suggestions.
But people actually *started to implement* these ideas.)
> Unless I miss something that means that the concept of variable will be
> expanded to keep track of whatever the RHS of an assigment was. But
> how can that work to include any lvalue such as substr() ?
I have no idea what you are talking about in these sentences.
Ilya
fin...@ts.co.nz
M....@ulcc.ac.uk (Malcolm Ray) wrote:
>
> Programming should not be done by guesswork.
Yes, we all have opinions on how programming should be done and who
should be doing it. But thats not going to solve the immediate problem
of existing code thats wrongly programmed. Is that not more of a concern
right now? What have you and other Perl developers done about that? Will
all Perl Y2K problems that occur be non-critical? Does the Perl
community take no responsibility in ensuring that Perl developers get
the message that there is a need to check Perl code for Y2K problems?
Particularly if there is the chance that they have not fully understood
the usage of localtime.
fin...@ts.co.nz
sit...@diac.com (Sitaram Chamarty) wrote:
> On Thu, 27 May 1999 14:36:01 GMT, fin...@ts.co.nz <fin...@ts.co.nz>
wrote:
>
> >Tom, thought you may be interested to know that I'm not the only
> >mis-guided soul using the term "programming language" to describe CGI
> >for expedience.
>
> You may have used it for "expedience" to start with - although I
> doubt that. But you cannot hide behind that word now, after
> arguing vociferously with everyone here that it *is* indeed a
> language. A full paragraph is not "expedient" in any way.
>
> Give it up, sister!
>
In the same section of my article I also included CICS, MVS and
Javascript - all of which could be disputed as being a programming
language. For the purposes of the article, in which I tried to avoid as
much jargon as possible, it was convenient to describe them as
programming languages, as programmers use them for
instructing computers i.e. programming. My point was to draw attention
to these languages as having a problem - which they do. You are only
arguing semantics because you are unable to sucessfully argue against my
main point which is that the Perl programming language is Y2K booby
trapped.
You would do the Perl community more credit by working on Y2K awareness,
not clouding the issue unecessarily.
Alan J. Flavell
> Yes, we all have opinions on how programming should be done and who
> should be doing it. But thats not going to solve the immediate problem
> of existing code thats wrongly programmed.
You seem to be wanting to ignore what the programmer specified, and
guess what they wanted instead. Excuse me, but I think this kind of
approach is ultimately doomed. If the specification is wrong, then
change the specification, don't just ignore it. In this case, the
specification is very simple and clear. I'm well aware that some have
preferred to ignore it, but I don't accept that ignoring the
specification and guessing what they really wanted is any kind of
solution.
> Does the Perl
> community take no responsibility in ensuring that Perl developers get
> the message that there is a need to check Perl code for Y2K problems?
> Particularly if there is the chance that they have not fully understood
> the usage of localtime.
Perl has no Y2K problems. That is clearly documented.
The Perl community took responsibility for making comprehensive
documentation available. I take my hat off to them (or would, if I wore
one). Those who preferred superstition over reading the documentation,
and thereby created Y2K problems where there were no Y2K problems, must
accept the responsibility for what they did.
Eric Bohlman
: The Perl community took responsibility for making comprehensive
: documentation available. I take my hat off to them (or would, if I wore
: one). Those who preferred superstition over reading the documentation,
: and thereby created Y2K problems where there were no Y2K problems, must
: accept the responsibility for what they did.
And those who preferred facts over superstition have no special
responsibility to the superstitious coders.
Jocelyn has made it pretty clear that the target audience for most of
her writing is PWPH (People With Pointy Hair). They're known to be more
responsive to FUD than facts. Usenet provides plenty of opportunities to
observe the interesting sociological phenomena that happen when someone
accustomed to a FUD-receptive audience suddenly finds him or herself in
front of a fact-receptive audience (probably the most famous case on
Usenet involved Andrew Milne, a PR writer for the Church of Scientology.
His posting history came to an abrupt end after the Co$ lost a court case
(Spaink, et.al.) in the Netherlands and he posted a press release
claiming the Co$ had won the case).
Lane Core Jr.
Eeckels) wrote:
>In article <374ed9b7...@news.sgi.net>,
> elc...@sgi.net (Lane Core Jr.) writes:
>> On 28 May 1999 12:04:34 +0100, Jonathan Stowe
>> <gell...@gellyfish.com> wrote:
>>
>>>I think that uri's point is that basically if someone is too dumb to have
>>>read and understood the documentation for the localtime function then its
>>>basically tough shit - it is not a problem with Perl its a problem with
>>>the meatware.
>>
>> Yeah, but it's still a problem. :-(
>But most emphatically *not* a Perl problem. If you use your
>Toyota to kill a couple of pedestrians it is *your* problem,
>not Toyota's.
Most emphatically not a COBOL problem then, either. :-^
---------------------------------------------------------------------------
Mr. Lane Core Jr. elc...@sgi.net http://users.sgi.net/~elcore/elc_y2k.htm
---------------------------------------------------------------------------
"More software projects have gone awry for lack of calendar time than for
all other causes combined". Frederick P. Brooks, _The Mythical Man-Month_
Tom Christiansen
:In the same section of my article I also included CICS, MVS and
:Javascript - all of which could be disputed as being a programming
:language.
MVS is clearly not a programming language. Javascript, equally clearly,
*is* a programming language, albeit an ill-regarded one. That you can
equivocate -- or prevaricate -- here suggests what a tattered patchwork
your understanding must really be.
:For the purposes of the article, in which I tried to avoid as
:much jargon as possible,
To the contrary, you avoided as much *technical accuracy* as possible.
Now with each posting refusing to admit the wrong, you just dig the
hole that much deeper.
--tom
--
I am a little more weird today than normal. --Andrew Hume