"Starting Forth, the Forth language tutorial, is shared freely here in its official online edition. Updates to the original text include code examples that run on iForth and SwiftForth systems. Aficionados (and detractors) of the original book’s illustrations will find most of them restored in this edition by FORTH, Inc.

"Notes about this online edition

"Changes made by FORTH, Inc. to Marcel’s version were primarily related to internet coding standards and visual presentation. We also restored the book’s original illustrations here, in most cases. The following notes are also relevant and important to those familiar with the original edition.

"Notes by Marcel Hendrix

"This transcript is not an exact reproduction. Forth code has been ANSified. All code should run on at least SwiftForth and iForth. Where necessary, statements that were valid in 1981 have been exchanged with statements more appropriate for 2003 (when this tribute was written)."

#forth #programming https://www.forth.com/starting-forth/

"Starting Forth, the Forth language tutorial, is shared freely here in its official online edition. Updates to the original text include code examples that run on iForth and SwiftForth systems. Aficionados (and detractors) of the original book’s illustrations will find most of them restored in this edition by FORTH, Inc.

"Notes about this online edition

"Changes made by FORTH, Inc. to Marcel’s version were primarily related to internet coding standards and visual presentation. We also restored the book’s original illustrations here, in most cases. The following notes are also relevant and important to those familiar with the original edition.

"Notes by Marcel Hendrix

"This transcript is not an exact reproduction. Forth code has been ANSified. All code should run on at least SwiftForth and iForth. Where necessary, statements that were valid in 1981 have been exchanged with statements more appropriate for 2003 (when this tribute was written)."

#forth #programming https://www.forth.com/starting-forth/

@akkartik Since #Forth is just so great for super concise code, allow me to add another example, here to transpile (a subset of) Forth into GLSL for livecoding shaders. This one is using my old 2015 CharlieVM and you can find all the example source snippets in the readme here:

https://github.com/thi-ng/charlie

The REPL itself live at:
https://forth.thi.ng/

The attached screen capture shows 4 shader examples (longest one is 12 lines of code)

#Livecoding #REPL #GLSL #Shader #Transpiler

@akkartik Since #Forth is just so great for super concise code, allow me to add another example, here to transpile (a subset of) Forth into GLSL for livecoding shaders. This one is using my old 2015 CharlieVM and you can find all the example source snippets in the readme here:

https://github.com/thi-ng/charlie

The REPL itself live at:
https://forth.thi.ng/

The attached screen capture shows 4 shader examples (longest one is 12 lines of code)

#Livecoding #REPL #GLSL #Shader #Transpiler

@akkartik Here's a small example using my #Forth-like DSL & livecoding REPL for 2D geometry generation with SVG export. The example source code is stored in the URL hash, but not sure how Mastodon handles it (let's try):

https://demo.thi.ng/umbrella/pointfree-geom/#eJx1UstugzAQvPsr9pwK7EQlh/QSKZ8RpZIxC1jyg9iGElX999omiYSaWlgadmZnH0ApnKzWaAI2MKHz0poDoRT6EAZ/oLSToR/rUlhNQy8L09FR1w6V4rRWtqYNTqjsQHHmelDo6WClCa1DLDqMSd6JqNG2DJ6QA7SOiwBb0LaBj/hurNMtbO7xRyTw8c4ktMlxzZsmwreErReFl+apTTjzifziE8LnNwzWQ+wpWuMVfgjEw+CYIkFqBBHpDRwze0za8vbw/aNN/mvtvNJOKHYZBMeNVzxgEebcjL+O3KH/r5+yWqqsrXPNLWPLTKumXiXcXifkvZE9mMGqG5yhxxn2DBx2o+IOLrDdp6dzsiHJd7m7xezhIY3HQM5QscgxtquW9V6WSdu4/yJ/cB81rHyvFtVz7At4wRUWIv1gjvwCN/TBcA==

A commented alt-version of this example (same URL minus the hash fragment):
https://demo.thi.ng/umbrella/pointfree-geom/

Project/example homepage:
https://github.com/thi-ng/umbrella/tree/develop/examples/pointfree-geom/

Made with these packages:

- https://thi.ng/geom
- https://thi.ng/pointfree
- https://thi.ng/pointfree-lang

#ThingUmbrella #Forth #DSL #Livecoding #Geometry #SVG

@freakazoid That's good to know. I would say not to neglect #Forth as an option to scratch the interactive programming itch. Sadly, not a lot of devs are aware of Forth's existence.

I didn't know people were porting BASIC to microcontrollers AND doing stuff with it. That's cool! I'm glad to see it.

https://www.forth.org/Ting/Forth-for-the-Complete-Idiot/Forth-for-the-Complete-Idiot.pdf
#forth

https://www.forth.org/Ting/Forth-for-the-Complete-Idiot/Forth-for-the-Complete-Idiot.pdf
#forth

It's been a pretty productive night in the ol' #DesmetC codebase. Regression tests finally checked in, all the mixed-size integer addition/subtraction involving signed chars I could think of is exercised and passing, nice.

Then I try i8 * i8 -> int and it instantly breaks, not so nice 🫠.
Oh well, that gives me something to fix tomorrow.

Also, I haven't ventured into floating point conversion land yet, either. I'm sure that'll have plenty of dragons when used with signed char.

All this is making me appreciate the wisdom of BCPL and B who have just a word-sized type -- or #Forth which takes that and adds char, as a treat.

#retrocomputing

In the Spring of 2025, I taught a course about interactive programming environments to a small group of students. For various reasons, I have to take down the official web page for that site, which includes slides that may be of interest to people who care about these things. I have therefore chosen to publish those slides on Lost Bits under a Creative Commons License.

https://lostbits.net/blog/interactive-programming-environments.html

If you are interested in such things, check it out!
#lisp #smalltalk #squeak #forth #emacs

In the Spring of 2025, I taught a course about interactive programming environments to a small group of students. For various reasons, I have to take down the official web page for that site, which includes slides that may be of interest to people who care about these things. I have therefore chosen to publish those slides on Lost Bits under a Creative Commons License.

https://lostbits.net/blog/interactive-programming-environments.html

If you are interested in such things, check it out!
#lisp #smalltalk #squeak #forth #emacs

The best example of distilled software that comes to mind is Project #Oberon, which was distilled by Niklaus Wirth (and others) for most of Wirth's lifetime (if you count his earlier time working on Pascal and Modula as earlier steps of the distillation). https://projectoberon.net/

There are also #Forth and #Lisp, of course, but they've been distilled in many different directions by many people so there isn't a clear unifying idea. You have to get more specific. Now, Chuck Moore's evolution of Forth -> MachineForth -> ColorForth certainly counts as distillation.

#LuaLang also comes to mind. Porting the most modern Lua to the 188K TI-92+ calculator (last year) is what sold me on the idea that widely used modern software can remain useful on the oldest computers. That said, Lua is not entirely immune to bloat: I had to roll back from v5.4 to v5.2 to cut my memory usage from ~170K to ~128K 😉

The best example of distilled software that comes to mind is Project #Oberon, which was distilled by Niklaus Wirth (and others) for most of Wirth's lifetime (if you count his earlier time working on Pascal and Modula as earlier steps of the distillation). https://projectoberon.net/

There are also #Forth and #Lisp, of course, but they've been distilled in many different directions by many people so there isn't a clear unifying idea. You have to get more specific. Now, Chuck Moore's evolution of Forth -> MachineForth -> ColorForth certainly counts as distillation.

#LuaLang also comes to mind. Porting the most modern Lua to the 188K TI-92+ calculator (last year) is what sold me on the idea that widely used modern software can remain useful on the oldest computers. That said, Lua is not entirely immune to bloat: I had to roll back from v5.4 to v5.2 to cut my memory usage from ~170K to ~128K 😉

While I was working on this, the article Python Numbers Every Programmer Should Know appeared on the orange website. In #LuaLang, and on a 16-bit target, these overheads are less -- for example, a number weighs 10 bytes instead of 24 bytes -- but overheads don't have much place to hide on a small, slow machine.

(Btw numbers cost 7 bytes each in 8-bit Microsoft BASIC so Lua isn't gratuitously inefficient here, even by the standards of 50 years ago.)

One place that makes overhead really obvious: a 64K segment holds a table of length, at most, 4,096 entries. That's 40,960 bytes, and Lua's strategy is to double allocation size every time it wants to grow the table. 2 x 40,960 exceeds a 64K segment, so 4,096 entries is the growth limit.

On a 640K machine, after deducting the ~250K (!) size of the interpreter (which is also fully loaded into RAM), you'll get maybe five full segments free if you're lucky. So that's like maybe 20,000 datums total, split across five tables.

Meanwhile a tiny-model #Forth / assembly / C program could handle 20,000 datums in a single segment without breaking too much of a sweat!

The efficiency has costs to programmer time, of course. Worrying about data types, limits, overflows, etc. The kinds of things I was hoping to avoid by using Lua on this hardware -- and to its credit, it does a good job insulating me from them. Its cost is that programs must be rewritten for speed in some other language once out of the rapid prototyping phase and having reasonable speed / data capacity becomes important.

I'd estimate the threshold where traditional interpreters like Lua become okay for finished/polished software of any significant scope, is somewhere around 2MB RAM / 16MHz. So think, like, a base model 386. Maybe this is why the bulk of interpreters available in DOS are via DJGPP which requires a 386 or better anyway.

#BASIC was of course used on much smaller hardware, but was famously unsuited to speed or to large programs / data.

I know success stories for #Lisp in kilobytes of memory, but I'm not quite sure how they do it / to what extent the size of the interpreter, and overhead of data representation (tags + cons representation), eats into available memory and limits the scope of the program, as seen with other traditional interpreters.

This is beginning to explain why #Forth has such a niche on small systems. It has damn near zero size overhead on data structures. (The only overhead is for the interpreter core (a few K) and storing string names in the dictionary (which can be eliminated via various tricks)). ~1x size and ~10x speed overhead is the bargain of the century to unlock #repl based development. However, you're still stuck with the agonizing pain of manual memory management and numeric range problems / overflows. Which is probably why the world didn't stop with Forth, but continued on to bigger interpreters.

#retrocomputing

While I was working on this, the article Python Numbers Every Programmer Should Know appeared on the orange website. In #LuaLang, and on a 16-bit target, these overheads are less -- for example, a number weighs 10 bytes instead of 24 bytes -- but overheads don't have much place to hide on a small, slow machine.

(Btw numbers cost 7 bytes each in 8-bit Microsoft BASIC so Lua isn't gratuitously inefficient here, even by the standards of 50 years ago.)

One place that makes overhead really obvious: a 64K segment holds a table of length, at most, 4,096 entries. That's 40,960 bytes, and Lua's strategy is to double allocation size every time it wants to grow the table. 2 x 40,960 exceeds a 64K segment, so 4,096 entries is the growth limit.

On a 640K machine, after deducting the ~250K (!) size of the interpreter (which is also fully loaded into RAM), you'll get maybe five full segments free if you're lucky. So that's like maybe 20,000 datums total, split across five tables.

Meanwhile a tiny-model #Forth / assembly / C program could handle 20,000 datums in a single segment without breaking too much of a sweat!

The efficiency has costs to programmer time, of course. Worrying about data types, limits, overflows, etc. The kinds of things I was hoping to avoid by using Lua on this hardware -- and to its credit, it does a good job insulating me from them. Its cost is that programs must be rewritten for speed in some other language once out of the rapid prototyping phase and having reasonable speed / data capacity becomes important.

I'd estimate the threshold where traditional interpreters like Lua become okay for finished/polished software of any significant scope, is somewhere around 2MB RAM / 16MHz. So think, like, a base model 386. Maybe this is why the bulk of interpreters available in DOS are via DJGPP which requires a 386 or better anyway.

#BASIC was of course used on much smaller hardware, but was famously unsuited to speed or to large programs / data.

I know success stories for #Lisp in kilobytes of memory, but I'm not quite sure how they do it / to what extent the size of the interpreter, and overhead of data representation (tags + cons representation), eats into available memory and limits the scope of the program, as seen with other traditional interpreters.

This is beginning to explain why #Forth has such a niche on small systems. It has damn near zero size overhead on data structures. (The only overhead is for the interpreter core (a few K) and storing string names in the dictionary (which can be eliminated via various tricks)). ~1x size and ~10x speed overhead is the bargain of the century to unlock #repl based development. However, you're still stuck with the agonizing pain of manual memory management and numeric range problems / overflows. Which is probably why the world didn't stop with Forth, but continued on to bigger interpreters.

#retrocomputing

My overnight activity on New Year's Eve was to rewrite the #uuencode utility that I lost in a battery-exhaustion incident. The old version was in #Forth, the new version in #LuaLang. Including interpreter size, the Lua version is 100x larger and 100x slower. I was not intending to provide a case study upholding Jeff Fox's writings about Forth efficiency, but there you go.