Hacker News Reader

Comment by teddyh | Hacker News Reader

80s style Basic does not have functions. This makes Basic programs tend to spaghetti and unreadable code, especially considering the constant memory constraints of those platforms. I grew up on these systems, and every time I think back on it I wish something like Forth would have taken its place - i.e. something with a clean and scalable pattern for abstraction. Basic, on the other hand, doesn't do abstractions. It barely has data types and what it calls “functions” are an even more limited form of Python's style of lambdas; every subset of code which can actually do something looks like “GOSUB 11600” when you call it. No naming, no abstractions, nothing.

View on HN

It doesn't have functions they are normally thought of - but most BASIC languages of the era (generally Microsoft derived) did have simple "DEF FN" style:

http://www.antonis.de/qbebooks/gwbasman/deffn.html

Otherwise, you had to fake it, which you kinda note: Since all variables were global in nature, this made it challenging - but possible. You could set aside a few named variables for your "functions", then just use GOSUB:

  10 X0=1:X1=3:GOSUB 1000:PRINT Y0
  .
  .
  .
  999 END
  1000 REM THE FUNCTION HERE
  1010 Y0=X0+X1
  1020 RETURN

That isn't "spaghetti code"; done properly, it's a form of structured BASIC. No, it isn't as readable, but you honestly get used to it. "GOSUB 2050" just means "do this task" and you know what to pass it (and if you don't, then you need to consult your docs or REM statements).

It's only when you start mixing in GOTOs jumping out of routines, all over the place, no structure, etc - that's where you get the infamous spaghetti code...

> It doesn't have functions they are normally thought of - but most BASIC languages of the era (generally Microsoft derived) did have simple "DEF FN" style:

Um, yes? That’s exactly what I meant by “an even more limited form of Python's style of lambdas”. Which is what they are. I never used them myself; I never, ever, found a use for them.

The rest of your argument seems to be “If you’re careful, it’s techically possible to write structured code.”, but the same can be said of most any language. Even assembly language for $FOO’s sake, usually has labels!

Modern BASIC like FreeBASIC has functions. When I tried different languages, FreeBASIC was easiest to set up getting from a download to compiling some source with a terminal command. Compiles fast, too, like older BASIC's or Go.

https://freebasic.net/

EDIT: Fixing comment to reflect you said 80's-style. My speedreading made me miss it first time.

> 80s style Basic does not have functions.

> No naming, no abstractions, nothing.

This is not entirely true. BBC BASIC (certainly the versions I used on the Electron and Master 128) had both named sub-procedures and named functions, with local variables and allowing recursion. While limited in some ways they did allow programming without sight nor sound of GOTO/GOSUB, which I actually used to do.

You could even do away with line numbers with a little hackery: write your code in a text editor (View, as built-in to the Master series and which we had as an add-on to the Electron we had at home before that, was what I used), I forget how due to the mists of time but I had a method of having the file repeated as if typed from the keyboard (adding in the line numbers via AUTO) and executing it directly. I felt rather clever, particularly as I did it mainly because a CS teacher had said it was not possible!

> BBC BASIC […] had both named sub-procedures and named functions […]

OK, sounds great. I also remember the versions of Basic on the Amiga and Atari ST being perfectly adequate in this regard.

But this is never the version of Basic which people talk about! What you describe is not the version of Basic used by all those listings in magazines, or in the linked article. This is, for all intents and purposes, not the “80s style Basic” which everybody remembers with such apparent and baffling fondness.

This is true of the 8-bit Basics.

However, later 80's 16-bit Basic (think Amiga, ST, QuickBasic for the PC, etc.) at least had functions, libraries, etc.

Going back to 8-bit is probably too far...

BBC BASIC (1981 - you want the 1982 version though) had procedures, multi-line functions, and variable names of any length. It's still a bit rubbish by modern standards, but workable for the sort of size of program that you might actually write. You're vanishingly unlikely to make something longer than 1,000 lines, if even that...

> and variable names of any length

Almost, but not quite. It would ignore anything after the 40th character of a name, and the overall line length restriction (255 characters, less line number) imposed a secondary limit.

Still night-and-day compared to some common contemporary BASIC variants what only allowed two-character variable names, of course, and not much of a limitation as really long names would soon have you hitting the overall memory restriction of the default address space (between 10 and 29Kbyte available, depending on screen mode, which had to be enough for the heap (including your code) and the call stack).

I perhaps remember this far too well, given how long it is since I touched one of those machines...

Yes, sorry, the line length is indeed limited to 255 chars (or is it 252/253?)! - I guess I just meant that there are no specific additional limits on variable name lengths.

I couldn't find any evidence of a 40 char limit on BASIC II... the full length of the variable name appears to be stored and compared.

253 IIRC: 256 less two bytes for a 16-bit line number and one for either an EOL marker or a length indicator (I forget which it used and I'm feeling too lazy to look it up ATM).

Though there was also a limit (also ~256) to the line on entry, which you would normally hit first because keywords are stored tokenised: "PRINT" would be stored as one byte not five.

Some of that stuff got burned in, if you ask me.

And many of them compiled to actual native code.

> Going back to 8-bit is probably too far...

I agree, but this is exactly what the linked article does. It even promotes the idea that the GOTO is better than functions or OOP, because it’s “simpler”. Needless to say, I disagree.

Naming things is almost a prerequisite to be able to think and reason about things without keeping the entire program in your head at once. And without any means of abstraction with names for code, old-style 80s Basic fails this requirement.

More precisely they didn't have a stack, and honestly most 8 bit comptuers didn't have the memory or hardware support for a stack.

I think exposing people to at least a little bit of basic or assembly is probably a good thing so people can understand why functions are useful.

I disagree; growing up deprived of things damages you deeply, as you can’t as easily get used to them later in life. I am reminded of the quote from The Unix-Haters Handbook:

“I liken starting one’s computing career with Unix, say as an undergraduate, to being born in East Africa. It is intolerably hot, your body is covered with lice and flies, you are malnourished and you suffer from numerous curable diseases. But, as far as young East Africans can tell, this is simply the natural condition and they live within it. By the time they find out differently, it is too late. They already think that the writing of shell scripts is a natural act.”

— Ken Pier, Xerox PARC

Reply on news.ycombinator.com