Hacker News Reader

Comment by danieltillett | Hacker News Reader

I have the opposite feeling. I used to write programs for the trash-80 with hundreds of variable all named $A, $B, $C...$AA, $BB. To top this off the inability to renumber lines meant that once you added 9 new lines you needed to solve the problem with a goto to a sub-routine ultimately ending up with spaghetti code of the worst kind.

Of course not having a printer meant the only way you could understand the now totally tangled spaghetti code was to keep all of it in your youthful short-term memory. Having nobody you could ask or learn from just added to the toxic mix.

Even now thirty years later the thought of programming like this makes me feel ill.

View on HN

I don't know what TRS-80 you used, but I do know that the Microsoft BASIC in the Color Computer had a re-number command (RENUM newline, startline, increment). It was actually a very sophisticated version of BASIC:

http://www.colorcomputerarchive.com/coco/Documents/Manuals/H...

As a kid (and I still own them) I had a Color Computer 2 and 3 - I programmed a ton of things on them, which ultimately led me to where I am today as a software engineer.

> I used to write programs for the trash-80 with hundreds of variable all named $A, $B, $C...$AA, $BB

Ummm, don't feel bad, you actually needed to. Each character of those variable names takes up RAM.

> Each character of those variable names takes up RAM.

Not to mention that at least on the C64, only the first two characters are significant anyway, ie, 'abba', 'ab', and 'abcd' all refer to the same variable.

I was never a big fan of Microsoft Basic. My prefered systems were BBC Basic (BBC Micro) and Locomotive BASIC (Amstrad CPC). Locomotive was larged based on BBC BASIC and both had a command called RENUM that would renumber your source for you. It was invaluable for smaller projects but I remember some of my larger projects I would have routines separated by thousands. eg

    10 REM main routine
    20 REM do stuff
    1000 REM another routine
    1010 REM do other stuff
    2000 REM a 3rd routine

Then have GOSUBs / GOTOs using the n*1000 as the entry point into that routine. RENUMing the source when you've got the aforementioned structure was not an option.

ISTR that Locomotive's RENUM took optional arguments that let you renumber chunks of the program separately... yep! You could renumber starting from a given line number through the end of the program, so in principle you could do a whole-program RENUM and then restore the larger gaps to your GOSUBs: [1]

[1] (what a horrible link) http://www.cpcwiki.eu/index.php/Locomotive_BASIC#RENUM_.5B.E...

Yeah but that was fiddly and scary when the only way to undo any mistakes was to reload your program from cassette.

We solved the line numbering issue with 100-increments

I have a vague memory that there was a reason for not doing this - something about using more memory or hitting a ceiling of some sort. The major problem of course was not having anyone to tell you that this was a bad idea.

I still remember trying to work out how to program in machine code by poking different values into memory. I had my own guide on what values to avoid and what values worked without having the slightest idea what I was doing.

I do recall there being a maximum limit on line numbers. I don't recall ever using a BASIC that couldn't renumber.

Likely 65535. I can't imagine a computer in that era using more than 2 bytes for a line number.

Absolutely. BASIC on a Sharp 6000 pocket pc[1] for example was limited to (32k or) 64k lines of 256 characters each. Like in many other basic versions, there was no automatic renumbering. Discovered it the hard way.

[1] https://duckduckgo.com/?q=sharp+pocket+pc&t=ffab&iar=images&...

Program on notebook first i guess?

I had to do that when writing programs in z80 assembly language - then converted to HEX bytes for each instruction.

It was always a pain because instruction-length varied and you had to account for the length when calculating the number of bytes to jump forwards/backwards. (I tended to prefer relative-jumps to absolute ones, but either way the same problem remained.)

Reply on news.ycombinator.com