When he told about that in the Fireside chat, I was really puzzled at first. I think Chuck was just being the eccentric guy he is was telling a cautionary tale for the shock effect, in a kind of dark humorous way. Also the guy is 88 years old now, so it's somewhat understandable when your energy levels are extremely low, both physically and mentally. With the little time left of your life, you wouldn't want to spend it fixing some random breaking API change from Windows.
I imagine his ColorForth has been more like a retirement hobby for the past decade. He used to screenshare from his ColorForth during the calls, but that could have been overcome more easily with a VGA->HDMI capture dongle and running ColorForth natively. And I doubt he needed the TCP/IP stack directly on his ColorForth based on what he shared so far. So I don't see the point of porting over to Windows to begin with. After all, ColorForth runs more easily on bare metal, on UEFI/BIOS or whatever, so it didn't ever need BitBlt to draw things on screen for sure. The guy built a ColorForth processor, and the devkit from GreenArrays has a VGA connector, etc. So I believe Chuck was on to something else when he shared that, perhaps just to stimulate thinking, but people tend to take things at face value.
On another note, ColorForth (or FORTH for that matter) is not meant to be owned/controlled by him or a committee. So it's not like he was maintaining it. AFAIK, he didn't even endorse or support FORTH standardization efforts, and somewhere said it's silly. I also find it interesting that in his book A Problem Oriented Language, there is not a single mention of FORTH even once (except in the preface, and in his bio) yet he describes FORTH in the book, just calls it as "A Problem Oriented Language" without naming it. So it's almost like FORTH doesn't exist. It's just an idea. And what doesn't exist cannot be broken.
Jonathan Blow is famously working on a programming language for games, called Jai; but he never mentions it by name when he streams. I think his concern is similar to Chuck Moore's: that the language should exist in the abstract, and when you start nailing it down too tightly by naming and standardizing it, you create problems later when you want to change those things. It's clay he can mold, something to experiment with. How much more true is that of Forth for Chuck.
The strange thing is that imho, as in many other things around language design, Scheme sort of had the right idea. I like having a well-defined semantics with wide agreement that I can write programs on. The fact that the Common Lisp standard is practically unchanged since the 80s, and the core of Ada has survived with only significantly useful extensions added on in later standards, is real neat to me, compared with C++0x/1x/2x being a completely different beast than the C++ of the 90s, and Rust and JavaScript undergoing constant churn. The RnRS process, historically, was all about defining a core that implementers could all agree on, calling it Scheme, and then letting implementers fuck around on top of that basis. R6RS and R7RS were controversial precisely because they deviated from this; although R7RS tried to please both the "small core" camp and the "Python with parens" camp. Which is kind of like trying to please both classic Sonic fans and post-Adventure Sonic fans.
But yeah, I think Chuck's advanced age and a general feeling of "I'm too tired for this shit" were the primary reasons for making that announcement. And you may be right, he may be just telling us not to get too attached to a particular artifact but to embrace the idea of Forth. Maybe the real ColorForth was the friends we made along the way. May the Forth be with you, my friend.
I like that the article mentions Manfred von Thun, his iteration over FORTH was a joy to use, spent many hours writing code with it. It's a breeze. It was the true mirror reflection of Lisp in FORTH, and helps one reap the benefits of concatenation without getting bogged down in the nitty gritty details as one often ends up dealing with in FORTH, at least in the beginning until a mature vocabulary is built for the problem.
As I'm still so far behind in the LLM tech in terms of how it works, so I don't know what to think of this article, but my experience with using them as a user to generate FORTH code was often a failure. They just can't get it right, most likely due to lack of training data. OTOH, I also found writing FORTH as a human way more difficult than any other language I used, even more so than hand written assembly. But it amortizes itself fairly quickly, and things get a lot easier after a point (what I called earlier as vocabulary maturity). But more importantly writing FORTH code is way more fun and satisfying to me somehow.
It may look more high-level than something like C, but it is actually no more high level than a macro assembler with registers eliminated. As there's no syntax tree, essentially every word that is parsed from the input stream is replaced with a subroutine call. So the resulting FORTH code is nothing but a series of subroutine calls.
In my experience quite often writing in assembler is easier than FORTH unless you have a strategy and self discipline, which when acquired makes one a whole lot more productive than using assembler, and arguably more so than a high level language. There're no pointer arithmetics, no rudimentary type checking, not even an array type (you have cells and addresses). There is nothing that throws an error except things like stack over/under-flow checks, and if you are lucky your code will crash. If not debugging can be tricky. Stack imbalances won't be reported/checked for you, there is no bounds checking for anything (not even structs). But there are conventions/strategies to prevent these kinds of bugs from happening that one needs to either discover for themselves, or find out in books (the book Thinking Forth helps, but is not enough I would say).
Working with the stack can be more difficult than with registers, although the latter can be easily simulated with variables, which is often frowned upon. But words like CREATE ... DOES> enables meta-programming that helps with generating code with code, and makes it quite powerful, but can make your code complicated to reason about (see the concepts of compilation vs. execution vs. interpretation semantics described in ANS Forth).
In the end the appeal of FORTH for me is in its "simplicity" (but nowhere any ease of use as it requires mastery of laying out code in memory as you would do in an assembler without any help from the language itself), its overall philosophy (see Chuck Moore's A Problem Oriented Language) on focusing on the nature of the problem rather than thinking in terms of the tools/language given to you (build a "language" for the problem), and providing solutions with as minimal "cruft" as possible.
It's great fun. The environment is pretty mature by now and for being a niche language there's lots of public code to study.
I'm not sure but I think John Benediktsson is still the maintainer, and at least a few years ago he was active in their Discord server. His blog is a very good resource. Some people are doing AoC:s in Factor, also worth a look.
> Working with the stack can be more difficult than with registers, although the latter can be easily simulated with variables, which is often frowned upon
Yet every time I hear experienced Forth developers recommending to use more variables, and that newbies tend to eschew them, making the code much harder to read and understand than it is necessary.
You become a true Forth programmer once you go past the code golf and stack juggle phase.
Anything that you say is missing can be added. I'm no expert but when I had some confusion about the stack I would create a word that did something in a balanced way, test it quickly, and use that word instead to build on. Forth makes it easy to climb the levels abstraction quickly.
The method that it uses to interpret/compile a word varies by implementation. Subroutine call is just one of them.
For sure, it can be extended indefinitely. It's good that you made that clear. You can add a C compiler if you like (see Dusk OS) even, or a generic BNF parser generator (see Bradford Rodriguez) into "the language". Anything that you devise for code correctness, and static analysis can be added. My points about the lack of these language features were towards the previous comment about FORTH looking "more high-level than C". These are definitely major shortcoming for an inexperienced programmer to be able to do anything reasonably complex in FORTH (similar to using assembly).
> ... I would create a word that did something in a balanced way, test it quickly, and use that word instead to build on. Forth makes it easy to climb the levels abstraction quickly.
I would say any programming language with functions provide the same ease by that definition. That is, in each you can write a set of functions, than use them to compose higher level functions ad infinitum until you create a DSL as essentially a collection of functions for your problem space. Although doing so in C-like languages syntactically it may look more like Lisp than FORTH. In FORTH it looks more concise, and reads left-to-right thanks to it being accidentally a "concatenative language" with point-free notation and combinatory calculus roots. A great example of this being formalized is Joy by Manfred von Thun.
So I think what makes FORTH unique is more of the philosophy around it (again, see POL book by Chuck), which is a kind of zealous struggle for simplicity, but not easy, and keeping the problem in focus and not ignoring what's inside the boxes you build upon. You could say it's a panacea for yak-shaving if done right. Concrete examples for what FORTH does away in its search for simplicity and avoidance of yak-shaving, here are a few:
- no in-fix notation or ASTs: computers understand post/reverse-Polish by default by virtue of them being a stack(/register) machine, the programmer can do this work without major difficulty,
- no filesystem: blocks and table of block indices are enough most of the time,
- no floating point: fixed point is good enough for most problems,
- no classes, arrays, structs: you can build your own constructs suited for your problem as they are needed, there is no one size fits all solution,
Etc. The list goes on. Some of these are added into the so-called standards, but some argue trying to standardize FORTH defeats itself.
> The method that it uses to interpret/compile a word varies by implementation. Subroutine call is just one of them.
I used a vague terminology there, and should have clarified by saying "regardless of the threading model". What I meant was that effectively the FORTH source compilation is a one step pass that converts string tokens into series of "subroutine" (conceptually) calls that map 1:1 with the source code (homoiconicity); direct/indirected threaded, token threaded, or subroutine threaded all effectively is laying out/interpreting a series of subroutine calls, including those in FORTH CPUs like Harris RTX or GA144.
There's a backlash to this called Old School Renaissance (or Revival, short: OSR) that tries to bring back high-mortality, "you play the world, not the characters" type of gaming to D&D. The character based and scripted story driven D&D was not always a thing. Some argue it started with second edition (which came 15 years later). Some good examples of such can be seen in the Judges Guild published material from 1975-1979 which focuses on procedural world generation and emergent storytelling rather than scripted characters with backstories and plotlines.
This strikes me with connotations from critical and literary theory of social sciences. Software architectures begin to resemble social structures such as governing bodies in a country, hierarchies in an organization and the protocols with which they implement interaction between human agents. Eventually the two might intermingle in such a way that the recent discourses may affect what will happen in social domains in the future. In software, too, there's already an ongoing almost ideological rather than practical conflict between the two ends of the cathedral and the bazaar frontiers for a long time. Gladly and hopefully the software culture is going in the bazaar way.
> Gladly and hopefully the software culture is going in the bazaar way.
That is, towards chaos, inefficiency and fragmentation? :P.
In software world, we pride ourselves of having at least some semblance of sense in the discussions about approaches and methodologies; the cathedral/bazaar model is not an evil/good model; both approaches have applications for which they're the best.
Right, it does not seem to be a raycasting algorithm, and the author mentions of it in the youtube comments that it's a "rasterization" meaning perspective projection of textured polygons.
I like the part where he mentions why using a traditional GUI tool is more difficult than using an expressive language with basic syntax.
"But in photoshop, I instead am relying on the problem being solved externally ("ok, how can I find the right menu that deals with this kind of operation? what's the word the designers of photoshop used to describe this... I hope if I google it in plain text it might link to a forum post or something of someone with the same problem?")."
This is valid for most cases when GUIs are harder to use than a CLI with syntax.
I imagine his ColorForth has been more like a retirement hobby for the past decade. He used to screenshare from his ColorForth during the calls, but that could have been overcome more easily with a VGA->HDMI capture dongle and running ColorForth natively. And I doubt he needed the TCP/IP stack directly on his ColorForth based on what he shared so far. So I don't see the point of porting over to Windows to begin with. After all, ColorForth runs more easily on bare metal, on UEFI/BIOS or whatever, so it didn't ever need BitBlt to draw things on screen for sure. The guy built a ColorForth processor, and the devkit from GreenArrays has a VGA connector, etc. So I believe Chuck was on to something else when he shared that, perhaps just to stimulate thinking, but people tend to take things at face value.
On another note, ColorForth (or FORTH for that matter) is not meant to be owned/controlled by him or a committee. So it's not like he was maintaining it. AFAIK, he didn't even endorse or support FORTH standardization efforts, and somewhere said it's silly. I also find it interesting that in his book A Problem Oriented Language, there is not a single mention of FORTH even once (except in the preface, and in his bio) yet he describes FORTH in the book, just calls it as "A Problem Oriented Language" without naming it. So it's almost like FORTH doesn't exist. It's just an idea. And what doesn't exist cannot be broken.