Dijkstra's Revenge

I have recently been on a quest to port some Classic BASIC language game programs to some classic computer systems (LCM's CDC 6500 and SDF's TOPS-20 TWENEX.org) for the entertainment and edification of myself and my fellow retro-computing hobbyists.

Classic BASIC refers to implementation of the BASIC programming language beginning with the original Dartmouth BASIC (1964), including various versions of Microsoft BASIC (1975-), prior to the development of versions with explicit support for structured programming (such as BBC BASIC) in the early 1980s. Classic BASIC programs are characterized by the requirement to number each program line and use of the GOTO statement for program flow control. They have an infamous tendency to devolve into "spaghetti code", inspiring computer scientist Edsger W. Dijkstra's aphorism.

"It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration." -- How do we tell truths that might hurt? (1975)

Actually, it's worse than mental mutilation. BASIC saps the will to live.

The first headache imparted by this project is that a large number of BASIC program source files available on-line makes use of one or more techniques of compacting the source code to save storage space and reduce typing time (retyping program source listings by hand was the primary method of porting software) that were supported by many BASIC systems of the day, but not by either BASIC-10 on TWENEX.org or the BASIC subsystem on the CDC 6500.

I briefly cursed Microsoft BASIC for introducing these wrinkles, but was later chagrined when I found in the Bitsavers archive a copy of the 1975 DEC book in which the original, pre-Microsoft versions of these games were first published and saw that the source-compacting techniques all originated in the various minicomputer BASIC implementation, each system in its own idiosyncratic way.


So although I started programming my source uncompacter program in the spirit of "Screw MS!", it was futile because 1) it's hard to screw a company with a product they haven't marketed for 16 years, and 2) the offending features weren't MS's idea in the first place.

Without Microsoft to offend, I decided the next best thing would be to go as retro as possible and program my uncompacter program with stone knives and bear skins, or the original Dartmouth BASIC. Or at least as close to the original as possible, since the original implementation lacked both file I/O and character string-handling functions.

That's when the headaches started. It shouldn't have come as a surprise, but reimplementing the function of a single line of my near-complete Perl language prototype required dozens of lines in BASIC.