Easy to do, when I first learned FORTRAN there were many versions of it (depending on who made the compiler) though there was a defacto standard, FORTRAN IV. When FORTRAN 77 came out it was the first attempt to make it more structured like ALGOL, but most FORTRAN programmers just wouldn't change. Last FORTRAN I used was FORTRAN 90, which finally had dynamic memory allocation and phased out the EQUIVALENCE statement, though it was still in most compilers at the time.
This was more or less my story as well. I was 12 and was forced to spend my lunches in the computer lab as a punishment so I started tearing into the crude games that were on there. One was a star trek game with quadrants and I remember you had to put in angles to shoot torpedoes at the Klingon ships and whatnot. I started tearing apart those games and playing around with the code to see how it worked.
So I don't feel THAT old anyway.
Because of the limitations of punch cards (and memory) programs back then were short, concise and very well planned out. I think that died out with a lot of the newer languages and expansion of memory resources. The code may have been called "spaghetti code" because of its structure but today I see such poor programing without respect to making the code efficient that it just boggles my mind. Had a professor once who said code should work first, worry about the decorations only after you are sure the code gives the correct results...And while I feel super old going back through memory lane into those early days of my programming, at least I'm not so far back as to be in the punch card era like KS.
One of the courses I took in college I learned how to do a lot that exceeded the limitations of the machine. One example would be calculating 2^64 on a 32-bit machine without integer overflow (and remember the limitations of 32 bit arithmetic then). Another was how to swap memory using XOR instead of needing swap space allocation.
If that was true there wouldn't be so many security issues with today's OSes and applications, some of which I attribute to laziness and a lack of understanding of the limitations of a computer language and the hardware.
Can't imagine too many things the average poster around here would be playing with in programming languages that would pose a security risk. Little applets and light duty games can be done on just about any modern language.
I was just pointing it depends on the type of programming one is doing. I can't imagine most of the posters here programming the diabetes testing models I did either...a lot of high level math and statistics.
