I have been using Forth for over 20 year now, and still find it a valid programming tool. Why? The answer certainly is not simple and for those not familar with Forth, will require some explaining.
I guess the best place to start is with a simple but quick review of Forth, something more than just another programming language. It all started with Chuck Mooore, when he was doing work for an Astronomy Observatory and needed some tools for programming multiple systems. He wanted something that would work across different hardware and software systems and yet had the performance of assembler generated programs. He achieved this by creating Forth, which is something more than just another language.
Forth works by creating in code of the machine it is on, a virtual system or CPU if you will. The "virtual" system is a stack oriented, reverse Polish notation system. By that I mean an architecture of a CPU/System that has stacks for loading and manipulating your data. No matter what actual CPU you are using, you program as if your system is a stacked based CPU. The virtual system is the same on all hardware platforms, and thus programs written on one hardware will work on another, since they both have the same virtual system.
There are several places where this concept is used and you are not aware of this as you use it. The most common place is java - the down and dirty low level coding is forth. You will not find anywhere "Forth" mentioned by name, but reading the java specifications for it's kernel, will be a trip down Forth's internal design. Sun developed this after years of using Forth for their boot system. A look at Sun's diagnostics and boot ROM commands strcuture is listed as Forth instructions. So boot up a Sun system and your using Forth.
Forth programming is usally done from the end closest to the hardware and works backward to the overall GUI or customer interface. Forth is still strong in embedded systems where talking to hardware is common. Hardware can represent the most difficult asspect of embedded programming and thus when working with some special I/O interface issue, a Forth programmer normally starts there. "words" are the "little modules" or snippets of Forth code that combined produce a overall program. So when working with hardware, a Forth programmer will normally resolve the I/O interface issues, by creating and testing the I/O words that talk to the device.
For most engineers, the hardest part of embedded programming is the actual I/O code, the rest is easy. Forth allows you to develop and test your code first, getting the hard parts over quickly and then moving on to the simple stuff knowing that the data your seeing is the real data. This makes programming hardware easier and quicker.
For embedded programmers this "warm and fuzzy" knowledge that your code has been tested and works makes for quick and fast development cycles. Forth has such a simple structure and layout, that many devlopers "roll" their own version of it. You can create your own Forth without long years of study. Several versions have even been done using "C" coding on both Windows and Unix systems. A shell with Forth like structre has even been done. I use one version for working on SiLabs 8051 embedded devices, which is called MyForth.
I did not write MyForth, Charley Shattuck did it for his own personal projects. Over a number of years of building and using Forths for embedded projects, he wanted a version that created 8051 assembler macros based on Forth concepts and words. Although your doing 8051 assembler like instructions, your also using Forth commands to debug your results. It is faster than straight assembler, produces really compact code like an assembler, and yet has many of the normal Forth words for debugging and testing that you need for fast development.
I took over a project for Charley and was up and running the code in a few days. I found it easy for me to understand, since I have done both assembler on the 8051 and Forth. I found a few issues and some minor fixes, but for the most part, Charley's code has been right on. The entire toolset is very efficent, with a compile like action that turns the forth screens into 8051 machine code. The toolset has words for loading to SiLab devices, working from a windows or Linux terminal as if you were inside the device. This working "as inside the device" is one of the great features of the embedded Forths. Your talking to the real devices and getting real data - no emulators here.
I can not stress how great it is to be seeing the real data moving back and forth in real time. While testing my routines, I created words that dumped sections of memory where data was buffered. As I had data moving between 6 separate systems running similar code, I could see each device do it's read and store it's data. I could connect using another terminal session with another device and test the code by adding or changing the data in it's buffer. The results would pop-up on the main systems memory. Very quickly I could see what some changes did to shared data and how the overall system would react.
I use Forth because it just works. There is no lock in to some company, although you can buy very good Forth systems from, Forth Inc. that have long pedigrees. You can roll your own, download many variations, and get complete working versions from the internet. With some book time, practice using Forth on the PC (gforth for example), and then creating your own, you too can become a Forth programmer. It is still possible to do difficult programming tasks without spending large amounts of cash.
Give Forth a try, you might be surprised at how well it fits your style of programming better than all those other very expensive compilers.