Hacker News Reader

Comment by mixmastamyk | Hacker News Reader

Excellent work and a fun read. I've got fond memories of loading programs from cassette tape on a Vic-20 in the early 80s (it took 10 minutes or so kids). I tried typing in a game from a magazine and was unsuccessful too--it never worked right, pre crc. Me and a few cousins had a ball though with a random sentence generator program. We filled all the data statements with all the bad words a group of 12 year olds could think up. Good times.

It was my first exposure to programming, and a bit too early perhaps. Other than an occasional session on an ancient TRS-80 in high school, I didn't do any real programming again until taking a Turbo Pascal course in the mid 90s in college.

View on HN

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.

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&...

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.

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.)

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 wrote a blog post recently about my early memories doing similar things on a ZX Spectrum. One thing I remember fondly is the books I checked out of the local library, which were full of listings.

Scrolling down to the bottom of this page you can find them online these days:

https://usborne.com/browse-books/features/computer-and-codin...

Just seeing the covers is enough to take me back ..

I wonder what I will be saying to people in twenty years time that will include the phrase: 'it took 10 minutes or so kids'?

"We used to have to write our own programs, like actually use buttons to type characters. It took a year or so kids."

The keyboard is an efficient way of getting a program from one's head to the computer, so I don't see that changing.

The inefficiency lies is in translating the business requirements of an application to something the computer understands via your brain and code syntax. There are plenty of ways that process can be optimised.

They've been optimizing that process since the 1950's. My hunch is that until they've built something sufficiently autonomous to accept blame when something is broken, humans will still be coding.

Until you also get a computer to write the business requirements, they will remain so nebulous that ONLY a human can translate them.

> The keyboard is an efficient way of getting a program from one's head to the computer, so I don't see that changing.

This seems an awful lot like saying, in (let's say) the 18th century, "the horse is an efficient way of getting from one place to another, so I don't see that changing." The keyboard seems efficient now, but it, or, to be certain, some current and apparently perfectly satisfactory technology, certainly won't do so after the next big innovation.

I guess I'm not holding my breath for this "next big innovation".

People will be programming computers for a very long time to come and they will, for the most part, be using a keyboard to do it.

"Predicting is hard, especially the future" (http://quoteinvestigator.com/2013/10/20/no-predict).

I'm definitely not suggesting holding your breath; it would be foolish to say "keyboard-less programming is just around the corner, so don't bother with your keyboard!" On the other hand, a confident prediction like:

> People will be programming computers for a very long time to come and they will, for the most part, be using a keyboard to do it.

(the keyboard part, at least) seems to be a sure route to some future "640K should be enough memory for anyone."

> "Predicting is hard, especially the future" (http://quoteinvestigator.com/2013/10/20/no-predict).

Indeed it is! We are all supposed to be living in a post PC world where everything we do, programming included, will be done on a tablet!

> (the keyboard part, at least) seems to be a sure route to some future "640K should be enough memory for anyone."

Heh. Ok. But is this the same thing really? I mean, how many forms of input are there? We've tried the obvious ones and the keyboard just sticks with us.

> Heh. Ok. But is this the same thing really? I mean, how many forms of input are there? We've tried the obvious ones and the keyboard just sticks with us.

I guess it's not the same thing in that it's at least obvious what one could do instead of a 640 KB limit (just install more memory), but I still think there might be some life to the analogy. I agree with you that there's no obvious substitute for the keyboard, but that to me says only that it is a local maximum—with a potential further global maximum to be discovered, probably not by obvious changes, and necessarily not by perturbations to what we have already—which might (or, I'll certainly grant, might not) be bettered.

Well, in the Mythical Man-month, Brooks describes the difference between accidental (later clarified as incidental) and essential complexity.

In other words, computers getting easier to use doesn't affect the complexity of the aforementioned "business requirements" or the kinds of research problems we attempt to tackle, which are only getting harder.

But yeah, ten minutes to load one program from tape... that was a productivity killer.

Reply on news.ycombinator.com