Understanding What It's Like to Program in Forth (2008)
prog21.dadgum.com
prog21.dadgum.com
I think Forth can be useful to learn today, at least to stretch the mind to realize that not all programming languages have to be variants of Algol. It can also be a fun game as suggested by the article. I have enjoyed fiddling with it, including re-implementation of the language, and I can recommend it to others as a fun Bazaar toy. In addition, the book Starting Forth is amazing and still worth reading, because it shows that complex topics can be explained clearly and with humor.
However, for actual production use, I do not think the Forth programming language is ever going to return to widespread actual use. Our computer systems are far more capable, and if you have to program a tiny of computer, you would use a larger computer for programming instead of trying to fit your development environment within a few K of RAM. Nowadays the big constraint is development time, including the time to develop the resort code the time to read existing code to modify it. Forth doesn't do as well by those measures. When something is trivial another languages, but it's a puzzle to solve in Forth, that is not a good thing. That does not mean that Forth is a bad programming language, it is a very good programming language, but it is designed and optimized for a situation that is increasingly unlikely.
He uses Forth.
I watched him write a tiny forth kernel in a Kb of RAM or so, then run a dictionary through it to get a brand new CPU bootstrapped in what could be as little as a day.
Very impressive. That system got an assembler / disassembler used to make new system words and other words fast.
Modifying a Forth system, and I say that due to how Forth is really an environment that becomes capable of the application, depends lot on who made it and what one can know of their thought process.
What I thought interesting about this guys approach us a fairly pure Forth is used to bootstrap. Then one that is a lot more comfy gets made for the longer get term.
Once that stage is reached, and there are good tools, assembler / disassembler, monitor, word viewer, etc... Forth can be made less of a puzzle.
One can even add other syntax, an interpreter, if desired.
The product is more like a dev system, self hosted and capable.
I find it all compelling, but as you say, much different.
And have been taking those steps myself.
It works how getting Linux onto something does. The benefit is much smaller initial resource footprint.
I think most people prefer cross-compilation on small systems for professional use.
If you are doing it as a hobby, ignore everything I just daid. I see the fun in it, and applaud it. Enjoy!
Counter question:
Given the obvious savings, why not invest some of that into a second person to retain a clear advantage?
Do what most people prefer and get results that most people get.
There are other ways to success.
Absolutely. I've played with Forth many times, and enjoyed it. But when it comes to building systems that people pay to develop & maintain, I haven't found any use cases recently. No doubt there are some, but I suspect they're much less justifiable today.
It's a big world out there. Guess I shall reply with same.
In a typical corporate environment, yes. Your thoughts ring true.
It is a big world outside that scene, and many playing there can benefit from Forth. That is the utility. People who grok Forth flat out solve hard problems like no other.
Tool for that toolbox, essentially.
No not my cup of tea but I guess other people put it to a good use.
There are other books about Forth, but this one is really its own thing :-).
I used Forth professionally for well over a decade. I made truckloads of money with the end products. One of the companies I was involved with, which was 100% Forth, sold for just south of $20 million USD.
Customers don’t go to Home Depot to buy drill bits. They go there to buy holes.
The world could not care less if solution A was coded in C, solution B in Forth and solution C using a keypad to enter machine code. All they care about is the best solution at the best price.
I have always felt that the distinction between experienced and less experienced engineers is that those with experience focus on what matters —delivering value to customers— while the less experienced folk needlessly burn time on theory, languages, code editors and other stuff.
25 years ago I made over $500K with a small 6502 embedded system used to help control lab equipment during cancer research lab tests. I made this box with a 6502, a couple of UARTS, a 2x16 LCD display and four pushbuttons. The box sold for $2,000 each. Sold piles of them. The code was written in Forth. The buyers could not care less. Neither did I frankly. I love Forth, but, at the end of the day, it’s just another tool.
Customers want holes.
At one level I entirely agree. But at another, when it comes to the holes they drill in the bathroom to hold the toilet roll, and the holes they believe were drilled in the pickle fork holding the wing onto the 737-max, they feel very differently about the holes. The first one, They don't much WANT The toilet paper falling off, but its kinda meh. The second one, being told uncle fester was given a hand drill from the barn and told to ream 'em good and deep doesn't fill anyone with joy.
Customers want the right kind of holes.
If you are in the business of delivering holes for aerospace customers your focus should be on delivering the kinds of holes they need. At the end of the day, they still only care about holes. That’s what they are buying.
Most customers using a software-based product could not care less if it was created using vim and python or toggle switches and machine language. They are after the solution to a problem; that’s all they care about.
Our customers don’t buy language features, compiler flags, stacks, lists, dictionaries, classes, variables or functions.
They are looking for a hole.
So what? The customers of Forth are computer programmers, not carpenters.
And I, for one, go to Home Depot to buy drill bits (not holes).
If I wanted to buy holes, I'd hire a handyman.
You are missing the point, which, frankly, is exactly the reason business types don't want engineers anywhere near customers. It took me lots of professional coaching and years of experience to stop seeing our products as an engineer.
> The customers of Forth are computer programmers, not carpenters.
Unless the activity being conducted is an academic pursuit, the tools (languages, compilers, editors, etc.) are utterly irrelevant. The customer isn't the programmer. The customer is the one exchanging something of value (typically cash) for a solution to a problem, and usually something that delivers value beyond the mere cost of the thing. The customer is NOT the programmer creating the solution. Far from it. Any software engineer who honestly believes they are the customer ought to be fired as quickly as possible.
> And I, for one, go to Home Depot to buy drill bits (not holes).
The only way that would be true is if you purchase drill bits for display and never use them. If they are used, even once, their purpose is to make a hole.
In other words, the solution one is seeking isn't "I need to own a drill bit", but rather "I need a hole" or "I know I might need a hole in the future".
> If I wanted to buy holes, I'd hire a handyman.
Only if you'd hire a handyman to just come over, drill a hole and go away. Which, of course, would be a very rare and even bizarre use case.
Again, this is missing the point of my parent comment: The discussion of tools and languages often diverts into truly irrelevant minutiae that has absolutely nothing whatsoever to do with what a business exists to deliver: Solutions to customer's problems.
To get back to Forth, it would be like objecting to the use of the language on the grounds that traditional Forth isn't object oriented (in a traditional sense) when all you are trying to build is a simple irrigation controller (or whatever). This is getting lost in the weeds for no reason at all.
What would be a valid objection to using Forth? Oh, there are many, and this coming from someone who loves the language and used it professionally for about a decade. The simplest one I can offer with my business hat on is, the pool of qualified programmers isn't large. Another would be that the library ecosystem is dwarfed when compared with something like Python.
How are these different from objections like "it isn't typed"? Simple: These are real impediments to the delivery of solutions customers need. All the CS theory stuff is irrelevant. The proof is that the language enjoyed commercial application for a very long time, with everything from embedded systems to sophisticated industrial controls and more being developed using Forth. As I said in my parent post, I was involved in a company that sold for USD $20MM and the product was 100% done in Forth. BTW, the first thing the buyers did is convert the codebase to C. Because by that time finding Forth programmers was starting to become very hard.
So, yeah, I would not use Forth or APL today (both languages I love) because this would be a bad business decision. On a technical level you can do anything with these languages, despite whatever limitations they may have. From a business perspective, if you advocate for the customer rather than the engineers, when contrasted to other options, they are not the best idea.
After playing with Forth, I bought Pegasus Lisp for the Apple II and for me Lisp hits a sweet spot of concision, bottom up REPL development, and readability.
That said, I can see why some people like Forth if they are very experienced with it and can get things done quickly.
If your language didn't come bundled with Vector support you can bet that adding two vectors wouldn't be terribly pretty either. Or at least it wouldn't merely be "+"
One can imagine "Forth with a typed Stack" where this would be as simple as "+".
Also - Forth can do named identifiers. It's just not the goto technique.
In this case, it doesn't even seem difficult. I've seen multiple stack-based systems that allow items labels. They don't use them for arg-passing (AFAIR), but I don't see why they couldn't.
I'm not even convinced that positional arguments are fatal for language design. Most popular languages today lack named arguments. They're usually only named on the callee side. I'm sure we've all run across a C function call that looked like foo(a, b, c, d, e, f, g, h), and cursed the author under our breath, and then counted out to the argument number we wanted to change.
Languages succeed or fail for many reasons, but I don't think I've ever seen "calling convention" be the deciding factor (no pun intended).
In the more general sense of concatenative (not necessarily stack-based) languages, Unix pipelines are a common example, and they don't seem to be doomed.
I gotta disagree. I've been working with Joy the last couple of years and I think it's possibly a "silver bullet".
Interestingly, it sidesteps a lot of the problems with stack manipulation by means of flexible combinators that permit various kinds of higher-order stack/expression manipulation.
- - - -
Also, see "Compiling to Categories" wherein Haskell is converted to a kind of point-free form very similar to Joy... https://conal.net/papers/compiling-to-categories/
See, for example,
http://zedcode.blogspot.com/2011/02/forth-parameter-stack-na...
Gory details here (warning, spec-ese): http://forth-standard.org/standard/locals
I don't know how widely these are supported in Forth implementations.
I think the spec's choice to term stack-allocated variables "locals" (for what we call "automatic" variables in C) is a bad choice, because it confuses the issue further. When we refer to "local" or "global" variables, normally we are referring to scope, which is a question of over what part of a program a name maps to a particular location (or, in functional languages, sometimes a value). But what we're talking about here is extent or lifetime: during what period of time is a particular location allocated. These are clearly not unrelated concerns, since a name cannot usefully map to an unallocated location, and the same static occurrence of a name can map to multiple different locations when that name is bound on different binding contours, which cannot happen when the name is bound in the global scope; but these two concerns are also not identical, and I think it is important to distinguish them.
In Scheme, for example, the scoping rules are the same block-scoping rules we're familiar with from Pascal and C; but the extent of all Scheme values is unlimited — they can continue to exist until the end of the program, regardless of which subroutines have returned. This is also true in the ML family (OCaml, Haskell) and the abundant crop of modern Scheme-descended languages, including JS, Perl5, Python, Lua, and Ruby, but not in C++ or Rust. (Most, though, don't follow Scheme's mind-bending lead in having first-class continuations with unlimited extent, though Ruby does.)
So, what the Forth-2012 locals word set provides is names with dynamic or automatic extent: they refer to values that exist during a particular activation of a particular function. It also provides local scoping for names for them, but this is a much less significant change.
> All variables in Forth are local variables.
That's true in some sense (that is, all variables must be in scope to refer to them). However, I think that statement is a little misleading.
Traditional Forth variables often do have scope that extends to the end of your program (and possibly beyond). E.g., if your program says:
VARIABLE FOO
Then that's essentially a global variable in other languages; any function can read/fetch from foo (FOO @) or write/store to FOO (new-value FOO !). Indeed, you can read/write them after your program has completed.
Forth locals do not have this extent; they disappear when the function encompassing them returns. I note that Forth locals are allowed to be stored on the return stack, so that is one way to implement them. Thus, Forth locals are basically like "auto" in other languages like C.
> VARIABLE FOO
> Then that's essentially a global variable in other languages; any function can read/fetch from foo (FOO @) or write/store to FOO (new-value FOO !)
This is the point where I disagree. Only functions statically within the scope of FOO --- that is, where FOO is visible when they are defined --- can read or write (or call) FOO, unless you pass them a pointer to it. If you write the following function in GCC, we have a similar situation with the variable m:
int (*adder(int n))(int)
{
static int m;
int rv(int p) { return m + p; }
m = n;
return rv;
}
Several of the problems of global variables in other programming languages are absent or less serious with Forth variables. As I mentioned in the other thread, non-preemptive multitasking avoids the problem of another concurrent thread overwriting the variable except at well-defined (if implicit) yield points, and because each thread has its own dictionary, ordinary variables like FOO can be thread-local. The fact that Forth variables must be declared, and a Forth variable's lexical scope is suspended when another variable of the same name is declared, means that you don't have the collision problem you have in C, where if two libraries both define a global variable called "errnum", it causes a link error, or under some circumstances, both libraries use the same variable. (The wordlist system, providing separate namespaces for separate libraries, also helps with this.) Because recursion doesn't happen implicitly in Forth, and you have a stack you can explicitly save values on, statically-allocated variables don't prevent reentrancy in Forth as they do in old versions of FORTRAN, or as they do if you use them in C.
So, yes, Forth "locals" are basically like auto variables in other languages like C, in that they are allocated in the same way. But, in C local variables are implicitly auto, and in Forth they aren't; and in C making a variable non-auto is usually a bad idea, and in Forth it isn't.
: MY-NAME {: var1 var2 var3 :} var1 var2 + var3 * ;
0 value var1 0 value var2 0 value var3
: my-name to var3 to var2 to var1 var1 var2 + var3 * ;
: my-name >r + r> * ;
: my-name -rot + * ;
A dangerous temptation with Forth is to use the stacks whenever you'd use local variables in other programming languages. A little bit of that can be good, but it only takes four or five variables before it becomes completely unreadable. It never becomes impossible, because with >r and r> you already have a Turing machine, and with dup and swap you can arbitrarily splice its tape, but it very quickly becomes a Turing tarpit. Instead, if you don't have {: :}, and maybe even if you do, your default replacement for local variables in other languages should be traditional Forth variables, even though they're statically allocated. The reasons to studiously avoid global variables in other programming languages are a lot weaker or inapplicable for traditional Forth variables.
I think the smirk was misplaced. What they needed to do was talk about this in comparative language classes and about why people drive to small(er) languages, and fitness for purpose, and what kind(s) of things happen when you force people to think this way, vs why you drive to COBOL and what you force people to think and do, when you go there. They're all turing-complete. They're all capable of expressing the same things, at some differing level of complexity and cost, in some variant of machinery.
In fact, by just adding first class function, retro forth makes the code way easier to read.
Not much of a stretch with C, really - there's a reason its used to write operating systems ;) (the standard library is mostly about OS interaction which is irrelevant in the bare metal/no OS context)
On some systems, C requires a minimal library for compiler-emitted intrinsics (e.g., for 16/32-bit multiplies on 8-bit systems, for floating point, etc).
Luckily for my already very limited spare time, so far I've managed to resist this urge.
Just about every PC before the IBM PC came with a BASIC interpreter with a built-in editor and some kind of storage interface, running on the bare metal. So did every IBM PC up to at least the PS/2. CP/M did provide a BIOS and BDOS, but they really were very basic, providing little more than a convention for talking to the terminal and avoiding overwriting disk sectors some other program was using. MS-DOS didn't do much more, especially in the early years. So, I'd say that every programming language implementation from that time qualifies, including Microsoft BASIC-80 (originally Altair BASIC), VisiCalc, Turbo Pascal up to version 3.0, Apple Integer BASIC and AppleSoft BASIC, the 6809 BASIC Microsoft developed for the TRS-80 Color Computer, ZX-81 Sinclair BASIC, BDS C with the RED editor, and so on; not to mention the first FORTRAN compiler (and up through at least FORTRAN III), LISP 1.0, COBOL, and assemblers for pretty much every machine. Also, and perhaps most notably of all, Smalltalk on the Alto, Mesa and Cedar on the Alto, and Oberon on Lilith and its successors (including a version for the IBM PC).
So, Forth is far from unique in being a bare-metal IDE without requiring an OS. It's just unusual in still surviving in that form.
C is a terrible language for Operating Systems.
No modules, weak-typing, and full of gotchas and pitfalls — plus, it's answers like this that ignore the history of OSes: the Burroughs was written in Algol, Multics was written in PL/I, and VMS in BLISS (plus other languages, thanks to the design/architecture of the CLE).
Here is the retro forth version of adding vector that I was talking about.
Tri@ apply function (2+x)on top 3 items. So get address of the 3rd element of c b a ..
Later I was going through a Forth phase and came back to it to tackle the puzzle it poses, here's my take on it:
https://mnemnion.github.io/blog/2014/01/12/those-dadgum-adde...
I hope this illustrates the raw power of the Forth paradigm a bit better than the OP.
"over", according to forth.com, copies second item to top... ( n1 n2 — n1 n2 n1 )
But I get lost with >r, r>, r@, and !
variable v1 variable v2 variable v3
: vadd v3 ! v2 ! v1 !
3 0 do v1 @ i cells + @ v2 @ i cells + @ + v3 @ i cells + ! loop ;
0 value v1 0 value v2 0 value v3
: vvadd to v3 to v2 to v1
3 0 do v1 i cells + @ v2 i cells + @ + v3 i cells + ! loop ;
Or maybe not. James Hague is a smart guy and he's shipped a lot of code, in assembly, C, and Forth. But I'd like to understand where my reasoning is going wrong, because I can't see it.
My perspective on Forth is that it's the thinnest possible layer on top of raw machine code that gives you all the fundamental mechanisms for improving your leverage. You need structured control flow, so it has IF ELSE THEN, DO LOOP, BEGIN WHILE REPEAT, and a couple of others. You need expressions, so it has an operand stack. You need procedural abstraction, so it has a return stack, which also serves to store loop counters. You need labels both to make your code readable and so that you can patch your code without overwriting parts of it with JMP instructions to wherever you have free space to put the patch code, so it has words. You need metaprogramming, so it has IMMEDIATE. You need run-time polymorphic procedure dispatch, so it has ', EXECUTE, DEFER, IS, and CREATE DOES>. You need namespace management, so new definitions hide old definitions with the same name, and you also have wordlists.
The problem with all these wonderful mechanisms is that they can become an attractive nuisance, as you futz around trying to find the perfect way to express your intent in the smallest, clearest amount of code, navigating the tradeoffs imposed by the sparse toolset. But you don't have to do it that way. You can just write simple, straightforward code that gets the job done with no fuss, and move on to the next problem. Forth lets you do that, too.
That said, I find it easier to get my code working in assembly language than in Forth, and I don't know if that's because I don't know Forth well enough, because Forth is inherently less practical than assembly language, or just because Forth somehow fails to fit my brain. My guess is that I fall for the attractive nuisances too often and waste my time with unproductive futzing. And that's what this blog post looks like to me.
I like stack-allocated variables, and they'd be the obviously correct solution in a language like C; but ANS Forth doesn't have them (oh, I see they've been added in Forth-2012; thank you!), they make it harder to factor words, and some of the other problems they solve in Algol-family and Lisp-family languages have other solutions in Forth, so the case for them is not as strong.
Also, traditionally, multithreaded Forth systems were multiuser; each task had its own dictionary. So a fourth way to avoid the problem (in addition to procedure-local variables, cooperative multitasking, and user variables) is to load the definitions above after spawning the potentially interfering task rather than before.
I would have went with riding a 5 EUR motorized kids skateboard without any protection and never looking back. But that's a good analogy too.