@k11m1 Yeah, it was something that was needed when computing power was a precious resource, much less common, and we needed to conserve it.

Good things resulted from that - people created solutions to enable remote access, shared systems, one large machine that processed tasks from many people or departments; scheduling, so you could slot a job for some late hour when there were less people around.

Following the logic is a good thing, as you write line by line, it should make sense, and flow -- or else, why did you use that line, and the next?

There are pesky typos that break things, but other than those small input errors, the code should be understandable and make sense.

Someone else might have to work on it someday, and that will make their job easier and faster too.

Back in time programming languages were developed to cater to some specific need or group of users; making it easier to create the projects they needed.

We used Fortran, which is Formula Translation; it was created for Science and Engineering students and professionals.

I had a room mate who was in the Math department, we were both 1st year students, had the same Profs (from Math department), and the same assignments.

But his class used another language, called Algol - which was a better fit for Math people's needs.

We enjoyed comparing the finished results of our assignments; quite simply, we looked at the thickness of each other's stack of cards. Sometimes, Algol would win (win being a smaller deck, less processing time), other times Fortran got it. 😄

It was my first time ever seeing and working with a computer -- a mammoth Burroughs 5500 mainframe, and I loved every aspect of it.

Over time, I observed that I could tell right away when something was broken in a new project.

* When I had my source code written up, the next step was to hand it in, for a pool of secretaries who would prepare our cards, overnight. Or find a spare IBM punch machine somewhere (my preferred, faster route).

* Got the cards? Processing time! Go to the computing center, and get in line with other students with their own decks; we lined up outside, in front of a room that contained a card reader (input) and a large printer (output). This was a smaller room, wired to the computer next door which was all air conditioned to around 18 degrees C year around.

* The card reader had two doors, it's own Input and Output of student processing; in via one, hand in the deck, watch it be read, get a printout, out via the other door.

* As the deck was handed in and loaded into the card reader, we stood watching, hoping for a good run. Any result would produce a paper printout, those continuous paper forms. Many times, it was a report of an error at some point.

* processing took some seconds; and I noticed that sucess or failure was indicated by the card reader behaviour; a perfect program would pass thru the reader in linear fashio, smooth flow. I got excited, maybe this time it's all Good!!

* I also noticed that hesitations in the stack flow indicated errors; it would stop at some card, pause or a few seconds, Bad sign! 😔 Soon it would resume, a short report printed, and a more or less dejected student headed out door #2.

...to go back to his desk, his notes and code write up. Read the report (quite cryptic usually), and trace thru the programme to find what was wrong.

Getting a smooth card reader flow was an instant sign I might have made it - and at best happened at the 3rd try or so (worse sometimes, in harder jobs or if you weren't focused enough).

Some great work was done in developing whole languages to be used for teaching Programming, like Pascal -- good habits would carry on into a professional's work life, and be appreciated by anyone working with this person, or later maintaining their legacy code.

#QotoJournal #History #Technology #Programming #Retro #IT