Running alternative operating systems on early micro-computers, such as CP/M on an Apple-II, provided more capabilities, and ability run slightly more powerful software

The IBM PCs and clones around that time-frame certainly had the power to host compilers, Turbo-Pascal was one early example.

Also, back then, with some exceptions, most commercial products on micro-computers were written in Assembly language, not a high-level language. This was done for performance. This was common.

However, C was generally regarded as producing code that's fast enough that enabled programmers to use it instead or coding directly in Assembly. Certainly, with the new crop of computers, the faster IBM PCs (ATs), Macintosh, Atari ST, Amiga, all had sufficiently sophisticated compilers where that became standard issue. Pascal and then C.

So around 1983, C was become something that people were starting to take a much closer look at because of the availability of hardware and operating systems that allowed them to use C. It is not that C was not available previously, but it was used by a different class of developers, the ones with S-100 Bus machines running CP/M of some form.. these are machines that often required you to re-target the BIOS from source when you add more RAM.

C also became the default language for Windows. For the Mac, it was a form of object Pascal at first, and then moved to C++ with MacApp.

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

http://en.wikipedia.org/wiki/Lotus_1-2-3 (Decline)

Flipping the pages of the magazine is awesome - the ads on every other page are just like time travel.

It has been so long since I have last seen the Charlie Chaplin ad for IBM: https://archive.org/stream/byte-magazine-1983-08/1983_08_BYT...

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.

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.

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

  With Microbuffer, you don't have to wait for your 
  printer to finish before you resume using your 
  computer.
  
  Data is received and stored at fast speeds, then 
  released from Microbuffer's memory to your 
  printer.
  
  This is called buffering. The more you print, the 
  more productive it makes your workflow.
  
  Depending on the version of Microbuffer, these 
  buffering capacities range from a useful 8K of 
  random access memory - big enough for 8,000 
  characters of storage - up to a very large 256K - 
  enough for 256,000 characters of storage.

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.

I remember as a child, being bitterly disappointed with how bad Ferrari Formula 1 was on the Amiga, and I ended up blaming the slow speed on C. That colored my attitude toward the language for years, though once I started working, I ended up writing C++ mainly.

Nowadays, I've reverted to coding in C99, simply because I can easily find libraries for 'hard things' like generating jpeg files, and because cleanly written C performs like almost nothing else, and because console programs have a refreshing simplicity about them, especially if you put all the cool stuff in a library, then just hash up a text-based front-end.

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.

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.

    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)

https://en.wikipedia.org/wiki/Algol_60#ALGOL_60

   procedure Absmax(a) Size:(n, m) Result:(y) Subscripts:(i, k);
        value n, m; array a; integer n, m, i, k; real y;
    comment The absolute greatest element of the matrix a, of size n by m,
        is transferred to y, and the subscripts of this element to i and k;
    begin
        integer p, q;
        y := 0; i := k := 1;
        for p := 1 step 1 until n do
            for q := 1 step 1 until m do
                if abs(a[p, q]) > y then
                    begin y := abs(a[p, q]);
                        i := p; k := q
                    end
    end Absmax