Wow, that takes me back. I learned to program on a PET and would have devoured this book had it been available. As it was one of our math teachers was tasked with teaching the computer classes bu didn't have any programming knowledge beyond input/output, loops, and simple calculations. Books and manuals were hard to come by.

Also learned to program on a PET in BASIC writing code that was much messier than this because I was probably 10 years old.

Might be why I'm good at restructuring horrible to read spaghetti code.

> And this is high-quality BASIC by 1979 standards — it’s in a printed book after all.

I don’t think that’s true, certainly not for books of that time period. Because the whole field was changing rapidly, writers would often work under tight schedules, and customers would buy about anything because they only had magazines and books to learn from and review sites didn’t exist.

I also think that’s bad Basic for the time. Certainly, comment lines before subroutines would help.

I would argue that the average program that got printed in a book was probably quite bad but still of a higher quality than the programs people wrote on their own, simply because the latter were usually written without any education or useful models of working programs.

It’s like an iceberg of bad code: the underwater part nobody saw was astonishingly terrible by modern standards. That code might be running a business, but its author would never get exposed to professional programming. Today Excel often serves a similar purpose. (Excel isn’t spaghetti though since the execution model is completely different.)

It looks pretty typical for BASIC of the late 70s to me.

You wouldn't want to waste characters on commenting code: machines of that era would have only a few KB of RAM, as low as 1K. For the same reason you don't want to waste characters on long, meaningful variable names or on well spaced code. Multiple statements per line isn't to save print space, it's to save RAM.

Meanwhile, the program's pretty well structured for such a short bit of BASIC: subroutines start at multiples of 100, for example, and each subroutine starts and ends clearly, no shenanigans like jumping from the middle of one sub to another, no multiple exit points for subs, all as linear as it can be. The use of IF is limited to skipping forward a short way to conditionally execute a line or two only. GOTO only exists in those IF statements.

I'd have been happy to have written code like this, back then.

I am pretty sure that my uncle ran this exact program on his computer and printed out biorhythms on listing paper, in the mid 80s.

I messed with some programs written in basic for industrial controllers that was written in late 1970's.

There is a simple thing. On a lot of machines only spaghettified programs would even fit in the memory available. Academic CS researchers with their unlimited accounts on the institutions mainframe didn't have that worry.

> comment lines before subroutines would help.

That code looks normal to me. I have a ton of BASIC books and magazines. You're talking about a time period before full screen text editors were a thing. It's almost impossible to explain to anyone that didn't have to work with TI-99 BASIC, C64 BASIC, GW-BASIC/BASICA, etc. what it was like. Once you got to QBASIC/QuickBASIC it was done. Life was easy. A few years before that, and you're printing out pages on a dot matrix printer and going line-by-line to debug. You'll notice a distinct lack of white space between lines and that comments start with "REM" and a line number. You didn't even get labels for lines. The code looks like that because those were technology limits on really rudimentary devices. You were editing code inside the BASIC interpreter, often using some command like "LIST <line#>". It was awful.

We take so much for granted today. Dual monitors. Color. More than 80x25 character display. Multiple screens and multitasking. Just getting to Linux in '95 and having F1/F2/F3/etc. switching terminals was a huge deal.

Wasting RAM on REM’s was just rookie stuff.

I remember chasing bytes with short variable names, abbreviated print statements, reducing spaces as much as possible etc.

I had like 28k to play with and I was 14 years old!

And we liked it !

I remember in Commodore basic, finding that a period by itself ('.') was parsed as zero, but was actually slightly faster than using zero, and saved a byte every time it was used. In other words, you could write:

    10 for i = . to 6.28 step 0.1:next

and it would be slightly faster and smaller than

    10 for i = 0 to 6.28 step 0.1:next

Made for some ugly inner loops, but you gotta do what you gotta do. For that matter, we certainly would have removed some of those extra spaces as well. Bytes mattered and whitespace slowed you down.

Worth also noting the sort of wild limits with Basic too that are partially responsible for the code being spaghetti, including effectively an inability to add new lines in the code without adding a goto between previous statements.

What are you talking about?

gwbasic had a function to relabel all the lines. And the labels skip by 10 numbers exactly for the purpose of inserting lines. Then when you had hit the limit you'd ask the computer to relabel them in steps of 10 again.

So many hours of my childhood. Wasted. Damn you. Why didn't you tell me about this then?

> gwbasic had a function to relabel all the lines. And the labels skip by 10 numbers exactly for the purpose of inserting lines. Then when you had hit the limit you'd ask the computer to relabel them in steps of 10 again.

gw-basic was released c4 years after this book, and there was a huge change over that period:

1976 - Release of Apple I

1977 - Release of Apple II / Commodore PET

1979 - This book

1982 - Commedore 64

1983 - GW Basic

This book is pretty much closer to the Apple I than gw-basic. Perhaps I should have specifically said developing basic in 1979 though as referenced in that book though (and there isn't just one sort of basic - there are so many dialects).

> The first program listing is on page 24 of the PDF. Try to follow the logic of the program. Why does line 400 go to 280? What paths can lead to line 400? Who knows!

Without looking at the post-program material, this isn't exactly a difficult question to answer.

Line 400 is preceded by some print statements:

    370    PRINT "PRESS 'E' TO END, SPACE TO CONTINUE"
    380    GET R$:IF R$="" THEN [goto] 380
    390    IF R$="E" THEN [goto] 120
    400    L=0:GOTO 280

So we have a prompt that says "press E to end, space to continue", and then branches one of three ways: if you provide no input, the prompt is shown again; if you provide an E, the entire program restarts from scratch, and if you do anything other than that, the count of lines drawn on screen is reset to 0 and the next 18 lines of the chart are drawn.

We can assume that line 400 will be hit whenever a piece of chart is drawn to the screen.

The program's structure here is a nested loop: there is a loop between lines 280 and 400 (displaying the chart indefinitely, 18 lines at a time) containing another loop between lines 300 and 360 (displaying 18 lines of a chart, one line at a time).

Why is this supposed to be an example of spaghetti code?

Now imagine you have got a typo:

    400  L=0:GOTO 290

This would be almost impossible to debug.

That would correspond to the following C:

    /* 280 */
    do_something();
    for (;;) {
      /* 290 */
      /* display chart in blocks of 18 lines */
      /* 400 */
      L = 0;
    }

when the correct code is this:

    for (;;) {
      /* 280 */
      do_something();
      /* 290 */
      /* display chart in blocks of 18 lines */
      /* 400 */
      L = 0;
    }

The bug is that the call to do_something() precedes the outer loop when it should be inside the loop.

Is that easier to debug in C than it is in the BASIC program? What's the difference?

Pretty sure we had that program on our home computer in the 80s (I was a young kid but I distinctly remember a biorhythms program). What impresses me reading it now is the "y2k" compliance. If the year entered is only two digits, it adds 1900, otherwise it takes the full year.