I've been putting little bits of musings on FORTH, as I use the fig-FORTH implementation on the Atari 800 to write a graphics demo that I am working on.
Because FORTH isn't a language, it's an environment with a way of life radically different than anything else out there, It has seriously caused me to reexamine my perspective on solving problems through computer programming.
I've spent the better part of 25 years writing computer programs. At first, it was me, as a kid, looking around this crazy world of the computer (at this time, an Atari 800), trying to see what I could get away with. I progressed to other languages, other processors, other systems, eventually entering into the workplace as a professional programmer, not forged from the halls of academia, but from my own autodidactic experience.
Along the way, I explicitly exposed myself to a variety of environments, both in play and in work, because I am genuinely curious, creating things interests me, and tools interest me because tools allow me to create, they allow me to visualize what is going on in my mind, and to do what I love to do best, to solve the problem. I use a healthy set of these environments that I've learned, on a daily basis, ranging from system languages like C, C++, Objective-C for application development, to PERL, PHP, Ruby, Python for web or small user facing applications, to even specialized languages like Erlang, which is unparalleled for distributed application development.
And yet, I am very disconcerted with the state of application development today. We create large, overly generalized programs, on top of layer cakes of generalized programming and operating system infrastructures which serve ultimately, to service themselves, with the side effect being that you, the user, are able to use the system, for....whatever you may generally want to use it for, so long as we have an App to do that. This hypergeneralizaton exists, because we are taught to create general solutions to problems; try to solve as many derivations of a problem that you can think of...
...but we never think of everything, do we? Somebody else will always want another feature.
So over time, these features aggregate into software, and, instead of writing software to solve the problem directly in front of us, we combine software off the shelf from different sources. A programming toolkit here, a physics library there, and we feel that these things get us to the finish line, faster. Sometimes, they do, but at a price. As Chuck Moore once said, "Programmers do not write megabytes of code. They borrow kilobytes of code; do this a thousand times, and you have a megabyte of code."
But the problems do not end there, in fact, they often start there. Bugs are everywhere, and it is a simple fact that none of the code a programmer will be using is bug free. This does not count the program code that a programmer writes himself. So therefore, a programmer ultimately pays for mistakes he isn't accountable for. This is a fact of software development that we take in stride, but often fail to factor into many design decisions when we make our assumptions on what tools to use to solve the problem. It's not just you developing your software, it's the rest of your team, the team that created your software toolkit, the team who created your programming language, ad nauseam; your programming team is now indirectly hundreds to thousands of people, most of which you can not contact or collaborate with, the advances in collaborative software development notwithstanding, the simple fact is, we do not live in a world where we can fix everything we ourselves did not make.
It is in this climate of making large balkanizing pieces of software, that I find myself introspectively thinking, what can be learned, and from where?
And in this context, what am I learning from FORTH?
I will stop here for a moment, and stress, that I do not see FORTH as a panacea for all of the problems of programming. However, it does espouse a great deal of good ideas which should be evaluated when you are looking for ways to solve the problem at hand.
FORTH is teaching me to solve the specific problem at hand. In FORTH, you do not write programs, you create vocabularies. It is in this context that I find FORTH's approach truly brilliant. Every problem must be able to be understood. We as human beings talk about problems, we have words to find if the problem exists, to describe the problem, to find approaches to solve the problem, even to find if our approach is the right one for solving the problem.
Even the largest of problems may have 500 to 1000 words at most, and this approach applies to everything. You may have words to manipulate an image, DESATURATE, COLOURISE, RETOUCH, at the same time, in an automotive factory, you may have words like ATTACH, ASSEMBLE, or CHECK. We take these words, and assemble solutions to a given problem at hand, and regardless of what anyone may tell you, all problems are specific. We often spend too much time, trying to solve specific problems using tools that are far too general for the task, and thus we find ourselves trying to deconstruct the problem and reassemble it in a generalized context, often losing subtlety or nuance that may be required to solve the problem in the first place.
FORTH is not a language, but an environment for making vocabularies specific to a given problem. These vocabularies are then assembled into useful tools for an intended user. Thus by this very definition, a concept of a "standard library" that you would often see in other languages like C is both moot, and superfluous; when it becomes easier to make your own tools to solve the problem at hand that completely fit what you're doing, why would you bother with using a set of standard functions?
FORTH has also shown, that as an environment, it has everything needed to utilize the hardware at your disposal, to solve the problem at hand. There are words for reading and writing to memory, to disk, to graphics hardware, to audio hardware, and more. Because FORTH provides this complete environment, and you are able to create precisely what you need quickly, you do not need this intermediate layer of an operating system to try and make sure things can talk to each other. The individual pieces that talk to peripherals are simple, and map to simple concepts within the language, so the usage of said tools are simple.
The price of all this, is that you, the programmer, live in this place that you've created, alone. But when you can create exactly what you need, exactly when you need it, quickly, is this a bad thing?
I am still thinking it through.