The idea of abstractions as lies which you must maintain using ever more clever lies is an interesting analogy I'd never used before, but it makes perfect sense.

It really also ties in with John Osterhout's views on "deep modules." A perfect example of an interface that is deep (in Osterhout's sense of the term) is the Unix file I/O API. Another, albeit to a lesser extent, would be #Forth's block storage wordset.

But, comparing the two is enlightening. Forth's blocks provides only the barest essentials for accessing mass storage devices in a device independent manner. You assign a range of 1KiB blocks to a specific device, and now you have full access to that storage. It works like demand paging, except with 1KiB pages and "demand" is driven by software explicitly, not implicitly. The interface is really deep: BLOCK, BUFFER, UPDATE, FLUSH, and EMPTY-BUFFERS. That's it (and 99.999999% of the time you will only ever use BLOCK and UPDATE).

But, in exchange for this simplicity, you lose the notion of a filesystem. You're managing space on a volume explicitly. I've found that, for most applications, you can get away with this no problem. It is actually pretty rare that one needs anything more than this.

The moment you introduce character stream support, though, this interface suddenly becomes inadequate. Now you need a completely new abstraction, where Unix's I/O calls fit more naturally. But, that is unarguably a more complicated stack of software to maintain, with many more interface points to maintain (open, read, write, close, seek, mkdir, unlink, mknod, etc.). But, it's a useful abstraction; that's why it (in some form or another and with varying degrees of completeness) has become so universal across different platforms. Including, ironically, in Forth itself.

But like all lies, you can only support them with more clever lies. Hence, why we have libraries that abstract other libraries, sometimes several layers deep. (Looking at you, SDL!) And while each claims to simplify some aspect of programming, I find usually it's just the opposite; they actually (sometimes greatly) complect the software as a whole.

This is one of those "I don't have the answer" type of posts. I'm not sure how one could arrive at the ideal "deep modules interface" for, say, something like SDL. I'm not even sure it's possible. But, maybe, just maybe, I can inspire someone somewhere to think about giving it a try for their software architecture. If you insist on making a lie, at least make it a good one.

Its such a joy to watch! Don't know if it has more to do with moving to Mastodon and following a quite different crowd of people, but even before that, for the past few years I started sensing a (re)growing interest in #Forth-style languages and related philosophies, i.e. low fat, low energy, minimalism, self-sufficiency, interactive programming, dynamic systems, DSLs, VMs, emulation etc. Renewed interest in all this also seems to come from people with vastly different backgrounds & ages. Forth being one of the most underappreciated langs ever, 10 years ago it felt (subjective experience, no proof!) most active Forthers were either a) #RetroComputing people who've been using the language for decades and/or b) people working w/ severely resource constrained embedded devices (often an overlap). These groups still exist ofc, but I wouldn't be very surprised to learn if demographics taking an active interest (above and beyond doing some toy examples) have started shifting noticeably.

Back in 2015, the ForthHub org on GitHub had a dozen or so members, today its ~240. /r/Forth also has 3k members now, which isn't too shabby (even though a mere blip in the greater picture, but still...)

Is some of this due to more people getting fed up with heaviness of existing mainstream langs & tooling, looking for lighter alternatives? I don't know. Maybe more people are finding their way to functional programming (incl. getting pre-exposed to REPLs and their life-changing impact/discovery of interactive dev processes) and from there taking the smaller step to explore concatenative/stack-based langs...? 🤷‍♂️

Enough hypothesizing — it's just all _very_ exciting to watch how this is developing and hopefully new ideas & learnings from other langs/envs finding their way into Forth-lands!

“…Forth does it differently. There is no syntax, no redundancy, no typing. There are no errors that can be detected. …there are no parentheses. No indentation. No hooks, no compatibility. …No files. No operating system.” — Chuck Moore

Ps. Now go check out @ratfactor's great talk/summary/history on the matter:
https://mastodon.art/@ratfactor/109925520445016458

Ps2. Shameless plug, if you want to try out a Forth in the browser, check out my VM/REPL (incl. screen casts, Forth shaders/webaudio examples):
https://thi.ng/charlie

ratfactor

2023-02-25 13:05:29

I would apologize for posting what at first appears to be another "tech toot"...but since I churned out almost 40 drawings for this talk on the Forth programming language, I don't feel bad about it at all. Here's the slides:

http://ratfactor.com/forth/forth_talk_2023.html

I happen to know some of you enjoy space ships, calculators, and old computers as much as I do.

#MastoArt #RetroComputing #Forth #ConfusedCat

Dave's Forth Talk 2023

^{ratfactor.com}