I have studied and used quite a few programming languages in the past 38 years.
Yes, I am *that* old ;)
In fact, when I started, there were no PC's, tablets and smartphones and even no homecomputers like the BBC and the Commodore 64.
I started, working with a mainframe (to be precise a Siemens 4004 which was compatible with IBM S/360 mainframes).
During the time that I learned to program in Cobol, I did all sorts of work, like operating the mainframe, exchanging tapes and disks (yes, in those days one could exchange complete disk packs depending on which job had to be run).
We had card readers and punchers. Also card sorters, which was a heck of a lot of work to handle, because sometimes we had to sort a very big card deck on multiple positions. That could take hours. And if we by accident dropped a bunch of cards on the floor we had to start all over ...
We had also mark sensing devices. There were cards with no punched holes in it yet, but people could "mark" a specific area on the card using a pencil. The device then would interpret the marked parts and punched holes accordingly, such that the cards could be read by the computer later on.
The last device was one which printed characters on top of the card. For those devices you had to use patch panels with cables to determine which punch positions should be printed where. A bit similar to the old fashioned telecphone switch stations where a few ladies did the wire patching ;-)
There were a few "punch guru's" among us, who almost always could detect errors in a card deck used for program input, simply by looking straight through the whole deck. They new there should be holes through and through on known positions and thus could spot a lot of "bad cards".
When I started programming, we wrote a (Cobol) program literally on paper. The complete program (on paper) would then be punched into cards by special ladies, called data typists. When we received the card deck the fun began...
In order to compile a program you had to feed the card reader with:
1. a punched card deck of the compiler itself (* later on the compiler would already be on disk)
2. the card deck with the source code
The compiler would then:
1. print a listing with any errors
2. punch a card deck containing the object format (* later on it went straignt to disk)
Most of the time there were lots of errors. Maybe not real programming errors, but just typos of the punch ladies, for whom all the text was just gibberish ;-)
After repeating this proces and punching individual "patch" cards to update the source, one would obtain an object deck.
This had to be linked via the card reader:
1. feed card deck of the linker (* later on the linker resided on disk)
2. feed the object deck (from the compile step)
(* With later on I mean that this became available at a later stage)
As you can see a very cumbersome series of tasks.
One of the most problematic things was the small main memory of the mainframe. In fact, our mainframe had a core memory of 128KB (of which I have still preserved a physical piece somewhere). Core memory really was handwoven by women under a microscope, where they put 3 very thin copper threads through each small magnetic core, a real wonder of technique indeed!
In order to save memory during compilation and loading of a program we used the so called "label lists". In the current times we can use variable names of any length, because we have plenty of memory. Not so in the old days.
We had, on paper, a list of our (very short) variable names and next to them the corresponding description a.k.a. the would be variable name :-)
Debugging a program was really mind boggling. One had to use an up-to-date label list. But, hey, in those days there were also a lot of people that eschewed documentation. Hence we had a beautiful task of trying to grasp the meaning and structure of sometimes very big and complex programs, not being helped whatsoever with the variable names.
That said, in these days we also had "cowboy programmers" using "go to" all over the place. And even worse, in Cobol you could change the meaning of a "go to", so that you ended up in deep shit when debugging ...
Luckily enough I was teached structured programming and later one most of my collegues as well.
Another nice thing was that big programs did not fit in the 64KB user part of core memory (the rest was reserved for the OS). So we wrote our programs in overlays. That is:
1. write a base piece which always stays in memory during execution
2. the base piece loads an overlayed part when needed
So, in fact we used our own hand written swapping mechanism. Nice huh?
Also notice that there was no multi processing whatsoever. When a job ran, it used the whole user part of the memory all the time. One job at a time. Unthinkable these days, isn't it?
What has this all to do with 8th?
Well, one of the reasons to be fond of 8th is it's heritage - Forth.
When I was struggling with Cobol, a lot of scientists (many astronomers) were using Forth to control their million dollar equipment (telescopes).
When we develop using 8th we take a lot for granted:
1. we have an easy to use Operating System
2. we have plenty of good and free program editors
3. we have marvelous PC's with lots of internal and external memory
4. we have enough room for nice word names :-)
Those astronomers just used Forth. No OS, no (external) editor, very small internal memory.
How could that be???
Well, in fact the old school Forth was an OS in itself. It supported editing etc.
Still, it was not easy at all, because:
1. one had to wite their own device drivers
2. one had to take care of using the right chunks of memory (no overwrites)
3. one had only a very simple in built editor
etc. etc.
When I take a step back and compare my current smartphone with the mainframe I started with, well the magnitude of scale is really beyond what one could ever have expected.
Given the fact that we now do have plenty of memory. I still hate (very much) the many bloatwarez. So, in my search for the best programming languages, I always end up with the small ones, that accomplish many things right out of the box.
So, not Micro$oft or O$acle programming languages prevail in my vision.
I think 8th ranks with the few very best languages, not bloated, small footprint, very functional (many libraries), many target platforms (in part thanks to its Forth heritage).
If you did not try 8th earlier, please download a free copy
here
The forum is *very* n00b friendly!
