4 ms·

Im very curious what the HN community thinks this looks like. Any thoughts? Past research? Good examples?

angersock 11y ago
So, for long-lived projects, I'd honestly look at games. Out Of This World has survived, a couple decades of frenzied developments, as has Doom and Quake and Adventure and Zork. That gets you around the 20-30 year mark. I'd look at old Unix utilities like awk and sed. That gets you around 40 years. I'd look towards the banking industry at old COBOL credit-card processing and reporting code. That gets you into around 50 years. The interesting thing to note is that in the first two cases, long-term support was caused by reverse-engineering and by having the source available to port. As long as there is a machine with an integer unit, we have Doom. As long as there is a floating-point unit, we have Quake. The third case, though, relies on turducken VMs of 360s running on 370s running ZMachines running on...whatever comes next. For long-term support, one wonders how tenable this is.
- AnonNo15 11y ago
  Lets not forget things like BRL-CAD or SPICE. Also I wonder how old is the code in IBM JCL runtime/interpreter. The secret to longevity is continuos support, so it seems.
  - Semiapies 11y ago
    Yes. It's the keeping a program working when the last programmer to work on it is retired that's tricky.
- fintler 11y ago
  https://mcnp.lanl.gov/ https://mcnp.lanl.gov/ has been in development since at least 1957 (according to wikipedia) -- so 58 years, give or take. It looks like it might be even older than that, it looks like Enrico Fermi may have started it in 1947 (a note in the introduction of http://arxiv.org/pdf/1207.5076.pdf http://arxiv.org/pdf/1207.5076.pdf).
  - reirob 11y ago
    Interesting, from the history section in [1]: --- At Los Alamos, Monte Carlo computer codes developed along with computers. The first Monte Carlo code was the simple 19-step computing sheet in John von Neumann's letter to Richtmyer. But as computers became more sophisticated, so did the codes. At first the codes were written in machine language and each code would solve a specific problem. In the early 1960s, better computers and the standardization of programming languages such as Fortran made possible more general codes. [..] MCNP5, released in 2003, is rewritten in ANSI standard Fortran 90. It includes the addition of photonuclear collision physics, superimposed mesh tallies, time splitting, and plotter upgrades. MCNP5 also includes parallel computing enhancements with the addition of support for OpenMP and MPI. Large production codes such as MCNP have revolutionized science − not only in the way it is done, but also by becoming the repositories for physics knowledge. MCNP represents over 500 person-years of sustained effort. The knowledge and expertise contained in MCNP is formidable. --- So it seems that Fortran is already the 50-year programming language. [1]: https://laws.lanl.gov/vhosts/mcnp.lanl.gov/pdf_files/la-ur-03-1987.pdf https://laws.lanl.gov/vhosts/mcnp.lanl.gov/pdf_files/la-ur-0...
- Semiapies 11y ago
  I've been thinking about that last question. The closest I can imagine to a solution would be coding programs to run within stripped-down environments, the specifications for which would be included with the program. The system running the program would read that spec, generate a version of that environment (as a container/vm/whatever), and then start the program within it.
  - angersock 11y ago
    So, to offer a slightly stronger version of your requirements, we're needing to ship: 1. The program itself. 2. The behavioral specs for the program. 3. The behavioral specs for the runtime environment. 4. The configuration specs for the runtime environment. Somewhat hidden in there is the ability to read an aribitrary program, transmute it to another program. That can be hard--especially with a language like C++, where significant computation can occur during compilation.
    - kuschku 11y ago
      Soo, we’d use a lisp? With lisp macros setting up everything?
    - Semiapies 11y ago
      "Somewhat hidden in there is the ability to read an aribitrary program, transmute it to another program." There'd probably be cases where it'd fall short of that capability, but ultimately, if the desire is to make sure you can run an arbitrary current program on an arbitrary future computer, you probably have to get pretty close to that.
sp332 11y ago
A lot of Mathmatica is written in Mathematica. They said porting from PowerPC Macs to x86 Macs took less than a weekend.
- Semiapies 11y ago
  GNU Emacs would be similar in that regard.

So, for long-lived projects, I'd honestly look at games. Out Of This World has survived, a couple decades of frenzied developments, as has Doom and Quake and Adventure and Zork. That gets you around the 20-30 year mark. I'd look at old Unix utilities like awk and sed. That gets you around 40 years. I'd look towards the banking industry at old COBOL credit-card processing and reporting code. That gets you into around 50 years. The interesting thing to note is that in the first two cases, long-term support was caused by reverse-engineering and by having the source available to port. As long as there is a machine with an integer unit, we have Doom. As long as there is a floating-point unit, we have Quake. The third case, though, relies on turducken VMs of 360s running on 370s running ZMachines running on...whatever comes next. For long-term support, one wonders how tenable this is.

AnonNo15 11y ago
Lets not forget things like BRL-CAD or SPICE. Also I wonder how old is the code in IBM JCL runtime/interpreter. The secret to longevity is continuos support, so it seems.
- Semiapies 11y ago
  Yes. It's the keeping a program working when the last programmer to work on it is retired that's tricky.
fintler 11y ago
https://mcnp.lanl.gov/ https://mcnp.lanl.gov/ has been in development since at least 1957 (according to wikipedia) -- so 58 years, give or take. It looks like it might be even older than that, it looks like Enrico Fermi may have started it in 1947 (a note in the introduction of http://arxiv.org/pdf/1207.5076.pdf http://arxiv.org/pdf/1207.5076.pdf).
- reirob 11y ago
  Interesting, from the history section in [1]: --- At Los Alamos, Monte Carlo computer codes developed along with computers. The first Monte Carlo code was the simple 19-step computing sheet in John von Neumann's letter to Richtmyer. But as computers became more sophisticated, so did the codes. At first the codes were written in machine language and each code would solve a specific problem. In the early 1960s, better computers and the standardization of programming languages such as Fortran made possible more general codes. [..] MCNP5, released in 2003, is rewritten in ANSI standard Fortran 90. It includes the addition of photonuclear collision physics, superimposed mesh tallies, time splitting, and plotter upgrades. MCNP5 also includes parallel computing enhancements with the addition of support for OpenMP and MPI. Large production codes such as MCNP have revolutionized science − not only in the way it is done, but also by becoming the repositories for physics knowledge. MCNP represents over 500 person-years of sustained effort. The knowledge and expertise contained in MCNP is formidable. --- So it seems that Fortran is already the 50-year programming language. [1]: https://laws.lanl.gov/vhosts/mcnp.lanl.gov/pdf_files/la-ur-03-1987.pdf https://laws.lanl.gov/vhosts/mcnp.lanl.gov/pdf_files/la-ur-0...
Semiapies 11y ago
I've been thinking about that last question. The closest I can imagine to a solution would be coding programs to run within stripped-down environments, the specifications for which would be included with the program. The system running the program would read that spec, generate a version of that environment (as a container/vm/whatever), and then start the program within it.
- angersock 11y ago
  So, to offer a slightly stronger version of your requirements, we're needing to ship: 1. The program itself. 2. The behavioral specs for the program. 3. The behavioral specs for the runtime environment. 4. The configuration specs for the runtime environment. Somewhat hidden in there is the ability to read an aribitrary program, transmute it to another program. That can be hard--especially with a language like C++, where significant computation can occur during compilation.
  - kuschku 11y ago
    Soo, we’d use a lisp? With lisp macros setting up everything?
  - Semiapies 11y ago
    "Somewhat hidden in there is the ability to read an aribitrary program, transmute it to another program." There'd probably be cases where it'd fall short of that capability, but ultimately, if the desire is to make sure you can run an arbitrary current program on an arbitrary future computer, you probably have to get pretty close to that.

sp332 11y ago

A lot of Mathmatica is written in Mathematica. They said porting from PowerPC Macs to x86 Macs took less than a weekend.

Semiapies 11y ago
GNU Emacs would be similar in that regard.