Science

Technology Anachronisms in Science

Cross-posted on my geology blog Georneys.

MacDiff program running in a Mac Classic environment emulator on my Windows XP netbook, January 2011.

Ever since I starting doing geology research back in 2003, I have encountered technology anachronisms in science. I find these technology anachronisms intriguing, humorous, and- sometimes- frustrating. Often, the challenge of using technology in science is not keeping up with the latest-and-greatest technology but rather remembering or learning to use very old, outdated technology.

What is a technology anachronism? Basically, this is a piece of technology (e.g. a computer, a data reduction program, a mass spectrometer) that is old and out-of-date– sometimes wildly so– but which is still in regular use for any of a variety of reasons. A good example of a technology anachronism is the soon-to-be retired Space Shuttle. My senior year of high school, I remember reading a 2002 New York Times article titled “For parts, NASA Boldy Goes… on eBay.” Basically, in 2002 (and probably in 2011) the Space Shuttle was still using early 1980s computer technology. In order to keep the shuttle computers in good repair, replacement parts were sometimes needed. The problem, of course, was that 1980s computer parts were hard to come by in 2002. Thus, NASA would buy replacement computer parts on eBay and any other place they could scavenge them from.

So why did NASA go on eBay rather than just outfit the space shuttle with new computer systems? Well, you’ll have to ask NASA about that for an official answer, and I’m sure they did make some updates to the shuttle’s computer technology. However, I imagine that designing a space shuttle– even just part of a space shuttle– is such a long, rigorous process that it is more practical to maintain the outdated but tried-and-trusted technology rather than overhaul with new technology that would require significant energy to design, test, and implement.

About a year after I read the NASA article, I started participating in science research in a geochemistry lab down at Florida State University (FSU). I went down to FSU to work as a summer intern. For my project, I measured hafnium (Hf) and neodymium (Nd) isotopes in some post-shield basalts from Hawaii. I measured Hf isotopes on a very old mass spectrometer* that had been specially modified for the task. The computer that was hooked up to the mass spectrometer was early to mid 90s in vintage. Much of the running of the mass spectrometer was done by hand (physically pushing in the samples, initial settings and calibration), but the computer did have a program for measuring the isotopes. The computer program was difficult to use and full of glitches. I forget what code was used, but I think it was an old FORTRAN code that had been programmed by a graduate student or technician way back when. The results came out on an old dot matrix printer with the holes on the edges to move the paper along.

More recently, I have encountered a technology anachronism in the software program I am using to identify minerals in X-ray diffraction (XRD) scans of rock powders. To identify minerals, I am using a program called MacDiff. This is a great XRD analysis program– it’s free and works really well for basic mineral identification. There are other, very expensive programs with larger mineral databases and more capability. However, I don’t require this much analysis for my thesis, so MacDiff is fine. There is just one problem with the MacDiff software: the program has not been updated since about 2000. The program also only works on a Mac, but even that wouldn’t be a huge problem if it worked on a recent Mac. Actually, the program can only be run in the Mac Classic environment.

There are two options for working with MacDiff. The first option is finding an old Mac computer that can run the Mac Classic environment. This is not too difficult as many scientists have old Mac computers lying about, and worst case scenario you can always buy an old Mac fairly cheaply off eBay. The second option, which I decided to pursue, is to set up an emulator environment so that you can run the Mac Classic environment in a window on a modern computer. Setting up an emulator is a little bit tricky (well, for me anyway), but I had a computer savvy friend help me figure it out. Running MacDiff through an emulator works well with just a few problems. The emulator tends to crash if you do certain things in certain orders, but I’ve managed to figure out ways around the problems I’ve had with the emulator. I really wish that a scientist or programmer would update the MacDiff code so that it would run on a modern computer, but that coding represents a significant time investment, so it probably won’t happen anytime soon.

I have encountered countless more technology anachronisms in scientific research. In my experience, there are several reasons why technology anachronisms exist:

1. Money:
There can be a high cost in replacing technology. Scientists cannot afford to replace very expensive equipment– such as million dollar mass spectrometers– often. For example, here at Woods Hole Oceanographic Institution there is an ion probe** that is from the late 1970s. There is also a newer, fancier ion probe. However, since ion probes are so expensive and in demand, the old 1970s one is still run regularly.

2. Time and Effort:
Replacing technology and becoming used to new technology takes time, which scientists have far too little of these days. Sometimes, it is faster and easier to keep the old technology limping along rather than take the time to transition to new technology. As an example, if an extensive code has been written in outdated FORTRAN, many scientists prefer to keep working with the pre-existing FORTRAN code rather than take the time and effort to re-write the code in a new language.

3. Comfort:
Humans, scientists included, are often resistant to change. Like NASA space shuttle operators, scientists like working with tried-and-trusted technology. Sometimes, this means clinging onto a computer or code or machine longer than they should. Older scientists in particular can sometimes be unfairly critical and suspicious of new technology.

4. Compatibility:
Sometimes, using older technology is really the only option. For instance, if you are using an old ion probe you may need to use an old computer in order to be able to talk to that old ion probe. Similarly, if you are using a group piece of technology– such as MacDiff– that you cannot update on your own, then you may be stuck with old technology unless the whole research community makes an effort to update the technology.

There will always be anachronistic technology in science, if only because the pace of technology development is so rapid these days.This is especially true when it comes to computers. The day you buy your shiny new laptop, this laptop is already out-of-date. New and better computers and computer-like gadgets– smartphones, electronic book readers, tablet PCs– are constantly being released. New software programs (Microsoft products, internet browsers, blogging platforms) come out every couple of years, and updates to these commonly-used software programs come out all the time.

So, whatever technology you purchase for your science, it’s likely to be out of date by the time you install it in your laboratory.

*For mass spectrometry geeks, the machine was the Lamont Isolab 54 Secondary Ionization Mass Spectrometer (SIMS).

**For ion probe geeks, the older ion probe is the IMS 3f. WHOI also has a IMS 1280.

Evelyn

Evelyn is a geologist, writer, traveler, and skeptic residing in Cape Town, South Africa with frequent trips back to the US for work. She has two adorable cats; enjoys hiking, rock climbing, and kayaking; and has a very large rock collection. You can follow her on twitter @GeoEvelyn. She also writes a geology blog called Georneys.

Related Articles

25 Comments

  1. Related to #2 is the factor of “Credit”. One very rarely gets any credit, either in corporate or academic labs, for updating a piece of software that can still be made to limp along. Most managers see this as “church work”, so unless it’s something you are willing to do in addition to all your normal work, it’s probably not worth doing.

    Grad school was a great place to learn how to deal with software kludges. Each successive generation of grad students adds their own layer of (non-commented) band-aids until it’s almost impossible to figure out how a program works. It’s a lot like DNA, in that large sections of code can be shut off, but still remain in the program. No one wants to take anything out for fear of causing some future instability.

  2. Don’t tell anyone but the computer I use for all my writing and software development is an Amiga 3000 that I bought in 1993. The reason I don’t upgrade is that I put hundreds of hours of work into writing firmware development programs for it in Forth. I use these daily and it would be an incredible investment in time and money to replace them all.
    Besides, it has a pretty good operating system with which I am familiar. I really don’t see why I should make Bill Gates any richer by buying his product which was, until recently, much inferior.
    Of course if my Amiga ever fails I too will be haunting e-bay for spare parts.

  3. Proposed solution to the problem, at least in the academic environment: Team up with your Computer Science department. The students over there have to write lots of useless code – the profs have got to be tired of seeing the same mistakes, and there’s no actual user testing for homework assignments. Several teams can put together and evaluate each other’s user requirements, then they implement in more modern code, and practice presenting the solution to the end users who care.

    This could result is a couple options of MacDiff replacements (hopefully one would be acceptable), and would give those CS coders some real-project experience.

  4. @rekre8 At least in my training, it’s less useless code and more practice in historically useful algorithms. The only real cross-departmental coding I’ve seen happens at the graduate student level when someone is looking for a project for their masters.

    Also, as someone forced to program in FORTRAN, I just want to say that the language has impressive backwards compatibility. One set of codes I use is still mostly FORTRAN-66 with some FORTRAN-90/95 tweaks for new features and it compiles and runs fine with the current PGI, Intel, and Gnu compilers.

  5. @Katherine: You have just delayed my PhD graduation by at least 2 months :-). Where I can I download Mac Classic games for free/cheap? Google this I must.

  6. There’s an old chart recorder in our lab that we are still trying to figure out how to hook up to more a more modern instrument. I just think it would be awesome to have all my graphs mechanically drawn by pen.

  7. @Evelyn – any helpful websites or tutorials on running (and even setting up) an emulator?

    My HPLC, Instron, and many other spectrometer tools in my Lab are SO old school.

    Also, anyone ever run into the problem that the computer can’t be updated because the licence software expired? Our equipment, though old, is good; but the computers used to run them are antiques for SURE. But we can’t replace the computer even though it’d be affordable because no one even knows the name of who installed the software in the first place.

    I guess in academia, when a student/postdoc/prof leaves, they LEAVE. And never come back to explain their research. (Bad Project Gaga Parody anyone?)

    @rekre8 I think I personally would find a CE or CP to do the code and fixing of the old stuff but for some reason our department just doesn’t speak to Computer scientists? Ridiculous really. Had the same problem with Web Design for the degree program/department. I said we should get a free/cheap graphic design major and have a phenomenal webpage and give some poor student some cash and a great resume experience. For some reason, at my university the Sciences work less together and actually compete more than anything. Idiocy, really.

  8. When I was studying wildlife management in the early ninties, one of our projector screens had “Impeach Nixon” scrawled accross the top.

  9. There are definite IPR problems with emulation. Suppose that you are managing an archive of Windows 3.1 games. You have the games and you have Windows install disks and you have an emulator for the old hardware. But can you still get licenses to run Windows 3.1? Can you be sure that you will always be able to buy a license?

  10. I work in the Geology dept. of a UK university, and all the post-grads complain because like @Divergence of B they have to programme using FORTRAN as that’s the language their supervisors learnt in the 60’s and 70’s, and can’t be bothered to learn anything more recent!

  11. @Evelyn: The Shuttle is a very good example to use. Many people see it and think “most modern, high-technology.” It’s not really that way except in a few limited instances. It’s mostly 1970’s and 1980’s technology with more modern stuff grafted on here and there.

    Budget is always a priority (though it doesn’t seem like it at times) in aviation/spaceflight. NASA frequently doesn’t have the money or the time to do a lot of upgrading on the Shuttles. The military upgrades their jet’s systems more often, but they have fewer budget problems than NASA does (Not a political statement, just a fact). It’s not all that unusual so see a modern military jet using 1990’s vintage technology, though.

    On big problem with a craft as complex as a Shuttle is the interdependence of all the different systems. Changing one system frequently has a cascade effect down the line – What seems like a simple and inexpensive change can be a nightmare when everything else down the line is affected. This is beginning to be an issue with modern aircraft, too. Just keeping the Shuttle safety-rated for crewed flight is an issue when making changes, too.

    Some of the Shuttles had cockpit upgrades, but it’s been awhile and I’m not sure if they all were upgraded.

    The software issue directly affects the Shuttle. Older computers require older parts, as Evelyn mentions…and older software…which requires people that can write and debug that software…and so it goes. We have better thermal protection for spacecraft, too. It’s just not cost effective to remove the current tile system and replace it, though. I suppose you could consider the Shuttle as being similar to an old airliner like a Boeing 727. The airplane itself is almost obsolete – so do you put more money into it or into its replacement?

    Sometimes you have to pass up “the best” or even “the better” for “good enough” to get the job done.

  12. Space electronics has always tended to be a decade or two behind the times but there are two good reasons for this — apart from the fact that it can take ten years to design and build a spacecraft.
    One reason is security. Before you install a chip you want a generation of engineers to have found all the bugs, accidental or deliberate, that it may contain. Older technology is simpler so its logic can be checked out by hand. A microprocessor, the original 1971 Intel 4004, was not installed in a spacecraft until 1978. British Rail used the 1972 Intel 8008 in their safety systems for years after it became obsolete since it was the last microprocessor whose logic they could completely trust.
    The other reason for preferring old technology is that older chips use larger transistors which are less subject to errors caused by radiation. It costs a lot to make a radiation-hardened version of a processor. Unless the military are prepared to pay for it, the spacecraft market is too small to make the effort worth while. One uses an old rad-hard part because the latest commercial parts simply can’t stand the space environment for long.

  13. Newer versions of Fortran do exist (Fortran 90, 2003) and add additional features to the language, whilst still retaining backward compatibility.

    I think part of the reason we retain old technologies and old code in particular is because science is such a long term endeavour. I work with a computational chemistry package called Molpro, which is written mainly (if not solely) in Fortran. Some parts in the newer iterations of the language and some components in the older versions. The package is constructed in such a way that new modules can be added to do different calculations. It might take a scientist years to contribute efficient code to do a specific, specialised, type of calculation. It would be inconceivable to rewrite the entire package in a more modern, more feature-rich language — doing so would mean loss of functionality. The current package is built on years of scientist’s effort and thought, so, though it is not written in a cutting-edge language, is unique in it’s functionality.

    I’m not convinced that the use of “old” technology in science is necessarily a bad thing. Nor do I think old technology must be “limping along”. Often I think items with aging components, programming or interfaces are used because they are built for a unique purpose. For some purposes, the new features, greater efficiency or connectivity brought by newer technologies are unnecessary (sometimes, maybe, even getting in the way of the desired functionality). One potential example of this would be a computer program written to do a specific calculation, outputting the data in a command-line setting. Yes, it might seem outdated, but a modern graphic user interface would actually get in the way of the scientific purpose of the program!

    Anyway, interesting article. I enjoyed reading it :) Good luck with your aging Mac Classic program!

  14. I sense an impending niche market, which I for one would love to fill. I love old technology, usually more than new technology.

    In the particular case of MacDiff, it seems you may be able to contact the author; maybe he would be willing either to port MacDiff to Windows, or share the source code so that someone else (not to name names <stands in corner, scuffing toe in dirt, whistling, looking up at ceiling>) could take a crack at it.

    Anyway–the author seems to be Dr. Rainer Petschick at the Goethe-Universität Frankfurt am Main, in Frankfurt, Germany. The institution’s directory still lists him with a phone number of 069/798-40192 which, as an American, I’m not sure how to interpret, and an email address of [email protected] .

    (The question then would be whether to port it to Windows XP which you (and I) are actually using now, or to Windows 7 which we will all be forced to migrate to, Real Soon Now. Maybe there’s a way to do it that will let it work on BOTH.)

  15. @jcwx86: I agree with you that often old technology doesn’t need to be replaced. I certainly don’t think that all “anachronistic” technology should be replaced. As you pointed out, sometimes simpler is better!

  16. @ChrisC: You got programming skilz?

    I’ll try writing to the professor to see if there’s any response. For all I know, might be an outdated address.

  17. “It would be inconceivable to rewrite the entire package in a more modern, more feature-rich language […] I’m not convinced that the use of “old” technology in science is necessarily a bad thing.” –jcwx86

    And, ironically, by far the most technologically modern, feature-rich (and science and maths-friendly) language is Lisp, and Lisp is almost as temporally antique as Fortran.

  18. I’am the programmer of MacDiff. Thank you very much for mentioning the software, Evelyn. Unfortunately you have linked to a very old obsolete page. The correct link is

    http://www.geol-pal.uni-frankfurt.de/Staff/Homepages/Petschick/Classicsoftware.html

    more info to MacDiff:

    http://www.geol-pal.uni-frankfurt.de/Staff/Homepages/Petschick/MacDiff/MacDiffInfoE.html

    The complete package of MacDiff 4.2.6 is available as Binhex file (do not unpack outside Classic OS):

    http://www.geol-pal.uni-frankfurt.de/Staff/Homepages/Petschick/MacDiff/MacDiff_4.2.6_complete.hqx

    I’am using SheepShaver emulations on Windows and MacOS X since several years. It is a pity that the code is not native works on modern operating systems. But unfortunately it has not been possible to convert over 60,000 mostly very special BASIC commands into a modern language such as C. MacDiff should have been programmed from scratch, but this is beyond my available time.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Back to top button