1. We're All Doomed (Programmers, That Is)
http://pw2.netcom.com/~rogermw/Y2038.html
-=ck
"Programming in a state of Euphoria."
http://www.cklester.com/euphoria/
2. Re: We're All Doomed (Programmers, That Is)
- Posted by "Brian K. Clark" <bkc02 at health.state.ny.us>
Mar 01, 2006
-
Last edited Mar 02, 2006
How about a euphoria program that illustrates the problem? Callin' you
slicksters out.
Gnu-B
cklester
<guest@RapidEupho
ria.com> To
EUforum at topica.com
03/01/2006 02:08 cc
PM
Subject
We're All Doomed (Programmers, That
Please respond to Is)
EUforum at topica.co
m
http://pw2.netcom.com/~rogermw/Y2038.html
-=ck
"Programming in a state of Euphoria."
http://www.cklester.com/euphoria/
3. Re: We're All Doomed (Programmers, That Is)
- Posted by Vincent <darkvincentdude at yahoo.com>
Mar 01, 2006
-
Last edited Mar 02, 2006
cklester wrote:
>
> <a
> href="http://pw2.netcom.com/~rogermw/Y2038.html">http://pw2.netcom.com/~rogermw/Y2038.html</a>
>
> -=ck
> "Programming in a state of Euphoria."
> <a
> href="http://www.cklester.com/euphoria/">http://www.cklester.com/euphoria/</a>
In the year 2038, the C programming language will be around 70 years old and C++
will be around 60 years old. Programming languages just dont live that long
unless they're virtually completely redesigned for modern times.
That means they will be ancient languages that would be older than Fortran and
Cobol today. Who would still be developing with such old languages? Who would
still be using software developed with those languages?
Besides by 2038 probably only 128 bit computers will be in use. Perhaps even
some full scale quantum computers as well. This C time function is only a problem
with 32 bit software and computers.
Regards,
Vincent
4. Re: We're All Doomed (Programmers, That Is)
- Posted by Al Getz <Xaxo at aol.com>
Mar 01, 2006
-
Last edited Mar 02, 2006
cklester wrote:
>
> <a
> href="http://pw2.netcom.com/~rogermw/Y2038.html">http://pw2.netcom.com/~rogermw/Y2038.html</a>
>
> -=ck
> "Programming in a state of Euphoria."
> <a
> href="http://www.cklester.com/euphoria/">http://www.cklester.com/euphoria/</a>
Hi there,
Who uses time_t anymore anyway?
Take care,
Al
And, good luck with your Euphoria programming!
My bumper sticker: "I brake for LED's"
5. Re: We're All Doomed (Programmers, That Is)
- Posted by "Greg Haberek" <ghaberek at gmail.com>
Mar 01, 2006
-
Last edited Mar 02, 2006
> http://pw2.netcom.com/~rogermw/Y2038.html
This is also known as the "Unix Epoch" and will plague society just
like the Y2K bug did in and around 1999. So in 2037 or so, we'll all
start to panic.
However, it is my guess that about 99% of the computers in 20 years
will be 64-bit. So instead of a maximum time_t of 2,147,483,647 the
maximum would be 18,446,744,073,709,551,615. That's over eight billion
times as long! I don't think we have anything to worry about. Last
time I checked, the Y2K bug had only affected like 4 people as of
January 2nd, 2000 (which oddly enough was my 16th birthday :).
~Greg
6. Re: We're All Doomed (Programmers, That Is)
- Posted by cklester <cklester at yahoo.com>
Mar 01, 2006
-
Last edited Mar 02, 2006
Guys, guys, GUYS! When instigating a panic, you never EVER reveal reality.
COME ON!!!
And I was going to make so much money, too. :P
-=ck
"Programming in a state of Euphoria."
http://www.cklester.com/euphoria/
7. Re: We're All Doomed (Programmers, That Is)
Vincent wrote:
> That means they will be ancient languages that would be older than Fortran and
> Cobol today. Who would still be developing with such old languages? Who would
> still be using software developed with those languages?
There are thousands of large institutions (banks, airlines, insurance
companies, governments) still using software written in Fortran, Cobol,
Algol, etc.
I don't see that changing for a very long time.
--
Craig
8. Re: We're All Doomed (Programmers, That Is)
Vincent wrote:
>
> In the year 2038, the C programming language will be around 70 years old and
> C++ will be around 60 years old. Programming languages just dont live that
> long
> unless they're virtually completely redesigned for modern times.
I would say that's incorrect. Fortran 77 is stil the de facto Fortran standard
despite Fortran 2003 being the newest standard. Occasionally I'll even run into
Fortran 66 code that I need to work on. The same is true with Cobol, Cobol 2002
is the newest standard but no one uses it instead opting for Cobol-85. We're
seeing the same with C now. K&R C is still used in some places (legacy code only
though, no one really writes new K&R C code anymore) but ANSI C (1989) is the de
facto standard despite C99 being specified. The most up to date C compiler? The
Risc OS C compiler. Microsoft, Borland, and Sybase (Watcom) aren't adding many
C99 features. GNU CC is doing fairly well but still isn't completely compatible.
So unless you use Risc OS (which few people do and most are confined to the UK)
you technically don't program in standard C. Although, GCC and to a lesser extent
Watcom are catching up.
> That means they will be ancient languages that would be older than Fortran and
> Cobol today. Who would still be developing with such old languages? Who would
> still be using software developed with those languages?
Well, I work as a sometimes Fortran programmer and despite inroads made by
Matlab and its ilk Fortran is still the primary scientific programming language.
Also, most companies that already use Cobol continue to use Cobol. In fact, Cobol
is still the most used language for new programming projects despite being
"obsolete". Lisp is still going strong as well and is the backbone of Yahoo!
Store and Orbitz. I guarantee that those languages will still be in use by 2038
as well.
> Besides by 2038 probably only 128 bit computers will be in use. Perhaps even
> some full scale quantum computers as well. This C time function is only a
> problem
> with 32 bit software and computers.
32-bit processors were first introduced in the mid to late 70s and didn't become
ubiquitous until the early to mid 90s. 64-bit processors were introduced in the
early 90s and are just starting to become popular in workstations. So we'll
probably see 64 bit CPUs in wide adoption by 2010 or 2015. This shows a cycle of
20 to 25 years so 128 bit won't become big by at least 2035 or 2040 assuming that
this trend holds and there's a general purpose 128 bit CPU by 2015.
The Euphoria Standard Library project :
http://esl.sourceforge.net/
The Euphoria Standard Library mailing list :
https://lists.sourceforge.net/lists/listinfo/esl-discussion
9. Re: We're All Doomed (Programmers, That Is)
Okay, how about this...
When I say I write code in RPG most non-RPG programmers get a goofy smile on
their face as if to say "Do you have any drive-thru experience?". The fact is
that RPG is still alive and kicking...AND still getting updated! AAMOF, there's
a movement that just started where people in the iSeries/i5 community want IBM to
change the name of the language. RPG stood for Report Program Generator. That
is FAR from true any more. I'm currently working on a project to generate
spreadsheets on the host to be emailed to salesman. The "outdated" RPG code
looks like:
// Create a row
rowcount += 2;
row = HSSFSheet_createRow(sheet:rowcount);
// Output the customer information
hssf_text(row:secbtx_c:
%trim(%editc(secanb:'Z')) + '-' +
%trim(seb9cd) + ' ' + %trim(secltx) + ' ' +
%trim(secptx):
ColHeadingL);
hssf_merge(sheet:rowcount:secbtx_c:rowcount:seitdsc_c);
And NO, this is not a C program.
The platform this is written on is and has been 64 bit since ~1994. It used to
be known as AS/400. Now it's called i5. Oh and by the way, you might recognize
the above hssf_ calls as being the Java package from Apache.org that lets you
create Excel spreadsheets. That's right, calling Java procedures.
Who uses this "old" IBM equipment, you ask? Wal-Mart, Costco, Sam's, Walgreens,
Enterprise Rent-a-Car, just to name a few.
Sorry, I just realized I was in rant mode.
Jonas Temple
http://www.yhti.net/~jktemple
10. Re: We're All Doomed (Programmers, That Is)
Attn Derek Newhall and/or other Euphoria/Fortran programmers
Many moons ago I posted this:
-- begin quote:
Date: Wed, 15 Apr 1998 18:35:05 -0400
Subject: Euphoria Programing Project
Comments: To: Euphoria Mailing List <EUPHORIA at MIAMIU.ACS.MUOHIO.EDU.>
Hello All:
Herein you will find a link to a page where a classic NASA document
regarding geodesic structures can be downloaded in adobe pdf format. The
document contains a mathmatical model for the derivation of geodesic
structures and an "ancient" Fortran program (vintage c. 1972) replete with
comments and flow chart.
I have thought that it would be interesting and useful to see this program
ported to Euphoria. It appears well beyond my abilities to do so... and
indeed I have sought assistance from an able programmer on the list who I
believe could have successfully ported the program had we been able to
understand the Fortran program.
Jay Salzburg has recently made the document available on the net in pdf
format and now easily accessible without cost ( $25 from NASA.... and a
sloppy zerox before ). Therefore, I thought I would suggest this document
to those of you who may be interested in a programming challenge. Here is
the url:
http://www.salsburg.com/geod/geod.html -- url updated March 2, 2006
Further comments:
There is a freeware program available on the net which does more and less
than the one described in this NASA document. This program "Dome 4.6" by
Ric Bono is available at: http://www.cris.com/~rjbono/html/domes.html
Bono's program is written in C++ (Borland 4.5, DOS) and is copyrighted
freeware available with source code under a GNU license. Bono specifically
provided the source code in case someone was interested in porting the
program to another language. A Euphoria port of this program, or parts of
it would certainly be interesting...
Yet, the older NASA program implements one important calculation that Bono's
program has yet to implement.... it calculates dihedral angles. I realize
that much of this may be of no interest to those of us who are not
interested in geodesic structures. I only wanted to note that I am aware of
Bono's very useful program, but I feel that a port of the program delineated
in the NASA document is of value.
Enough said. Please let me know if you decide to go for it. And if you
have any questions that you feel I might be able to help you with you can
correspond with me directly at the address below:
-- end quote
Ken Rhodes
100% MicroSoft Free
SuSE Linux 10.0
No AddWare, SpyWare, or Viruses!
Life is Good 
11. Re: We're All Doomed (Programmers, That Is)
Al Getz wrote:
>
> cklester wrote:
> >
> > <a
> > href="http://pw2.netcom.com/~rogermw/Y2038.html">http://pw2.netcom.com/~rogermw/Y2038.html</a>
> >
> > -=ck
> > "Programming in a state of Euphoria."
> > <a
> > href="http://www.cklester.com/euphoria/">http://www.cklester.com/euphoria/</a>
>
> Hi there,
>
>
> Who uses time_t anymore anyway?
>
>
> Al
>
>
> My bumper sticker: "I brake for LED's"
Still waiting for an answer :)
Take care,
Al
And, good luck with your Euphoria programming!
My bumper sticker: "I brake for LED's"
12. Re: We're All Doomed (Programmers, That Is)
- Posted by Jason Gade <jaygade at yahoo.com>
Mar 02, 2006
-
Last edited Mar 03, 2006
Kenneth Rhodes wrote:
>
> Attn Derek Newhall and/or other Euphoria/Fortran programmers
>
> Many moons ago I posted this:
>
> -- begin quote:
>
> Date: Wed, 15 Apr 1998 18:35:05 -0400
> Subject: Euphoria Programing Project
> Comments: To: Euphoria Mailing List <EUPHORIA at MIAMIU.ACS.MUOHIO.EDU.>
>
> Hello All:
>
> Herein you will find a link to a page where a classic NASA document
> regarding geodesic structures can be downloaded in adobe pdf format. The
> document contains a mathmatical model for the derivation of geodesic
> structures and an "ancient" Fortran program (vintage c. 1972) replete with
> comments and flow chart.
>
> I have thought that it would be interesting and useful to see this program
> ported to Euphoria. It appears well beyond my abilities to do so... and
> indeed I have sought assistance from an able programmer on the list who I
> believe could have successfully ported the program had we been able to
> understand the Fortran program.
>
> Jay Salzburg has recently made the document available on the net in pdf
> format and now easily accessible without cost ( $25 from NASA.... and a
> sloppy zerox before ). Therefore, I thought I would suggest this document
> to those of you who may be interested in a programming challenge. Here is
> the url:
>
> <a
> href="http://www.salsburg.com/geod/geod.html">http://www.salsburg.com/geod/geod.html</a>
> -- url updated March 2, 2006
>
> Further comments:
> There is a freeware program available on the net which does more and less
> than the one described in this NASA document. This program "Dome 4.6" by
> Ric Bono is available at: <a
> href="http://www.cris.com/~rjbono/html/domes.html">http://www.cris.com/~rjbono/html/domes.html</a>
> Bono's program is written in C++ (Borland 4.5, DOS) and is copyrighted
> freeware available with source code under a GNU license. Bono specifically
> provided the source code in case someone was interested in porting the
> program to another language. A Euphoria port of this program, or parts of
> it would certainly be interesting...
>
> Yet, the older NASA program implements one important calculation that Bono's
> program has yet to implement.... it calculates dihedral angles. I realize
> that much of this may be of no interest to those of us who are not
> interested in geodesic structures. I only wanted to note that I am aware of
> Bono's very useful program, but I feel that a port of the program delineated
> in the NASA document is of value.
>
> Enough said. Please let me know if you decide to go for it. And if you
> have any questions that you feel I might be able to help you with you can
> correspond with me directly at the address below:
>
> -- end quote
>
> Ken Rhodes
> 100% MicroSoft Free
> SuSE Linux 10.0
> No AddWare, SpyWare, or Viruses!
> Life is Good
This sounds pretty cool, but I'm not sure if I have enough math background for
it. I've at least downloaded the two files and I can take a look at those.
--
"Any programming problem can be solved by adding a level of indirection."
--anonymous
"Any performance problem can be solved by removing a level of indirection."
--M. Haertel
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
13. Re: We're All Doomed (Programmers, That Is)
- Posted by ags <eu at 531pi.co.nz>
Mar 03, 2006
Al Getz wrote:
>
> Al Getz wrote:
> > Who uses time_t anymore anyway?
> >
> >
> > Al
> >
> >
> > My bumper sticker: "I brake for LED's"
>
>
> Still waiting for an answer :)
Hi Al
I was going to answer this but got side-tracked with work (which is not a bad
thing actually being at work at the time :)
I dug a bit into Linux's header files but got lost in the 10 level deep nested
#include <this.h> where this.h includes that.h etc etc.
I was looking to see whether the define for time_t was an explicit signed int or
the compiler somehow converted that to the machine specific word size.
My guess is that in the world of C 'signed int' means just that, ie 32 bits.
Upgrading to a 64-bit architecture might not necessarily automatically promote
this to 'signed long'.
So I tend to think there might be cause for concern here. Just because there's
new programming language being used at that time doesn't mean that it hasn't
actually been written in a 70 year old language. And even putting the issue of
new applications aside, if (say) Linux is still being used by then (which I'm
sure it will be) then that in itself uses a lot of time_t's for things like the
filesystem etc.
Of course, Linux being open source means that by that stage someone will have
done something about it by then. In fact I predict by then there will be
secluded monastaries up in the mountains devoted to the maintenance of the GNU
source code. (And we'll be flying around in our cars ... yeah right).
Gary
14. Re: We're All Doomed (Programmers, That Is)
- Posted by ags <eu at 531pi.co.nz>
Mar 03, 2006
ags wrote:
> I was looking to see whether the define for time_t was an explicit signed int
> or the compiler somehow converted that to the machine specific word size.
>
> My guess is that in the world of C 'signed int' means just that, ie 32 bits.
> Upgrading to a 64-bit architecture might not necessarily automatically
> promote
> this to 'signed long'.
I checked the comp.lang.c FAQ since I remembered something about 'how big an int
actually is' ie (bit messy sorry):
--begin FAQ
From these values, it can be inferred that char is at least 8 bits, short int
and int are at least 16 bits, and long int is at least 32 bits. (The signed and
unsigned versions of each type are guaranteed to have the same size.) Under ANSI
C, the maximum and minimum values for a particular machine can be found in the
header file <limits.h>; here is a summary:
Base type Minimum size (bits) Minimum value (signed) Maximum value (signed)
Maximum value (unsigned)
char 8 -127 127 255
short 16 -32,767 32,767 65,535
int 16 -32,767 32,767 65,535
long 32 -2,147,483,647 2,147,483,647 4,294,967,295
(These values are the minimums guaranteed by the Standard. Many implementations
allow larger values, but portable programs shouldn't depend on it.)
--end FAQ
Checking limits.h on Linux, it says int is 32 bits, and _if_ you're on a 64-bit
processor only long long is 64-bits.
So I'd day time_t would remain 32-bits even on a 512-bit processor...
Gary
