Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Programming Apple Hardware Science

Will Your Code Run Ten Years From Now? (nature.com) 219

Nicolas Rougier, a computational neuroscientist and programmer at INRIA, the French National Institute for Research in Digital Science and Technology in Bordeaux, writes: I organized with [Konrad Hinsen, a theoretical biophysicist at the French National Centre for Scientific Research (CNRS) in Orleans] the "Ten Years Reproducibility Challenge," whose goal was to check if researchers would be able to run their own code that has been published at least ten years ago (i.e. before 2010). Most participants managed to run it, but it was not without pain. Today, Nature published an article summarizing the different problems we encountered. I myself tried to re-run an Apple II program I wrote 32 years ago on a vintage Apple IIe. This was quite instructive, especially regarding modern software system with the dependencies hell.
This discussion has been archived. No new comments can be posted.

Will Your Code Run Ten Years From Now?

Comments Filter:
  • by ls671 ( 1122017 ) on Tuesday August 25, 2020 @05:45PM (#60440507) Homepage

    I guess It depends which language you use, my 22 years old java 1.0 code still runs fine in current java versions but I have had less luck with php and other languages which don't run on latest distributions so you need unsupported and security risk releases of the OS and libs to run it. Upgrading and adapting your code is better in that case.

    • Java, C and C++ will all still work. Maybe C#. But most other languages are in so much flux that you're lucky if something you wrote five years ago will run.

      • by NFN_NLN ( 633283 )

        Any self contained language that has the library bundled with it can be installed clean and your code should work.
        Any code that relies on 3rd party libraries... good luck.

        Or are people asking if code written for an older compiler will work with the latest compiler?

      • Most things you write for the browser will still work, as long as you don't have dependencies other than the browser.
      • Don't forget code for PLCs and systems programmed in assembly language. I have programs (ladder, IL, function charts, etc.) that have been running for decades on PLCs. I also routinely update code running on these. The hard part is that for some of the older PLCs it is sometimes hard to get the programming environment to run on newer OSs---especially because of some license locks.
        Also many systems can be programmed in assembly code and their assembler code is in the wild (especially for some older proces

      • What if I've been using Common Lisp for the past almost two decades? I sure hope it will still run at least two-three more decades from now.
      • by arglebargle_xiv ( 2212710 ) on Wednesday August 26, 2020 @02:09AM (#60441603)

        In this case though the question wasn't about code in general, it was academic code. With academic code you're lucky if it survives a recompile.

        Seriously. I've got various pieces of code that came from academic projects where you need to freeze a VM with the one specific environment under which the code will build and run, because if you make the tiniest change to anything it'll break. And it's not just a specific config of a normal system, it's a massive collection of wierdo tools and binaries, a version of OCaml from an abandoned FTP site in France, a binary-patched gcc available via email from some beardy wierdo at UCSD if you send him a message with "Frogs" in the subject line, and some scripts written in functional Lisp that need to be interpreted by a tool running on Voyager 2, that's academic-grade code.

    • by twdorris ( 29395 ) on Tuesday August 25, 2020 @06:12PM (#60440593)

      Agreed. Say what you will about Java (much of it may be well deserved), but I've got 20 year old Java applications still being used on Windows and Linux as it was deployed 20 years ago...same code, same jar file bundle, just newer machines and newer OSes. Of course there are newer versions of those applications too that runs just as well, but if someone wants to run the original 1.0 stuff (and they do for whatever reason), it still compiles and builds and runs just the same as it did then. There aren't even any hoops to jump through. Install a modern JRE and run the app jar. It just works. Install a modern JDK and recompile the same 20 year old source just as well. Fire off the same Install4J project and build the installer just the same.

      Java's not everyone's cup of tea (pun intended), but the concept of "write once, run anywhere" has served me well for over two decades and I've not seen any reason to believe the same won't be true two decades from now (despite Larry's best efforts).

      • And I pretty much only worry about Java to access IPMI. And it's the biggest nightmare ever!

        I have virtual machines that are explicitly blocked from getting any updates so that I can keep this access working. Because after each JVM update it's hours and hours of work to get it working again.

        (Browser updates are equally problematic)

    • My java 1.4 code stopped running a month after I wrote it. So many things broke in the next release.

  • by jschultz410 ( 583092 ) on Tuesday August 25, 2020 @05:45PM (#60440511)

    That code will live a long time.

    • by gmack ( 197796 )

      Some of my older C99 code from 15 years ago works, but needs some small fixes with each new GCC version to handle the new compile warnings and some old code it now errors on. GCC has gotten more strict over time.

      Mind you that's not a bad thing and the fixed version will still work in older versions of GCC

  • by Camel Pilot ( 78781 ) on Tuesday August 25, 2020 @05:49PM (#60440529) Homepage Journal

    I have production Perl code that is over 20 years old still reading instruments (Opto22, RM Young weather, Power control outlets, 1wire temperature, etc.) and displaying data and plotting via GnuPlot. Our in-house developed operation/maintenance log is nearly 25 years old and still functional and being used with over 50 thousand MySQL entries comprising the knowledge base of our org.

    • by cas2000 ( 148703 ) on Tuesday August 25, 2020 @09:43PM (#60441071)

      Same here - I have several perl programs I wrote over 20 years ago still running just fine.

      I just checked on one that, according to the Revision History comments, I first wrote in Feb 1999. It's so old that I used RCS for version control.

      It's not a huge program, but not a trivial five-liner either - according to sloccount, it has 1294 lines of perl code. 961 LOC in the main script, the remainder in various support programs.

      ---

      BTW, while I've learned to ignore the white-space issue with python (resigned acceptance, not liking), one of the things I've come to really dislike about the language is how fragile it is - even minor version updates tend to break it. Which is why they came up with that #!/usr/bin/env abomination and all the virtualenv nonsense, I suppose.

    • Pretty much all my 20 yo code still runs.

      Times are different now, I guess. Or whatever their excuse is.

      • by dwywit ( 1109409 ) on Wednesday August 26, 2020 @12:03AM (#60441399)

        I haven't coded RPG II/III/400 on an AS400 since the late 1990s, but after finding a free public AS400 server (pub400.com), for the sake of interest I re-keyed a small program (I only had the fan-fold listing) that I'd written to put the brakes on system hogs (cue the long story about programmers given too much authority). It compiled without errors. The date on the listing is 1996.

        I can't run it, the account doesn't have QSECOFR status, but there's no reason it wouldn't run on the current hardware. That's one of the selling points of that system - binaries compiled for the first generation AS400 can be ported to each iteration of the hardware. That's *binaries* - you don't even need to recompile the source.

  • And several BIOS images that are still running after 25 years and will probably outlive me.
  • Who cares? (Score:5, Funny)

    by slapyslapslap ( 995769 ) on Tuesday August 25, 2020 @06:02PM (#60440563)
    This is why you change jobs at least every 5 years.
    • Re:Who cares? (Score:5, Insightful)

      by Weirsbaski ( 585954 ) on Wednesday August 26, 2020 @02:14AM (#60441609)

      This is why you change jobs at least every 5 years.

      I get that this was a joke, and it gave me a (small) chuckle, but it still touches a nerve- for those of us sticking to one company for more than a couple years, it's a huge, sucky PITA to have people dump volumes of crappy code into your jurisdiction, only to watch them move on to someplace else as the maintenance cost comes due.

      Not sure which is worse- that they're treating a group (that's unglamorous, but important to the company) as a short-term stepping-stone to something they consider "better", or that this strategy works with no repercussions (to them, at least).

      Ok, rant mode off.

      • by bartle ( 447377 )

        I get that this was a joke, and it gave me a (small) chuckle, but it still touches a nerve- for those of us sticking to one company for more than a couple years, it's a huge, sucky PITA to have people dump volumes of crappy code into your jurisdiction, only to watch them move on to someplace else as the maintenance cost comes due.

        Speaking as another long-term code maintainer, my irritation is that management tends to give new hires the new development work because they don't want to train them up on the existing code base. What happens though, more times than not, is that the new hire throws together something using their own techniques and coding styles, then quits without leaving behind any documentation. At that point, their code becomes my responsibility and usually I end up depreciating or rewriting it in order to bring it in l

  • Not likely (Score:5, Insightful)

    by BrainJunkie ( 6219718 ) on Tuesday August 25, 2020 @06:02PM (#60440565)
    My code barely runs today, I can't imagine it would last 10 years.
    • Re:Not likely (Score:5, Insightful)

      by avandesande ( 143899 ) on Tuesday August 25, 2020 @06:22PM (#60440613) Journal
      LOL, ever run across something you wrote a year ago and say 'who wrote this shit'?
      • I uysed to comment every line about what I was thinking. Not what it was doing but why it was done this way
        The next curator stripped it all out. I can't read my own code anymore.

        • by hcs_$reboot ( 1536101 ) on Tuesday August 25, 2020 @06:53PM (#60440709)
          It is well known that comments slow down the execution of a program
          • by mark-t ( 151149 )

            While of course comments do not actually down slow down execution of a program, they can ironically slow down the understanding of one.

            Because comments can lie. In the end, the only thing that tells you what the code does is the code itself, not the comments that you decorate it with. If you waste your time reading deprecated comments trying to undestand code, it will take you longer to understand what the code is doing than it would if you just read the code.

            Where I work currently, there is a requi

            • Re:Not likely (Score:5, Insightful)

              by mhotchin ( 791085 ) <slashdot@NOSPam.hotchin.net> on Tuesday August 25, 2020 @11:57PM (#60441385)

              That's crazy. Comments saying what the program does are of course redundant, but comments that describe *why* it does something, or why it *doesn't* do something, are pure gold.

              Do you want code monkeys? Because that's how you get code monkeys - people focused on the small, with no overall understanding.

              • by segin ( 883667 )
                Comments should be used on every function for it's API documentation. I think that's how Doxygen, et. al., work.
            • Re:Not likely (Score:4, Insightful)

              by angel'o'sphere ( 80593 ) <angelo.schneider ... e ['oom' in gap]> on Wednesday August 26, 2020 @12:56AM (#60441495) Journal

              it will take you longer to understand what the code is doing than it would if you just read the code.
              What the code is doing, is completely obvious.
              The question is: why is it doing it that way (strange code) or why it is coded that way (business requirement).

          • Slashdot comments, you mean.

        • Re:Not likely (Score:5, Insightful)

          by 140Mandak262Jamuna ( 970587 ) on Tuesday August 25, 2020 @07:38PM (#60440809) Journal
          Most important comments for me was to write down what is not there.

          Some function to find proximal triangles might look needlessly complex and stunning simple solution might seem obvious. But there will be comment there saying, "I tried this idea and it did not work out for these cases, so it was taken out. 1m2j 2004 May 14" so valuable.

          Write down the design intent and what the algo is trying to do, and some salient points of the method.

      • I see you're familiar with my work.

      • LOL, ever run across something you wrote a year ago and say 'who wrote this shit'?

        Try having a kid, then coding in their early years... Looking back at some of my code from that time, my "logic" did the job, but it was so un-necessarily convoluted I could hardly work out what it was supposed to do.

    • Given how diluted the average developer level is, more and more, in 10 years you will be considered a genius.
    • by gmack ( 197796 )

      I knew a programmer who never fixed compile warnings and kind of tweaked his code until it mostly did what he wanted. One day it exploded when he tried to compile it 64 bit. Eventually the weight of it all kind of made him lose interest.

      One day he finally left the company (there was some disagreement over whether he was let go or was fired. I spent a solid 2 weeks turning each compile warning on and fixing the warnings and suddenly 90% of the bugs were gone.

      So yeah, bad code can be recoverable

  • I have code still running in production from 22 years ago that I wrote, it hasn't required change in all that time and it has processed more than 10 billion transactions in that time connecting to an external system (just about all the code around it has changed, but the EDI I wrote is unchanged from day 1)
  • by sk999 ( 846068 ) on Tuesday August 25, 2020 @06:06PM (#60440573)

    ... will not compile without mods, in spite of the fact that it is fully compliant with ANSI Fortran 66. Reason is that current compiler maintainers insist on deprecating certain of F66's features.

    • Yeah, Fortran 66 was the first standardized version, but Fortran 77 was the first version that we could probably now characterize as "modern" (which is why it stuck around for so long). I suspect that the deprecated F66's features go back to Fortran IV or even further. I would expect that your program should work today without mods if it was in F77 since there is a huge amount of numerical libraries still in use that are written in F77.

  • I have asp.net, vb code easily ten years old that works just fine...as long as it was using the default controls that have been in asp.net forever. Some of the early ajaxcontroltoolkit controls? That stuff broke a long time ago. Third party controls? Somewhat work.

    Even updating the ajaxcontroltoolkit controls that broke is not hard. Going back to vb after using C# for a long time. Not really fun, but even that isn't that hard.

  • Visual Basic (Score:5, Interesting)

    by localroger ( 258128 ) on Tuesday August 25, 2020 @06:10PM (#60440581) Homepage
    I have VB code I wrote in the mid 1990's which is still running in production environments today. In fact I still use VB6 for new work and fully expect the executables to run 10 years from now. The key to VB3 upgrade is to forget dot-NET and get VB4, which came with both 16-bit and 32-bit compilers and IDE's. Both versions were highly compatible with the old byte-coded VB3, although much faster having a modern compiler. 32-bit VB4 binaries still run on a new machine today. (This is not true of all the plugins, alas. But the core language has better forward compatibility than early versions of .NET, which already won't run on a Windows 10 box.)
    • Re:Visual Basic (Score:5, Interesting)

      by pz ( 113803 ) on Tuesday August 25, 2020 @07:09PM (#60440753) Journal

      I would *love* to have a modern equivalent to VB6. There are serious warts with VB, but the compelling case for it is that it makes creating really pretty complex UIs tolerable in a way that more modern Visual Studio languages seem to have forgotten about. Regrettably, one of the serious warts of VB6 is a stunning lack of rudimentary optimizations (like common sub-expression elimination -- that rudimentary) which means the code is ridiculously inefficient. Contemporary C/C++ compilers from that era could wipe the floor with VB6.

      But there are some nice things about it. Like you can use strings as arguments to switch statements (I'm looking at you, C++). It's easy to make pretty complex UIs. You can control whether arguments are call by reference or call by value. And a gazillion fanbois used it to develop games, so that writing the sort of code we use in my laboratory is straightforward because there's almost always an example of someone having done something similar before on the net. For getting a small application running quickly, it's really pretty good, but you have to be far more disciplined about coding than with other languages (like you can't assume that arrays start with 0 ... or 1 ... because they can start with any arbitrary integer index).

      In my lab, we have a central appilcation that is used to run our experiments that has been under continual development for about 20 years, in VB6. We recently decided that it had become too difficult to get VB6 and our applications running under Windows 10 (and we presume it will only get worse with time), and decided to switch to a new language / platform that we need to be stable for another 20 years. Visual Studio C/C++ seems to be the only thing going at present that fits the bill.

      In terms of stability, though, one of the important, and counter-intuitive aspects of that is that VB6 has 6 not had any updates in something like 15 years. So it is stable. Rock stable. All of the bugs that were there a decade ago are still there. A few new quirks have emerged as VB6 applications are adjusted to run under Win7 and Win10, but a lack of development on the IDE / compiler means that the code from yesteryear more-or-less runs perfectly now.

      • Regrettably, one of the serious warts of VB6 is a stunning lack of rudimentary optimizations (like common sub-expression elimination -- that rudimentary) which means the code is ridiculously inefficient.

        Stop talking out your ass.

        VB6 used the Visual Studio 98 stage-2 C compiler just as VC98 did (C2.EXE) and does literally every optimization that VC98 did for equally functioning C++ code.

        The shit that slowed optimized VB6 code down vs optimized C++ code is that not all functionality had to be equal. Everything from arrays to strings to classes have different implementations and functionalities between the languages, their respective standard libraries are also significantly different, and of course the

        • Interesting.

          One thing that VB6 does is detect integer overflows. That costs nothing to do in assembler with traps, but is horrible in C because C grade programmers do not care about errors. If VB6 used the C compiler, then that might mean that the integer overflow checks need to be done very inefficiently, and for every integer operation.

          Do not use C/C++. Use either C#.Net or Java. VB.Net is sadly dieing but could also be a good choice if you have lots of VB6 code. C/++ is an archaic system that will c

          • Re:Optimizations (Score:4, Informative)

            by vyvepe ( 809573 ) on Wednesday August 26, 2020 @07:16AM (#60442097)

            One thing that VB6 does is detect integer overflows. That costs nothing to do in assembler with traps, but is horrible in C because C grade programmers do not care about errors.

            Checking for integer overflow on x86 and amd64 is not free. It requires an additional instruction (into or jo). But it is cheap enough and should be used by default. You can enable automatic signed overflow checks in gcc with -fsanitize=signed-integer-overflow. I bet other C compilers have similar options too. C/C++ has many disadvantages (especially the memory related stuff), but overflow checking is not it.

  • by Tontoman ( 737489 ) * on Tuesday August 25, 2020 @06:12PM (#60440591)
    I was told (as of a couple years ago) code I wrote about 40 years ago is still running. Heat transfer engineering code written for a HP-86B in a variant of Basic. The Pressure Vessel fabrication design shop never needed to updated it since it just kept working for them. Saved them thousands in timeshare expense at the time. Those days HP made good hardware!
  • by hcs_$reboot ( 1536101 ) on Tuesday August 25, 2020 @06:13PM (#60440595)
    "I myself tried to re-run an Apple II program I wrote 32 years ago on a vintage Apple IIe"
    Are we talking about code, or hardware? If it's really about code, run your Apple ][e code using any of the Apple ][e emulator available.
    • by Cassini2 ( 956052 ) on Tuesday August 25, 2020 @06:48PM (#60440693)

      Try reading an Apple II floppy disk ...

      I had the same thought about trying to get some of my old programs to run. Essentially, the only readable media from a long time ago (early 90s) is CD-R discs. The Kodak 50+ year media and the better media from that era (now 25 to 30 years old) worked when I last checked the backups. Hard drives, floppy disks, magnetic tape is almost all useless. VHS is marginal. Much newer DVD+R disks have also failed. It is only the CD-R discs that have had a long lifespan and are readily supported in current equipment.

      The odds of restoring from a long-lost backup improve dramatically if the old hardware is still operational. Particularly if it has a working hard disk or floppy disk. However, the next problem is finding a device to talk to the old hardware. RS-232 works well. Kermit is still supported in some terminal clients. Interlnk and Intersvr run well. Use Intersvr on DOS Box or in a VM, and Interlnk on the remote machine. Interlnk has the ability of copying itself across the RS-232 port to older DOS machines. The parallel port solutions, which were much faster, do not work today for lack of a matching parallel port.

    • Pedantic: It is //e, not ][e. There was a ][, ][+, //e, //c, //c+, and IIgs.

  • Irony of Python (Score:4, Interesting)

    by jythie ( 914043 ) on Tuesday August 25, 2020 @06:21PM (#60440605)
    So I work in research as a staff programmer. Python is really popular in research, but I've found over the years it is TERRIBLE when it comes to compatibility across decades. Great language to give researchers who are only going to care about their code till they finish their dissertation, but wow can it be a struggle when you have to maintain a repository of models going back over a decade. Crow, even keeping it working across minor versions alone can be a horrible. My personal nightmare involves researchers or clients finding out about some model someone worked on years ago and having to explain that no, it will not run as is, and will either require extensive rewriting or running multiple python versions with some kind of bridge plus tracking down all pre-compiled/packaged libraries it needs and hope that the person wrote down the exact versions it needs.
    • by nnull ( 1148259 )
      That is one nightmare I ran into with Python. I wrote a lot of things in Python 2 for my equipment and trying to get things moved up to Python 3 has been a hassle, specifically libraries. There's a better way to handle this which I've started to learn with static versions and making my own packages, just in case my updates fail and I don't want to bother finding a solution.
      • by jythie ( 914043 )
        Yeah, our historical solution was we had a web page for the lab with copies of all the various package's installers. The big problem with that is researchers would want to make use of models people had written in the past, which means they would need to work with whatever current python environment they were using. We've gone from 2.3->2.6->2.7->3.7->3.8 and all of them were massive headaches. I still occasionally hit code paths that require 2.3 or some version of a library that has changed
    • The worst part with Python is if you get a bunch of old Python code dumped in your lap that utilizes a bunch of libraries and you have no idea where it came from. So not only do you have to figure out what version of Python was used to initially develop and run the code, but what version of the libraries were used as so many libraries seem to constantly introduce breaking changes. It can be nearly impossible unless you can track down the computer where the Python code actually runs, and then you can dive

      • by thogard ( 43403 )

        We are finding that as a Python code base ages, it gets very expensive to maintain. We went down the Zope path a long ago and so far every one of those projects have cost more to "update" than they cost to write in the first place in just coding hours. The newer frameworks are much cheaper to maintain but there seems to be a excessive amount of problem cases that just shouldn't have been problems at all.

    • I know nothing about Python, but this apparently is the reason for the excellent Revelation password manager vanishing from the repositories of the current Mint 20/Ubuntu 20.04 OSs. Possibly Fedora too. The maintainers were working on getting it to work with Python 3 and AFAICT missed the deadline.
      Anybody who wishes to use it can now get the 0.5.0 source and install from that. See AskUbuntu.

  • But if you are coding using their toolchain and code for their OS, you will be able to recompile and re-run your software 10 and even 20 years from now.

    To begin with, you will be able to run the 10 year old binay unmodified.

    But let's say you want to recompile. If the code does not compile on the new toolchain, the old toolchain from 10 years ago will run on modern OSs, the new compile will run, and if push comes to shove, you can track down a vintage OS image, install the toolchain from10 years ago on a 10

    • It really depends on which Microsoft toolchain that you used. The old software written for Windows 2.0 will almost kind-off work if you deal with the K&R C code and the 16 to 32 bit migrations.

      If we are talking about flavor of the month Microsoft code, for example IE 4.0, the code has not aged well. In one application, I embedded IE 4.0 pages via an MFC control. It was the latest cool fad. On the first commercial deployment, I realized that I had to get rid of the IE 4.0 code. It gave my program a

      • by jezwel ( 2451108 )

        Microsoft supports the core windows API's for a long-time.

        Yup, we're still having to rung Lotus Smartsuite 97 in our Win10 evergreen environment. Plus some old Macromedia apps that went EOS back in 2003. That's not counting all the old internally developed DOS apps (PASCAL?) run from a file server that are coming to light now that Win10 policy prevents them executing until an exception is granted.

    • by lgw ( 121541 )

      How easy is it to run VisualBasic code today, now that the language is long gone?

      • The language and tools are long gone but to this day MS still include the VB runtime in the OS (yes even windows 10). so as long as you have an old version of visual studio or the compiler itself you can still happily run vb code.
  • by jmccue ( 834797 ) on Tuesday August 25, 2020 @06:26PM (#60440621) Homepage

    A DOS utility (.com) running running around 30 years. It is a detail loan calculator written using Zortech c version 1.0

    I know of 1 person still using it on Windows in a dosbox.

    I should see if I can find on an old diskette

    • vDos is also nice and has a little bit better support for printers if you're trying to run old apps. I managed to get patient forms to print out for a small office and they were able to take those print outs and send them to a company that scans medical records (as required for compliance in these modern times). They were happy enough with running the app in an emulator that they never switched away from the DOS app and continue to send duplicate print outs for scanning.

  • Did you install the right version of Python and dependency manager [python-poetry.org] in a container?

    No? then sorry, my 50 line script won't run.

  • Most of the code I write at this point is glue between a vendor's data API and the specific business processes of the business I work for. It mostly runs in Python 2 with PyQt bindings. Ten years from now? Only if it's actively maintained the whole time, the business doesn't die or change dramatically, we don't switch to a different data vendor, etc, etc. So probably not.

    In some ways it's like the scaffolding for a building. The building - in my case episodes of animated TV shows - will live on, but

  • There's code I wrote ten years ago running now.
  • The stuff that I write tends to be of the "we might look at that again in 20 years" sort; industrial monitoring and the like. I usually use C and ncurses these days, and xforms-toolkit (http://xforms-toolkit.org/) for anything that needs a gui. None of these three things are changing or going anywhere for the foreseeable future.

    I wrote a vending machine in Turbo C about 35 years ago that runs on DOS and still works fine. (You can still buy DOS computers, too.) There's also a program that creates product

  • I have code in production use right now that was originally compiled 29 years ago for use on IBM XTs running DOS. It now runs on multi-core Linux boxes, with a recompile.

    And I have code written in PHP still running after 25 years, that the powers at PHP.org have been fighting valiantly to break... but they haven't, yet.

    "You shouldn't be using the PHP interpreters that run your code! They have serious bugs in [list of functions]!" Yeah, and if I were using those functions, I might be worried about it. I'd us

  • by NotSoHeavyD3 ( 1400425 ) on Tuesday August 25, 2020 @06:58PM (#60440727) Journal
    I'm convinced most of them believe they have some form of eidetic memory and think they don't need to document because obviously they'll remember. Of course I've never met any developers that actually convinced me of that.(Most actually have pretty bad memories.)
  • by nyet ( 19118 )

    All of the code I wrote still works.
    I'm not incompetent, and I don't choose frameworks written by the incompetent.

    The exception is java, which is now completely broken since you can't crosscompile installers any more; you can only build them natively. So java now counts as a framework written by the incompetent.

    Fuck you Oracle.

  • ...if I design it to never run in the first place!

  • The toolchain I use to compile my stuff I wrote in the late 90's. Still works today unchanged with just a recompile for 64 bits. I'm sure I have 20 year old code unchanged that I still use in the product itself. C...
  • Most of my code is in C89. It ran in 1990 and it will run in 2090
  • We are certified and authorized vendors for nuclear reactor design by various alphabet soup agencies regulating nuclear industry. And various others that regulates air plane design. It is a requirement for us to be able to rerun the simulation that was done 10 years ago. And then we need to explain every difference with the next version for the same simulation.

    The process is so cumbersome some of the customers refuse to retire any version and keep old versions running in different machines. Thus in Westin

  • by WhoBeDaPlaya ( 984958 ) on Tuesday August 25, 2020 @07:46PM (#60440829) Homepage
    I have Perl 5 code used everyday by my colleagues that I began writing as an intern in 2010, so yes, it has been running for 10+ years.
  • then yes it will run.
  • I have code for an 8 bit microcontroller in infrastructure equipment, that very likely deployed on the order of 10^6 units over a designed service life of 15 years. We are at the end of the 15 year interval, but it would not surprise me to find some of these are still deployed.
  • I still have a db app running at a customer that I wrote in Delphi 5 in 2000. Delphi tend to be forgotten but it is a stable language.
    • The company I just left is running 20+ Year old Delphi 6 code. I was using Delphi 10.3.3 which is about 20 computer versions later. The code still compiled.

      Where we ran into trouble was some of the older components that were no longer supported and used 32-bit specifics. Code that used components still maintained by the vendors was easily compiled as both 32 and 64 bit functional executables.

      Code that was straight Delphi compiled without issues. Delphi was designed to be backward compatible but not forw

  • I have a friend that I learned writing code with 50 years ago. We had access to an IBM 1620 and a 1401. He is the type that kept all his old paper tapes and card decks. I didn't.

    For the fun of it he still runs those programs written way back when in a simulator.

    Same thing for all these "modern" programs. I still have some written on DOS 5 and I can still run those. Those are more than 30 years old.

    Is this even really a question?

  • by account_deleted ( 4530225 ) on Tuesday August 25, 2020 @10:16PM (#60441145)
    Comment removed based on user account deletion
  • I'm still trying to get the code to work today.
  • My Boune shell scripts continue to work fine. Always will.
  • Betteridge, Betteridge, my she shed for a Betteridge

  • What about code that needs hardware from the future to run in a reasonable time frame? I'm sure there's plenty of that floating around the crypto world
  • "dependency hell" is the right keyword there.

    I have a bunch of code that's 10, 15 years old. All of it still runs. In its fixed, never-touch-a-running-system environment.

    But try to update something, anything, and welcome to refactoring week. That library you want to update, say because of a critical security issue, depends on ten other libs, which have been updated, which pull in... and so on... in the end you update the entire system, half the stuff breaks, the rest isn't backward compatible, the language

  • It's also rock stable, refined by the first 10 years or so. My more recent code, in more modern languages, is less stable partly because the components of the language change.

  • I have code written in 2001 still running on production web servers. It was a asp/com+ app lol. Obviously we re-wrote the software (did this in 2005 and 2015) but for whatever reason some legacy clients never wanted to upgrade. That code hasnt even been touched in many many years. No bugs, no crashes.
  • by ledow ( 319597 )

    I don't see why not. It's C99. It would have worked 20 years ago, I expect it to work 20 years into the future. Possibly a library update here or there or, in an extreme case, emulation of the underlying environment (e.g. a game written in SDL should work with SDL libraries but it might well be such an old SDL library that it needs emulation of an old DOS environment or similar).

    However, the article is far more about people who are trying to run their original code (which worked fine in an emulator) on a

  • I wrote a system in then 1980s using Turbo Pascal, under MS-DOS to control water meter calibration. It has graphics and multi-tasking (I rolled my own cooperative multi-tasking and open-sourced it back then).. There were no Y2K problems. It last required attention in 2004 because an IO board had to be replaced, and they accidentally swapped the cables when they did it.... swapping them back fixed it. 8)
    As far as I know it will outlive me because it does the job, and there's no reason to replace it.

  • I've got a small command line Windows tool that I wrote - I think in 1997. If you copy a file to the clipboard, you can just run this tool from the command line, and it will "paste" (i.e., copy) the file into the current working directory the command line is in.

    I use it every day and it's worked flawlessly in every version of Windows I've had since I wrote it.

    It is pretty simple - less than 200 lines of (probably very bad) C. But I'm always impressed that it still Just Works. Windows is pretty amazing somet

  • How many python interpreters do I need today just to run software on my system that other people have written? 3? 4? You're lucky if Python code survives the week.

Don't tell me how hard you work. Tell me how much you get done. -- James J. Ling

Working...