I'm brand new here, so an #introduction is a good idea:
I'm a freelance tech writer / software developer / KM project manager based in Europe. Digitally, I was born in the 90s. So I grew up eating cyberpunk books, BBSs, home computers, hacking, then the first doses of Internet and the Web.
In the 90s and the first 00s I developed my (ahem) "philosophy": digital spaces are (can be, should be) autonomous zones where different cultures, and sub/counter-cultures, can thrive.
These are the years of the enshittification of Internet, but it can't rain forever (cit.) and I see the Fediverse as a new opportunity for some of us to recreate better and safer digital spaces.
That's the "vision". Than there's the daily life: I write code (awful, mostly), help companies in managing their knowledge bases, write technical documentation, sometimes write tech articles for (mostly unknown) business tech manazines.
In the spare time, I tinker with Linux, Risc-V boards and "old" languages like Forth, Assembly and C (but I'm a fan of Haskell too). I'm convinced that permacomputing and, maybe, collapse computing are our digital future. So, "back to basics" seems a good idea.
@hugoestr it was one of the first languages to implement #CSP (C.A.R. hoares process calculus formalism) specifically to work on the #inmos transputer (a multi processor computer from the 80s as they saw the writing on the wall wrt moores law coming to an end.. they were just 30ish years early). The reason I am obsessed with it is the same reason I love #lisp#forth#ml#prolog and #smalltalk - there is something endlessly fascinating about the roots of computing. Especially when it is so applicable to modernity (eg we are all programming with concurrency now).
Its been years since I checked in on the status of the #collapseOS project, and to my delight it seems the author has only gone further and further down the #forth rabbit hole, starting a blog called Tumble Forth and launching cOS's successor, #duskOShttps://tumbleforth.hardcoded.net/
A moon lit vista of the bridges over the river Forth, north of Edinburgh.
Captured from a late squeezy jet trip to Europe, I always try to get the window seat 'just in case' 🙂
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.
Finished the last tweaks on the #ForthDeck today, covering the solder joints of the switches with a 0.5 mm sheet of white plastic. Then I stuck a 3.7V LiPo to that and soldered the missing connector. Look mom, no wires!
I'm happy to report that Shoehorn V2.0 is now pushed to my SourceHut repo.
Shoehorn is a #Forth subset bootstrap compiler for use in bringing up new hardware completely from scratch.
I'm currently using it to write my own Forth interpreter/compiler for my homebrew 65816-based computer design, proving that it's not just a toy. (If you are lost figuring out where to start, look in mkdisk0 and sysf.f)
This version introduces support for CREATE, DO/?DO, LOOP/+LOOP, and a new way of supporting primitives that allows them to be linked into the dictionary hash chain.
Dammit!! The #Forth dictionary layout that has worked so well for me before is now failing me in a big way.
I can't expose primitives in the dictionary, because the way things work now, the header MUST preface the actual code of the word. However, primitives are written by hand, and thus don't have headers in front of them. (Indeed, it's extremely difficult to maintain by hand, as primitives come and go at any time, and the dictionary is a hash structure.)
OK, finally got numeric output working in my 65816 #Forth interpreter. . U. D. UD. D.R and UD.R all seem to behave as expected, and don't appear to corrupt the stack.
So, that's a thing, I guess. Only took one full year to get the ambition to finish this.
Now to add arithmetic and logical operators so that I can use the interpreter as a calculator, I suppose.
(Colon compiler will, I suppose, come shortly after that's done.)
It's taken a while and a bit of a rewrite of the rainbow compiler but here is "advance" defined to advance through a gap buffer. This is the basis of the "l" key command for my text editor which will be completely scriptable with Rainbow code. #forth#Rainbow
And here it is, at long last. A rough, preliminary sketch of the new instruction set architecture for a next-generation successor to my S16X4 #stack CPU family.
This is a proper #Forth CPU ISA design. A bit CISCy, though, but I think it's usable.
In a fit of nostalgia, I've installed gForth on my Pixelbook for a little play and now have to think of something amusing to do with it. I last used #forth on the Commodore VIC-20 in the 1980s and have forgotten everything beyond basic stack manipulation. I think having a crack at writing a clone of the #todotxt CLI (http://todotxt.org/) might be good for a laugh.