Lost Lessons from 8-Bit BASIC • Hacker News Board

Re: Lost Lessons from 8-Bit BASIC

#41

Post by [deleted] » Tue, Sep 02, 2014, 2:12 PM UTC

JoeAltmaier wrote: post #39

laumars wrote: post #35

Earlier quoted context omitted.

> BASIC and its command shell were in an 8KB ROM. They were one monolithic program. You've got modern ideas, and trying to apply them to a 20-year-old environment. Its not 'like' a lot of things; it came before them so the most you could say is, those things are like BASIC. Except what you've described is exactly what I described with Bash ;) > What BASIC was, was an extremely accessible try-it-now environment that n…

I only disliked the wrong arguments :) Like "The IDE facets that the author fondly remembers isn't part of the BASIC programming language, it's part of the command shell" There was no such distinction. That's recasting of the facts into something understandandable today. Know why the language keywords were so short? Because in an 8K ROM the symbol table was a significant hit on resources. Add a keyword? Means remove…

[deleted]

Re: Lost Lessons from 8-Bit BASIC

#42

Post by JoeAltmaier » Tue, Sep 02, 2014, 2:21 PM UTC

[deleted] wrote: post #41

JoeAltmaier wrote: post #39

Earlier quoted context omitted.

I only disliked the wrong arguments :) Like "The IDE facets that the author fondly remembers isn't part of the BASIC programming language, it's part of the command shell" There was no such distinction. That's recasting of the facts into something understandandable today. Know why the language keywords were so short? Because in an 8K ROM the symbol table was a significant hit on resources. Add a keyword? Means remove…

[deleted]

Good point! Minicomputers were around before micros. So BASIC wasn't born in a vacuum. Lots of precedent.

What's relevant is, modern ideas of encapsulation, object-oriented design or even structured design were not available to the inventors of early language ROMs. Nor did they have the room for such luxuries. They wrote one blob of code, probably in one large .asm file, that got the job done.

Re: Lost Lessons from 8-Bit BASIC

#43

Post by laumars » Tue, Sep 02, 2014, 2:24 PM UTC

JoeAltmaier wrote: post #39

laumars wrote: post #35

Earlier quoted context omitted.

> BASIC and its command shell were in an 8KB ROM. They were one monolithic program. You've got modern ideas, and trying to apply them to a 20-year-old environment. Its not 'like' a lot of things; it came before them so the most you could say is, those things are like BASIC. Except what you've described is exactly what I described with Bash ;) > What BASIC was, was an extremely accessible try-it-now environment that n…

I only disliked the wrong arguments :) Like "The IDE facets that the author fondly remembers isn't part of the BASIC programming language, it's part of the command shell" There was no such distinction. That's recasting of the facts into something understandandable today. Know why the language keywords were so short? Because in an 8K ROM the symbol table was a significant hit on resources. Add a keyword? Means remove…

> There was no such distinction. That's recasting of the facts into something understandandable today.

But that's the whole bloody point of the article. If you have an issue with that then take it up with the author rather than me.

Please also remember that the Bourne Shell is as old as BASIC micro computers. So my comparisons are of two environments of the same age rather than older systems vs modern systems (like you keep accusing me of).

And around the same time some micro computers (even the lower end ones) would support other interpreters (eg the BBC Micro supported BBC Basic, LISP, LOGO, Fortran, and a few others) and you could switch between languages like you switch shells in Linux. Which is also why I like to make the distinction between the language and the shell.

> Know why the language keywords were so short? Because in an 8K ROM the symbol table was a significant hit on resources. Add a keyword? Means remove some other feature. It was a whole different world, with different constraints. And still it was usable, accessible, friendly even.

I know - I was there. And while it's interesting, it's also irrelevant to any of mine or the authors points.

Re: Lost Lessons from 8-Bit BASIC

#44

Post by laumars » Tue, Sep 02, 2014, 2:31 PM UTC

JoeAltmaier wrote: post #42

[deleted] wrote: post #41

Earlier quoted context omitted.

[deleted]

Good point! Minicomputers were around before micros. So BASIC wasn't born in a vacuum. Lots of precedent. What's relevant is, modern ideas of encapsulation, object-oriented design or even structured design were not available to the inventors of early language ROMs. Nor did they have the room for such luxuries. They wrote one blob of code, probably in one large .asm file, that got the job done.

They were available as Fortran, LISP, C and Pascal were all around back then. But you're right about the necessity code the ROMs in Assembly .

Re: Lost Lessons from 8-Bit BASIC

#45

Post by mseebach » Tue, Sep 02, 2014, 2:35 PM UTC

antimagic wrote: post #28

mseebach wrote: post #20

Earlier quoted context omitted.

That's a false equivalence (at least I think that's the right term). Back then, computers were by a huge barrier to entry the exclusive domain to the kind of people who would grow up to read hacker news. Blindly typing in games from magazines without trying to understand them is the 1980's equivalent of "watching shit scroll by for hours makes me a Linux expert overnight". If that gives you an illusion of being able…

I know this isn't really your main point, but I think you're probably selling short the activity of typing in code from a magazine. Firstly, the act of typing in and of itself is an advantage in the task of learning to use computers. Secondly, no-one ever typed a program in perfectly, you would have to debug the program when you made a type. Sometimes the typo would create a syntax error and your interpreter would po…

It's not worthless, and neither is "watching shit scroll by for hours", but I think the better signal is in the motivation and tenacity of the kind of people who set out to do this in the first place. In the 80's, this kind of people made up a very large proportion of all computer users out of sheer necessity (heck, in the 70s, you generally had to assemble your own hardware as well). Today, it's a vanishingly small fraction - but in absolute numbers, it's much much bigger, and a much much easier group to enter.

Re: Lost Lessons from 8-Bit BASIC

#46

Post by jhallenworld » Tue, Sep 02, 2014, 2:42 PM UTC

You can easily have this on a Linux machine:

First install basic: apt-get install bwbasic

Next find where getty starts the login program, but change it to run basic instead. In Ubuntu: /etc/init/ttyS0.conf:

   start on stopped rc RUNLEVEL=[2345]
   stop on runlevel [!2345]
   respawn
   exec /sbin/getty -8 -n -l /usr/bin/bwbasic -L 115200 ttyS0 vt102

You will see this on the serial port:

   Bywater BASIC Interpreter/Shell, version 2.20 patch level 2
   Copyright (c) 1993, Ted A. Campbell
   Copyright (c) 1995-1997, Jon B. Volkoff
 

   ERROR: Failed to open file --
   bwBASIC: 
   bwBASIC: print "Hello, world!"
   Hello, world!
   bwBASIC: 10 for a = 1 to 10
   bwBASIC: 20 print "Hello ", a
   bwBASIC: 30 next a
   bwBASIC: run
   Hello         1
   Hello         2
   Hello         3
   Hello         4
   Hello         5
   Hello         6
   Hello         7
   Hello         8
   Hello         9
   Hello         10
   bwBASIC:

bwBASIC is a shell.. so you can type "ls".. or "exec emacs"..

Re: Lost Lessons from 8-Bit BASIC

#47

Post by JoeAltmaier » Tue, Sep 02, 2014, 2:48 PM UTC

jhallenworld wrote: post #46

You can easily have this on a Linux machine: First install basic: apt-get install bwbasic Next find where getty starts the login program, but change it to run basic instead. In Ubuntu: /etc/init/ttyS0.conf: start on stopped rc RUNLEVEL=[2345] stop on runlevel [!2345] respawn exec /sbin/getty -8 -n -l /usr/bin/bwbasic -L 115200 ttyS0 vt102 You will see this on the serial port: Bywater BASIC Interpreter/Shell, version…

That's pretty similar to what the OP covered. Except part of the attraction was NOT having to install or configure special tools. Remember having BASIC always-on was what made it so accessible.

I get it, after you do this you can just log in and voila Basic. Still until Linux comes with this as a special user login, there's a gap in the experience.

Re: Lost Lessons from 8-Bit BASIC

#48

Post by npsimons » Tue, Sep 02, 2014, 2:54 PM UTC

laumars wrote: post #31

I think the article misses the point a little bit. The IDE facets that the author fondly remembers isn't part of the BASIC programming language, it's part of the command shell. It's loosely akin to your terminal emulator running Bash. By default it works in real time but you can write more complicated routines programmatically and then run them at your convenience; and you can do so from the shell prompt (either via…

Plus a lot of his complaints seem to be about the modularisation of modern languages - which seem an odd complaint to make in my opinion. If anything, I'd personally argue that things like importable, self-contained, chunks of code is one of the single greatest advances.

Yeah, his respect for BASIC seems misplaced at best. Take this excerpt:

There's a small detail that I skipped over: entering a multi-line program on a computer in a department store. Without starting an external editor. Without creating a file to be later loaded into the BASIC interpreter

So what? Any language with a REPL (and nowadays, that's pretty much all of them) can do that. And sure, computers don't boot up into a REPL, but a) do you really want them to? and b) as the top comment here shows, you can easily set up a computer to boot straight to a REPL.

Re: Lost Lessons from 8-Bit BASIC

#49

Post by jhallenworld » Tue, Sep 02, 2014, 2:56 PM UTC

JoeAltmaier wrote: post #47

jhallenworld wrote: post #46

You can easily have this on a Linux machine: First install basic: apt-get install bwbasic Next find where getty starts the login program, but change it to run basic instead. In Ubuntu: /etc/init/ttyS0.conf: start on stopped rc RUNLEVEL=[2345] stop on runlevel [!2345] respawn exec /sbin/getty -8 -n -l /usr/bin/bwbasic -L 115200 ttyS0 vt102 You will see this on the serial port: Bywater BASIC Interpreter/Shell, version…

That's pretty similar to what the OP covered. Except part of the attraction was NOT having to install or configure special tools. Remember having BASIC always-on was what made it so accessible. I get it, after you do this you can just log in and voila Basic. Still until Linux comes with this as a special user login, there's a gap in the experience.

You don't even have to log in: it just comes up when you boot the system. I think if you install the server version of Ubuntu, no GUI automatically starts so you could run this on tty1 (first VGA console).

Anyway, I understand the OP's point. You are right that a new computer does not come up this way right out of the box. I could see setting up a bunch of Linux machines like this, to recreate something like the C64 school computer labs of the past.

Re: Lost Lessons from 8-Bit BASIC

#50

Post by jerf » Tue, Sep 02, 2014, 2:59 PM UTC

JoeAltmaier wrote: post #47

jhallenworld wrote: post #46

You can easily have this on a Linux machine: First install basic: apt-get install bwbasic Next find where getty starts the login program, but change it to run basic instead. In Ubuntu: /etc/init/ttyS0.conf: start on stopped rc RUNLEVEL=[2345] stop on runlevel [!2345] respawn exec /sbin/getty -8 -n -l /usr/bin/bwbasic -L 115200 ttyS0 vt102 You will see this on the serial port: Bywater BASIC Interpreter/Shell, version…

That's pretty similar to what the OP covered. Except part of the attraction was NOT having to install or configure special tools. Remember having BASIC always-on was what made it so accessible. I get it, after you do this you can just log in and voila Basic. Still until Linux comes with this as a special user login, there's a gap in the experience.

We have to cut ourselves a bit of slack here. Sure, 8-bit computers came up in a BASIC prompt... but they could default to a BASIC prompt because they had nothing else to do. Modern computers do. We do need to at least spot ourselves having to tell the computer to bring up this environment rather than something else... after all, if there are so much as two wonderful learning environments we need to be able to pick between them.

If you insist, you can build a kid-friendly distro of Linux, and then build custom computers to put it on which come up straight into this environment... but given that that's been tried before, I'm not terribly optimistic about that shutting down the continuous stream of complaints of this nature.

And I guess that I know this is a popular opinion amongst a certain segment of the programming population, but the scientist in me can't help but note the large number of times this has been "fixed", yet, literally years and decades after the fixes, the complaints are still flowing, virtually unchanged. Personally I think the most likely explanation is simply that this is an incorrect diagnosis of the problem. Tempting, easy, seductive, but incorrect.

Further evidence for the incorrectness: Despite the way that many programmers got their start in this environment, I'd point out that far, far more people were exposed to this environment and still did not become coders, or worse, decided that computers weren't for them. I don't see any particularly concrete evidence that leads me to believe this was that special of an environment, once I discard nostalgia. At the very least we'd need to show some sort of difference between two environments without the confounding factor of a dozen orders of magnitude difference in performance, to say nothing of the other advancements made since then.