Simple software manifesto

We are in the midst of a complexity epidemic in software. To address this, a new computing environment is required. We are building and promoting software which follows the following principles:

1. All software breaks, but complicated software breaks in complicated ways, and simple software breaks in simple ways. This is also true of the system as a whole.
2. Constraining the user to simple tools encourages creativity and allows the system to be more quickly understood. This supports the removal of complicated features.
3. There is only one correct way to do something, because two ways would be more complex. You often can't change your mind later, so take great care in doing it right the first time.
4. The dependencies of a system are part of that system and cannot be treated as a black box. The maintenance of the entire system is your responsibility.
5. Standards are useful, but often full of cruft. This is not a license to write software which extends them, but rather to implement only subsets of them.

Some of the practical implications of these principles are described here.

Are we simple yet?

NOT REALLY

Package manager apk-tools

STATUS: YES!

✗ Requires non-POSIX shell ✗ Needs better docs

Version control system git

STATUS: WE OVERDID IT

✗ Perl ✗ Spaghetti ✗ Needs be rewritten with the benefit of hindsight

Compiler cproc & qbe

STATUS: GETTING THERE

Mostly complete: ✗ VLAs ✗ Preprocessor ✗ Lots of architectures

Shell mrsh

STATUS: GETTING THERE

80% complete: ✗ Arithmetic expansion ✗ Job control ✗ Signal handling

Utilities ctools

STATUS: GETTING THERE

12% complete: ✗ Mostly incomplete

Assembler & binutils

STATUS: NOT YET

Build system

STATUS: NOT YET

Kernel

STATUS: NOT YET

libc

STATUS: NOT YET

init / supervisor

STATUS: NOT YET

High-level programming

STATUS: NOT YET

Graphical user interface

STATUS: NOT YET

Simple software in practice

C

We target C99 or C11, but do not use the following features:

• Anything in headers except guards, prototypes, extern globals, and comments
• Macros
• typedef
• Inline assembly
• Dynamic linking/loading
• Wide characters

POSIX

We target POSIX.1-2017, but do not use the following features:

• SCCS
• UUCP
• pthreads
• posix_spawn

POSIX should probably be replaced when the time is right.

Unicode

UTF-8 is the only permissible text encoding. Software may assume all text is UTF-8 and waste no effort on other encodings.