Immortal Code

ziani writes ""... Sometimes a piece of code is so elegant, so evolved, that it outlasts everything else." Nice article at Wired wondering how much great (and lousy) code is lost due to business failures."

Comments

Immortal code - which do you know?

[jschrod]

There are code pieces I think might get immortal. Henry Spencer's regexp routines come to mind.

What other basic code pieces, used in hundreds or thousands of programs, do you know?

The Book

[s20451]

I'm reminded of what mathematicians call "The Book". This is based on a quote from Paul Erdos, who said that God keeps a Book in which He writes the most elegant proofs -- as a mathematician, you don't have to believe in God, but you do have to believe in The Book, and strive to make your proofs Book-worthy. Maybe God keeps a Book of Hacks, too?

YEAH LIKE WATFIV!

[Mainframes ROCK!]

WATFIV (and WATFOR, WATBOL etc) are the classic example in my mind. Made by the University of Waterloo, now languishing somewhere (at Sybase maybe?!)

Oldest working code...

[Anonymous Coward]

I'm always curious as to what may be some of the oldest "working" code that's publicly available. Code that was written ages ago, but still used today.

I'm sure that there are other examples, but I'd like to put forward the first candidate of such code: Squeak Smalltalk.

The reason I put it forward is more because of my knowledge with it. Of course, I may be wrong also, but...

Anyway, the first time I saw the predecessor to Squeak was back at an Apple sponsored event at college in 1985. They were showing off the Macs and new Mac Plus.

One fellow there managed to have a copy of the original Smalltalk-80 image that Apple worked on with Xerox. It was a fascinating piece of software.

That image was sourced from the original work done at Xerox in the late '70s and early '80s.

When they decided to bring forth Squeak, they started with the original Apple image (which started with the original Xerox image).

So, I'd like to think, though I don't know, that there are lines of code within that Squeak image that literally date back to the late '70s and have never been changed since. Coded late at night by some hacker at Xerox and simply pulled along with the Smalltalk image, never needing to be tweaked.

No doubt there are the zillions of line of code still kicking and screaming within industry, but I'm more interested with code that is out in the wild, and still being used somewhat actively.

Any other contenders?

Re:Oldest working code...

[jridley]

There are millions of lines of code running in financial institutions from possibly as early as the late 50's for which the source is lost. That's why there are emulators. I've heard that some places have emulators running emulators running emulators running their original compiled code.

Much of it may be replaced by now but when i was taking my CS classes back in the 80's I was told this was true.

Re:Oldest working code...

[n__0]

Space war has been running since the 60s I think, on a website somewhere there is an emulation of the original machne running in java using the complete original code. I may be wrong though.

Re:Oldest working code...

[Anonymous Coward]

European Center for Nuclear Research has CERNLIB which is has some ancient Fortran routines in it. Also, there is an old beast named SAGE that simulates particle decay distributions -- it was certainly written Fortran IV. I knew someone who used the SAGE precursor. I think the oldest comment I ever saw in SAGE was about 1966, but it might have been 1969.
With respect to the original article, SAGE is immortal but somebody should have put a stake through it's heart years ago. Inside it looks like it's still trying to run on a machine with 64kb RAM and plays all the dirty EQUIVALENCE tricks necessary to do so.
This necessitates the question: is the probability of becoming immortal code related to the code itself or what it does?

Re:Oldest working code...

[Sinical]

Not exactly out in the wild, but not exactly purely for an industry, are mathematical routines and the like.

For instance, a lot of aerodynamics code I've seen is written in Fortran IV or Fortan 77. It's often not the nicest formatting and stuff, but Fortran compiles cleanly, and the code still does it's job, so people still use it: it's also easy to interface Fortran and C/C++, which is a bonus. So you build on the core of this hard mathematical stuff that was written long ago.

Of course, part of that's bad, because there's a chance there're some gotchas still in there that wouldn't be understood anymore, but thankfully a career in my industry is quite long typically, so there's often a gray-haired sage that you can consult.

I think things that do math (even financial calculations) are more likely to last, because those kinds of operations endure.

Re:Here's some REALLY immortal code

[Anonymous Coward]

For any right triangle with sides of length A and B and hypoteneuse of length C,

A^2 + B^2 = C^2

Intentional programming

[Anonymous Coward]

Intentional Programming

Lifetime of code...

[mseeger]

Hi,

there are several limitations for the lifetime of code:

• Hardware lifetime: hardware specific code may loose its usefullness once the hardware itself becomes obsolete.
• Purpose lifetime: A lot of code serves a temporary purpose. Once the purpose is achieved or dropped, the code will die.
• Language: A code in an obsolete programming language will probably be dropped as there is no one to judge the elegancy of it.

Perhaps we should look at it that way: If all good code would and could be reused, more than the half of all software engineers would be ou of duty soon. I think i once read a figure that less than 20% of all code written is "new".

Yours, Martin

Duff's Device

[Tokerat]

Tom Duff once came up with this very useful yet ugly piece of C code for high-speed blitter routines, or any other instance where data must be moved as quickly as possible.

I'd post it but the Slashdot lameness filter is just that: It makes posting code like this impossible, therefore making Slashdot lame. :-/

There is a link to a full explaination here. Damn, if only we could all be this good.
PS: Yea, I do believe it beats the living crap out of memcpy() or BlockMove() or whatever other routine your using ;-)

Re:Duff's Device

[Chocolate Teapot]

Judging by your reference to BlockMove(), I take it you are a Mac programmer? In which case, you would gain a lot more by:

a) Moving 32 bits at a time instead of 16

b) Use four source pointers and four dest pointers, allowing the pipelining to really scream on the PPC

c) Consider using Altivec (very Mac specific though)

d) Lose that f***ing % operator, which will do a lovely job of stalling the integer pipelines while it computes the modulo. ( count & 0x03) does the same thing much quicker.

In some cases, you can easily beat BlockMove(), especially if you know that your memory was nicely aligned on 4 byte boundaries. However, pit you code up against BlockMove() with mis-aligned data (especially if both the source and dest are on weird alignments) then BlockMove() will whip your sorry ass. My $0.02

Re:Duff's Device

[Chocolate Teapot]

In my experience compilers (nowadays) are quite good at deciding which to use:

You would think so, wouldn't you, but last time I looked at this (last year) CodeWarrior didn't do this. Probably an old version I expect. AFAIR though, the Microsoft compiler seemed to benefit from explicitly using & in place of % as well. IMO, it's always worth double checking the disassembled output if the code is speed critical. You never know what a change in a compiler or it's flags might do. (Of course I meant & 0x07, not & 0x03)

Re:Duff's Device

[swillden]

Actually, Duff did this the most elegantly in C. However, I had seen the equivalent in assembler much earlier.

Duff had also seen, and written, the same construct in assembler many times. His Device was born out of frustration that he would have to drop down to assembler to unroll his loop. His fit of genius led him to try to construct it in C, and he was surprised when it compiled without complaint and ran perfectly.

Makefiles

[HisMother]

This story reminds me of the old saw that there is only one Makefile; everyone edits it for their own projects. There is grain of truth in that.

A modern-day analogy might be the line

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

that opens XSL stylesheets -- NOBODY ever types that by hand.

Re:It's nice

[pVoid]

you can't see microsoft code because you don't look.

Download the friggin DDK from their site, and they have working samples for almost all their core drivers.

Stripped of a license, the samples in there are as good as OSS.

And btw, they are nice cleanly coded samples. There is just as much pressure on programmers there to keep that code clean: it's in their DDK, and they don't want to show shody samples. So I'm sure the code review processes are just as stringent.

memes

[Anonymous Coward]

Richard Dawkins, author of The Selfish Gene, would point out that all information, code included, survives, multiplies and mutates like genes. The code is to the gene as the application is to the organism.

what about artistic code?

[i.r.id10t]

Anyone remember the kernel source stuck between tags that was the color highlighted, so the whole thing was this big penguin? http://www.cc.gatech.edu/~ncb/penguin.html

Re:Elegant code

[hughk]

This is one of the reasons for the projects to emulate historical computers. It doesn't matter whether it is a PDP-11, an IBM 360 or whatever, there is often a simulator out there. The odd thing about it is that due to the speed of modern hardware, you can often run the emulations at the proper speed.

is there anything that a markov matrix can't do?

[AssFace]

That article talks of Baker using statistical probability towards speech recognition.
That immediately makes me thing of the markov matrix/chain.
The two ways I would have looked at speech without having read anything on it would be FFT and neural nets, and/or markov matricies (likely also with fft).

When I first learned to use them in speech generation (either written or spoken) and also general analysis that became my favorite tool to abuse (my hammer making everything look like a nail?).
I immediately thought of how I could use them in image recognition, game ai, and stock analysis...
But mostly I used them to post to newsgroups and web discussion boards and then laughed at people responding to them as if they were regular users and usually fighting with them.
I wrote a Poe generator (would write stories/poems based on his matrix) and also a radiohead song generator.

Now my current hammer(s) are neural nets and genetic algorithms - but the markov matrix is stuff fun as all hell.

It never says straight out in the article that Baker uses those - but the general concept that is discussed seems to point at them.
(and yeah - I know the article was about losing code - but that's boring - what is cool is the code discussed)

Speaking about "deep code/knowledge"

[jeorgen]

...I bought Lernout and Hauspie (LHSP, the company featured in the article) shares in their heyday, thinking the tech was good. But all the technology isn't worth anything if they screw up other parts of their business.

Incidentally I also bought Tanox (TNOX) at about the same time. Thought they could come up with some interesting immune system stuff. They did, it seems they've made a vaccine approved in Australia for getting rid of allergies (anti IgE). Still their share value lingers in the basement!

So now twice I've betted on technology, been right, and still lost.

Check E-trade account:
LHSP: -99.96 %
TNOX: -80.99 %

Seem you need more knowledge than just a bit of tech savy. Bummer.

/jeorgen

Voyager

[tellezj]

is in its 25th year, and still communicates daily. I'm sure the bus has been running the same code for the whole mission, although I'm sure the payload may have had some code revisions uploaded along the way.

Re:Excuse me?

[On Lawn]

I'd bet that most if not all coders get themself copies of their code and keep it in their own portfolio to reuse and recycle it.

I worked for a dot-bomb, and a company that is still around. I erased all of it. Not for security or copyright issues, but becuase there wasn't anything of use.

Most of the broad purpose code was like re-writing CVS (yes I'm not kidding), or gnu-E. One of my qualms in working for those companies was their hush-hush secretive attitude. And when you get past to find out what the secret is, its like "your doing that? Why not just use this GPL code right here?"

I realize my experience might be out of the ordinary, but I got rid of it just becuase I had no use for it.

__________________________________
OnRoad: Boldly reporting the SUV war from the middle of the road.

I learned my lesson

[Anonymous Coward]

Absolutely. When I went from my first to my second job, I foolishly took none of my source code with me. Since the second job was with the same company as the first, just a different division, I assumed I'd still have access to it. Hah. Many times, I regretted that as I had to re-create an object I should've been able to copy and paste.

When that division folded and I moved on to the next job, this time I took a little more with me. Just some of the essentials I'd need for my portfolio, though, since I felt at the time that it would be wrong of me to abscond with the company's and clients' IP. I now very much regret that decision, because the company itself is gone and the clients have no access to the source - they're stuck with un-upgradeable software.

At my current job, I am backing up everything I do. I will never touch or look at it except in case of an emergency, but this time if the floor falls out from under me I will be prepared.