paritybit.ca

Raw content of https://www.paritybit.ca.
git clone https://git.sr.ht/~jbauer/paritybit.ca
Log | Files | Refs | README | LICENSE

commit 8861574e91a31db01c9e62327ad0a26e0e656f1c
parent 76ce8929a971478f6a746a6c557f4e51dab29ecc
Author: Jake Bauer <jbauer@paritybit.ca>
Date:   Wed, 21 Sep 2022 21:34:07 -0400

*

Diffstat:
Mcontent/garden/plots/philosophy-software-development.gmi | 16+++++++++-------
1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/content/garden/plots/philosophy-software-development.gmi b/content/garden/plots/philosophy-software-development.gmi @@ -4,21 +4,23 @@ I believe that the way we are building software today is fundamentally flawed. It creates and emphasizes a producer-consumer relationship between the developers of software and the users of that software instead of creating a more holistic environment in which [they are not separate]. It is an environment that creates renters instead of empowering creators. -Develop software that fits your needs or the needs of your community, not others. +By all accounts this is not a new idea; aspects of this philosophy have existed since the early days of programming. -Do not take feature requests that don’t align with your intended vision, let those people fork and do the work to make the software fit their needs. +The overarching theme of this philosophy is that you, as a developer and user of software, should develop software that fits your needs or the needs of your community, not others. Do not take feature requests that don’t align with your intended vision. Do not add features that you don't need but someone else wants. Let those other people fork your project and do the work to make the software fit their needs. Software and computers should be tools to accomplish specific tasks the same way hammers or saws are. This is only possible when they serve the needs of the user-developer, not the needs of the some creators who maintain control [weak]. -Software should be simple and perform broadly one task well. We do not need massive kernels which handle absolutely everything about a system, browsers which have become app platforms, or messaging apps which have become social media. +This ties in with the notion that software should be simple and perform one task or one logical grouping of tasks well. Writing the tool you want to fulfill just your needs Software should be made on the human scale. It should be simple enough that a single human can hold all the code in their head and know exactly which parts do what. Failing that, it should be broken up into a base system with an API/ABI and a set of plugins/modules/extensions such that each part can be understood on its own, like a lamp can be understood independently of the electrical grid. -This results in simpler software that is easier to maintain, learn, and develop. Simpler software means fewer security holes and fewer things that can break (minimize the “this is broken for no reason!” moments). This includes libraries. Libraries should be vendored if possible and binaries should be statically linked so each application or program is one complete object and there can't be any surprises from libraries being updated in the background or LD_PRELOAD. Always know all aspects of your programs, fewer issues will arise as a result of putting in this effort. +We do not need massive kernels which handle absolutely everything about a system, browsers which have become app platforms, or messaging apps which have become social media. Creations like these lend themselves greatly to the current ecosystem where a team of developers, a company, or a single person has utmost control over the direction and featureset of that piece of software, and people who find that software useful for production are at the mercy of those developers and have to suffer when those developers add extra features that introduce more bugs and more issues when the original tool was doing its job just fine. Think Google and the Chrome web browser ecosystem. Think Apple and their entire ecosystem. Think GNU and gcc. It doesn't matter if the purpose is to earn more money or to provide more features to users (consumers), the end result is the same: complicated, buggy, hard-to-understand software that users cannot mold to fit their needs, except in limited cases where allowed by the creators (e.g. browser extensions). -Software and computers should be tools to accomplish specific tasks the same way hammers or saws are. They can be tools for entertainment, but only when they serve the needs of the user. +This results in simpler software that is easier to maintain, learn, and develop. Simpler software means fewer security holes and fewer things that can break (minimize the “this is broken for no reason!” moments). This includes libraries. Libraries should be vendored if possible and binaries should be statically linked so each application or program is one complete object. Always know all aspects of your programs, fewer issues will arise as a result of putting in this effort. -When possible, design from the ground up. You can reuse existing code or make libraries out of the things you write, but don’t rely on abstractions to take care of absolutely everything for you (cough cough Python). Expose the inner workings of your programs to developers wherever possible. Keep the human in the loop. +When possible, design from the ground up. You can reuse existing code or make libraries out of the things you write, but don’t rely on abstractions to take care of absolutely everything for you. Expose the inner workings of your programs to developers wherever possible. Keep the human in the loop. -Computers should be built for specific purposes in mind and should not have general purpose kernels or OSes on them. This simplifies the operation of a device at the cost of development time, but ultimately the whole stack is understood and under your control. +In fact, abstraction is the wrong word to refer to libraries as they are used today since most libraries are treated as black boxes; as services which someone else wrote for you that you don't have to think about at all. When it boils down to it, libraries and web APIs aren't really that different in terms of how they are used by software developers. You have allowed someone else to think about the details of whatever the library does and deferred not only that burden to them, but also any knowledge of how that library influences and shapes your program and control over that aspect of your program. + +Computers should be built for specific purposes in mind and should not have general purpose kernels or OSes on them. This simplifies the operation of a device at the cost of development time, but ultimately the whole stack is understood and under your control. [eh, not so relevant to this] Check out Dijkstra's ACM Turing Award lecture in which he describes how programs may be written to be virtually free of bugs