3 ms·

I learned Dartmouth BASIC on a timeshare in 1981. Variable names are single letter, or a letter and a digit. All variables are global. No function headers. Bran

I learned Dartmouth BASIC on a timeshare in 1981. Variable names are single letter, or a letter and a digit. All variables are global. No function headers. Branching by GOTO. It means that modularity and structure are virtually impossible. It practically forced you to write obfuscated code, and programs larger than a few dozen lines become exponentially harder to manage. Imagine the worst code you've ever seen. People who got good at coding in this way tended to develop mental habits that had to be un-learned when they moved to a more advanced language such as Pascal, as I did. With that said, beginners in any "scripting" language can evolve in the same way, if not taught some better habits. I've seen some Python programs that were as bad as my BASIC programs.

matthewdgreen 3y ago
Did you also use Dartmouth BASIC6 on a DCTS connection? That was my first language, and god it was miserable. But on the same machine we had BASIC8 which was essentially True Basic.
- analog31 3y ago
  Don't know. It was what we got when we entered BASIC. We didn't have the manual, but only our textbook. The timeshare was on some kind of minicomputer. I later got a summer internship at the facility that hosted this thing, and the rack of modems was as big as the computer.
  - matthewdgreen 3y ago
    I wrote a multi-thousand line conferencing program in BASIC6. It was an absolute nightmare (no subroutines, everything global, line numbers were hardcoded and couldn't be changed.) Weirdly, the experience was almost like learning an assembler as your first language -- you had to keep state for everything. Learning Pascal and C after that was actually a huge relief.
    - analog31 3y ago
      It's still amazing, considering that there was no networking at the time. Today, a conferencing program would be able to take advantage of phenomenal networking infrastructure, yet instead of multi-thousand, it would be multi-million lines, and still an absolute nightmare. Some sort of Parkinson's law applies: The code expands until it becomes unmanageable. When AI can write code for itself, it will be trillions of lines.
Brian_K_White 3y ago
I've been playing with vintage 8bit machines the last few years and it's true. Nontrivial basic apps have to be written essentially like assembly, or worse even, chock-a-block with single lines with 2 or 3 different exits, and every 3rd line is also a goto target while also still being the ordinary next line in some routine. And it's not because the programmmer was thoughtless or undisciplined. With only a few k and basic to work in, this is just required to get the job done. Outside of something quite as limited as a trs80 model 100, you can have at least some kind of modularity using chain, if you architect everything around that concept, and develop a framework or set of rules you follow the same way everywhere, like having a dispatcher main loop and all other modules all follow some consistent set of standards so that all modules can rely on all other modules working the same way, with a common interface, entrance, exit, params, etc. Instead of functions or gosubs, you are always chaining forward, loading a new file, and sometimes the next file happens to be the one you came from previously.
- analog31 3y ago
  >>> ... every 3rd line is also a goto target while also still being the ordinary next line in some routine. This is also what killed the Apple II. People figured out places that they could branch into the BIOS and OS code to do weird things or bypass the time consuming parts. The result was that every byte of the code was potentially a branch target, and Apple could never change it. Even upgrading to the Apple IIe was fraught, and I made a hack for my mom with a toggle switch for choosing between the Apple II and IIe ROMs. It's one of the reasons why Apple preferred a "closed" system for the Mac.
  - Brian_K_White 3y ago
    The model 100 is like that. Almost all software uses the main rom as a library of functions, and if you change almost anything in the main rom, you break almost all software. It's why a lot of software that works on the model 100, doesn't work on the practically identical Olivetti M10, Kyotronic KC-85, NEC PC-8201, and doesn't even work on the non-US versions of the model 100! All of those machines have practically identical hardware, and practically identical main roms, but, not identical. Mostly it's all the same routines just with some addresses moved around by a few bytes, and that's all it takes to break everything. To patch the main rom for y2k, you can search for a particular string of bytes to find the spot where "19" is hard coded, and edit it to "20". It's in a different spot in every different rom, but the routine it's part of is actually the same in all of them, and the same search & edit works on all of them. (ok the NEC does add something else since it also hardcodes "83" for "1983" somewhere else as part of some other routine that only the NEC has, but the part that has the "19" is the same as all the others.) The point is, that's how similar they all are. And yet software isn't portable between them. The exact same routines, not even changed, but just landing at slightly different addresses, breaks all the software.

matthewdgreen 3y ago

Did you also use Dartmouth BASIC6 on a DCTS connection? That was my first language, and god it was miserable. But on the same machine we had BASIC8 which was essentially True Basic.

analog31 3y ago
Don't know. It was what we got when we entered BASIC. We didn't have the manual, but only our textbook. The timeshare was on some kind of minicomputer. I later got a summer internship at the facility that hosted this thing, and the rack of modems was as big as the computer.
- matthewdgreen 3y ago
  I wrote a multi-thousand line conferencing program in BASIC6. It was an absolute nightmare (no subroutines, everything global, line numbers were hardcoded and couldn't be changed.) Weirdly, the experience was almost like learning an assembler as your first language -- you had to keep state for everything. Learning Pascal and C after that was actually a huge relief.
  - analog31 3y ago
    It's still amazing, considering that there was no networking at the time. Today, a conferencing program would be able to take advantage of phenomenal networking infrastructure, yet instead of multi-thousand, it would be multi-million lines, and still an absolute nightmare. Some sort of Parkinson's law applies: The code expands until it becomes unmanageable. When AI can write code for itself, it will be trillions of lines.

Brian_K_White 3y ago

I've been playing with vintage 8bit machines the last few years and it's true. Nontrivial basic apps have to be written essentially like assembly, or worse even, chock-a-block with single lines with 2 or 3 different exits, and every 3rd line is also a goto target while also still being the ordinary next line in some routine. And it's not because the programmmer was thoughtless or undisciplined. With only a few k and basic to work in, this is just required to get the job done. Outside of something quite as limited as a trs80 model 100, you can have at least some kind of modularity using chain, if you architect everything around that concept, and develop a framework or set of rules you follow the same way everywhere, like having a dispatcher main loop and all other modules all follow some consistent set of standards so that all modules can rely on all other modules working the same way, with a common interface, entrance, exit, params, etc. Instead of functions or gosubs, you are always chaining forward, loading a new file, and sometimes the next file happens to be the one you came from previously.

analog31 3y ago
>>> ... every 3rd line is also a goto target while also still being the ordinary next line in some routine. This is also what killed the Apple II. People figured out places that they could branch into the BIOS and OS code to do weird things or bypass the time consuming parts. The result was that every byte of the code was potentially a branch target, and Apple could never change it. Even upgrading to the Apple IIe was fraught, and I made a hack for my mom with a toggle switch for choosing between the Apple II and IIe ROMs. It's one of the reasons why Apple preferred a "closed" system for the Mac.
- Brian_K_White 3y ago
  The model 100 is like that. Almost all software uses the main rom as a library of functions, and if you change almost anything in the main rom, you break almost all software. It's why a lot of software that works on the model 100, doesn't work on the practically identical Olivetti M10, Kyotronic KC-85, NEC PC-8201, and doesn't even work on the non-US versions of the model 100! All of those machines have practically identical hardware, and practically identical main roms, but, not identical. Mostly it's all the same routines just with some addresses moved around by a few bytes, and that's all it takes to break everything. To patch the main rom for y2k, you can search for a particular string of bytes to find the spot where "19" is hard coded, and edit it to "20". It's in a different spot in every different rom, but the routine it's part of is actually the same in all of them, and the same search & edit works on all of them. (ok the NEC does add something else since it also hardcodes "83" for "1983" somewhere else as part of some other routine that only the NEC has, but the part that has the "19" is the same as all the others.) The point is, that's how similar they all are. And yet software isn't portable between them. The exact same routines, not even changed, but just landing at slightly different addresses, breaks all the software.