Some cryptic source examples

See if you can decipher this one free-form example (courtesy Paul Henning):

integer function end(return,&
integer integer,return;;;;;;&
integer;;end function end;;;;

Here is another one for fixed-form (I invented this one):

1 Like

Not exactly cryptic, but my two “favorite” fixed vs free form anomalies I encoutered in a Sandia fixed form Fortran code (still in use and comprising close to 500K lines of code) were

  1. Someone thought it was jolly fun to put a space between letters in keywords (namely)

    S U B R O U T I N E or F U N C T I O N

    This caused a tool I wrote to convert from fixed to free form a lot of gastric distress


  1. Someone thought that breaking the decimal part of a number in a data statement across a continued line was also cool. I guess just so the columns would line up.

ie Data /a/…1.234 ← col 72
col 6–> +5678

You normally see these kinds of things with codes that have been around for decades, had several people contribute to it, and no one is providing any adult supervision in the form of rigidly enforced coding standards and practices.


I learned recently that the reason spaces were allowed is because it would be inconvenient if you had to repunch a card in case of a mistake.

1 Like

Yes but this particular part of the code was written after key punches were a thing of the past. It was just someone (probably a novice post-doc) who probably thought it was more “readable” that way. BTW I started my Fortran programming journey with punch cards. In my first real engineering job, I was responsible for implementing the Space Shuttle ascent and on-orbit guidance and control algorithms in a simulation code NASA used to do trajectory design and mission planning. One day I sent several boxes of cards over to the central computing facility at JSC were they were read into a Univac 1108 system. The next day I got my listing back and I had exceeded the maximum number of errors allowed by the Univac Fortran compiler. Turns out a kid hired for the summer to feed the card readers had dropped a couple of boxes but decided to feed them into the reader anyhow because they thought the computer would figure it all out. Thankfully, the cards all had sequence numbers in cols 73-80. Although cards could be a pain, I kind of miss those days because I would write the code on a “green” sheet, give it to our company key punch operator and then go do real engineering work. These days with interactive editors, etc. I find I sometimes get to caught up in just creating the code and the real engineering work takes a back seat for a while.


For those too young to know what a “green sheet” is. Here is an example. For some reason I still have a pad of forms in my archives so I’m prepared when punch cards make a comeback. Hey if it can happen with vinyl records why not punch cards :smile:


Some lines and sharpie pattern across the sides of the cards – similar to the picture below – were a popular approach to keep the stacked cards in correct sequence.


(image credit: University of Washington)

Lending a hand to vacate a room for new installations, one of the boxes was like this one. According to the seniors, only once a day was a possibility to submit a stack to the computing centre, so the additional rubber band was a usual thing. (Beside, the elders became highly attentive to spot syntax errors prior to sending the stacks out.)


Punch cards are great, I think it is more durable to store source code on paper in “analog” form. I still have some code from 30 years ago on floppy disks, and I doubt I could read it. I then found a printout of some code from the same time on paper and that is perfectly readable.

What is the most efficient way to store programs on paper?

The most robust, but low density, is probably just printing it with some high quality font.

The highest density can be achieved with something like a QR code. Here are some links for some formats that seem higher density than a QR code:

They often also put some error correction in it, which relates to robustness of reading it back correctly, but reduces capacity.

1 Like

In the GitHub Arctic Code Vault short-movie, they mentioned using archive-quality silver-halide film which is meant to last about 1000 years. The 21 TB of data was imprinted on 186 archive-quality film reels, encoded as QR codes. According to articles I could find a company called Piql provided the service.


I recently had a company get all my old college programs code off a set of 40-50 year-old 1/2-inch mag tapes for me. I was overwhelmed that they could extract it at all.


It was important to get a good severe angle on the lines. You didn’t want ambiguity when comparing two cards you were picking up off the floor.


@ivanpribec thanks, I think this is the state of the art technology how to do it. I’ll see if I can find out the resolution of their QR codes. I would be very interested in doing the same kind of state of the art, but using a consumer printer, so it would have to be larger resolution. It would also be nice to “scan” the whole page using a phone, that would make it very easy to use. I would like to use today’s printers to print it (probably in color, to increase data density), with the property that if the very paper that I print today, was somehow stored in the attic in 1990, I could immediately read it using my phone today (30 years later). So if I print it today, I want to be able to read it in 2053.

@gak nice! You should upload your 50 year old code to GitHub. :slight_smile:

Already there in a private repo. I sent you a collaborator invite. Most of it is ancient PL/I, System 360 assembler, some Algol-W, and Pascal. Lots of stuff from my student days. There’s also a Basic interpreter that I sold to get the down payment on my first condo.

1 Like