An Attempt at a Compelling Articulation of Forth's Practical Strengths and Eternal Usefulness

PRELUDE

Problem Statement

It's done! We have that crucial ingredient giving life to that little Forth, allowing it to walk by itself! Unfortunately, you'll soon see that after a few steps, this little creature stumbles and falls. What is it lacking, a little balance maybe? -- Virgil Dupras

Explaining why Forth is still relevant has become a bittersweet, ironic comedy routine enthusiasts and "operators" are finding themselves in more frequently. We usually begin with lavish statements of simplicity, and ease the reader into a fog of what Forth is. We return the reader back to the concrete with examples... Examples so contrived that they have the complete opposite effect - a tint and a dulling of any allure that may have existed as sparks in the prospective Forther's mind. Speeches of grandeur falling flat.

Virgil's quote is a perfect specimen of this phenomenon. The miracle of popping into existence - walking nonetheless - is a direct testament to Forth's evolutionary nature. It's such a strong positive to begin with, yet immediately follows up with "it's useless".

Virgil needs no defense: he's right. It is useless. The point is, that statement is a negative wrinkle for what is a positive feature: a foundational, minimal core to build on. It's these instances of faulter that contribute to Forth's continual uncertainty in today's context.

On Saturday I saw the final act causing me to want to write this piece.

The Ironic Proposal to Implement a Forth in C

A long-running project called eforth was linked on lobste.rs, a link aggregation site, attempting to sell Forth on still having relevancy: https://github.com/chochain/eforth. It is based on eForth, created by Bill Muench, which strength lies in being a meta-compiler (it can compile itself) for easy portability.

The author details their history, how they worked with a prolific Forth user and contributor, Dr. Chen Hanson Ting (a heavy user and ethusiast of eforth, passed away 2022), and why their particular Forth project is a successor to his work.

But it's the first paragraph that catches my attention. It unironically reads:

With all the advantages, it is unfortunate that Forth lost out to C language over the years and have been reduced to a niche. Per ChatGPT: due to C's broader appeal, standardization, and support ecosystem likely contributed to its greater adoption and use in mainstream computing.

The project's README then proceeds into lengthy detail about how to implement Forth in C.

Yep.

It is the fastest open-closed case I've seen to date of someone explaining why you'd use Forth and then miraclously shoot both their feet at once.

It seriously left me empty-minded after reading.

The only hint of relevancy revolves around compilation and being able to build the system for many architectures, thanks to C compilers and ease of implementation.

Disclaimer on Authority and Guarantee on Love for Forth

I'm not a Forth guru; a great sage like those of LISP, C, or Haskell. No universal promise can be made to you that what I say is unyielding truth. You will have to verify that for yourself. What I can promise is the perspective from a simple, passionate programmer of a couple decades, and 3 years of those belong to Forth. Never has my heart been completely enveloped by an idea. The allure and compulsion has practically caused me to fall in love with a programming language. Maybe this is how Pythagoreans felt about their triangles. With this great fire, I will tell you why Forth is forever.

WHAT IS FORTH

Each of the following sections touch on what Forth is. The brief version is:

Forth is a simple high level programming system.

People that drive-by usually see "Forth is a stack-based programming language", but it's never explained what the implications are - effectively a useless description. The stack is an important core part to what makes Forth simple in execution and implementation, but there's more to it than that.

It's very possible many readers will be hearing about Forth for the first time when they encounter this essay. There are two recommended readings for all Forth first timers by Leo Brodie: Starting Forth, and Thinking Forth. The former focuses more on concrete code, and the latter is a philosophical read. They go hand-in-hand and I can't really recommend one over the other: it really depends on the kind of person you are.

I will do my best to give an extremely short description of what Forth is in this essay to remain self-contained.

Explain Like I'm 5: Forth Edition

For those completely new to stack programming at all, read this. Otherwise you can skip to the next section. After you understand what stack-based language is, the next section explains how you use it.

Forth is a pancake stacking machine with superpowers. 

  top      pancake5
           pancake4
           pancake3
           pancake2
  bottom   pancake1

You eat these pancakes like you normally would: from top to bottom.

What do you normally eat pancakes with? A fork and a knife.

In Forth you can make your own super special fork and knife, maybe they shoot lasers, but you can also make robots that help you.

For example, the Gigafork-o-tron 9000 lets you eat 3 pancakes at once, by smushing them into 1 big pancake for you to eat: 

   smushed_pancake
   pancake2
   pancake1

With 100s of robots you can do some really cool stuff when you start feeding them things other than pancakes, like build video games.

Why use Forth and not something else? Because all you need are some elastic bands, pencils and paper to build this stacking machine with superpowers! These are all items you've got lying around the house! Get going!

Explain Like I'm Familiar With Programming

Ok let's try again: so Forth is a stack-based programming language.

On the surface that statement means nothing except somehow the stack data structure is somehow involved.

In Forth it's core to data passing (arguments) and your memory pool (allocated memory).

To program arguments onto the stack, list them out before functions (words): 

     1 2 3 4 + + +
  -> 1 2 7 + +
  -> 1 9 +
  -> 10

We're left with 10 by the end of the reduction.

You're intended to create 100s of words (functions), which are inserted into the dictionary (a global stack), which make up a vocabulary. Yes, each Forth program is a domain specific language (DSL). 

  \ A comment describing what's going on.
  \ ( stuff ) is an inline comment but it is used commonly to denote expected
  \ function arguments coming in on the stack. They do nothing.
  : my-func  ( int int -- int ) * 10 + ;

Forth can manipulate its own interpreter at "compile time". You can leverage this when needing to parse formats, or create new syntax. 

  s" something-to-parse-until" parse

Doing common work like splitting strings or concatenating lists is all provided as words too.

That's Forth. It's so simple the idea is you can bootstrap it from assembly relatively quickly.

Forth is a Philosophy

At first it's not obvious there is a philosophy behind Forth so powerful it can creep into other aspects of your life. Most people focus on the eccentric syntax and semantics, and stop there.

Lars Brinkhoff, a prolific Forth enthusiast (and now professional!) sent me an email after reading this piece, reminding me of the overarching philosophy Forth brings. They explain its essence well:

I have been fortunate to have worked professionally with Forth recently. It was so fun! But I still struggle to point out exactly why I like Forth, and why and how it's different. Your essay is fresh take, which is good.

To me, maybe the most important lessons are:

  1. Eschew complexity (sometimes to a fault), and
  2. Improve the code by redefining the problem. Look at things from another angle. (I hate to say it, but think out of the box.)

Much of Forth falls out from these principles. E.g. people are quick to point out Forth is a stack based programming language. Which is true enough, but to me it's kind of beside the point. The point is the language does away with local variables (redefine the problem) to lay the ground for a much simpler implementation (eschew complexity).

Yes, there's REPL. But why? Because Forth is (or can be) a programming language, operating system, compiler, and command line rolled into one. Heaps of layers and components done away with.

File system, virtual system, code structure, documentation? Blocks!

The list goes on. Once you internalize this, the veil falls from your eyes, and you see how much needless complexity stands in your way in most other languages, operating system, tools, apps, ... it's everywhere.

SUPERNATURAL BOOTSTRAPPING

Programming Language By Synthesis

Programmers will often use other programming languages to implement their new programming language. The choice of parent language is usually determined by what problems the child language is intended to solve. Choosing a suitable parent reduces time to implementation, keeping the programmer motivated and actually achieving a finished program.

A side effect of using a parent language is the child will inherit its traits. The performance ceiling of the parent becomes the ceiling of the child, unless it's able to evolve a code generator. All available parent language packages and libraries are available to the child for use toward its own development and extensions. Any memory management and access faults are transfered.

It's understandable why using an existing language to bootstrap your own is very reasonable.

A familiar case of the preceeding is Python. Python has and continues to be written in the C programming language. Its C core hardly minimal, clocking in at 35% of the whole codebase as of writing.

The Glasgow Haskell Compiler, the most prolific functional programming language compiler, does the same, but with an exceptionally smaller, desireable core size: 8% is C. Unfortunately it uses Python as well, pulling in 952 C source files if we are to require it to build. So is it really small then, or simply abstracted away into other software packages?

Clojure is a case of being a far descendant of C. Bootstrapped from Java, which itself written in C++, further evolved from C. Clojure benefits from Java's garbage collection and being able to interoperate with other Java source files, while offering unparalleled expressiveness. CPUs that implement JVM bytecode compatible hardware (such as the "Jazelle ARM extension") are an interesting case of removing ancestrial ties, simplifying lineage. Similar can be said with CPU architectures that favor C-like code.

C is Not Free

What's the problem then? C is the lingua-franca of the programming world. It exists for nearly every practical architecture imaginable. It's free!

At the risk of getting absolutely roasted by two (or more) very strongly opinionated communities, I will say pretty much (not every!) every mainstream development in programming languages, Rust and Zig included, are guilty of this fallacy. They are built around the illusion of their parent language having low to zero cost. Some of them, like Zig, attempt to escape their parents, but still needed one in the first place.

LLVM is the typical basis of these languages: a heavy technology largely funded by mega corporations. A Zig and Rust enthusiast argument about their language being less complex than the other is off-putting. The reality is the complexity comparison is surface level. The shape of two fruit are compared but the genetic structure of the fruit is 90% the same. Theirs arguments revolve around particular expressions of logic in various situations but ignores everything else.

Zig and Rust experts will try to reason about this cost, that "they only make up 1% of the code base". Uh, no, without that 1% there is nothing; the code will not compile, and cannot be invoked. That 1% is made up of millions of dollars and lines of code. It is not free, far from it for these LLVM-based languages!

Let me make an evidentary statement:

A C compiler takes a non-trivial amount of energy to create.

Following are projects that I believe cover a range of full-featured to smallest C compilers, and ran sloccount on them. The evidence leans toward a good estimate, as the timelines match up with the commit histories and the amount of contributors.*1 The results are organized from most to least expensive. 

    clang *2 *3

    Total Physical Source Lines of Code (SLOC) = 11,200,038
    Development Effort Estimate, Person-Years  = 3,570.35
    Total Estimated Cost to Develop            = $ 482,305,367

    gcc *2 *3

    Total Physical Source Lines of Code (SLOC) = 8,208,908
    Development Effort Estimate, Person-Years  = 2,576.50
    Total Estimated Cost to Develop            = $ 348,049,714

    tcc

    Total Physical Source Lines of Code (SLOC) = 108,038
    Development Effort Estimate, Person-Years  = 27.31
    Total Estimated Cost to Develop            = $ 3,688,901

    chibicc

    Total Physical Source Lines of Code (SLOC) = 9,487
    Development Effort Estimate, Person-Years  = 2.12
    Total Estimated Cost to Develop            = $ 286,832

    cc<< *4

    Total Physical Source Lines of Code (SLOC) = 1,119
    Development Effort Estimate, Person-Years  = +1.00

Now add on top the person-hours required to build the child language. Bonkers.

Programming Language By Evolution

New programming languages are also created through more natural, evolutionary means. Common examples are C++ and TypeScript. C++ came to be from C programmers required to handle ever-growing requirements and complexity of systems software. Web developers turned to type-systems to deal with their own ecosystem and social complexity, structuring JavaScript code written by people, and now robots, from all walks of life. What could such an evolution look like when we go back to the roots of programming: assembly?

Assembly is the lowest level of abstraction we can get from the computer. The IBM 1401 from the 1960s forced humans to write code in literal 1s and 0s. Quickly we learned mnemonics are easier on the brain than monotonous numerals. Textual code is a one-to-one abstraction that arose from naturally using the technology of the time. As programs grew in complexity, and humans being incredibly good pattern matchers, they realized a lot of code could be deduplicated into reuseable chunks. At first this took the form of subroutines, but it was not enough. The macro was created to resolve this complexity. Once again a natural solution to a natural problem. Now assembly programmers could create systems beyond their normal comprehension - literally!

This is where Charles Moore (aka Chuck) enters the scene. The idea of Forth is not particularly genius or crazy, but his resolve toward simplicity is something to really celebrate. The story goes Chuck worked at various astronomical observatories throughout the years, and needed to program the telescopes. He found himself needing to interact with all the different hardware frequently. Bringing a set of macros to each new telescope, this is the system that became Forth. An evolution of assembly macros; Forth is a true example of holistic design.

While it took years to refine the idea of what Forth was, the implementation of a Forth-like takes place all the time, to this day. The first thing language implementation learners do: implement a stack machine. When a technology accidentally exists time-again the cost is even better than free. It just is. For me this equivalent to discovering how to create your own molecules. A true lingua-franca of the Turing machine.

Masterclass Example of a Forth Bootstrap

SmithForth is a golden textbook example of bootstrapping a Forth from nothing. SmithForth literally constructs executable headers using binary, and each line of binary maps to an instruction, with each commented in great detail.

Here is an excerpt: 

################ Interpreter subroutines #######################################

99 05 43 4F 4D 50 4C #### COMPL Forth's COMPILE, B9 ( ebx=xt -- )
B0 FF AA                # compile >>>>>>>>>>>>>>>>> call r/m64          FF /2
B0 14 AA                #     al = _                mov r8, imm8        B0+rb ib
B0 25 AA                #         [rdi++] = al      stos m8             AA
93                      # eax = ebx                 xchg eax, r32       90+rd
AB                      # [rdi(++4)] = eax          stos m32            AB
C3                      # return                    ret                 C3

Absolutely psycho. And it goes on for ~500 lines. I am envious of the mind that yields the mental model to parse this fine.

A C programmer in comparison would have to write a minimal C compiler this way, to then write some C to bootstrap other C features. All while on that same computer. Sounds painful. The person who wrote the smallest useful C compiler, chibicc, shown in the previous section, also wrote 8cc. Both took over a year to write.

Meanwhile the Forth programmer is off to solving their original problem in a week. A full working environment. Their power continues to build as the dictionary fills out with useful words. Maybe they go a little overboard and develop a full operating system. That's the principle behind Virgil's incredible Dusk OS. It's a testment to the practicality of doing that in Forth.

EXTENSION THROUGH SELF-MODIFICATION

Programming languages rarely expose methods to extend the language syntax itself, or modify existing syntax. The latter is more common in interpreted languages like Python or JavaScript, where an object property can be overridden with a new one. Forget about this in systems languages. C++ has method override but it's not the same: you cannot change the behavior of how addition works on two 64-bit integers (such as treating them both as fixed-point numbers). At most these languages expose complex macro or template systems, and it's a discouraged practice depending on where, or how, you work. Adding more syntax to already complex languages literally creates more complexity.

The opposite approach is taken in Forth: syntax is non-existent, so adding it to simplify reasoning about the solution to a problem is encouraged. Each program then is a narrow, well-focused expression of a solution.

For example, there's a complex tax situation, and you want to record and calculate everything with some sort of special text record file. The playbook for this problem is to write a parser. Design decisions such as number precision and operations are made. Finally, the the actual computations take place. Then there's the output format.

In Forth, we leverage the language itself. Your program code doubles as the record file. There is no separation because the Forth programmer can leverage the Forth compiler, morphing it to their needs at run-time. Changing addition to work on "bignum"s (numbers that have arbitrarily large precision) is a good usecase of overriding the addition operation. This is possible to some degree in many languages, but usually occuring as defining bignum as a new type on addition, rather than redefine how two u64 should be added.

As you may have guessed, this is a real situation I found myself in. Encoding tax brackets and having a system that calculated tax became trivial once I defined the "tax bracket" word. Cute how it's a literal bracket: 

    ...

    \ Calculate a bracket.
    \ ac:accumulated capital, rb:remaining balance
    \ r:tax rate, l: upper limit
    : ]> ( ac rb r l -- ac rb )
      ( ac rb r l ) frot
      ( ac r l rb ) f2dup f< if
        fremaining frot frot f*
        ( ac rb tax ) frot
        ( rb tax ac ) f+ fswap
        ( ac rb ) else
        fswap fdrop f* f+ 0e \ rb is zero
        then
    ;

    : tax-cra-income ( income-to-tax -- collected )
      0e fswap
      ( collected remaining ) 0.150e  55867e ]>
                              0.205e 111733e ]>
                              0.260e 173205e ]>
                              0.290e 246752e ]>
                              0.330e fover   ]>
      fdrop
    ;

    ...

    accounts LeeBusiness
    accounts ACompany BCompany

    -5674.84e tax-sales   ACompany
    remaining  tax-income LeeBusiness

    -2145.66e            BCompany
    remaining tax-income LeeBusiness

    ...

The word acts as both a computation and a data structure. Very Forth-y to achieve multiple goals once!

Then we arrive at the point of divergence: most languages stop at a parser for a new file format. Little Forth goes beyond: you can also modify and extend the "outer interpreter".

This is the REPL most Forths offer to developers so they can poke and prod at hardware. In this case the hardware is literally the computer you're working at. It is common for Forth developers to create their own rudimentary text editors as an exercise. Quickly it becomes obvious how such a holistic system gives a natural extension power very few other languages have.

Some people have taken this strength to the extreme: Virgil Dupras's DuskOS and mschwartz's mykesforth both build entire operating systems off these principles.

DuskOS is intended to solve the goal of bootstrapping other C-based operating systems with a Forth core that implements a C compiler.

mykesforth is a complete pure Forth OS.

EXECUTABLE COMPRESSION

Texas Instruments' introduction of the MSPM0C1104 this year (2025) has ushered us into the world of nano-controllers. A computer that can sit on a pin-head. With only 16 KiB of storage and 1KiB of memory. The 1980s were more generous: most home computers had 64 KiB of memory and much more storage. It's no surprise Forth found itself popular in that era. The ability to create essentially compressed executable code was and still is unmatched and greatly desired. This is achieved through a particular implementation called Indirect Threading Code (ITC). Combined with heavy code refactoring into small functions, programs become executable Lempel-Ziv-Welch compressions, which astonishingly also have a concept of a "dictionary" and reusable parts. The parallels are remarkable. There is literally no other language I'm aware of that does this kind of optimization to this degree.

Briefly I will explain what ITC is.

Here is a pseudo example of some program code (& means address, : is a label): 

  my_func:
   &other_func1
   &other_func2
   &other_func3

  other_func1:
    &deeper1
  other_func2:
    &deeper2
  other_func3:
    &deeper3

  deeper1:
    push a
    ld a, 7
    ...

  deeper2:
    ...

Each function, which is extremely small because we've done the correct practice of refactoring them, reside somewhere in memory like usual. Compilers typically will then use a CPU's call instruction to jump to the address and set the return register. Forth instead opts to place these addresses to functions one after the other. A function call may do tens to hundreds of lookups - so yes, the trade-off is slower code... except you can decide to switch out that model of function calling! It's a win-win. There is an even more compact variant called Huffman Threading and it's exactly what it describes: using Huffman codes to create indexes to functions. On the opposite end a developer can invoke particular Forth compilers, such as gForth, to use familiar code optimizations found in LLVM and other code generators, to generate fast code.

The best part of the above is you get the advantages by doing good practice. Refactoring code into small composable functions is what everyone strives for in the first place!

ENLIGHTENMENT GAINED FROM
EXPLICIT DATA-FLOW

Time for a little detour into the higher level topic of data-flow.

Being a stack-based language, Forth passes arguments to functions using the stack. Yes, pretty much every other language in existence also does this, but usually only after registers are exhausted, and it's implicit. Never does a programmer explicitly need to say "this goes on the stack", it just sort of happens, and is placed in whatever position is deemed most optimal by the compiler.

In Forth once again the opposite is true: argument passing on the stack is explicit! The most compelling reason for this is how natural it is to pass an arbitrary amount of arguments to a function this way, and how portable that is.

As long as the target machine has memory that can be linearly accessed, it can express a stack machine. The original Turing machine is essentially a stack machine. There is something inherently natural about these machines.

After you use Forth for a little you begin to realize, there is no logical sense to have it reversed: a computer cannot be told to do something, expecting input to act on, without the input!

It makes way more sense to have that data preceed the operation: 4 7 +. Personally seeing and taking this fact in for the first time kind of unlocked something in my head. I'm led to try algebra this way. I'm led to doing every day quick math this way. No more does order of operations or parenthesis matter, the order is baked into the expression. And there's a trick to reading expressions written this way: you can read them like operations consuming their operators, sweeping your eyes from right to left.

With explict data-flow, value copies and reuses become extremely obvious. They become painful to see in code, similar to when encountering .unwraps in Rust. There is a new drive to remove any copies, because it causes the stack to thrash more. You literally feel it in your brain when trying to reason about the stack manipulations. These new experiences teach that we've had the blinders on this whole time on data-flow.

AN ALTERNATIVE TO

C

Python, JavaScript, Ruby being interpreted languages are incapable of writing low level code to poke at memory registers, use pointers or inline assembly.

For years these needs have been fulfilled by C and C++, followed by some niche languages like D. Within the last 10 years there has been an explosion of contenders for a better systems / low-level programming language, with Rust and Zig being the most well-known.

Meanwhile Forth has been busy benchwarming. Never do I see it recommended as an alternative to C in programming discussions. It's surprising, because Forth has the same low-level mechanisms as C and can express the same high level constructs. It has pointers. It can poke arbitrary memory. The default memory allocation model, the dictionary, can grow arbitrarily big, unlike C's malloc. Forth has alloc. too, but it's heavily discouraged. Sticking to growing the dictionary forces the programmer to construct their program in such a way that it only uses the memory it absolutely needs at any point in execution.

All these C alternatives are also missing another Forth superpower: the REPL. (Just like LISP!)

Forth is designed to play with hardware at run-time, being able to poke memory with the keyboard as the program runs. The closest thing we've ever had to that I think is Terry Davis's HolyC, that provides a C shell (lol), and could allow the same technique.

And there's all the benefits that have been mentioned in previous sections: cheap, fast, compact, simple, portable.

LISP

If you've gotten this far, and love LISP, you have probably seen many parallels to LISP, especially after the mention of REPL in the previous section. The evidence is strong enough for me to believe that Forth is some sort of LISP sibling.

LISP's birth took place in the academic, hacker stronghold of MIT, as a language to further develop artificial intelligence. Forth was born in the messy work world, with ever changing requirements and environments. I tell people that Forth is a "working man's LISP", because of how closely it looks like a LISP but born out of completely different circumstances.

Here are some direct code comparisons for a quick visual: 

                   (+ 1 2 3 4 5) vs 5 4 3 2 1 + + + +

       (defun my_func (a b) ...) vs : my_func ( a b -- ) ... ;

                        'my_func vs 'add

    (LOOP (PRINT (EVAL (READ)))) vs BEGIN ACCEPT EVALUATE TYPE AGAIN

Is that not the just the coolest thing to see in awhile? A simple, fast, low-level LISP is possible! It's called Forth! With a skip and a hop you can get LISP-like list operations very easily: 

  : E+ 1 - 0 do + loop ;
  1 2 3 4 5 5 E+

Now take into account how there is no garbage collection. Inline assembly is possible. It is even more syntax-less than LISP. These are aspects I find myself desiring more than hygenic macros, or data structures (lists) that also define the language. Don't interpret that as me saying LISP sucks. It's me saying I'm so incredibly glad there is a LISP-like with trade-offs I'm happy with. Forth is a chimera of the Turing Machine and the Lambda Calculus.

UNSUITABLE CLASSES OF USE

The purpose of this section is to trick the reader into thinking of their own reasons why they would use Forth.

Imagine a venn diagram with these aspects of Forth, with an unknown "For" side: 

                        Against       Both       For
                                    |        |
                      security      |        |   ???
                      memory safety | cost   |   ???
                      logical rigor | no-ast |   ???
                      teamwork      |        |

Since file formats parsed by Forth are Forth programs themselves, we can't really say Forth is suitable for security, since someone could simply craft a file that is also some malicious Forth code. On the opposite end, if you work in a secure environment, this is no longer a problem. So Forth is suitable to use in all secure environments.

Working in a large team can be difficult with a growing list of vocabulary in a custom Forth DSL. In contrast, Forth is an excellent language to work as a solo developer, allowing you to work in your own comfy mental models.

Type systems and logical constructions are not concepts available to a Forth programmer - which allows them to achieve some of the most unholy logic ever, and get away with it! Of course, that means they can also always develop their own type system to work within too!

While the grand total cost of Forth is significantly less than pretty much any other mainstream language, the human costs can be much higher. A C or JavaScript programmer cost significantly less because they can use abstractions that are consistent across thousands of codebases. We can ignore the underlying technology cost "just because" (an exercise for the reader to think about). We have agreed as a society, or at least with some sort of inherent bias, to using free compilers and interpreters for the most part. This is why Forth is generally rarely, if ever, suitable for a business, but thrives in individualism.

Those examples hopefully convey the duality of Forth's weaknesses.

CLOSING COMMENTARY

If there's one thing I'd like to drive home, it's the natural evolution of Forth from the primordial assembly ooze, and all the power for the low cost it brings along.

I look forward to what challenges the next generation of Forth programmers will face, and the beautiful spawn that will rise from them.

An Attempt at a Compelling Articulation of Forth's Practical Strengths and Eternal Usefulness

Thank you for reading.

- Lee

Special thanks to paultag, austin, appledash, and jon, for peer reviewing!

2025-11-09T21:25-04:00