The Implementation Square

Software bloat is a menace to users and maintainers alike, but it can be difficult to avoid. The implementation square can help determine how to implement different features.


“Large” and “Small” refer to the size of the implementation of a specific feature. “High” and “Low” refer to the demand of that particular feature.

If followed accordingly this can achieve a balance between useless programs and bloatware.


Do not bother to implement.


Provide a patch as the suckless community does, or extension with a language like Guile.

Patches are a simple way to extend functionality for small programs with technically capable users. Unfortunately, major changes to the program’s source may invalidate many patches so this is only a feasible option for reasonably stable software.

Extension languages are a more complicated solution that may require deep integration with the architecture of the program itself, but confer many benefits.

Just don’t go overboard like Vim does. It not only has it’s own scripting language VimL, but supports plugins in Ruby, Tcl, Lua, Scheme, Perl, and Python. Worse still, support for these scripting languages are compile-time flags meaning plugins written in them will often fail to work on other machines.

Language agnosticism is noble, but language inclusionism is not.


Write an auxilary program that may interact with the current program. This can either happen through a shell pipeline or some other form of IPC.

See Beej’s Guide to Unix IPC for the technical details.


Implement within the program itself.