4 ms·

This is exactly it one thousand times over. The C64 was a gateway drug and everybody that was 'into it' really was a kindred spirit. C64 BASIC has ingrained 1

This is exactly it one thousand times over. The C64 was a gateway drug and everybody that was 'into it' really was a kindred spirit. C64 BASIC has ingrained 1 evil in me. "goto" Atleast once a month I'll be working on some script and I'm stuck but a little voice in the back of my head will say: "a goto would fix this part you are stuck on!" And damn if that doesn't reverberate into the past. I went the hardware route. I bought additional hardware for my C64. First the 1541 (5.25" floppy drive), then the 1581 (3.5" floppy drive), then a 300/1200 baud modem, then a 2400baud modem. I've been hardware hooked ever since. I'm now a sysadmin working with *nix servers. I tried programming. I really did. I meticulously copied one of the sample programs out of the back of the C64 manual. It never worked.

nobleach 4y ago
Definitely a gateway drug. I had an Apple ][+ around that time too. The manuals for that were incredible. Luckily, my dad's startup had tons of old hardware for it. Printers, Koala Pad, plenty of disk drives, modem, EPROM programmer, 80 Column Card with C/PM and Pascal.... even though it was about 10 years old, it was great. But the C64 always seemed far more approachable. That brown box with the clacky keys... And I was too young to know about Djkstra's "Goto Considered Harmful". It probably could have made me a far better engineer if I had picked up better habits sooner.
PaulHoule 4y ago
Programming BASIC was a lot like programming assembly language in terms of how the GOTO and GOSUB keywords worked. GOTO led to a lot of criticism over "spaghetti code", but the limitations of GOSUB were worse. GOSUB would put the calling location on a stack so you could RETURN to it later but there was no stack for parameters, local variables or return values so you had to use global variables for all of those. You could not write recursive functions in BASIC unless you implemented a stack yourself using arrays. It was easy to compute Fibonacci iteratively, but people had to sort in BASIC all the time and wrote bubble sort, shell sort and other algorithms that were slow but easy to code in BASIC as opposed to Quicksort. If you have the kind of functions that exist in C, Pascal, LISP, ML, Python and many other languages then you can write a simple Quicksort in a few lines of clear code.
- II2II 4y ago
  > Programming BASIC was a lot like programming assembly language in terms of how the GOTO and GOSUB keywords worked. One of the things many people fail to understand when they criticize GOTO and GOSUB is that it is essentially an expression of what is happening at the hardware level. Modern languages didn't really do away with them. They simply added a layer of abstraction that made it easier to develop reliable software. Unfortunately that abstraction also has overhead, which as problematic when you had a few kilobytes of RAM to work on with early personal computers. I would imagine that it was also problematic on the early multi-user systems that BASIC originated on. It isn't that GOTO is evil. It simply became less necessary for developers to use it in high level languages as technology improved. Of course, the other thing that made spaghetti code inevitable was the line number based syntax. Until development tools improved, people were basically plopping new statements in random locations because they needed more "space" between existing statements. Yet line numbers were used in early systems since the BASIC REPL also served as a line editor. (At least on personal computers. I'm not sure how it worked on mainframes.)
  - actionfromafar 4y ago
    MSX Basic had "RENUM" or some such, which would renumber all the lines to for instance 100, 110, 120 etc. It also automatically updated all GOTO and GOSUB. So if you ran that all the time, it was almost like line numbers in a text file, but with an extra manual "RENUM" chore thrown in.
    - ok123456 4y ago
      This was standard in Microsoft BASICs.
  - PaulHoule 4y ago
    People got BASIC to run in very tiny machines such as the 4K TRS-80 Color Computer, the 1K Sinclar ZX80. If you added a bit more RAM than that you had more of a choice, for instance a 16K Color Computer could run https://www.cocopedia.com/wiki/index.php/EDTASM%2B https://www.cocopedia.com/wiki/index.php/EDTASM%2B editing programs with a text editor, saving them on cassette tapes, assembling them, etc. In the same amount of RAM you could have fit a FORTH implementation and with a disk system you could have an experience similar to BASIC based around editing individual disk blocks. With 64k of RAM I would run a C compiler on that color computer and people did the same with CP/M. So far as mainframes at first they didn't have text editors, instead you would put together a deck of punched cards and submit that to the FORTRAN compiler which would output the object code to another deck of punched cards. It wasn't unusual for people in the 1980s to use BASIC preprocessors that would read a text file, append line numbers, and let you use structured loops, and GOTOs with named labels. I read about https://www.pcjs.org/software/pcx86/lang/other/ratbas/1982/ https://www.pcjs.org/software/pcx86/lang/other/ratbas/1982/ and wrote one for my TRS-80 Coco. It was the sort of thing you could write in BASIC without a lot of understanding about how to write compilers.
ako 4y ago
Just sprinkle a few NOPS in your 6502 assembly regularly, so you can replace it later with JMP.
- tomcam 4y ago
  Wait wut?
  - flohofwoe 4y ago
    If you programmed in machine code (without a fancy assembler), you can't simply move your instructions around in memory to make room for bugfixes, so instead you place a couple of nops here and there (usually in strategic places like the start of a function or right after a conditional branch, so that you can later replace those nops with jumps or subroutine calls to add patches.
    - bombcar 4y ago
      http://www.neocomputer.org/projects/et/ http://www.neocomputer.org/projects/et/ has some really good examples of that kind of debugging (reusing existing space/instructions)
    - tomcam 4y ago
      OK, I get it now. You brought me back. I now do remember peppering my X86 asm code with those nops when writing early code generators, for example if a JMP instruction might go past 127 bytes.
anyfoo 4y ago
> C64 BASIC has ingrained 1 evil in me. "goto" Atleast once a month I'll be working on some script and I'm stuck but a little voice in the back of my head will say: "a goto would fix this part you are stuck on!" goto is perfectly fine if used right. Kernel C code tends to use a lot of goto, to consolidate return points and to clean up resources on the way. A long function with no goto to one common return point, or multiple staggered ones, is suspicious. The problem that led to the famous paper was rather that goto was abused, used at places where "higher level" control construct like "for", "while" and so on would be better. Partly because the languages just didn't have any, like for example... C64 BASIC.
- JKCalhoun 4y ago
  Yep, used a lot of goto's writing framework software that worked with CoreFoundation on Mac OS. We used it a lot in early Mac Toolbox framework code as well. Often within the scope of a function we would need to allocate/create dictionaries, arrays, other objects requiring disposal. MacOS's CoreFoundation API often returned NULL when creation (or insertion, etc.) failed. The sane thing to do when you got an unexpected NULL was to "bail" from the function. But rather than return immediately, there was clean up code at the bottom of the function — code like "if stackDict != NULL {CFRelease(stackDict);}". So we often added a label (called typically "bail") just before the clean up code and would "goto bail". These were the days before garbage collection....

nobleach 4y ago

Definitely a gateway drug. I had an Apple ][+ around that time too. The manuals for that were incredible. Luckily, my dad's startup had tons of old hardware for it. Printers, Koala Pad, plenty of disk drives, modem, EPROM programmer, 80 Column Card with C/PM and Pascal.... even though it was about 10 years old, it was great. But the C64 always seemed far more approachable. That brown box with the clacky keys... And I was too young to know about Djkstra's "Goto Considered Harmful". It probably could have made me a far better engineer if I had picked up better habits sooner.

PaulHoule 4y ago

Programming BASIC was a lot like programming assembly language in terms of how the GOTO and GOSUB keywords worked. GOTO led to a lot of criticism over "spaghetti code", but the limitations of GOSUB were worse. GOSUB would put the calling location on a stack so you could RETURN to it later but there was no stack for parameters, local variables or return values so you had to use global variables for all of those. You could not write recursive functions in BASIC unless you implemented a stack yourself using arrays. It was easy to compute Fibonacci iteratively, but people had to sort in BASIC all the time and wrote bubble sort, shell sort and other algorithms that were slow but easy to code in BASIC as opposed to Quicksort. If you have the kind of functions that exist in C, Pascal, LISP, ML, Python and many other languages then you can write a simple Quicksort in a few lines of clear code.

II2II 4y ago
> Programming BASIC was a lot like programming assembly language in terms of how the GOTO and GOSUB keywords worked. One of the things many people fail to understand when they criticize GOTO and GOSUB is that it is essentially an expression of what is happening at the hardware level. Modern languages didn't really do away with them. They simply added a layer of abstraction that made it easier to develop reliable software. Unfortunately that abstraction also has overhead, which as problematic when you had a few kilobytes of RAM to work on with early personal computers. I would imagine that it was also problematic on the early multi-user systems that BASIC originated on. It isn't that GOTO is evil. It simply became less necessary for developers to use it in high level languages as technology improved. Of course, the other thing that made spaghetti code inevitable was the line number based syntax. Until development tools improved, people were basically plopping new statements in random locations because they needed more "space" between existing statements. Yet line numbers were used in early systems since the BASIC REPL also served as a line editor. (At least on personal computers. I'm not sure how it worked on mainframes.)
- actionfromafar 4y ago
  MSX Basic had "RENUM" or some such, which would renumber all the lines to for instance 100, 110, 120 etc. It also automatically updated all GOTO and GOSUB. So if you ran that all the time, it was almost like line numbers in a text file, but with an extra manual "RENUM" chore thrown in.
  - ok123456 4y ago
    This was standard in Microsoft BASICs.
- PaulHoule 4y ago
  People got BASIC to run in very tiny machines such as the 4K TRS-80 Color Computer, the 1K Sinclar ZX80. If you added a bit more RAM than that you had more of a choice, for instance a 16K Color Computer could run https://www.cocopedia.com/wiki/index.php/EDTASM%2B https://www.cocopedia.com/wiki/index.php/EDTASM%2B editing programs with a text editor, saving them on cassette tapes, assembling them, etc. In the same amount of RAM you could have fit a FORTH implementation and with a disk system you could have an experience similar to BASIC based around editing individual disk blocks. With 64k of RAM I would run a C compiler on that color computer and people did the same with CP/M. So far as mainframes at first they didn't have text editors, instead you would put together a deck of punched cards and submit that to the FORTRAN compiler which would output the object code to another deck of punched cards. It wasn't unusual for people in the 1980s to use BASIC preprocessors that would read a text file, append line numbers, and let you use structured loops, and GOTOs with named labels. I read about https://www.pcjs.org/software/pcx86/lang/other/ratbas/1982/ https://www.pcjs.org/software/pcx86/lang/other/ratbas/1982/ and wrote one for my TRS-80 Coco. It was the sort of thing you could write in BASIC without a lot of understanding about how to write compilers.

ako 4y ago

Just sprinkle a few NOPS in your 6502 assembly regularly, so you can replace it later with JMP.

tomcam 4y ago
Wait wut?
- flohofwoe 4y ago
  If you programmed in machine code (without a fancy assembler), you can't simply move your instructions around in memory to make room for bugfixes, so instead you place a couple of nops here and there (usually in strategic places like the start of a function or right after a conditional branch, so that you can later replace those nops with jumps or subroutine calls to add patches.
  - bombcar 4y ago
    http://www.neocomputer.org/projects/et/ http://www.neocomputer.org/projects/et/ has some really good examples of that kind of debugging (reusing existing space/instructions)
  - tomcam 4y ago
    OK, I get it now. You brought me back. I now do remember peppering my X86 asm code with those nops when writing early code generators, for example if a JMP instruction might go past 127 bytes.

anyfoo 4y ago

> C64 BASIC has ingrained 1 evil in me. "goto" Atleast once a month I'll be working on some script and I'm stuck but a little voice in the back of my head will say: "a goto would fix this part you are stuck on!" goto is perfectly fine if used right. Kernel C code tends to use a lot of goto, to consolidate return points and to clean up resources on the way. A long function with no goto to one common return point, or multiple staggered ones, is suspicious. The problem that led to the famous paper was rather that goto was abused, used at places where "higher level" control construct like "for", "while" and so on would be better. Partly because the languages just didn't have any, like for example... C64 BASIC.

JKCalhoun 4y ago
Yep, used a lot of goto's writing framework software that worked with CoreFoundation on Mac OS. We used it a lot in early Mac Toolbox framework code as well. Often within the scope of a function we would need to allocate/create dictionaries, arrays, other objects requiring disposal. MacOS's CoreFoundation API often returned NULL when creation (or insertion, etc.) failed. The sane thing to do when you got an unexpected NULL was to "bail" from the function. But rather than return immediately, there was clean up code at the bottom of the function — code like "if stackDict != NULL {CFRelease(stackDict);}". So we often added a label (called typically "bail") just before the clean up code and would "goto bail". These were the days before garbage collection....