Is Forth a better unix than Unix?

If a unix is a bag of tools in which each tool does one thing, and does it well, then Forth is a better unix than Unix, especially if you don’t use conditionals. However, Forth philosophy is quite a bit more radical than the unix philosophy.

Rule of Modularity: Developers should build a program out of simple parts connected by well defined interfaces, so problems are local, and parts of the program can be replaced in future versions to support new features. This rule aims to save time on debugging code that is complex, long, and unreadable.

In Forth we avoid hooks for future functionality because they lead to stack juggling at the front of word. Instead of juggling arguments into position at the beginning of a word as if it were an interface, put them where they belong at edit-time, and then slice the code up into factors as needed. A word is a slice of functionality not a self contained bubble. Stack juggling is a symptom of code that is too general and doesn’t do one thing well.

Rule of Composition: Developers should write programs that can communicate easily with other programs. This rule aims to allow developers to break down projects into small, simple programs rather than overly complex monolithic programs.

Yes, but words are not functions and don’t encapsulate anything. They are documentation. Mnemonics for slices of functionality. Hooks for future functionality reduce future flexibility. Forth words shouldn’t talk to each other any more than they would without factoring.

Choose portability over efficiency.

In the same vein as the previous two points, portable software tries to fit every platform but works well on none of them.

Store data in flat text files.

Parse as early as possible, store data in data structures as soon as possible, or better yet use on-line algorithms. Multiple levels of parsing means you have unnecessary extra steps.

Use software leverage to your advantage.

A Forth program executes in four phases: the design time, the edit time, the compile time and the run time. The former phases should be enough unless there are externalities on the latter phases.

Make every program a filter.

Avoid the need to filter. Filtering is an extra step for all but the uncontrollable world beyond the sensors.