Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Learning BASIC Like It's 1983 (2018)

twobithistory.org

Post reply on HN
Print view View original

71–80 of 93 posts

Re: Learning BASIC Like It's 1983 (2018)

#71

Post by timbit42 »

hfo wrote: post #24

Mine was the Atari 800XL. Atari Basic hadn't PEEK and POKE as the C64 (though something similar which I can't remember right now), but some more possibilities to switch graphic modes and plot things. But I never learned how the machine worked from that, it was still magic. I tried typing in listings, but you only knew that there was a typo somewhere after you finished hundreds of lines. Finding the typo was out of th…

Atari BASIC does have POKE and PEEK but unlike C64 BASIC, it also has some graphic and sound commands to change the screen mode and draw stuff and play some notes. Atari BASIC also checks for syntax errors when you enter a line of code. C64 BASIC doesn't check until you run it.

Re: Learning BASIC Like It's 1983 (2018)

#72

Post by ghaff »

muyuu wrote: post #6
jmmv wrote: post #2

Agree with the author’s thesis of how the folks that “grew with computers” have an advantage over those approaching them now, in terms of understanding the inner workings. I’m not sure that this matters much in terms of solving actual problems though, which is probably a good thing. But I somehow find it a little bit sad that this is the case, so I’ll plug my own https://www.endbasic.dev/ because it’s very fitting in…

let's not overly romanticise it though the vast majority of people with access to computers in the 80s didn't harness the opportunity to be able to understand a lot of what was happening that was always going to be the case, and similarly people nowadays more often than not don't harness the vast opportunities that they have at their fingertips

I'd add that right around 1983 is sort of a special date. It was just around that time that it was becoming reasonable for a middle-class person to buy a home computer. Go back a few years from that time and you could potentially program in Basic or Fortran but you were doing so over a terminal or with punch cards and didn't really have any direct interaction with the computer except in relatively specialized situations.

Re: Learning BASIC Like It's 1983 (2018)

#73

Post by sandworm101 »

jagged-chisel wrote: post #61
jmmv wrote: post #2

Agree with the author’s thesis of how the folks that “grew with computers” have an advantage over those approaching them now, in terms of understanding the inner workings. I’m not sure that this matters much in terms of solving actual problems though, which is probably a good thing. But I somehow find it a little bit sad that this is the case, so I’ll plug my own https://www.endbasic.dev/ because it’s very fitting in…

> I’m not sure that this matters much in terms of solving actual problems though ... That is certainly correct. But The Industry hasn't successfully abstracted things such that pure problem solving is all there is to software creation. Current abstractions create a reliance on (probably inefficient, likely costly) infrastructure. One needs to understand how so much of a system works so that changes can be made to imp…

Why start at rotary phones? Why not start them out on Morse code? Semaphore? Naval flags moved data faster than horses for centuries. Should kids learn how to cut pens out of quills?

Re: Learning BASIC Like It's 1983 (2018)

#74

Post by neandrake »

sandworm101 wrote: post #73
jagged-chisel wrote: post #61

Earlier quoted context omitted.

> I’m not sure that this matters much in terms of solving actual problems though ... That is certainly correct. But The Industry hasn't successfully abstracted things such that pure problem solving is all there is to software creation. Current abstractions create a reliance on (probably inefficient, likely costly) infrastructure. One needs to understand how so much of a system works so that changes can be made to imp…

Why start at rotary phones? Why not start them out on Morse code? Semaphore? Naval flags moved data faster than horses for centuries. Should kids learn how to cut pens out of quills?

It’s been a few years but the book Code by Charles Petzold covers a number of those topics which I found interesting to learn about (but not study).

https://www.codehiddenlanguage.com/

Re: Learning BASIC Like It's 1983 (2018)

#75

Post by bitwize »

No, the author didn't miss out by not having been born in the late 70s or 80s and not experiencing this form of development.

8-bit micro BASIC development was based on the idea that it's the programmer's job to produce a complete program, and to understand all that it does from the time you type RUN until the program ends or is interrupted (by pressing Ctrl-C or RUN STOP, resetting the computer, etc.).

Today, most software developers develop program fragments that are plugged into a framework. The framework takes care of most of the details and only calls into your code for specialized logic. If you grew up programming BASIC (or Forth or Logo or Turbo Pascal), it can be confusing and frustrating to work this way because your intuitive sense of the program flow is completely disrupted.[0] I've found that younger programmers have fewer issues writing framework code. When their brains were still pliable, they learned that this is what programming is, so they adjusted to it. Even game programming, long the purview of hardcore bit diddlers, is high-level and framework-oriented thanks to engines like Unreal and Unity. Older programmers like me, sometimes their instincts and intuitions got in the way. The ones who thrived are the ones who adapted, who stopped worrying and learned to love the framework.

The entire discipline of programming is going to be disrupted again -- by AI. So today's programmers are going to be confused and frustrated when their jobs switch from writing code to prompt-engineering a model into writing code. But Gen Z will be right at home with it.

[0] I've found that working in Spring is for me an aggravating process because it involves guessing how to make ill-specified framework magic do what I want instead of, you know, writing a program that does what I want.

Re: Learning BASIC Like It's 1983 (2018)

#76

Post by teddyh »

The article delves only very shallowly into programming, so it stays away from this problem, but Commodore 64 BASIC is fundamentally unsuitable for programming anything larger than a few lines of code.

The most widely used version of Basic which Commodore (and other) platforms used 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. (No parameters or return values, only global variables.)

(This is in some ways even worse than assembler, which usually has labeled goto’s.)

When I programmed in Basic those many years ago, I was stalled when my programs reached a certain level of complexity. I was then mostly halted in my education and development as a programmer for many years, because the language did not make program composition easy. It was not until I had the opportunity to learn other languages with did have proper functions and other methods of program composition that I could break through the barrier, so to speak.

(Reportedly, BBC Basic on the BBC Micro did have proper named functions, and later versions of Basic like on the Atari ST and Amiga also had them. I believe that those versions of Basic would have been vastly more productive and taught people the usefulness of abstracting things as you go, building ever higher abstractions, etc. But this is never the version of Basic which people talk about, or used by all those listings in magazines, etc. These are, for all intents and purposes, not the “80s style Basic” which everybody remembers with such apparent and baffling fondness.)

(Mostly a repost of a previous post of mine: https://news.ycombinator.com/item?id=34033513)

Re: Learning BASIC Like It's 1983 (2018)

#77

Post by aksss »

rtpg wrote: post #41

Anyone up for this exercise, I might recommend QBASIC from Microsoft instead. Built in help manual and a "real-ish" IDE. And it was on the Windows 98 CD! I value "infinite online resources" but having integrated books of documentation in the IDE includes such valuable writing. I miss it so much when going through the hastily-written "getting started" tutorials I end up with nowadays (the scope of problems trying to b…

Yes, but how I coveted QuickBASIC as a kid - it could compile to an executable!

Re: Learning BASIC Like It's 1983 (2018)

#78

Post by stormdennis »

sandworm101 wrote: post #73
jagged-chisel wrote: post #61

Earlier quoted context omitted.

> I’m not sure that this matters much in terms of solving actual problems though ... That is certainly correct. But The Industry hasn't successfully abstracted things such that pure problem solving is all there is to software creation. Current abstractions create a reliance on (probably inefficient, likely costly) infrastructure. One needs to understand how so much of a system works so that changes can be made to imp…

Why start at rotary phones? Why not start them out on Morse code? Semaphore? Naval flags moved data faster than horses for centuries. Should kids learn how to cut pens out of quills?

We made and used quills in primary school, in a sort of arts and crafts/history crossover, I suppose. Didn't hold us back any, hopefully.

Re: Learning BASIC Like It's 1983 (2018)

#79

Post by jagged-chisel »

sandworm101 wrote: post #73
jagged-chisel wrote: post #61

Earlier quoted context omitted.

> I’m not sure that this matters much in terms of solving actual problems though ... That is certainly correct. But The Industry hasn't successfully abstracted things such that pure problem solving is all there is to software creation. Current abstractions create a reliance on (probably inefficient, likely costly) infrastructure. One needs to understand how so much of a system works so that changes can be made to imp…

Why start at rotary phones? Why not start them out on Morse code? Semaphore? Naval flags moved data faster than horses for centuries. Should kids learn how to cut pens out of quills?

We should absolutely include the telegraph, wired and wireless. Which leads into radio…

I just picked an arbitrary starting point to illustrate the hands-on approach I would like to see.

Re: Learning BASIC Like It's 1983 (2018)

#80

Post by themadturk »

ghaff wrote: post #72
muyuu wrote: post #6

Earlier quoted context omitted.

let's not overly romanticise it though the vast majority of people with access to computers in the 80s didn't harness the opportunity to be able to understand a lot of what was happening that was always going to be the case, and similarly people nowadays more often than not don't harness the vast opportunities that they have at their fingertips

I'd add that right around 1983 is sort of a special date. It was just around that time that it was becoming reasonable for a middle-class person to buy a home computer. Go back a few years from that time and you could potentially program in Basic or Fortran but you were doing so over a terminal or with punch cards and didn't really have any direct interaction with the computer except in relatively specialized situati…

1983 was when I got my first computer, a Timex/Sinclair 1000, followed up about a year later by a Commodore 64. Unlike many who had their first computing experiences then, I was already an adult, married and almost 30 years old. My experience and enthusiasm for small computers led directly to the IT career I started in 1989.
Post reply on HN