BYTE Magazine: The C Language (1983)

The exceptions were interesting. A common approach was a byte code interpreter/machine. This had the advantage of being easier to port, as you only had to port that piece rather than the whole app. Hardware used to be a lot more interesting back then with all sorts of variations on memory addressing modes, size of units of information (bits & bytes), overlaying (you couldn't fit all your code and data in memory at once), file access, and even something as simple as drawing text or graphics on the screen.

An example for games is https://en.wikipedia.org/wiki/SCUMM

UCSD Pascal, and later large parts of Microsoft Excel (plus Word I believe) also used the approach, especially in the latter case because it needed less space - https://en.wikipedia.org/wiki/P-code_machine

Programming back then was very different to today. Virtually everything was constrained by cpu, memory and storage. Writing products involved working out how you could do things despite those, and debugging was not fun. Just like using 9 inch monitors, it seemed fine at the time, but now I really like having almost unbounded everything, and several freaking huge monitors!

And the Apple II clones and the PC clones...:-)

Back then, I was just going through high school with an Atari 800.

In summer 1982, a learned of Pascal's existence at the local university...but my classes were in Basic. I first encountered C in the late 1980's in the context of the Amiga and its ROM Kernel Manuals.

Two decades later, HN is where I heard of Python, Ruby and Clojure [and Rust, Go, Haskell, J, Julia, etc.]. The medium had changed, but for anyone not tuned to the right channel it all passes unnoticed. Even today. most people use Windows and installing a C compiler is outside normal operating parameters.

None of which prevents me from noting how I miss the physicality of BYTE and other magazines from that era, too.

C compilers for microcomputers were still a new thing in 1983. They were common (for obvious reasons) on Unix machines and larger mini-computers. The only 8-bit C compiler I touched was Aztec C for the Apple II computers and it was unbearably slow (even though the II was quite zippy compared to its Z-80 based counterparts). Borland made an excellent Pascal IDE for CP/M computers but I can't remember a decent C for those.

Fun thing is that Aztec C came with a bunch of tools, including a csh-like shell and vi (no, not vim) text editor. Very slow (felt like a 300 bps terminal line), but one could pretend to be accessing a much larger computer somewhere else.

An ad for an oscilloscope in a computer magazine! Heaven!

My mom subscribed to Byte during that time period, and I remember counting the days until the next issue would arrive. There were so many cool articles about fundamental things, many of which were over my head as a high school kid. My favorite part was Ciarcia's Circuit Cellar.

In my view all of the computer magazines went downhill (for me) when personal computers began to mature, and the articles stopped being about nuts and bolts.

An ad for the Apple III. Perhaps a warning of the overheating MacBook Pro logic board woes to come!

Thompson went a step further by inventing the ++ and -- operators, which increment or decrement; their prefix or postfix position determines whether the alteration occurs before or after noting the value of the operand. They were not in the earliest versions of B, but appeared along the way. People often guess that they were created to use the auto-increment and auto-decrement address modes provided by the DEC PDP-11 on which C and Unix first became popular. This is historically impossible, since there was no PDP-11 when B was developed. The PDP-7, however, did have a few `auto-increment' memory cells, with the property that an indirect memory reference through them incremented the cell. This feature probably suggested such operators to Thompson; the generalization to make them both prefix and postfix was his own. Indeed, the auto-increment cells were not used directly in implementation of the operators, and a stronger motivation for the innovation was probably his observation that the translation of ++x was smaller than that of x=x+1.

http://cm.bell-labs.com/cm/cs/who/dmr/chist.html

Note that one of the claimed benefits is "expressions that eliminate most temporary variables". That was a huge advantage because memory to store source code was scarce, and even more so because compilers were dumb. If you used a temporary, chances were the compiler would use a store for every write and a load for every read.

Compilers were dumb because they had to run at reasonable speed in scarce memory. The time of the 63-pass Fortran compiler for the IBM 1401 (http://ibm-1401.info/1401-FORTRAN-Illustrated.html) was gone, but for microprocessors, not by much.

    add(a, b, c) { return a+b+c; }

    msg(s, a1, a2, a3, a4)
        char* s;
    {
        printf("info: ");
        printf(s, a1, a2, a3, a4);
    }

    ...later...
    {
        msg("an int is %d", anInt);
        msg("a string is %s", aString);
    }

I don't know classic Algol, but I've dabbled in Algol-68 (a most underrated language), and in that the parameter passing syntax is unrelated. The add function would have looked like:

    proc add = (int a, int b, int c):
        (a + b + c)