Early Programming Books

[Toby Thain]

On 2021-06-20 10:06 p.m., ben via cctech wrote:
> On 2021-06-20 6:57 a.m., Toby Thain via cctech wrote:
>> On 2021-06-20 1:39 p.m., Paul Birkel via cctech wrote:
>>> Dave;
>>>
>>> I'm much more curious about programming books that were *not* machine
>>> specific.
>>> That is, about "general principles" of designing/preparing software for
>>> execution.
>>
>> Not sure if it's what you are looking for, but if you haven't, check out
>> "Classic Operating Systems" by Per Brinch Hansen.
>>
>>>
>>> Of course, one needs a language; McCracken (1957) defines TYDAC.
>>> Much later (1968) Knuth defines MIX.
>>>
>>> In between perhaps one could argue that ALGOL 58 qualifies as such a
>>> language-for-demonstration, but I don't believe that there were any
>>> books
>>> specifically about programming in ALGOL 58.  I presume that there were
>>> eventually such books for ALGOL 60.
>>
>> Pretty sure I own one, by Dijkstra. Will get details later if you are
>> interested.
>>
>> --Toby
> 
> I suspect after 1958 people stopped thinking of real world programming
> problems. All the general programming books, seem to want to get rid of
> the "goto" or have Strange-multi-level variables or procedures or just

Structured Programming is even manifested in a language as neckbeardy as
C; it's not only for quiche eaters any more.

> use unbounded memory. Operating system books have chapters about some
> logic construct only to state later in the book, "That does not apply
> to this system setup".
> My latest gripe, is I still am looking for a algorithm to generate
> code for a single accumulator machine for an arithmetic expression.

Tried the Shunting Yard algorithm? But watch out, it was invented by a
quiche eater...

> Parenthesis need to evaluated first and temporary variables allotted,
> thus a two pass algorithm. Everything is single pass. Recursive decent
> can parse but can't generate 'correct' code. A-(B+C) is LD B ADD C ST T1
> LD A SUB T1, not LD A ST T1 LD B ST T2 LD C ADD T2 NEGATE ADD T1
> Ben.
> 
> 
>