So this is dedicated to Nick (and the first part of it is meant in the spirit of friendly teasing; no serious criticism intended). It was brought on by his response to the discussion on “Bibi to Obama,” but somehow it got so long and was so far O/T that I thought I really shouldn’t entirely derail that discussion. Hence the new posting. It happened like this….
Nick ended his passionate defense of the Israelis’ contributions to the Global Good by referring to their improvements in computer technology thus:
August 4, 2014 at 8:05 pm
Write a program once and… I have more computing power on my lap in this Lenovo S440 Thinkpad than probably existed in 1960 on the planet. The CPU was designed in Israel.
Never one to keep to the subject, I interjected the question,
Nick, one can actually program that sucker?
meaning the Lenovo Thinkpad, that is.
Nick responded to that:
August 5, 2014 at 8:12 pm
I adored that response, because I too am a HUGE fan of Fortran. Besides, it offered me an opportunity to issue a correction, a hobby of mine which, surprisingly, some people seem to find tiresome. Ah well, their loss….
So I commenced, and the thing grew, and, well, here we are. Or here I am anyway. You, dear reader, may have gone on to washing your hair, or cleaning the groove in the patio door….
* * *
Nonsense, Mr. Mc[I-forget-the-rest] *g*. You program a computer IN a language. You USE a language to program a computer (in any given particular case). More correctly still, you write a program FOR (or to be RUN ON) a computer IN a language. I trust this clarifies the matter. *haughty sniff*
By the way, one does not write “machine code.” At least, not unless you mean writing in actual hex, or octal, or, to really get right down to it, binary. And it is insulting and fake elitism to talk about “writing code*” or saying something gaggingly sophomoric like “do they ship code on time.” Yes, I’m looking at you, Eric Raymond.
*Toward the end of my “career,” there developed a custom where System Engineers designed the layout of programs, including writing the specs; these were handed off to the “programmers,” who (I guess) drew up flow-charts and indicated where blocks of instructions (i.e. “code,” f’rgod’ssakes) would go, and passed those on to mere “coders,” who wrote out the actual instructions comprising the program. Division of labor, don’tcha see.
The upshot of that was that real programmers, now called “coders,” got a bad name as being the less-than-bright grunts of the data-processing hierarchy. I hope this dreadful faux-efficiency-system dropped dead long ago. Complete modularity in creative endeavors does not work.
But as to the main point. Basic rocks. No it is NOT a “toy”; it comes within hailing distance of Fortran. And Fortran IV-G or IV-H, awesome !!! is the only high-level language worth using professionally. Ahem. At the lower level, Assembler (for the S/360-370) and its cousins in the Assembly Language level, Autocoder for the 1401 and 7070 series, Map for the 7090-7094, so forth are the best of the best.
I LOVED Fortran and Assembly Languages, specifically Fortran IV and Assembler. You could get at the machine! You could tell it step by step exactly what to do, you could make it change its instructions, you could tell it to stop using valuable space for instructions and stick some data in there instead, and vice-versa. You could probably have told it to unplug itself, and then plug itself back in!
You sure couldn’t do that with COBOL. COBOL was for people who couldn’t be trusted to go messing about with the machine’s insides. Such things as “peek” and “poke,” even, could not be allowed to Business Types who probaby needed help tying their shoelaces.
I used to try to write COBOL in Fortran, just because of the whole logorrhea business. Thankfully I subsequently worked for an outfit that actually had programmers. Assembler, YUM.
Nick, do not feel like the Lone Ranger. I have messed about a bit with C and follow-ons, and as far as I can tell, the object of so-called OOP languages is to complify, complify, complify. The syntax would seem to defy any vaguely-human logic. Ostensibly these languages were developed so that any fool could read and understand at once any other fool’s program. Tchah! In any case, I was trying to correct an information deficit, as is my Nature, but not trying to put biscuits on the table, so lacking that incentive, in the end I treated the Book as the Koran was not treated by the boorish wardens at Guantánamo, and never looked back. :>))
. . .
Really, there’s nothing mysterious about the basic idea. In assembly languages and the next level of languages, Fortran, COBOL, whatever else qualifies, you have “routines,” which — and this is all as it was denominated in my day, back before the Silurian Epoch — meant the entirety of a program. Some portions of the program were dedicated to particular tasks and were distinct enough from other portions to be little mini-programs — “subroutines” — in their own right.
Somewhere along the way some bright language-designer or programmer (they once upon a time occupied the same physical body, can you imagine!) figured out that some of those subroutines were used often enough that it would be convenient to plunk them down, pre-fabricated, into his program. So he dreamed up a way to “call” the subroutine from within the main program. This little block of instructions that executed the “subroutine call” was incorporated into the main program with a special name or mock op-code of its own. IIRC, which I might not, in Fortran you just wrote “Call so-and-so” and then wrote a list of parameters the called subroutine would use.
Of course, you could get the exact same result by branching to the subroutine in the normal way, provided you knew where everything was (Assembly languages, Fortran). But the Subroutine Call was more elegant in a way, and when it was properly written at the assembly-language level (or IN Fortran FOR Fortran programs) you could use it pre-fab in any program into which it could be compiled. (Assembler subroutines for Assembler programs, Fortran subroutines for Fortran programs, even COBOL subroutines for COBOL programs, etc., though the subroutine itself might not be in the same language.)
Thus were developed Subroutine Libraries, which when you licensed whatever language and its compiler from whomever (by which I imagine I mean, chiefly, IBM) you could get the subroutine library as well, with all its useful pre-fab routines.
Then, some dingbat had the idea of obfuscating the basic logic of the pre-fabbed subroutines system by calling these subroutines “macros.” So now instead of having a subroutine call in a program, you used a “macro,” which as far as I could tell was just the same old thing under a new name.
Macros were used in Assembly languages, like Map and Assembler. I can’t remember if Autocoder had any macros or not. When we got our first Mac, a Mac Plus, it still had macros. In that case at least (and in Excel) one could write one’s own macros. But they were still just subroutines.
Now we have Object-Oriented Programming languages, OOPs. Indeed! In which, I gathered, the idea was to write programs by assembling blocks or “modules” of “code” (read, putting together various sets of subroutines) to accomplish the program’s results.
The syntax would appear to be a nightmare. Why go through all that when you can just haul out the ol’ Fortran, or the appropriate assembly language for the machine-cum-OS.
I say it’s spinach, and I say the hell with it.