Early draft. Please help us shape this manifesto
Complex systems have failed us. Therefore, we need simple systems.
What is a simple system? A simple system is a system which can be maintained and completely understood by one person.
What's so good about them? They make sense.
Ideas matter. Focus on IdeaReuse: write thorough docs. The system does not have to be open-source, because systems that are simple enough can be reimplemented when needed.
How to make my system simple?
- Keep protocols unambiguous. When every client implements a protocol in a different way, simple systems fail. Therefore, make it hard to implement them in a different way.
- Drop features when they are not needed. But note that simple doesn’t mean easy or primitive. Do not drop features when they are hard to implement. Do not drop features when they are hard to use.
- Use open standards because they make the software more reliable and interoperable. Also prefer using existing and known standards over obscure ones when it makes sense.
- Think about humans first and machines second. After all, computers were made to serve people.
- Make sustainable software because such software is expected to run for ages. It doesn’t mean it has to be bug-free. It means that the bugs can be worked around. It often implies open source.
- Make it easy to install your software. It is easy to install software that has few dependencies, few requirements, where installation is short, where configuration is either automatic or obvious, in one place, where documentation is easy to find and easy to follow along; it has a section that helps people get a running system as quickly as possible.
- Make your software extensible. Extensible software is simple software that doesn’t try to cover all the use cases. Instead, extensions can be added successively as those use cases become more obvious. Note that having extensible protocols is not a good idea.
Discussion
Let’s keep it in tree mode to solve questions one by one.
- ππ¦ agreed that:
- π: I have gathered several links on CyberRachel related to PermaComputing?. We can get some inspiration:
- π¦: I think CodeReuse often works against Simple Systems, because all code embeds assumptions, and trying to fit assumptions with incoherent assumptions makes things messier and harder and more complex, not simpler.
- π gave an example when CodeReuse is not that bad (and it doesn’t contradict the statement given by Lion; note the word often): βTake a look at any web wiki (that is, everything but Phoebe and TwinWiki which run on Gemini). They all use HTTP libraries, I’m sure none of them reimplemented it. I don’t think it makes them more complex. In fact, it makes them simpler! Sure, there are assumptions, but HTTP is thoroughly documented, just like in one of our principles.β
- π: I understand why you say that βCodeReuse often works against Simple Systemsβ but I can’t think of any example. Can you find one please?
- π¦: I don’t have one example, I have 10,000 examples. I personally think that almost the entire history of programming is an example.
- π¦: Consider: You want to create a simple website. You use Django, because that’s what you were taught. You’re reusing code, but it’s far in excess of what you actually need to do what you want to do. You end up writing your own systems for what Django has automated, because Django’s system was written with assumptions that don’t really apply for your situation. For example, you’re writing a wiki like Oddmuse, and Django admin interfaces assume that Users have passwords.
- π¨βπ: But if you want user without password you can just disable it, If you want to change anything in django standart components - you can configure or change it without any pain. You don’t need to rewrite whole framework. Also, custom components for frameworks can be reused, and it is wery useful and allows to keep systems simple - programmers don’t need to write own compoments every time.
- π¦: Yes. For example, you are attempting to write a GUI that has a right-click circular menu. You discover that your GUI library has no way to implement this feature, except by a very, very strange route – by creating transparent pop-up dialogs, (say) and very carefully positioning them on the screen. You have to do some round-about things, perhaps going outside of the capabilities of the GUI system at times, in order to get what you want. It’s like this, because the library was written with assumptions that don’t really apply for your situation.
- π: Good examples! Comparing your examples and mine, the one with wikis, I noticed this: using implementations of protocols is ok, using complicated frameworks that run using the same implementations of protocols is not ok: HTTP lib is simple, Django is not.
- π¦: OK, but I’m saying something deeper than that. I’m not saying that “complicated frameworks” is at issue; I’m saying that all frameworks are in question, by the simple fact that frameworks embody assumptions. There is a fundamental ignorance between the author of the framework, and you in your situation.
- π¦: I’ve written this with the examples of off-the-shelf code-reuse, but you can also apply personal code reuse. Just it’s harder to find examples that everybody can relate to, because it’s necessarily discussed in terms of personal projects, which by definition, others don’t know about.
- π¦: Abstractly, and like I said before, every library or continent of code is written as a collection of steps and promises. Violate those promises, and you have a hard time doing what you’re doing. CodeReuse means pulling in a continent of code from somewhere else, and now you are dealing with all of the dependencies and requirements and assumptions and complexities that that continent of code brings with it.
- π¦: The people I know who are masters of SimpleSystems write by hand the things that other people go to great lengths to “oh, let’s use this package, let’s use that package.” They write it by hand because they understand that the mechanism that they need is simple, does not require much code, gets maximal effect, and creates minimal exposure. They look at the mass of code that comes from some package, and they realize, “I do not benefit from pulling in that entire body of code.” They look skeptically at code, not eagerly. They know what is meant by the Go maxim, “The Go player is reluctant to make a move.”
- π: The Law of Leaky Abstractions. Are leaky abstraction ok for simple systems? After all, some abstraction leak may provide extensibility.
- π: For protocols, it is not ok, of course.