Love this one. Build a recursive stack using AppleSoft BASIC:
On Fri, 24 Apr 2026 21:35:47 -0700, Chris M. Thomasson wrote:
Love this one. Build a recursive stack using AppleSoft BASIC:
I’ve done that in Python, too.
Because the default recursion limit
wasn’t big enough for my (admittedly brute-force) algorithm for
resolving the types of the long chains of data blocks in a Blender
document.
<https://gitlab.com/ldo/blendhack>
On 4/24/2026 9:49 PM, Lawrence D’Oliveiro wrote:
On Fri, 24 Apr 2026 21:35:47 -0700, Chris M. Thomasson wrote:
Love this one. Build a recursive stack using AppleSoft BASIC:
I’ve done that in Python, too.
It was really fun to make in AppleSoft BASIC. I used to code for it
as a little kid.
Because the default recursion limit wasn’t big enough for my
(admittedly brute-force) algorithm for resolving the types of the
long chains of data blocks in a Blender document.
<https://gitlab.com/ldo/blendhack>
Perhaps try to make an iterative version? Or is that out of the
question?
BASIC offered a wonderful sense of immediacy: type a statement without
a line number, and it is executed right away. Or put a line number on
the front, and it gets kept in RAM as part of your program. Great for >incremental development, and “scratchpad” programming.
There is a modern system that offers this sort of immediacy: ...
Jupyter <https://jupyter.org/>.
On Fri, 1 May 2026 23:00:44 -0000 (UTC), Lawrence D´Oliveiro ><ldo@nz.invalid> wrote:
BASIC offered a wonderful sense of immediacy: type a statement without
a line number, and it is executed right away. Or put a line number on
the front, and it gets kept in RAM as part of your program. Great for >>incremental development, and “scratchpad” programming.
There is a modern system that offers this sort of immediacy: ...
Any language whose implementation includes a REPL.
Lisp, Scheme, Racket, Python, and Lua immediately come to mind.
Probably others I don't know about ...
there used to be interactive
interpreters for C and Pascal, but I haven't seen one for decades.
Such things tend to suffer from the fact that the programming
language has not been designed with a REPL in mind.
On Fri, 1 May 2026 23:00:44 -0000 (UTC), Lawrence D´Oliveiro
<ldo@nz.invalid> wrote:
BASIC offered a wonderful sense of immediacy: type a statement without
a line number, and it is executed right away. Or put a line number on
the front, and it gets kept in RAM as part of your program. Great for >>incremental development, and “scratchpad” programming.
There is a modern system that offers this sort of immediacy: ...
Any language whose implementation includes a REPL.
Lisp, Scheme, Racket, Python, and Lua immediately come to mind.
Probably others I don't know about ... there used to be interactive interpreters for C and Pascal, but I haven't seen one for decades.
Apologies if I missed your favorite REPL language.
ERROR "unexpected byte sequence starting at index 97: '\xC2'" while decoding:
George Neuner <gneuner2@comcast.net> writes:
On Fri, 1 May 2026 23:00:44 -0000 (UTC), Lawrence D´Oliveiro ><ldo@nz.invalid> wrote:
BASIC offered a wonderful sense of immediacy: type a statement without
a line number, and it is executed right away. Or put a line number on
the front, and it gets kept in RAM as part of your program. Great for >>incremental development, and âscratchpadâ programming.
There is a modern system that offers this sort of immediacy: ...
Any language whose implementation includes a REPL.
Lisp, Scheme, Racket, Python, and Lua immediately come to mind.
Probably others I don't know about ...
Forth, if you want a low-level programming language.
--- Synchronet 3.22a-Linux NewsLink 1.2there used to be interactive
interpreters for C and Pascal, but I haven't seen one for decades.
Also for Java. Such things tend to suffer from the fact that the
programming language has not been designed with a REPL in mind. So
the REPL designer has to change the programming language, and the
mainstream users of this programming language then tend to ignore it.
- anton
George Neuner <gneuner2@comcast.net> schrieb:
On Fri, 1 May 2026 23:00:44 -0000 (UTC), Lawrence D´Oliveiro
<ldo@nz.invalid> wrote:
BASIC offered a wonderful sense of immediacy: type a statement
without a line number, and it is executed right away. Or put a
line number on the front, and it gets kept in RAM as part of your
program. Great for incremental development, and “scratchpad”
programming.
There is a modern system that offers this sort of immediacy:
Jupyter <https://jupyter.org/>.
Any language whose implementation includes a REPL.
Lisp, Scheme, Racket, Python, and Lua immediately come to mind.
Probably others I don't know about ... there used to be interactive
interpreters for C and Pascal, but I haven't seen one for decades.
Apologies if I missed your favorite REPL language.
Julia :-)
On Fri, 1 May 2026 15:16:31 -0700, Chris M. Thomasson wrote:
On 4/24/2026 9:49 PM, Lawrence D’Oliveiro wrote:
On Fri, 24 Apr 2026 21:35:47 -0700, Chris M. Thomasson wrote:
Love this one. Build a recursive stack using AppleSoft BASIC:
I’ve done that in Python, too.
It was really fun to make in AppleSoft BASIC. I used to code for it
as a little kid.
BASIC offered a wonderful sense of immediacy: type a statement without
a line number, and it is executed right away. Or put a line number on
the front, and it gets kept in RAM as part of your program. Great for incremental development, and “scratchpad” programming.
There is a modern system that offers this sort of immediacy: Jupyter <https://jupyter.org/>. Only it does it without line numbers, using a notebook paradigm instead, that works across multiple languages. A
notebook consists of a series of cells, each of which can hold any
number of lines of program code. Executing a cell doesn’t throw its contents away, so you get both immediate mode and incremental program development in one.
Because the default recursion limit wasn’t big enough for my
(admittedly brute-force) algorithm for resolving the types of the
long chains of data blocks in a Blender document.
<https://gitlab.com/ldo/blendhack>
Perhaps try to make an iterative version? Or is that out of the
question?
Do you mean iterating over an explicit stack of objects that describe
what to do next? That’s what I did.
On 5/1/2026 4:00 PM, Lawrence D’Oliveiro wrote:
Do you mean iterating over an explicit stack of objects that
describe what to do next? That’s what I did.
I mean trying to turn a recursive algo into a pure iterative algo.
On Fri, 1 May 2026 23:00:44 -0000 (UTC), Lawrence D´Oliveiro <ldo@nz.invalid> wrote:
BASIC offered a wonderful sense of immediacy: type a statement without
a line number, and it is executed right away. Or put a line number on
the front, and it gets kept in RAM as part of your program. Great for
incremental development, and “scratchpad” programming.
There is a modern system that offers this sort of immediacy: ...
Any language whose implementation includes a REPL.
Lisp, Scheme, Racket, Python, and Lua immediately come to mind.
Probably others I don't know about ... there used to be interactive interpreters for C and Pascal, but I haven't seen one for decades.
Apologies if I missed your favorite REPL language.
Jupyter <https://jupyter.org/>.
Has issues mixing code written in different languages, and many of the available language kernels are incomplete and/or outdated.
[Still, it is a good effort that just needs more work.]
There is a practical difference though between these and an
old-school BASIC:
These languages allow you to evaluate expressions one line at a
time, and sometimes define small functions in a purely volatile
manner, but not so much to edit the programs in this form.
The old school BASICs typically functioned more as a combination of
line editor and interpreter.
On 5/1/2026 11:46 PM, George Neuner wrote:
On Fri, 1 May 2026 23:00:44 -0000 (UTC), Lawrence D´Oliveiro
<ldo@nz.invalid> wrote:
BASIC offered a wonderful sense of immediacy: type a statement without
a line number, and it is executed right away. Or put a line number on
the front, and it gets kept in RAM as part of your program. Great for
incremental development, and “scratchpad” programming.
There is a modern system that offers this sort of immediacy: ...
Any language whose implementation includes a REPL.
Lisp, Scheme, Racket, Python, and Lua immediately come to mind.
Probably others I don't know about ... there used to be interactive
interpreters for C and Pascal, but I haven't seen one for decades.
Apologies if I missed your favorite REPL language.
There is a practical difference though between these and an old-school >BASIC:
These languages allow you to evaluate expressions one line at a time,
and sometimes define small functions in a purely volatile manner, but
not so much to edit the programs in this form.
The old school BASICs typically functioned more as a combination of line >editor and interpreter.
The old school BASICs typically functioned more as a combination of line editor and interpreter.
The old school BASICs typically functioned more as a combination of line
editor and interpreter.
Indeed, but there aren't many people around who still prefer line
editors over "visual editors", so I wouldn't take this as
a desirable feature compared to things like Jupyter or `codeboot.org`.
The old school BASICs typically functioned more as a combination of line editor and interpreter.Indeed, but there aren't many people around who still prefer line
editors over "visual editors", so I wouldn't take this as
a desirable feature compared to things like Jupyter or `codeboot.org`.
I freely admit that I haven't taught children programming in quite a
long time. That said, BASIC with line numbers and GOTO seems like
the environment with the smallest initial cognitive load.
On Wed, 06 May 2026 14:19:21 -0700, Andy Valencia wrote:
I freely admit that I haven't taught children programming in quite a
long time. That said, BASIC with line numbers and GOTO seems like
the environment with the smallest initial cognitive load.
Python was specifically designed, at least to start with, to be
approachable for beginners, while using more modern capabilities than
were available back in BASIC days.
Even back in BASIC days, there were other languages better suited for teaching purposes, particularly for children: LOGO being the main one
that comes to mind.
On 5/6/2026 2:33 PM, Lawrence D’Oliveiro wrote:
On Wed, 06 May 2026 14:19:21 -0700, Andy Valencia wrote:
I freely admit that I haven't taught children programming in quite a
long time. That said, BASIC with line numbers and GOTO seems like
the environment with the smallest initial cognitive load.
Python was specifically designed, at least to start with, to be
approachable for beginners, while using more modern capabilities than
were available back in BASIC days.
Even back in BASIC days, there were other languages better suited for
teaching purposes, particularly for children: LOGO being the main one
that comes to mind.
PILOT was a fun one.
On 5/6/2026 2:33 PM, Lawrence D’Oliveiro wrote:
Even back in BASIC days, there were other languages better suited
for teaching purposes, particularly for children: LOGO being the
main one that comes to mind.
PILOT was a fun one.
On Wed, 6 May 2026 21:43:25 -0700, Chris M. Thomasson wrote:
On 5/6/2026 2:33 PM, Lawrence D’Oliveiro wrote:
Even back in BASIC days, there were other languages better suited
for teaching purposes, particularly for children: LOGO being the
main one that comes to mind.
PILOT was a fun one.
Never encountered that. According to Da Wiki <https://en.wikipedia.org/wiki/PILOT>, seems it was designed for
authoring courseware, not for experimentation by the kids themselves.
The old school BASICs typically functioned more as a combination of line >>> editor and interpreter.
On DTSS, the line editor was part of the terminal
monitor, so any line you typed that started with a digit was just
buffered up. When you typed something else like RUN, it sorted the
lines into order and started a copy of the BASIC compiler which
generated machine code and ran it. It did this extremely quickly. DTSS
ran on a GE 635, which was about the same size as the original PDP-10,
with a very slow front end terminal processor. While you could run a
dozen users on a -10, I can say from having tried it that DTSS ran 100
with snappy responses.
Real BASIC was always a compiled languages. The interpreted versions
were at most second-best.
The use of line numbers for both editing and control flow is clever,
and, at least on the C64 (and probably other Commodore machines),
the OS allowed moving the cursor up to a line output with LIST (only
within the screen, no scrollback), editing that line, and then
pressing Enter, which overwrote the old line with that line number.
So there was no need to retype the whole line.
John Levine <johnl@taugh.com> writes:--------------------------
[someone:]
The use of line numbers for both editing and control flow is clever,
The program is stored as a linked list of lines (IIRC in line number
order, but I may be wrong), with the line numbers encoded as binary
number in 2 bytes, two link bytes, and IIRC a line length byte, and
then the contents of the line, with the commands replaced by
single-byte tokens (faster interpretation and less memory usage).
The line interpreter encodes the program code in this way, the BASIC interpreter interprets it, SAVE stores programs in this form to tape
or disk, and LIST decodes it to plain text.
The organization of the lines as linked list means that a GOTO to a
line late in the code is slow.
- anton--- Synchronet 3.22a-Linux NewsLink 1.2
On Sat, 09 May 2026 17:31:08 GMT, Anton Ertl wrote:
The use of line numbers for both editing and control flow is clever,
and, at least on the C64 (and probably other Commodore machines),
the OS allowed moving the cursor up to a line output with LIST (only
within the screen, no scrollback), editing that line, and then
pressing Enter, which overwrote the old line with that line number.
So there was no need to retype the whole line.
Did that work for scrollback?
On 2026-05-09 7:25 p.m., Lawrence D’Oliveiro wrote:
On Sat, 09 May 2026 17:31:08 GMT, Anton Ertl wrote:
The use of line numbers for both editing and control flow is
clever, and, at least on the C64 (and probably other Commodore
machines), the OS allowed moving the cursor up to a line output
with LIST (only within the screen, no scrollback), editing that
line, and then pressing Enter, which overwrote the old line with
that line number. So there was no need to retype the whole line.
Did that work for scrollback?
I liked the full screen edit on the Commodore machines so much that
I use it for my machines. There is not as much need for scrollback.
One can just cursor to a line containing a command and hit enter.
What if the line was off the screen?
My basic interpreter (NCR 1982-3) had a renumber command that would
take the current 'order' and replace the line numbers as a stride
based series including the gotos and call-subs {and shortening the
bytes in the line when possible}.
The organization of the lines as linked list means that a GOTO to a
line late in the code is slow.
A quick check on the line number you are currently 'on' gets rid of
½ the delay.
anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:
John Levine <johnl@taugh.com> writes:--------------------------
[someone:]
The use of line numbers for both editing and control flow is clever,
APL used floating point line numbers, allowing the insertion of
a line between any two other lines. {10.5, ...}
---------------
The program is stored as a linked list of lines (IIRC in line number
order, but I may be wrong), with the line numbers encoded as binary
number in 2 bytes, two link bytes, and IIRC a line length byte, and
then the contents of the line, with the commands replaced by
single-byte tokens (faster interpretation and less memory usage).
My basic interpreter (NCR 1982-3) had a renumber command that would
take the current 'order' and replace the line numbers as a stride
based series including the gotos and call-subs {and shortening the
bytes in the line when possible}.
On Sun, 10 May 2026 02:08:52 -0400, Robert Finch wrote:
On 2026-05-09 7:25 p.m., Lawrence D’Oliveiro wrote:
On Sat, 09 May 2026 17:31:08 GMT, Anton Ertl wrote:
The use of line numbers for both editing and control flow is
clever, and, at least on the C64 (and probably other Commodore
machines), the OS allowed moving the cursor up to a line output
with LIST (only within the screen, no scrollback), editing that
line, and then pressing Enter, which overwrote the old line with
that line number. So there was no need to retype the whole line.
Did that work for scrollback?
I liked the full screen edit on the Commodore machines so much that
I use it for my machines. There is not as much need for scrollback.
One can just cursor to a line containing a command and hit enter.
What if the line was off the screen?
Stefan Monnier <monnier@iro.umontreal.ca> writes:
The old school BASICs typically functioned more as a combination of line >>> editor and interpreter.Indeed, but there aren't many people around who still prefer line
editors over "visual editors", so I wouldn't take this as
a desirable feature compared to things like Jupyter or `codeboot.org`.
I freely admit that I haven't taught children programming in quite
a long time. That said, BASIC with line numbers and GOTO seems like
the environment with the smallest initial cognitive load. It lets the student focus on the absolutely non-intuitive semantic of:
30 x=x+1
while leaving a host of modern amenities (initially, they
are just attractive nuisances) off in the wings.
It's an environment they'll of course leave behind. But there's a
reason to start here, along the lines of why one learns to fly
in a Cessna 152, not a Boeing 737.
We also took advantage of a feature of the basic on the Sigma 7,
called "Newbasic" that I haven't seen anywhere else (though I
haven't really searched). When running a program, a user could type "newbasic" and get a fresh basic environment where they could write
and run their own programs. The unique feature was that when they
exited, it took them back to where they were in the original
program.
Regarding teaching, in 1972 I was student teaching high school students.
The school had a grant from NSF to teach students to use computers. We had time on a time shared Xerox Sigma 7, communicating with teletypes
(yes, real KSR and ASR 33s!).
My high school, ca. 1977, had a computer programming class. The
equipment available was a Decwriter II, one keypunch machine, a card
reader, and a 300bps modem to talk to the school systems Decsystem
10.
Students didn't get to use the keypunch machine. Instead they had to
hand mark 40 column cards. Ugh. Glad I never did that.
On Sun, 10 May 2026 02:08:52 -0400, Robert Finch wrote:
I liked the full screen edit on the Commodore machines so much thatWhat if the line was off the screen?
I use it for my machines. There is not as much need for scrollback.
One can just cursor to a line containing a command and hit enter.
On Sun, 10 May 2026 08:45:21 -0000 (UTC), Lawrence D’Oliveiro wrote:
On Sun, 10 May 2026 02:08:52 -0400, Robert Finch wrote:
I liked the full screen edit on the Commodore machines so much
that I use it for my machines. There is not as much need for
scrollback. One can just cursor to a line containing a command and
hit enter.
What if the line was off the screen?
You could list ranges, so you'd list an earlier chunk of lines to
get it on-screen.
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,116 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 85:27:35 |
| Calls: | 14,305 |
| Files: | 186,338 |
| D/L today: |
647 files (184M bytes) |
| Messages: | 2,525,478 |