I was about to write something encouraging people to learn FORTH, but after some consideration, I started having second thoughts.
I really like FORTH, but I think it promotes some subversive/extreme views which can sow seeds of discontent (or at least it did for me).
Much of my dissolution with the business of programming can be traced back to learning FORTH. It showed me just how much is possible if you optimize for simplicity, and it encouraged me to ask the question: maybe the trade-offs in programming aren't necessary i.e. we don't need to trade complexity for functionality? Now that I have some distance, I was/am probably wrong, and they are necessary, but this question still bugs me.
After learning FORTH I enjoyed my job less. I no longer had the patience I once had for the build tool breaking the umpteenth time, or dealing with yet another poorly documented and barely working REST API.
To be fair, this probably wasn't FORTH's fault. Waning enthusiasm may happen naturally as you gain experience in the industry, but it certainly seemed to accelerate the process.
Anyway, FORTH is awesome, but maybe you shouldn't learn it.
You are correct: there is no need for the huge complexity we see in modern applications. However, such complexity exist because companies want to create standardized software, with readily available components, based on mainstream technology pushed by big corporations, written by AVERAGE programmers. Because of this, everything has to be watered down, created to the minimum common denominator, so that the work force becomes just another piece in the system that can be readily replaced. Programmers like Chuck Moore are viewed, in this environment, as a problem, not as an asset.
If you want to take the plunge, jhbadger's recommendations of starting FORTH and thinking FORTH are both great. Starting FORTH covers the language itself, whereas thinking FORTH deals more with the philosophy of FORTH and programming in general.
If you really want to get serious, writing your own FORTH, which is a kind of right of passage in the FORTH community, is a good way to learn. While somewhat controversial among FORTH purists (for reasons I don't entirely understand), I would recommend Richard Jones' jonesforth as reference for this: https://github.com/nornagon/jonesforth/blob/master/jonesfort...
I have programmed for years with Forth and I really think it was not a wasting of the time for me. I had very interesting Forth-related job, I became more proficient in PL design/compilers-related things because of Forth.
Alas, I don't think that Forth is very relevant today in the professional SW development. But it's still a great teaching tool. I would like to see, for example, a PL design course where first pages would be about META II and Forth implementations.
Modern programmers need more examples of beautiful, miniature software architectures. Tools like Forth are especially interesting, because they show us that even a single developer may do great handcrafted things and he doesn't need to depend on third-party tools, IDEs, frameworks for it. Charles Moore haven't invented Forth from scratch, he "synthesized" it from some really great ideas of 50-60s, like Lisp, B5000, APL etc. Moore took only those parts, which were good components (simple to implement, understand, combine) to build his own independent tool. N. Wirth uses the similiar approach, by the way.
Maybe today we could repeat the same synthesis/minimisation process with some modern ideas/technologies to create a beautiful tool for a modern programmer - lone craftsman. Or maybe the whole "tool-making" (see Whole Earth Catalog etc) movement is just a thing from the past?
META II appears to have been a DSL that used a more straightforward equivalent of BNF and transpiled/metacompiled it to a RPN-parsing VM. It was built around 1963.
I wonder if Forth is still used today for some applications of if anyone has stumbled over some production Forth code lately.
For me, Forth is a language in which you can easily shoot yourself in the foot. One element more or less on the stack and you run into strange problems ten functions later in your code.
But what I especially like is the enhanced naming of "words". You can choose "variable" or "function" names such as "a->b" instead of "a2b()" or "a_to_b()". Or "@X" for "GetX()" and "!X" for "PutX()".
People still use Forth for embedded work (there are two major Forth vendors with a definite customer base). I'd say it's quite rare in the server realm, but I know of one company doing storage stuff that has a Forth written on top of C running on FreeBSD and their engineers really like it as they understand the full system outside of the C compiler. Who understands even 25% of C++?
The Philae spacecraft [1] (2014, first craft to "land" on a comet) was controlled by a couple of Harris RTX2010 CPUs, which are radiation-hardened CPUs that execute Forth words natively.[2]
Apparently one of the "features" motivating the decision to use Lua is "it's interpreter is very small (~240 KB)," which sounds like a dumb joke when you consider Forth's footprint.
if I understand correctly, you're the author of decompiler for StarFlight game. The most famous game written in Forth. And maybe most popular piece of Forth software of all times. So I think you surely know more about Forth than many modern Forthers do :)
Sorry, if I reveal this link too early, but this is very impressive work of you and StarFlight game/engine really deserves more popularity!
Yes, that's me. I decompiled it. And it is the most fun reverse engineering project you can imagine. Expect the unexpected. There is a Forth interpreter hidden in the code and some of word names are still in the code. So you can produce almost readable code.
When I started I had not even a clue what Forth is about. I read the first articles about Forth long after I started the decompilation project.
I still have to write a long text in the README, why the code of Starflight is almost as awesome as the game itself. Then it is ready for publish :-)
I would say, that I know about this special dialect more than most of the other Forthers. I have not written more than a few lines of Forth myself. But I have read a lot of Forth code.
I still use a version of FORTH as an embedded debug tool, have done for several different CPU architectures over the years. I wrote some extensions that help to offset the "double edged sword with no handles" danger, such as local methods, call/return prototypong (basically formalize=ing the conventional word definition comment, which I also snag as is into definitions as a help string) that garuntees stack frame handling on entry and exit. Also wrote an auto-translater for C wrappers of function calls and struct definitions to get symbolc interaction with the code being debugged. Really speeds up behavioral debugging (Real Time systems have to be runnig to diagnose, not halted and flayed open on the operating table like breakpoint debugging does).
The IBM 1130 was a great little machine. I wrote a high school course scheduling program on it in 1969 at the Universidad de San Andres in La Paz, Bolivia. Highest university in the World (12,000 ft).
I really like FORTH, but I think it promotes some subversive/extreme views which can sow seeds of discontent (or at least it did for me).
Much of my dissolution with the business of programming can be traced back to learning FORTH. It showed me just how much is possible if you optimize for simplicity, and it encouraged me to ask the question: maybe the trade-offs in programming aren't necessary i.e. we don't need to trade complexity for functionality? Now that I have some distance, I was/am probably wrong, and they are necessary, but this question still bugs me.
After learning FORTH I enjoyed my job less. I no longer had the patience I once had for the build tool breaking the umpteenth time, or dealing with yet another poorly documented and barely working REST API.
To be fair, this probably wasn't FORTH's fault. Waning enthusiasm may happen naturally as you gain experience in the industry, but it certainly seemed to accelerate the process.
Anyway, FORTH is awesome, but maybe you shouldn't learn it.