Hacking for the latest and greatest Xeon CPUs feels a lot like Forth on small machines to me. Each core has only 256KB of fast private memory (L2 cache). Squeezing the working set into that memory means fast execution that is independent of the other cores. That is really worth spending some brain cycles on when optimizing for 36+ core servers.
The more things change, the more they stay the same?
I'm among those who have enjoyed the satisfaction of making my own Forth-like, and I've even used it only to find the same kinds of difficulties as author. Aiming for less is always a valid approach, but it's hard to reconcile with this era of software and the benefits of sheer magnitude. It might have been less true in the early 70's when software was less of an "ecosystem."
But on re-reading this for the n'th time I think the lede of this one is in the comments. Like any guru who is selling a "right way of doing," Chuck Moore has always had a business interest in selling snowflake Forth services of some kind. He, and other Forth followers, may well believe the pitch fervently. It is, at least, a relatively self-consistent ideology, and it discards the messy aspect of building any kind of institutional presence. But it also has a kind of dogmatic quality.
I also wrote my own Forth implementation, in 6502asm, back in high school. Was great fun and a great learning experience. I later wrote a Star Trek space battle game in it.
As for aiming for less is hard to reconcile - that's where you and the majority of programmers in the industry go wrong. You should have said "aiming for less is always a valid approach." - full stop.
My LMDB database engine is the world's smallest/fastest/most reliable full ACID transactional data store. The core of the engine is less than 32KB of x86-64 object code - it can execute entirely within a CPU's L1 instruction cache. It blows away other DB engines that are several times bulkier in size. It's only 6kloc of C. It does what it does precisely by following the Forth philosophy - do what you need, throw everything else away. http://symas.com/mdb/
Efficiency always matters, even today with CPUs whose L2 cache is larger than entire computer systems of 30 years ago. Efficiency always matters because all of these compute resources have a cost - electricity isn't free, and time spent is irreplaceable.
I have other ongoing projects in Forth because it can handle some cases easily that are awkward in other languages. (E.g., an ASN.1 parser for dynamically adding new syntaxes to the OpenLDAP server. Forth is the perfect tool for the job because it's inherently a language designed for extension.)
Forth has good affordances for compact solutions. Compactness is the is the single most important metric in robust solutions. Tractable, low inertia, retargetable and emulatable are all qualities that come with compactness.
One would do well I think to explore through old code bases and algorithms for stuff that ran well on those old systems. Because memory is plentiful doesn't mean we need to waste memory bandwidth or cache locality.
* [a handful of zero-comment and one-comment reposts I've elided]
This is a very popular repost—as it should be, because it's a very good and well-thought-out article, and a surprisingly well-reasoned and well-written example of the "meditation on a programming language" genre of blog post—and each of the past comment threads is also worth consulting.
That's interesting. I am looking for things to write in my new language. The itch was to make a Forth, coming up with an application of it is the next problem.
FYI, bitcoin's programmable signature language is Forth. Variants of Forth are used on many NASA spacecraft and rovers. Forth is doing quite well, thank you :)
I know. But I feel that it still has not reached anywhere near its potential and I'm not sure if it ever will.
First time I worked with it was in the 1980's, I've been only an observer since then but the bug never left me. It's a language for the equivalent of software jewelers.
I used Forth professionally in an industrial single-board computer product in the late 1980s. But I haven't see it "in the wild" since, with the exception of the occasional mention in spacecraft control.
At one period, there was a lot of interest in stack machines; IIRC, there was a BYTE issue that either covered it in many articles, or was dedicated to that topic. Can't remember the month and year.
The more things change, the more they stay the same?