Minimalism in software

"We do not consider it as good engineering practice to consume a resource lavishly just because it happens to be cheap"
-- Niklaus Wirth

"Everything should be made as simple as possible, but..."

In the world of software programming the are three statements that are unconditionally true. Namely, if two (non-trivial) programs have the same functionality, then:

  1. The smaller in size program is better.
  2. The faster program is better.
  3. The more simple/convenient in use program is better.

From which we deduce the three qualities of a program that represent the unconditional good in the world of software programming:

  1. Small in physical size.
  2. Fast in execution speed.
  3. Simple in use.

The conventional wisdom and the "Law of Two-Thirds" tell us that for sufficiently complex software systems one can't have it all. Only two out of the three at the maximum.

Those programmers/users who did computing at the times when "640Kb of memory was enough to anyone" observe, that nowadays the first unconditional good in the above list is often if not completely and outright forgotten, then by and large neglected.

But, the fact is that compactness of a software system has not ceased to be an uncoditional good. And we, at Transd, put it as one the main software design principles (and selling points), and go a long way to observe it. We consider keeping the software size minimal not only as an important technical aspect, but also as an element of manufacturing culture and almost as an item in the programmer's "Code of Conduct".

What is included into the notion of "physical size" of software?

In the order of importance:

  1. The number and size of software prerequisites that need to exist on the user's computer for our software to run. (Excluding the size of the targeted OS in its standard configuration.)
  2. The size of our software assembly shipped to the user, and/or artifacts resulting after user's compiling the source code distribution.
  3. The size of source code. (Especially in the case of source code libraries that are included in user's software programming project.)

Minimalism in Transd

The "user" here means both the programmer who uses the Transd library in their software programming project, and the end user who uses the program written in Transd.

  1. The number of prerequisites that need to exist on user's computer is zero. Transd compiles and runs on Windows and Linux out of the box in their base configurations. Transd source files do not include anything besides C/C++ standard libraries.
  2. The size of Transd run-time assembly, needed for executing Transd programs, is zero in case of using Transd as a source code library compiled together with the host software project. In case of using Transd as a bundled separate executable, the size of executable is less than 3Mb on Windows and less than 5Mb on Linux (as of November, 2021). The Linux executable is statically linked, so there is little chance of libraries incompatibility.
  3. The Transd source code included into the distributed C++ source library is minimized: that is the number of files in the library and their size are reduced to the minimum. Currently, the Transd C++ source library consists of two files: one header file, and one CPP file. The program text is deflated by replacing the identifiers with short symbols, and by removing empty lines. Whereby the size of program text is shrinked several times. Currently, the minimized source code library contains totally less than 20,000 lines, and has the size less than 700Kb.

All in all, the minimization of size and dependencies is important for any software, and for embeddable libraries like Transd it is a major requirement.