Tiny FORTH from scratch in 1 week (bootloader-based Arduino UNO, 2K of RAM)
thanassis.space
thanassis.space
Other than that looks like you had fun but I can't stress how much more fun bootstrapping a Forth directly on bare metal is.
In all seriousness I agree that Assembly and C are probably the best choices for putting together a serious Forth for most work.
Ron's commercial 8th language (very much a Forth) is written in C++ though and that allows him to add in support for a lot of common enterprise needs (ODBC, SQLite, AWS, Android/iOS, Bluetooth, GUI, a bunch of file formats...etc etc) that you almost never see in other Forths. So C++ is a blessing and a curse.
"There is a problem that I first saw at iTV. It was the first time I have been in the presence of a Forth project that I wasn't contributing to. I saw how other programmers use Forth. They don't always get it right."
"Besides stacks plus colon definitions there is something else. There needs to be another book written about writing good code."
-- Chuck Moore, 1997
He is the author of the earlier Forth implementation called Reva Forth also.
The website is https://8th-dev.com/ .
Tune the hardware for its Forth, and vice versa, instead of one Forth to rule them all.
Keep in mind that Forth as Chuck envisioned is amazing, but entirely impractical for most of us. He had the luxury of being a genius AND working on projects where he could design an entire solution from hardware through software. I'm not aware of many of us that are in that same situation. Most of us will be on Windows, Mac, or Linux and have to work with common file formats like JSON, .CSV, .XML, common databases...etc. Moore never had to do any of those tasks, so his extreme minimalism has to be understood in context. My boss isn't going to give me 5 years to first design my own chips to run the software for a problem we have now. I'm sure the final result could be 4x-10x less code, but I could have also just finished the code in a few weeks by itself and then moved on to 20 different projects in that same time. Slapping components together like modern software engineering teaches isn't romantic or as lightweight as what Chuck does (MB vs kB), but it is likely the most efficient from a business perspective. If anyone brings up technical debt, I'd rather try to figure out how to port an old pascal program written for DOS than something Chuck wrote on completely custom hardware in his own custom built language for the problem. That doesn't mean I don't respect, am not awestruck, or can't see the sheer elegance of what he's done. I just don't think it's for those of us towards the center of the bell curve.
Alan Kay (of Smalltalk fame) also has a good talk on software bloat/complexity where he shows that Microsoft office has like 10x the lines of code than the entire smalltalk OS on the computers his group designed. Their approach was very different than Moore's, but had some common themes.
I could never get into Factor (despite trying a bunch), but have found using 8th to be pleasant enough. Sure it wouldn't work for Moore, but it plays very nice in the enterprise and hobby spaces. It is concatenative like all Forths and uses the stack for everything. I like the fact that there are built-in words for pretty much everything I need without any kind of class bloat. It is not even remotely an ANS forth I don't think.
I went through a phase where I thought each one of those would be a solution to my problems and give me a competitive edge. That never came to light as I never felt that they gave me much more power than what I already had available with modern scripting languages. So in a way, it was a waste of time, and in another way it allows me to see the breadth of the options out there. It also makes me sympathetic to those also taking the journey and excitedly posting related articles.
When a 16 year old getting into cars posts about a 69 mustang on an automotive forum, I wouldn't expect the older crowd to role their eyes and say "ughh...this again". In the same way, digging into Forth is a rite of passage for many.