ComputerCraft (programmed in lua usually) is more common these days.
Chapter 9 of Leo Brodie's "Starting Forth" is the text that kicked off my implementation in the early 80s (and undoubtedly countless others): https://www.forth.com/starting-forth/9-forth-execution/
You might check out Jonesforth , which is an extensively-documented Forth implemented in x86 assembly language. If you read the single source file top to bottom, you'll get a good understanding of how it is implemented. There are also ports to x86-64, ARM, and other machines.
If you're looking for something in C, you might check out Ficl. 
Ah, that github link is not the official repository. The following link appears to be the official repo:
Most of the principles described in the book can be applied to any programming languages, but the book itself uses Forth. Give it a try!
If you want to learn Forth, this might be the book you need: https://www.forth.com/starting-forth/ (https://1scyem2bunjw1ghzsf1cjwwn-wpengine.netdna-ssl.com/wp-...)
Old HN discussion: https://news.ycombinator.com/item?id=13505285
I would also recommend checking out Factor (http://factorcode.org/, created by Slava Pestov).
More details on the programming language:
Old HN discussion: https://news.ycombinator.com/item?id=9008472
I wrote a 5k line RenderMan RIB exporter for this app in RPL.
I remember how hard this seemed when I started but how natural working in a RPN language felt after only a few hours. It was almost as if the stack had become an extension of my brain.
Trivia: Real3D was eventually rewritten from scratch and is now called Realsoft 3D. Afaik it doesn't support RPL/Forth any more.
I often think of myself in the past as a completely different person who seems to be capable of many surprising actions.
"4tH is a very small Forth compiler that can create bytecode, C-embeddable bytecode, standalone executables, but also works fine as a scripting language. It supports over 85% of the ANS Forth CORE wordset and features conditional compilation, pipes, files, assertions, forward declarations, recursion, include files, etc."
Home page: https://thebeez.home.xs4all.nl/4tH/
Also..anyone tried or programmed in colorForth? Sounds extremely colourful!
"colorForth uses different colors in its source code (replacing some of the punctuation in standard Forth) to determine how different words are treated."
Would like to hear if anyone thinks it is worth continuing to elaborate on.
The idea for the game was that you pilot a space ship, but your only interface was a C64-like clone. You'd have to write programs to navigate, make jumps, and explore the galaxy. Connect to space stations using a modem, and dial into their local BBS for buying and selling goods.
So I built a 6502 emulator and emulated hardware for all the subsystems (display, disk, engines, modem, etc). It really was a legit emulated system ... just that some of the addressable hardware was a space ship :P
I started out using a modified KERNAL ROM with BASIC, but ran into problems. In the first iterations of the game all the subsystems were a bit too realistic. For sensors you'd have to manually move the sensor beam around and read out results constantly. For the engines you have to manually adjust the engine thrust and read back velocity information. Same with the jump mechanic.
I figured making the subsystems realistic, as if they were real hardware that you had to write firmware for, would be interesting. But coding the "firmware" in BASIC was a nightmare, and so slow. The jump subsystem was especially problematic, because the velocity was so high. The program would point your ship at a space station in the local system, engage jump drives, and then constantly monitor distance to the station and try to disengage once you got close enough. But because of the high speeds and the need for large integers to represent the distances, the program just couldn't PEEK and react fast enough. I could never get it accurate enough to drop out of jump close to the station. So you'd spend 10 minutes crawling over there with your sub-lightspeed drives the jump.
And on top of those speed issues, BASIC was too much of a PITA when you had to do a lot of hardware manipulation and processing of large numbers (like the vast distances of space...).
So after hacking on that for awhile I looked for a better alternative. That's when I stumbled into Forth. There's an actively developed Forth for C64 (https://github.com/jkotlinski/durexforth) which even included a Vi implementation. So I could get a nicer, faster language and an editor in one package!
A bit of hacking later, and it really was a massive improvement. It was especially nice having VI.
I ended up ditching a lot of the hardcore realism in the subsystems. Even with DurexForth, which was significantly faster and handled the math better, it was still problematic coding what should be fundamental programs in this game. And it certainly wasn't fun (if a game like this could ever be considered fun).
But the journey gave me a lot of exposure to Forth, and it is such an interesting language. I definitely recommend playing with Forth, at least for a weekend, just for fun and to expand your mind a little.
P.S. As for the game, it's collecting dust. One of these days I'd like to dust it off and get back to it; I find the idea of it terribly seductive. It's like a new genre: 6502-Punk :P But I'm half tempted to drop back to BASIC, since Forth is such a foreign experience. I'd probably continue simplifying the subsystems, add a floating point co-processor, and mod BASIC to use large hardware backed floats, just to make everything easy.
> It is called Force because of its assonance of Forth and since the Force is the main power of the Jedi the files have .j (or .jedi) extension. So Force is the Jedi programmers language !
I find it both easier to implement than C and easier to develop in than C, while being nearly as fast as C, and often lower footprint than C. It's a really good language for "I really don't want to write in assembly, but there are no decent HLLs already implemented for my target"
It basically lets you string together a bunch of primitives and user defined functions using a stack. It is probably the only system that is useful where a single person can understand the entire language and implementation. You have to build everything yourself though.
I always wondered how Sun and Apple addressed this, as they used forth in the form of OpenBootPROM as a boot environment on various platforms. Very, very nice.
On the (much) lower end was the Jupiter Ace (https://jupiter-ace.com/jupiterace/). The Ace is a fun what-might-have-been where Forth beat BASIC for the '80s PC soul. There were commercial Forths for other PCs of the time (Apple II, Atari 800, TI99), but I guess because they were extra cost, they didn't become that popular.
in academia. Not outside.
In fact, I don’t think I’ve ever seen a .ps file that wasn’t hosted on a .edu domain (or other countries’ equivalents.)
I needed to do batches of mathematical and optical analysis of novel materials synthesized in their labs. This demanded conditional logic, statistical analysis, layout, rasterizing, and archival of results. A single PostScript file did all of the above, with handwritten and template-generated code that ran on the output device, typically a printer. Weird choice of language, maybe; I was a lone computing nerd in a lab of mad chemists. But for rapid prototyping and always having presentable results as the analysis evolved, PostScript ended up being really easy to use.
Looking back 30 years now, I think it was also impressive that it was device independent, readable and commented code, with numeric data embedded like a heredoc. I haven't seen those docs or PostScript code for decades but it wouldn't surprise me if they ran on a PostScript device or viewer today.
Anyways, commercial use of PostScript happened, if mostly internally. At that workplace it was a known and reasonable document format to distribute.
> in academia. Not outside.
NeXTSTEP utilized "Display PostScript" for both printing and display. Apple's Cocoa can trace direct ancestry to frameworks originating in NeXTSTEP. I am pretty sure this included use of PostScript in the display/printing frameworks as well, but do not have references to support that memory.
So, while '.ps' files are not often seen in the wild, as you say, a strong case can be made that PostScript was once (if not currently) widely used.
0 - https://www.oreilly.com/library/view/learning-cocoa-with/059...
1 - https://arstechnica.com/gadgets/2012/12/the-legacy-of-next-l...
I would argue that’s not widely used.
Apple's Cocoa can trace direct ancestry to frameworks originating in NeXTSTEP
Not sure ancestry counts.
Ah, fair point, thanks. I had forgotten about that.
My original claim is incorrect.
Similarly, PostScript was the control language for high-end printers back in the day, so it was used extensively as the final output format for print, even if it was rarely saved off as a .ps file.
No, that would be C. (In both senses of the word 'hacker'.)