I hope you don't see the Forth I wrote in Python ;)
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.
Chuck Moore wouldn't consider ANS Forth a .. Forth. There is something to be said about the spirit of Forth as expressed through Moore and his ideas versus the sterilized, industrial or more elaborate offshoots. For us loyal Moore acolytes, things like 8th and even Factor are abominations.
He'd likely consider it A forth instead of THE forth as Forth INC and some others wanted to be.
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.
Can you expand on this line of thought. I have a gut feeling you are correct based on what I’ve read from Moore, but if you can summarize why he would think this I’d like to see it distilled.
"I had reservations about ANSI. I worried that it would be a disaster and not merely a dubious advantage. All of my fears of the standard and none of the advantages of the standard have come to pass. Any spirit of innovation has been thoroughly quelched. Underground Forths are still needed. I said I thought the standard should be a publication standard but they wanted an execution standard."
"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."
The impression I've always gotten, admittedly second-hand, is that Chuck feels a Forth and its hardware should be designed at the same time, as an integrated solution.
Tune the hardware for its Forth, and vice versa, instead of one Forth to rule them all.
Can someone add more context here? When ever I read about forth it always seems like there's some missing context that isn't mentioned any where. Who's Ron? What's the 8th language? Do these things have more sugar?
Ron Aaron, who currently lives in Israel, is author of 8th, which is based on Forth (i.e. 8 > 4). I think that he is just called Ron due to being so well known in the Forth community.
He is the author of the earlier Forth implementation called Reva Forth also.
Yes, actually, as Moore's initial FORTHs were written for machines that only had a single case. That said, the above poster isn't quite on the mark, either.
I think that's a charm of HN that people are continuously discovering the niche languages of Forth, Haskell, APL, Common Lisp, Scheme, Prolog, Smalltalk...etc.
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.
you're right that im sounding like the for sure. but, someone seeing something niche for the first time often has gems of insight within the naivety as well to give credit where it's due - so it's worth prodding each time or giving old hand tips like elmers
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.