Hacker News Reader

Comment by glimshe | Hacker News Reader

BASIC was responsible for sparking the interest in computers for a generation. One of the most harmful falsehoods about it is that somehow GOTOs and line numbers would turn you into a bad programmer for life. I think that even today there is nothing like BASIC to get kids interested in computers.

But it's not a language just for kids. While most dialects are somewhat limiting, there is nonetheless a TON of real useful stuff you can do with it.

View on HN

> One of the most harmful falsehoods about it is that somehow GOTOs and line numbers would turn you into a bad programmer for life.

In fact GOTOs in BASIC were, I think, a big part of lowering the barrier to programming for the new and the young. It relieves the mental load of structuring the program, allowing you to concentrate on the logic and syntax. Not using GOTOs requires already having a mental picture of what the program should look like before you write it, or at least rewriting it multiple times as you go.

As a Rust programmer, I probably spent 5-10% of my time restructuring branches to deal with Results and Options more elegantly, and it is the least fun part. While not related to program flow, it's an example of a Good Thing that makes coding less fun.

For me BASIC led to VB which led to VB.Net which quickly led me to C#.

I did some real fun stuff in BASIC as a kid that I never replicated in later languages. In kindergarten or first grade, I picked up a book called something like "Make Your Own Computer Games" at my local library. Everything was GOTOs and LABELS. The librarian didn't want to let me check it out because it was beyond my understanding, but my grandma insisted. That night and for the following 2 days, on my Dad's work computer, I would type and retype these computer games into GWBASIC in MSDOS, and then type run at the end. There was no way to actually save the .BAS files, so any time I wanted to play one of these games, I had to type it. So I memorized them before I had to turn the book back in.

I then started to combine games together. Like "Guess the Number" and "Hangman" which actually taught me more about programming than anything I learned later in life from education.

For me, as a golang programmer, it's almost the same like you mentioned. Additional mental overhead in golang is that you also need to implement everything in as-flat-dependencies as possible due to the compiler not having support to resolve single methods or recursive dependencies (and -injections).

Usually I find myself rewriting the codebase at least 3 times until I have a modular enough architecture that does not have any unresolvable recursive dependencies. Usually it ends up in a folder structure with a top level structs, utils, actions, cmds, schemas, parsers, protocols etc.

While it also embraces strong knowledge about the architecture, it also is a much higher threshold until you have a program working. Add to this the always occurring defined but not used errors and you can demotivate kids real fast, even though the language syntax and grammar could be very easy to learn (apart from what pointers, slices and reflections or memory allocations and callstacks are).

The funny part, and perhaps the part that really damns the critics, is that (IF..GOTO,) GOTOs and line numbers are useful baseline concepts because they have a direct correspondence to what a computer actually does. People who went from BASIC to assembly language did not experience much cognitive dissonance compared to your average JS programmer. And decades later, computers still work roughly this way under the covers complete with (tests,) jumps and memory addresses. :-)

That's an interesting observation that's never occurred to me. As a teen I got a 4k 8-bit home computer in 1981, connected it to the family TV and taught myself BASIC programming from the manuals that came with it and by typing in simple game program listings from hobbyist magazines. As I got the hang of it I started customizing, expanding and combining different games just as you did.

When I got tired of BASIC and wanted to do more, the only option was this thing called assembly language. The three letter mnemonics were kind of cryptic at first but I somehow got the idea of calling up Motorola and some kind sales rep took pity on me and sent me the reference book for the 6809 CPU. The book was too advanced for me but fortunately, it came with folding quick reference card with a simple chart showing the registers, a listing of all the mnemonics and a sentence or two about each one. That card was my constant companion as I taught myself assembler by writing simple programs that would put graphics on the screen.

Just as you said, I never really had any conceptual problem with ideas like holding a numeric value in a register, an index pointer storing the address of a string or array in memory or conditionally branching. All of these had fairly direct analogs in BASIC like LET, IF, GOTO, GOSUB, ARRAY, PEEK and POKE. Even primordial 8-bit ROM based BASIC wasn't that awful. The biggest challenges were the lack of editing tools, being locked into line numbers and the cryptic two-letter error codes. I think a modern BASIC dialect with full-screen editing (no line numbers), named function calling with parameter passing and a decent debugger would still provide a reasonable introduction to computer programming.

This was enough to launch me on a successful lifelong career in high tech as a programmer, product manager, entrepreneur and eventually senior executive. Every bit of it self-taught with no formal computer education at all.

I still have my 6809 book. Back then, Motorola would send docs for the asking.

I actually went to a field office where one of their engineers sat with me for a while! Very cool.

Started on 6502, friend got Color Computer, and I loved 6809. Beautiful chip.

Exactly and why I wrote my comment above.

I would add the computed goto, as in something like:

GOSUB (X * 100)

Is really fast, and using switch, or case, or a set of if, then, else statements can work, but not work well.

There are times when a numeric value works for branching, and having this in BASIC maps directly to assembly language where that sort of thing gets done all the time.

That's not something the Locomotive BASIC of Amstrad or the C64 basic support, seems like at least these two require a literal line number (probably also because how else would `RENUM` work?)

To emulate that feature in a development tool for the Parallax Propeller (FlexSpin), a sequence of labels was used.

on X goto a, b, c, d, e, 10000, Fred

While not quite the same, the core need is addressed and compiles to a fast jump table.

Interestingly, that tool allows one to build programs in SPIN, assembly, C and BASIC. The developer can mix and match at will and it all compiles into an executable image.

The Propeller Chip, especially Propler 2, is a literal, embedded playground. Lots of fun.

> somehow GOTOs and line numbers would turn you into a bad programmer for life

I think the opposite. It's super simple to understand as a beginner and is a low barrier to entry. The key is likely aligning when to introduce someone to a more structured language with when the are hitting the limits of GOTO - like just have finished writing an awkward large program that could be significantly simpler, spent hours debugging a problem caused by lack of scoped variables, or are trying to modify something they wrote a few months ago that has dozens of GOTOs. These are the things where ideally the light goes on and people "get it".

On the last point, I think that is really what makes people great. Go back and try to work on code you haven't looked at it even thought about in 6+ months. If you've only been coding a couple years, you'll gain a ton of insights into what (not) to do to write maintainable software, in the same way students learn why we don't use GOTO.

Good point actually - when teaching absolute newbs, I found they'd often confuse the point of a while with a for with an if block.

GOTO is super unambiguous and probably a better introduction to program control flow while they get used to manipulating and juggling variables around

I would suggest that Rust's only actual loop, (using the keyword loop) is unambiguous while also being structured. You can (and during development I sometimes do) just write loop until it's apparent what you actually meant and then rewrite - also the Clippy linter will point out various obvious idioms e.g. for or while let loops if they are written as legal but unidiomatic loop constructs. So that aids pedagogy. Your loop works, but the linter explains how an experienced programmer would express the same loop more clearly.

Computed GOTO is often possible in BASICs. In one sense that's awesome, this is a very powerful technique, but in practice it's so unstructured that you shouldn't ever use it so why even offer it?

"That's how the machine works". Yes it is, which is why we don't write raw machine code when we can.

I think it should be used when one needs a fast, deterministic field of branches.

When I used them, I would use boolean in the math to insure the input value was bounded properly.

X = (Y > 5) and Y (for systems setting true to -1 all bits set)

X = Y * (Y > 5) (for systems setting true to just the value 1)

Basically an in-line compare where the actual numeric value result of the comparison is used in a math expression rather than as an input to an if-then construct.

And these two ideas map directly to assembly language, which given the speed of the machines back in the day, made sense. People were going to be using assembly sooner or later.

You didn’t have to go straight from BASIC to a more structured language - you could learn about GOSUB first.

Doesn't that still use unscoped global variables, though? That, to me, is the thing that causes unmaintainable spaghetti code more than anything else (in any language).

GOTO-based programming is just continuation passing style - the definition of GOTO is literally switching the continuation of the current statement to something else. (Which means that its preconditions are OR'd to the preconditions of its target statement, and its post-condition is not defined. A GOTO-based program becomes easier to analyze and understand if you add COME-FROM markings to every possible GOTO target.) Incidentally, one can understand self-modifying code in a similar way.

I find this intriguing. Would you mind to expand?

I second the request to expand. I do not understand your comment and I want to.

Got a link we can use to get some insight maybe?

GOTO does not pass a continuation though, so I can't see how it is similar to continuation-passing style. GOTO is just a jump like jumps in machine code.

BASIC does not have notion of a continuation as a value.

Some BASICs such as BBC BASIC allowed GOTO to take a variable or expression directly, and many BASICs supported the ON..GOTO construct that allows for the same. And turning all control flow within a program into jump-like operations is arguably the main point of CPS.

But this is just computed gotos. There is no continuation passed.

Arguably the main point of continuation-passing style is that you pass a continuation along with the jump. Hence the name.

I learned Basic at 10, and I would argue that Python is a better choice today. But regardless of which one, the most important thing about basic was that for a while every computer came with some flavor of Basic. It's what got a generation hooked on tech.

Why oh why doesn't Windows and macOS come with Python and Idle out of the box? Or does Mac, I forget.

The Mac does come with Python, but of course it’s easier to get started from zero when the first thing you see after switching on the computer is a BASIC prompt.

Not just that, usually the computer came with a printed manual for BASIC too.

Having an onramp to programming is nice. I also imagine there was more of an incentive to write your own programs when there weren't a million games and other apps already available in app stores.

Mac like other bsd/linux includes a system python but not idle.

I also started with BASIC at 10 (C64 in 1990) and I'm going to teach my kids to code in Python. It's simple (low abstraction) and integrates well with other things (IoT) and they can use a REPL.

It's disappointing that Windows doesn't release with an accessible interpreted language. They ship with a couple of games so why not drop some kind of super integrated and simple programming environment? Most of my generation cut their teeth on Microsoft Basic after all.

I think most tech companies rely on ignorance to sell their "simple" solutions. If everyone could solve their own problems their own way, then nobody would buy "simple" solutions.

Tech companies sell convenience. Most people don't want to to do the work required to "solve their own problems their own way". They aren't buying simple. They are buying: "It's Already Built".

`Win+X I` brings up a PowerShell window. It’s supremely integrated - it can do ANYTHING a compiled .NET language can do, including calling into unmanaged COM, etc.. And it’s super simple - you can get started with simple string processing and file manipulation in just a few characters. It’s just not popular in the same way BASIC was.

Agree with everything you've said about Powershell. It's pretty cool.

Buuut...the common Basic computers of the time had commands that let you do built-in graphics in a very simple manner. Not anything as crazy complex as the .NET charting and GUI stuff available to Powershell now. It's a real shame there isn't a built-in DSL that could allow normal users (i.e. not full time developers) to build some really simple games in like half a page of code.

> the common Basic computers of the time had commands that let you do built-in graphics in a very simple manner.

I don’t remember Commodore Basic for the VIC-20 and Commodore 64 doing graphics other than through a series of POKEs.

Commodore was very much the exception here. Pretty much every other 8-bit computer's Basic had a bunch of commands to do graphics and sounds. But Jack Tramiel just slapped in a licensed copy of Microsoft's Basic with the least amount of work necessary to make it run.

I know, but it also was one of the most common of the “common Basic computers” of the time.

The Commodore machines at least had a fairly extensive set of graphics symbols to create basic [pun not intended] graphics. For sound, though, there indeed wasn't really anything in Commodore BASIC V2.

Tangential: Artist Raquel Meyers does really great stuff with the CBM graphics character set, see https://www.raquelmeyers.com/

Yup.

I think the C64 alone was responsible for a lot of the bad press BASIC got in the 1980s-1990s, from former Commodore owners who knew that one, terrible BASIC and concluded from a sample size of 1 that BASIC was bad.

Most other BASICs were better. Some on machines of the same era were much better. The BBC Micro had the same CPU and had BBC BASIC, the fastest interpreted BASIC ever written, with types, structured code, named procedures with local variables, inline assembler, rich graphics and sound support and more... in 32 kB of ROM (half for the modular extensible OS, the other half for the BASIC).

Tramiel cheaped out: the machine had 20 kB of ROM, with an OS half the size and a BASIC half the size (plus a fancy character set).

I expanded on this a few years ago, here: https://liam-on-linux.livejournal.com/71381.html

I had Microsoft basic on an Interact of all things, and it had plot x,y and a way to set color.

CMD.EXE is sort-of BASIC-like and you can write simple games in it:

https://www.wikihow.com/Make-a-Video-Game-With-Cmd

https://youtube.com/watch?v=tYgUxz6Rd_o

A somewhat better choice is VBScript, which also ships with Windows and can be run with cscript/wscript.

What’s indeed missing is a built-in IDE. At least MS Office comes with a VBA IDE.

Apple encourages you to use Swift with Playgrounds on macOS and iPadOS.

BASIC is smarter than Python, don't need :, and it can work out the difference between = and == by itself

One of the advantages of a classic BASIC for a beginner was its very small feature set. It was easy even for a kid to get it all in his or her head. Python not so much, especially the idiomatic stuff. BASIC is very clear:

    10 PRINT "HELLO"
    20 GOTO 10

If you understand that the computer will execute lines in numerical order, it's very easy to understand that. The equivalent in Python of just that simple thing would not be so clear.

It's great as an introductory language IMO. I disagree with Dijkstra that it will do any permanent damage -- if anything it will help the programmer appreciate the advantages of structured or object-oriented code when they are ready for it.

Right? I was just about to say that Windows ships with power shell these days, but then immediately realized how poorly that maps.

It used to ship with qbasic and a nice editor held over from dos. That was pretty good, though it was essentially hidden. It was there, but there was no icon for it and no docs or directions said to use it, let alone boot right to it as your primary interface.

Basically the driving force behind the production of Windows is the parts of MS that make money from it, not the developers who would write stuff for other developers if they could.

They want users that consume, not produce, and they absolutely do not want users who tinker and poke and modify.

They offer development systems only because they still have to, and they make even those into managed inscrutable products you merely use like powerpoint as much as possible.

> I disagree with Dijkstra that it will do any permanent damage

Dijkstra's quote about people who learned programming with BASIC being beyond repair is obviously hyperbole, but given the number of programmers he taught, I'd assume he was seeing some significant difference that was important enough to prompt his statement.

macOS-10.14 (Mojave) has python-2.7 + idle still bundled, but macOS-13 (Ventura) not any more. You'll have to install it via MacPorts, but at least you'll have a choice which version to install.

My Mac with Sonoma aka macOS 14 has Python in /usr/bin/python3, so I assume it's been installed with the system. It might have been installed with Xcode, though.

That's not Python; it's just a hard link to a generic shim for every program in /usr/bin that ships with the developer tools,

    $ find /usr/bin -inum $(stat -f %i /usr/bin/python3) | wc -l
          76
    $ cp /usr/bin/python3 /tmp/IEFBR14
    $ /tmp/IEFBR14
    IEFBR14: error: sh -c '⋯/Xcode.app/⋯/xcodebuild -sdk
    ⋯/Xcode.app/⋯/MacOSX.sdk -find IEFBR14 2> /dev/null' failed with exit
    code 17664: (null) (errno=No such file or directory) xcode-select:
    Failed to locate 'IEFBR14', requesting installation of command line
    developer tools.
    $

and then if you're in a GUI session it pops up a dialog box[1] offering to download and install the developer tools (even if they're already installed; the example above is from a Sonoma box with both Xcode 15.1 and the latest command line developer tools installed).

[1] https://jasomill.at/IEFBR14.png

I do have Xcode installed, and for me it's just Python

  $ /usr/bin/python3                                                                                                                                                
  [ 12:18:42 ]
  Python 3.9.6 (default, Nov 10 2023, 13:38:27)
  [Clang 15.0.0 (clang-1500.1.0.2.5)] on darwin
  Type "help", "copyright", "credits" or "license" for more 
  information.
  >>>

So I guess it depends on whether Xcode and developer tools are installed or not. Too bad it's not installed by default any more anyway.

> Why oh why doesn't Windows and macOS come with Python and Idle out of the box?

Because they have something better: a web browser with a javascript console.

Even I don't know how to use that ;-)

Definitely not just a language for kids - When I worked for the Navy in the early 90s, they were still using software written in Rocky Mountain BASIC on all the submarines in the fleet.

That's mindblowing! I'd expect Ada there! Do you have any references that I should add to the post? :D

Edited: Here’s link to an article that includes a first person account of why RM BASIC (developed by HP) was used by the fleet.

http://hpmuseum.net/display_item.php?hw=367

I agree, and frankly having gone from BASIC to 6502 assembly language, GOTO made perfect sense.

What I like most, and still enjoy today when possible, is how open the hardware is!

For someone wanting to know how computers work, it is damn tough to beat what many of us got as kids; namely, a respectable computer, schematics to understand the hardware, and BASIC right there, ready to go.

My first disassembler was written in BASIC. So was my assembler, and it was a line oriented one modeled closely after the one built into the Apple 8 bit computers.

And look at the BBC Micro! That BASIC was great and offered in-line assembly code! Excellent!

These days, I find microcontroller can offer something similar.

If I ever find time, the Parallax Propeller 2 could make a fantastic computer. It can run cores concurrently, or parallel, or even doing different things entirely. Jim Bagley and friends setup a NAMCO emulator and found they could host 8 simultaneous sessions of Space Invaders, complete with player controls and displays!

Put a BASIC on that, and a reasonable macro assembler and the result would be a killer learning system able to drive lots of hardware and use any display one can find from old TV's to HDMI panels and everything in-between.

> GOTOs and line numbers would turn you into a bad programmer for life

Dijkstra will go down in history as one of the great algorithm designers, but this will always be a black mark on his legacy, possibly overshading his contributions. There's a lesson here about not pontificating outside of your field.

In his text he argued for higher level constructs, as they are established now. I think there he was right. Unrestricted goto often isn't good for complexer programs.

My understanding is that when "GOTO consider harmful" came out, the typical code flow was to put values into global variables, goto to some piece of code then goto back and continue. Nowadays we have functions with arguments and you should just use that. But harmful goto was about the specific type of coding that happened at the time, but people assume it's any goto use in general.

And notably the famously provocative title did not come from him. You could say "he never even said that".

Dijkstra wrote that in 1968. At the time, quite a few languages didn’t support recursion (ten years later, FORTRAN 77 didn’t, officially), and lots of hardware didn’t have a call stack (a word that Dijkstra invented, and described in 1960. See https://ics.uci.edu/~jajones/INF102-S18/readings/07_dijkstra...), so if they needed one, they’d have to write it in code.

Using a language that supported structured programming would get rid of such scaffolding code that hid the logic of the actual program.

Many languages also allowed code to jump out of and into loops, and programmers (ab)used that to cram their code into the small amounts of memory they had at their disposal. The resulting code could be quite hard to understand.

> There's a lesson here about not pontificating outside of your field.

How was that outside of his field, which was about thinking logically about programming?

'Goto considered harmful' really brings nothing new to the table. It just states that gotos are hard to reason about. Well yes, that's true. Computer programs are hard to reason about as a baseline. Everyone knew that goto was hard to reason about before he wrote about it, but for some reason his letter became a reference for people who wanted to abolish GOTO from their codebases.

> How was that outside of his field, which was about thinking logically about programming?

Language design falls under human-machine interfaces, and while basically everyone in that era dabbled in that field, it wasn't really his forte.

Modern Goto's are nothing like what Djikstra was writing about. Reading it in the context of the time it was written it is a fairly good write up.

Never said that they were...

> Dijkstra will go down in history as one of the great algorithm designers, but this will always be a black mark on his legacy, possibly overshading his contributions. There's a lesson here about not pontificating outside of your field

I am begging of you, please do a little bit of investigation into the historical context in which Dijkstra wrote that memo.

Your comment was likely inspired by other replies to my comment, but please, don't assume someone who has an opinion other than yours simply hasn't done enough research to agree with you.

In one 1971 dataset fully 13% of all executable statements were "GOTO": https://www.cs.tufts.edu/~nr/cs257/archive/don-knuth/empiric...

In 1971 people really cared about binary density.

Reading that paper it's hard to believe that the typical programmer cared all that much beyond getting something to work. Whatever you mean by "binary density", the subjects were programming for an IBM Model 67 which was a pretty hefty system for the time. The programs weren't all that big by modern standards either, with "number of executable statements" in the hundreds; when you have megabytes of memory it doesn't seem like spending a few extra bytes on instructions would be that big a deal.

By and large the ancients couldn't have been all that concerned about optimizations. Take a look at their "Example 6" in which the authors were able to significantly improve an inner loop thru such advanced techniques as "use 0.0 instead of 0 if you want a REAL" and "don't make extra assignments".

Do you have some evidence to back any of this up? You're claiming that software developers who had access to an IBM Model 67 didn't actually make use of its full storage space. In that case, why not buy a smaller machine? It sounds completely fantastical/fabricated to me.

> Do you have some evidence to back any of this up?

The paper that I linked?

> In that case, why not buy a smaller machine?

Because they needed to support an entire department or university worth of users, many of them at the same time.

> It sounds completely fantastical/fabricated to me.

Have you ever done serious work on a time-shared system? The kind where you type `w` and see a bunch of people who aren't you?

Nowadays everybody gets their own workstation and can use as much or as little of it as they see fit, but on a shared system trying to use the whole thing is a great way to get people mad at you, because you're taking away resources they need for their own work.

Not that you'd necessarily be allowed to use all that much in the first place, that's why things like `ulimit` exist.

Sounds like you're actually agreeing with me. If there are multiple users, then that just puts more pressure on users to write compact code.

I took the liberty of quoting the first sentence of your comment as the first sentence of the article intro.

I couldn't agree more with you :)

It's all about picking the right tool for the job, and the language itself, as it evolved, picked the concepts it could use from everything else - like other languages do as well.

I hope I didn't convey a message of BASIC being for kids - it just happens that many people that start their adventure with programming (especially in the 80s and 90s, but often also today) look for a simple language to learn the core concepts of how a computer operates internally. It's also a little like with Python - you can create a complex and deeply structured application with it, but it's also a language great for simple scripts that will look much more like the BASIC programs - glueing together a bunch of statements to get to the result ASAP. And this is extremely useful.

It seems like the same characteristics that made BASIC so good to start coding are also the ones that get the most criticism, which is a fascinating paradox.

I see many Ph.Ds programming in Matlab as if it were BASIC -- no functions, everything global, etc, and they get a lot of stuff done!

Rocky Mountain basic had exceptionally nice string handing, array handling and could do matrix math.

I think traditional CS hates BASIC because it's hard to get people to look at it in terms of pure math. And it enables muggles to create useful programs.

I look at it more like Excel now. It gives you just enough to do simple things easily with tools that make more complicated things ... Horrifying.

Seeing deeply nested excel IFs that parsed out individual letters of a string for recursive cell logic still gives me nightmares.

It's not a falsehood. It allows for a lot of bad stuff. Like the following

  function Thing1()  
  begin  
    do important things  
    if condition  
      goto thisIsBad  
    end if  
    do more important things  
  end

  function Thing2()  
  begin  
    do different things  
    label: thisIsBad  
    perform actions  
  end

And people would do the equivalent of that. You'd run across uninitialized variables, variables accessed outside of scope. Yes, there are disciplined ways to use GOTOs. And most control flow can be implemented with conditionals and jumps, but most people are not disciplined.

> most people are not disciplined

Abstracting from programming languages alone, this is the reason why good software design makes doing the wrong thing either impossible, or at least very hard, while making the right use very easy.

I am still learning to do that better. Sometimes I am able to foresee the misuse of a feature and make it impossible, but not always - and it's harder to correct the error once it proliferates.

However, the article puts the quote (though it had nothing to do with GOTO) in context - and at the time no dialect of BASIC that was used by millions of users had support for functions (other than mathematical expressions declared with DEF FN), or procedures - so you couldn't jump out of scope... because there was only one scope.

> GOTOs and line numbers would turn you into a bad programmer

And yet no one said this about programming assembly.

because there's no alternative to assembly, whereas for higher order languages there is

line numbers don't exist in assembly?

Are memory locations or labels resolved to them, probably at compile or startup time, really any different?

The whole GOTO-harmful is a product of a bygone time much as anyone needing to keep track of a jump table by hand is now.

I think the real GOTO-harmful lesson is that for any non-trivial program, you'll end up implementing conditional blocks, loops, and functions by hand. There just aren't other abstractions on top of a von Veumann architecture, and GOTO arbitrary line rarely does anything other than those three cases, and when it does, it's exceedingly hard to get right. Like sure, true spaghetti code is bad, but it's also really hard to write.

> One of the most harmful falsehoods about it is that somehow GOTOs and line numbers would turn you into a bad programmer for life.

Yup! As soon as I was exposed to a language withOUT line numbers and GOTOs, a little light went on, and stayed on.

>>One of the most harmful falsehoods about it is that somehow GOTOs and line numbers would turn you into a bad programmer for life.

i had nightmares about avoiding GOTOs in my teens...

Speaking of line numbers, does anyone know why DECSYSTEM 10's and DECSYSTEM 20's BASIC had a "LISTREVERSE" command?

Yes, it actually did exactly what it sounds like!

Chalk one up for DEC and BASIC. What other programming languages support that feature, huh?

Now all you need is a COMEFROM and COMESUB and RUNREVERSE (or NUR) statements, and you can write reversible BASIC programs!

https://en.wikipedia.org/wiki/Reversible_computing

https://en.wikipedia.org/wiki/Counter-Clock_World

https://web.archive.org/web/20210713130832/https://imgur.com...

    DECSYSTEM 20 BASIC User's Guide: LISTREVERSE command

    LISTREVERSE
    LISTNHREVERSE

    LISTREVERSE and LISTNHREVERSE print the contents of the
    user's memory area in order of descending line numbers. 
    LISTREVERSE precedes the output with a heading,
    LISTNHREVERSE eliminates the heading.

    LISTREVERSE

    EQUIV             10:53                      13-NOV-75

    40    END
    35    PRINT "THE EQUIVALENT CURRENT IS",I, " AMPERES"
    25    I=E1/R
    10    INPUT R
    5     INPUT E1

    READY

http://bitsavers.org/www.computer.museum.uq.edu.au/pdf/DEC-1...

http://bitsavers.org/www.computer.museum.uq.edu.au/pdf/DEC-2...

Reply on news.ycombinator.com