This page describes the Forge development mindset.


A minimal viable program is the smallest program that solves a particular problem. It is small and beautiful. It has no additional features.

If you removed a single feature it would be totally useless. If you added a new feature that feature would not be essential, you could use the program without making use of the new feature.

Minimum Viable Programs - Joe Armstrong

Computer graphics software is a complex domain with many working parts that are often tightly coupled (or just badly designed) for the sake of performance or to satisfy obscure edge cases. With Forge, we take a step back and challenge the conventions of traditional computer graphics software design.

Developers who are keen to write high quality and experimental software are more than welcome to contribute. It is an opportunity to entirely rethink any approaches made in existing solutions, and build novel ideas by returning to first principles. We are conservative in that we do not try to solve many problems, but keep the problem domain small, focusing on tackling a few problems well and carefully.

Designing components as beautiful, "minimum viable programs" is possible, it just demands some patience and forethought.

#Best practices

Write clearly. Clarity here refers to elements of the program such as readability and control flow. Most of the code we write on a daily basis is really for other humans (including your future self) to read and maintain, the less time and cognitive load it takes for others to grok, the more time can be spent on actually hacking away.

This should not discourage the use of complex mathematics/algorithms or advanced language features where it makes sense, although it is helpful in these situations to include additional commentary to help less familiar/experienced developers. Comments are also instrumental on the occasion when readability is sacrificed for performance.

Assume other developers working on the project can read and understand most of the code. This means avoiding "fluff" comments. Name variables, methods, etc. clearly and your code will be naturally "self-documenting".

Exercise discipline. Satisfaction should not come from merely getting something to work, but instead from having it work elegantly. If it means spending more time on the task, then, by all means, take your time to iterate, revisit, and rewrite where necessary. Try to strike a balance, but prefer quality over speed. To reiterate, if something is a hack, then work on it until it is nothing short of simple and beautiful.

Use common sense to make decisions. There is intentionally no mention of coding style, just stick to the style of the existing code. The maintainer has absolute say over formatting, this avoids any bottomless debates and avoids wasting time trying to address formatting-related changes. When in doubt, loosely refer to the Linux kernel coding style.

Unlike the suckless philosophy, frugality is a non-goal. Having fewer lines of code is ideal as it encourages re-use and simplicity, leaving less to maintain. On the other hand, it can often negatively affect clarity, which should be considered the primary motivation of Forge.

About this wiki

commit 0984d33a3f7fc3167f25810c5126ff97c2dd65e3
Author: Ryan Chan <rycwo@posteo.net>
Date:   2021-02-10T10:24:10+00:00

Migrate from Tau project wiki
Clone this wiki
https://git.sr.ht/~rycwo/forge (read-only)
git@git.sr.ht:~rycwo/forge (read/write)