Also around that era was a game-programming system called White Lightning for ZX Spectrum and Commodore 64. It was very clever but I found it quite hard to use because of the block-based editor. It was not a great fit for computers using cassette tapes for storage.
Does anyone know if this is the reason for Starflight's madding save system[0]? I can't think of a technical reason it would need to work that way, but it is an exceptionally rare way to do things so I'm forced to wonder if the use of forth is partly responsible.
[0] Starflight self-modifies as it runs, meaning the executable itself is re-written with the game state baked in. If the game exits without saving in the approved way the executable is broken.
I have no inside information on Starflight but this is typical of Forth systems. They are an image structured environment.
Unless you build your own data structures that are external to Forth's memory image, called a dictionary, everything exists in that chunk of memory. Variables and arrays etc. exist where they are declared in the code sequence. So to save the game they opted apparently to just save the system image. It was the simple way out IMHO. It's trivial to create separate data area and write that out to a file in Forth.
I have a theory that the best forth programs for a domain approach a optimal Huffman encoding for the problem. This explains why Chuck Moore (who probably had the IQ to spare) could do amazing things such as design a chip design language in forth. Unfortunately Forth programs are about as hard to grok as manually decoding a Huffman encoding. ;)
Real-world FORTH code has lots of non-trivial stack operations which are quite far from 'optimally' encoded, in fact they're quite unintuitive. You could get quite a bit closer by somehow extending the language with direct representations of data flow and control flow/dispatch, but that of course loses the FORTH property of all composition being represented as simple concatenation of tokens.
> Real-world FORTH code has lots of non-trivial stack operations which are quite far from 'optimally' encoded, in fact they're quite unintuitive.
I guess it depends on what you consider to be "real-world".. but usually when I see a ton of stack manipulation, it's from a newer forth programmer who thinks that they should be programming that way, i.e. forth is stack based, so I should be putting everything on it.
I went back and looked at an old SHA1 implementation I did[0], and I think the "worst" stack manipulation was a -rot in one place, and maybe the handful of overs.
I've seen this touched on several times across various threads, but if you can compile down to assembly, is there an advantage to use a custom forth as essentially the bytecode to compile down to?
It's always impressed me just how much mileage a small team with Slava Pestov was able to get out of Factor.
I am not sure what you mean by "custom forth", but threaded code ("bytecode") can be much denser than machine code, so it saves space, thereby allowing FORTH to run on systems with as little as 2K bytes of memory.
This very much depends on the Hardware that Forth is running on but the concept is very old. Interpreters of all types are used to encode higher level functions than the hardware supports as a single bytes or integers. Then you write your program using the byte/integer code as instructions and it takes less space for a given program.
Byte code threaded programs are small but less speedy.
(Open-Firmware is byte coded Forth)
Traditional Forth systems encode this virtual machine as lists of addresses. These lists are "interpreted" by a piece of code that is 2 to 3 instructions on modern computers, so it's pretty fast. (slightly bigger on an 8 bit CPU)
This address based VM code "can" be smaller on a 16bit machine but might not be on a 32bit machine until you raise the programming level to very high level functions. This depends on the CPU. On RISC-V it's probably still true based on what I see of the instruction set. (not tested)
The typical Forth development cycle involves extending the language in the direction that one needs, writing higher level functions, combining them into even higher level functions such that at the end of the coding process you are using very few of these application specific functions to write the program. Thus a space saving because each function uses only one byte or integer in your program to reference it.
> I've seen this touched on several times across various threads, but if you can compile down to assembly, is there an advantage to use a custom forth as essentially the bytecode to compile down to?
Forth is compact and performant at runtime, and then it's possible to implement it compactly too. This gives the language particular advantages in small and resource constrained environments. (Just a few kilobytes, in fact, are enough.)
To wit:
Adobe Postscript is itself a variant of Forth, that was of course originally designed to run embedded on printers. These printers originally weren't exactly resource constrained, but most of the resources they had available were dedicated to printing the page. (Memory was expensive at the time and, for Postscript, you needed enough to store every pixel on a page before printing.)
PostScript is also notably 'a bytecode to compile down to'. It's a fully Turing complete language (people can and do write it by hand), but it is mostly generated automatically by various drawing and page layout packages.
Another good example of the power of Forth school is the later model HP calculators. HP devveloped a custom language (RPL) that combined the execution model of Forth with a number of features of Lisp. (Note that this does not apply to all of HP's RPN calculators, just the later ones done in RPL.) There's a lot that can be said, but these were small machines with limited RAM and an outsized amount of functionality. It was a good engineering trade off for the time.
Interestingly, the entire software stack for an RPL calculator was done in either machine code or in RPL. The only distinction between "User RPL" and the "System RPL" was whether or not the calculator had user-visible symbolic names for the various entry points. If the calculator knew the name of a symbol, you could enter it and request it be called. If it did not know the name of a given symbol, you needed specific development tools that did, and they usually ran externally. The process was also bi-directional - enter a program, and the calculator 'compiled' the text into a binary representation. Edit the program, and the calculator reconstituted the text (in pretty-printed form) based on the binary representation. It made programs nicely editable without having to carry around all the source text in addition to the runtime representation. All very cool and efficient.
> It's always impressed me just how much mileage a small team with Slava Pestov was able to get out of Factor.
I think most or all of that has to do with Slava Pestov and his general dedication and skill. (At least based on the high rate of progress he made early on, when it was just himself.)
If C is a "portable assembler", then Forth is a "non-portable assembler" (many people roll their own, which resulted in a proliferation of non-compabile versions).
Neat little language, small enough to pick it up in one afternoon, versatile for tiny to small projects, in particular embedded systems and control software, but nothing you should use for anything that involves medium to large size or more than a single developer.
Languages similar to Forth are often used as intermediate languages in portable compilers, in particular ones written for educational purposes, because it's easy to generate code for stack machines (no register allocation needed).
>"Forth is a text-based language that is essentially context-free. It combines 'words' separated by spaces, to construct new words. About 150 such words constitute a system...
[...]
Such a system has 3-8K bytes of code compiled from 10-20 pages of source. It can easily be implemented by a single programmer on a small computer.
[...]
Another application of least-squares was the program CURVE, coded in Algol (1964). It is a general-purpose non-linear differential-corrections data-fitting program. Its statistical rigor provides insight into agreement between model and data.
The data format and model equations were interpreted and a push-down stack used to facilitate evaluation.
I am watching this talk now, and so far two things have stood out to me:
1. He flatly declares that forth is the only programming language he deems usable. No contributions to computer science since have added ANY value?
2. He called his program to communicate between cpu cores "ether", to confuse the unwary that it might have something to do with networking.
That sort of willful ignorance verges on arrogance, and it sits strangely on someone who is a CEO of a company that wants to sell CPUs in the marketplace.
https://en.wikipedia.org/wiki/Jupiter_Ace