Memories – Starting in Computing, in the 70's
Z(1) = Y + W(1)
The famous “punched cards”, which each cold hold 80 characters or one line of programming instructions or data for processing.
I learned this language, and created my assignments in decks of those cards.
Back in November, when I was starting in mastodon, we had a delightful thread about it, which included this image. @k11m1 — see it here
May 17, 2020, 8:32 PM
Programming, can be Fun or Frustrating
A more recent conversation, which started naturally once I saw Klimi's post :
My response to this simple statement was a long reply, which I thoroughly enjoyed writing, and now forms the body of this page.
Getting it Right on the First Try ?
It is not impossible, but it takes a lot of concentration, and hopefully a smaller programme to work with.
When I first learned, we did not have access to computers directly at all; that was reserved for the high priesthood, serving the needs and whims of the large, school gym sized computer center. We students would create our programmes, that had to do some task assigned by profs.
Making my own Deck — IBM model 29 :
And later get the lines of code ready for input — punch cards for us. I did my own punching, found a quiet room with a machine in the Physics department, little used, and would go there to prepare my deck,
Because testing was laborious (revisions equaling new cards needed, finding a punch, etc) we tried the best we could to read and follow the logic.
But I think getting it bug free in 3 passes was good, very good.
20 Years Later...
Fast forward many years, and me teaching BASIC programming; my students were bright, did well, but they found it quite hard to create a small programme in paper only (without trying to run and see what happens, to find the errors).
This was good for discipline, but it is less common. They whined every time I called for a pencil and paper only task, lol....😺
And it continued :
@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.
Programming Languages Evolved from Needs
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. 😄
My First Computer was a Burroughs 5500
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 Celsius 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 success or failure was indicated by the card reader behaviour; a perfect program would pass thru the reader in linear fashion, 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.
Smooth Flow is Good News
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.
And Klimi enjoyed it. 😺
Thank you, I enjoy writing a lot.
And this could be developed into a new Blog post easily, a thought that occurred to me as I wrote it too. Another motivation for going in length.
I have a couple of favourite Blog posts that started this way, as a Toot or a series of them, and were so interesting that a Blog page was next. :)
I am having many ideas for Blogging again, hope it does come; just got to clear my head, jot down notes and fire up the tools. Appreciate the comment, which means a lot. 😄
Some Articles about Punched Cards and Computing :
While searching for the references in the next session of this page, I came across a wonderful list of articles. At the must-visit Computer History Museum, located in Mountain View, California.
Computer History Museum 1401 N. Shoreline Blvd. Mountain View, CA 94043
About 100 Kilometers south of beautiful San Francisco, and very near the GooglePlex, the giant company headquarters which I suggest as a second attraction to visit if you find yourself in this region. The Museum is breath taking, wonderful, get there early as there's much to see.
Reference Articles from CHM :
References — Keywords used in this Article
a. FORTRAN :
Fortran is a general-purpose, compiled imperative programming language that is especially suited to numeric computation and scientific computing. Originally developed by IBM in the 1950s for scientific and engineering applications, FORTRAN came to dominate this area of programming early on and has been in continuous use for over six decades in computationally intensive areas such as numerical weather prediction, finite element analysis, etc. Wikipedia page
b. BASIC :
BASIC is a family of general-purpose, high-level programming languages whose design philosophy emphasizes ease of use. The original version was designed by John G. Kemeny and Thomas E. Kurtz and released at Dartmouth College in 1964. They wanted to enable students in fields other than science and mathematics to use computers. Wikipedia page
c. Punched Cards :
A punched card or punch card is a piece of stiff paper that can be used to contain digital data represented by the presence or absence of holes in predefined positions. Digital data can be used for data processing applications or used to directly control automated machinery. Wikipedia page
d. ALGOL :
ALGOL is a family of imperative computer programming languages originally developed in 1958. ALGOL heavily influenced many other languages and was the standard method for algorithm description used by the Association for Computing Machinery in textbooks and academic sources until object-oriented languages came around, for more than thirty years. Wikipedia page
e. Burroughs 5500 :
The Burroughs 5500 was a unique machine, first introduced in 1961 as the B5000. Later advanced to the B5500 (1964) adding disks and finally the B5700 (1971) adding solid state drum. It was the first computer to use the stack as its only means of accessing data. The Burrows 5500 article, Sky Visions Burrows 5500 computer Brochure, Computing History Museum
f. IBM model 29 Card Punch :
The IBM 29 Card Punch (also called the 029 or Type 029 Key Punch or Keypunch), introduced about 1964 to coincide with the introduction of the IBM 360. Available in nine models with various combinations of keyboard (12-key numeric or 64-key alphanumeric)... Columbia University page IBM model 29 video YT
g. PASCAL :
Pascal, a computer programming language developed about 1970 by Niklaus Wirth of Switzerland to teach structured programming, which emphasizes the orderly use of conditional and loop control structures without GOTO statements. Although Pascal resembled ALGOL in notation, it provided the ability to define data types with which to organize complex information. Encyclopedia Britannica page
Follow Blog via your Fediverse/Mastodon account :
This page created entirely in MarkDown language. Thank you for reading, feel free to comment about this post – reach me at my Writer's Lounge.