10 PRINT "1"
30 PRINT "2"
20 GOTO 10
What would print out? Just a bunch of "1"s or "12"s? char** lines = malloc(...);
lines[10] = &line1;
lines[30] = &line2;
lines[20] = &line3;
Then when executing, it starts at `lines[0]', sees nops, gets to `lines[10]' and runs it, sees more nops, gets to `lines[20]' and jumps to `lines[10]'. All the while ignoring `lines[21]' and up.http://xania.org/200711/bbc-basic-v-format
That's Basic V, which was the variant used on the ARM-based Archimedes, but it's the same file format as the 6502 machine Basics.
Note that the line numbers used by GOTO and GOSUB were specially flagged --- this was so the RENUMBER command could find them. It also meant that computed gotos weren't renumbered...
(Of course, BBC Basic had proper named procedures and functions with local variables, but all self-respecting Basics had to support GOTO and GOSUB.)
The thing is that basic programs were not entered through a 2D text-editor per rather line per line. You would type "LIST" to re-read the whole program you typed so far, with the lines in the correct order. Then, you would enter a line starting with a number. It would overwrite any existing line with the same number.
Typically, a way to correct the program you wrote would be to type:
30
15 PRINT "2"
(replace the line 30 by an empty line, and insert a line number 15)
17 GOSUB 5500You can get around that with some flags, but its more of a pain than its worth.
We tend to go by hundreds for programs, and we have a renumber command, but using it is the nuclear option because it will break goto line number references from outside programs (yeah, that's a very common thing in this language)
The main application is decades old, and Providex provides a database of sorts, the language/runtime, a GUI toolkit, and the ability to run on windows, linux, and as a web app (you can use a "desktop" application written in providex in the browser, a great idea in principle, but with the cost of each user license of the language becomes cost prohibitive really fast).
So while everyone agrees that providex needs to go, that would mean replacing just about every single aspect of the company's core application GUI, language, database, even simple-ish things like the editor we use (which is built into the language) all need to be replaced. It's not an easy task.
We've started moving away, but it's going to take a lot of time, and a ton of effort. Right now we are still relying on the providex db stuff pretty much across the board (although i'm launching a new node.js+postgresql server in the next month or so), and we are slowly moving our hosted applications to more traditional web languages (we have some PHP, a bunch of javascript, and a little python).
But the language hurts. It is a combination of compiled and interpreted, so unless you jump through hoops files are saved in a binary format, and you can only use their editor. This also locks us into SVN as our source control, as it's the only VCS that providex supports (and even then, it's pretty bad support). There is virtually 0 tooling, nothing is open sourced, and it's really expensive. It's impossible to remove old code as there is 0 safety, any line can be GOTO'd or GOSUB'd by any other program at any time, and while new programs don't do that, the old programs that do are the ones that you want to refactor but can't. There are also programs where we are out of line numbers and need to resort to GOSUB "hacks" to add a line.
But it's not all bad. Being able to use a "drag and drop" visual editor to make a screen that will work on windows, linux, and the web is pretty nice, and having the DB so tightly coupled means stuff like upgrades/downgrades are pretty simple and don't involve multiple systems. It's also a pretty capable language all things considered (it has classes/objects, it's not as slow as i thought it would be, and it runs on anything without any modification).
SCREEN 9
LINE (100,100)-(200,200)
I only know processing that has this kind of ease of use. But any curious kid, given a BASIC interpreter and the LINE instruction will start drawing stuff around, naturally come to loops, and so on, without having to worry about the details of "real" programming languages.
FOR i$ FROM 1 TO 10 STEP 2
PRINT i$
NEXT
and get back 2, 4, 6, 8, 10, each on its own line.I don't remember a command to set the increment for line numbers, but that may be because I never used a BASIC which didn't either require a number on every line or not care about line numbers except as targets for GOTO and similar.
LIST
command, the interpreter would return 10 PRINT "1"
20 GOTO 10
30 PRINT "2"
You don't have to type LIST to reorder the lines, that just shows the re-ordering to you. If you didn't type LIST, but did type RUN (with the "unordered" listing) the interpreter would run each line in sequence of line number.If you ran out of line numbers you could sometimes RENUMber the listing.
Here's Stackoverflow:
This question is marked as a duplicate: http://stackoverflow.com/questions/2435488/why-basic-had-num...
Here's the closed question it's marked as a duplicate of: http://stackoverflow.com/questions/541421/why-did-we-bother-...
10 PRINT "1" 20 GOTO 10 30 PRINT "2"
The reason this is allowed is because it let you rewrite existing programs; if you later entered
10 PRINT "Hello World"
It would replace the original line 10 and use this one instead.
I escaped the "permanent brain damage" that Dijkstra complained about that era of BASIC producing, but I understand where he's coming from now and don't begrudge him the slight hyperbole. It was a language where there were so many accidental complexities that there was virtually no prayer of someone penetrating through to the essential issues, using Fred Brook's definitions of accidental/essential. You're not learning anything useful while you're manually renumbering lines because you used up everything between 15-20 and fixing up the GOTOs. (I never had anything with RENUM support.)