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

61–70 of 93 posts

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

#61

Post by jagged-chisel »

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 improve performance and/or reduce costs.

I took a look at EndBASIC and I find it rather awesome. But I also think it's limited to folks who have experience a perspective similar to my own. When looking this from my 7yo's POV, she would have no idea where to start. I could guide her, but it would be nothing like how I learned, alone, on an Apple //c. I'm certainly biased in thinking "how I learned was a pretty good process," and I wouldn't want to assume anyone else learns like that, but exposure to a simple (but complete) system and the ability to program it seems like a phenomenal way to learn.

----

I was thinking recently that it would be beneficial to teach the last century of technological advancement at a slow-ish pace. Kids spend a few months getting to know/understand how early telephone systems routed calls by using the same equipment from the day. Advance up through rotary dial, touch tone dialing, cordless phones, mobile phones ... over the course of a couple years. Parallel to that, the same kind of thing with computers and programming - switches, punch cards, tape, disk; mainframe, mini-, micro-computers; ...

It'd be pretty expensive though... :(

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

#62

Post by pipo234 »

muyuu wrote: post #51
DeathArrow wrote: post #49

If you want to learn how computers work now is easy. Learn C and a bit of assembly, read about hardware and try to do low level stuff. Play with memory, play with system calls. Learn a bit about GPUs, some OpenGL, DirectX, shading language or Vulkan and tinker with the GPU.

idk about that I mean, all of that is grand but you remain for, for from the metal in all these instances and even in assembly you cannot go under several layers of abstraction with modern architectures in the days of 6502 and Z80 compatible microprocessors, you could go down to the NAND gate level, to the transistor level - it was doable, not that it made much sense to go there for most people, but it was nearly a r…

In essence, the hardware hasn't changed a lot. There was less focus on efficiency, much more on price - computers were expensive. In the (early) 80s, memory came at a premium, most micros had no permanent storage (except audio cassettes), so CPU, peripherals and OS abstraction weren't though of as the bottleneck.

Given only kilobytes of memory, the problem basically came down to: how much of your computer can you make get to do something useful or fun within those RAM limits. I think that perspective allowed room for (and necessity to) learn about and understand all levels of everything inside the piece of hardware you bought. Abstraction was still relevant, but detailed documentation on the actual guts was much more necessary then than it is today.

To exaggerate: why would you need to understand how to bitshift/add/compare to perform multiplication or division if you never need to think beyond python 3/typescript/java syntax?!

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

#63

Post by heywhatupboys »

> (Your sister protested this decision, but it was 1983 and computers weren’t for her.)

oh dearest, save us from false revisionist shit political takes on gender/race/politics in every modern journalistic piece. There was no stigma or bias for women going into CS/programming in 1983.

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

#64

Post by dole »

defrost wrote: post #46
DeathArrow wrote: post #45

>. In the 8-bit computer era, many games were available only as printed BASIC listings in computer magazines and books. Actually the best games and software were programmed in assembler and you had to load them from cassette tapes. You couldn't do much in Basic.

You could LOAD a massive array of numbers and POKE them into memory ... Such things were printed in magazines as BASIC listings and they were, in fact, "programmed in assembler" and typed in by hand.

Nothing like typing in a 2 page program full of DATA statements and number values only to find out you made a mistake SOMEWHERE and they didn’t have any checksum routines.

I don’t know how many times I typed in that damn MAD magazine program and never got it to work. It took 30+ years to find out it had a error, would never run anyway and seeing someone else fix the bug and watching the program execute after all those years was finally closure.

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

#65

Post by nickt »

heywhatupboys wrote: post #63

> (Your sister protested this decision, but it was 1983 and computers weren’t for her.) oh dearest, save us from false revisionist shit political takes on gender/race/politics in every modern journalistic piece. There was no stigma or bias for women going into CS/programming in 1983.

To be fair to the author, they are using that sentence to link to the (admittedly fairly lightweight, but somewhat interesting) NPR article.

https://www.npr.org/sections/money/2014/10/21/357629765/when...

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

#66

Post by PopAlongKid »

In the early 1980s, graduate MBA (business school) students at Univ. of California at Berkeley took a required intro computing course, which was mostly BASIC programming. The computer lab was a room full of Lear Siegler ADM3A terminals connected to DEC VAX running Unix. The login shell was the BASIC interpreter, and Unix was hidden.

That was another way to learn BASIC like it's 1983 that I haven't seen mentioned yet.

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

#67

Post by datavirtue »

DeathArrow wrote: post #44

> I think the people that first encountered computers when they were relatively simple and constrained have a huge advantage over the rest of us. Even if they were simple it was hard to program them because there was a very limited amount of information on how to do it. The few books available didn't cover a lot of things. Learning was mostly done lots of things until you succeeded. And that took a lot of time and pa…

Easier after you fight through hours of fruitless configuration and version differences.

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

#69

Post by jmull »

II2II wrote: post #40
jmull wrote: post #10

To be fair, those memory mapped locations of the C-64 were APIs… for accessing the graphics, sound, and i/o capabilities of the system. It was a pretty nice design. One abstraction made the entire system programmable in a flexible, intuitive way and played well with the CPU’s native machine language. You just needed a good memory map. (A knack for memorizing useful memory locations didn’t hurt either)

It may have been possible to use them as an API, but it was different in the sense that you were interacting with the hardware directly. There were some nasty consequences to that (it was difficult to maintain compatibility between hardware models, nevermind hardware vendors). There were also some cool consequences to that (you could bend the hardware to do a lot of undocumented stuff). That said, even firmware calls…

A memory mapped API isn't inherently more (or less) subject to compatibility issues and versions than any other kind of API. With the C-64 it was hard-wired but that's not any more necessary than burning the OS on to ROM. (Which is to say: totally necessary at the time, for a machine of that capability and cost, but not at all necessary for systems that have the APIs we're comparing it to.

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

#70

Post by muyuu »

pipo234 wrote: post #62
muyuu wrote: post #51

Earlier quoted context omitted.

idk about that I mean, all of that is grand but you remain for, for from the metal in all these instances and even in assembly you cannot go under several layers of abstraction with modern architectures in the days of 6502 and Z80 compatible microprocessors, you could go down to the NAND gate level, to the transistor level - it was doable, not that it made much sense to go there for most people, but it was nearly a r…

In essence, the hardware hasn't changed a lot. There was less focus on efficiency, much more on price - computers were expensive. In the (early) 80s, memory came at a premium, most micros had no permanent storage (except audio cassettes), so CPU, peripherals and OS abstraction weren't though of as the bottleneck. Given only kilobytes of memory, the problem basically came down to: how much of your computer can you mak…

there have been many developments that have been strongly anti-user

partly because of the limitations of these days, there was a strong incentive to expose every detail of products to consumers that were not abstracted away from professionals or developers at any level

the abstractions of the day were solidly grounded by the nature of the underlying hardware, whereas nowadays we've used the freedom and leeway of more powerful hardware to make intermediate abstractions that are more transient and throw-away

for instance, everybody doing amateur level computing in the mid 80s had a strong understanding of he concept of interpretation vs compiling, understood binary coding, base conversion, some decent amount of information theory and boolean logic, addressing modes, fundamental data structures... those were all basic requirements and a lot of that is knowledge that won't fully go obsolete per se

whereas now, nothing of that being a requirement, people are often just given some explicit indications to do something and it just "automagically" happens, and this comes pretty much by definition with an increasingly "smart" interface and "dumb" user who is usually defeated if he or she tries to think outside the box (and thus doesn't)

Post reply on HN