I recently posted a paper on the Permacomputing Aesthetic (https://news.ycombinator.com/item?id=41818119) which argues there is a counter current of developers that want to go against the maximalist world of computing and rediscover programming as art on constrained systems. In this world, where we do not idolize the large teams of code monkeys, languages like Forth can see a resurgence. Forth is a bad language for a team of people of dubious and different skillset, but in the hands of a single person it is the most moldable environment, even moreso than Lisp.
I have been designing some sort of "persistent" Forth OS, that boots into an interpreter and persists your defined words across sessions and reboots, so you can incrementally build your own personal computer from scratch.
Let's take Laxen and Perry's F83 implementation as an example.
F83 implements an assembler, a memory hex dumper, an interpreter, a sort of bytecode compiler, a decompiler, a single-stepping source-level debugger, a screen editor (which could jump to the definition of any function and jump back and forth between source and documentation, and which tagged each screen of source code with the last edit date and author's initials), cooperative multitasking with thread-local data, a print spooler, and virtual memory. It can also compile programs into standalone executables, and in fact it's written in itself, so it can cross-compile itself for other architectures and operating systems; it supported CP/M-86, MS-DOS, and CP/M for the 68000.
The Forth programming language it implements is low-level but relatively powerful; among other things, it includes structured control flow, Turing-complete compile-time macros, closures, pointers, and multiple return values.
This is nothing unusual for a Lisp system, of course. What is different is that F83 is only about 2100 lines of code by my count. That's what makes it "more moldable" than a Lisp system with the same features, which would require around an order of magnitude more code.
There are some major compromises made in pursuit of this level of minimality, though: no type-safety (not even to the extent of calling functions with the right number of arguments), no built-in structs (though you can build them with its macro system and closures), no bounds-checking on arrays, error-prone manual access to the virtual-memory system, no syntax, no stack-allocated named variables, etc.
Thank you, that's interesting. The classic Lisp machine systems are very compact by modern standards but not 2100 lines compact, although they had about two decades of continuous development to accumulate cruft (and useful features like various network protocols support and sophisticated graphics as well).
Yeah, LispM system software is orders of magnitude larger than that, but, for example, David Betz's XLISP for CP/M is 2800 lines of C, and it doesn't include any of those facilities except for an interpreter. Now, the interpreter does have some things F83 doesn't: a fully dynamic object system which supports adding new methods at runtime, named stack-allocated variables, dynamic typing, a string type, a file-pointer type with character I/O, Lisp lists, S-expression reading and printing, and a garbage collector. But it doesn't have an assembler, a memory dumper, a bytecode interpreter, a debugger of any kind, an editor of any kind, any kind of version control, any kind of multitasking, or virtual memory. For many of these, adding them in Lisp is a lot more difficult than adding them in Forth.
Probably the most influential use of XLISP is as AutoCAD's built-in scripting language, AutoLISP, but it's also the basis of Nyquist.
I have been designing some sort of "persistent" Forth OS, that boots into an interpreter and persists your defined words across sessions and reboots, so you can incrementally build your own personal computer from scratch.