7 ms·

Simple Software Manifesto

82 points by Spakman 7y ago

Porthos9K 7y ago
This reminds me of suckless. https://suckless.org/philosophy/ https://suckless.org/philosophy/
- Koshkin 7y ago
  There is something weird about trying to put a layer of simple software on top of an astonishingly complex system kernel. (RiscOS, for example, looks more balanced in that regard.)
  - Porthos9K 7y ago
    I'm tempted to suggest that the suckless people are on Linux because they can't handle OpenBSD or Plan 9, but that would be cruel.
nullspace 7y ago
> There is only one correct way to do something .... so take great care in doing it right the first time. I hear this a lot, in various contexts, and I even used say it a lot. But this has actually stopped making sense for me. I don’t think I’ve ever genuinely seen a case where there is only one obvious way to do something, or that there’s a way that is obviously the “right” way. Everything non-trivial is chock full of trade offs and hidden corners that could make it obviously wrong in hindsight. Does someone disagree? Can you share your perspective.
- GR-O-ND 7y ago
  This certainly seems a bit too idealistic. Not only is a problem with a single correct solution a rare thing indeed, but in my experience complexity often springs from shifting priorities and requirements for the software coming from sources outside of our control (ie, management or the client), and digging in to determine the most elegant solution is often not within the time budget for completing the project. While I agree that simplicity is always better than complexity, in practice it is an abstract target rather than a hard requirement.
- ceautery 7y ago
  I agree with you. If there is one correct way, then software writers are fungible, and software can be built with commodity parts. I don't think this is true. If it is, then we have an awful hard time finding correct ways; just look at how many sorting algorithms there are.
  - gerbilly 7y ago
    > If there is one correct way, then software writers are fungible I don't believe that follows. For example, there is one 'correct way' to unscramble a rubiks cube, but humans unscramble them in a much more roundabout manner. Just because there is one correct way to do it doesn't imply that all rubiks cube solvers are fungible. This is because of the very high cognitive load of finding the correct way. Math, especially number theory, is full of conjectures that are easy to state but take hundreds of years to resolve, and at it's base computer science is math.
    - Supermancho 7y ago
      > For example, there is one 'correct way' to unscramble a rubiks cube Thats not true from a mechanical standpoint. From start, rotate an edge 180degrees. Now you can turn it right 180 or left 180. Making 2 coins show the same face (when they differ) doesnt have one correct algorithm, in the same vein. Developers necessarily interact with apis at this level and generalize from these choices.
      - gerbilly 7y ago
        The integrity of my rubik's cube analogy isn't critical to my argument, but... Even allowing for equivalent rotations as you mention, the method humans use to unscramble a rubik's cube is far far from optimal because we can't grok a scrambled rubik's cube then just execute the optimal solution. Also this is just pedantry because WLOG you could just name those equivalent 180 rotations as a single operation anyway.
        Supermancho 7y ago
- williamdclt 7y ago
  Completely agree. I'd change this whole line to something like: "There is never only one way to do something. You can't know which is correct, so go for the simplest option that is easy to change later"
  - AstralStorm 7y ago
    Unless you happen to know which is correct, such as when working with a full specification. Complete trumps simple. (Grumble grumble when parts of protocols are ignored for not even simplicity.)
  - gerbilly 7y ago
    > go for the simplest option that is easy to change later And once customers get their hands on your simple thing, management won't let you change it to something better... (Also known as, "The demo becomes the product.") Your simple solution is embedded in a complex social reality. If you're not taking that into account, it probably won't stay simple for long: i.e. simple to maintain, simple to operate, simple to build new features on.
- no_flags 7y ago
  Perhaps the author meant something like: "There is only one correct way [for a user] to do something [with your software]"? That would kind of make more sense with the follow up remark that two ways is more complex. Otherwise I completely agree, every non-trivial design will involve tradeoffs.
- Ididntdothis 7y ago
  The thinking that there is only one correct way is very damaging. In reality there are almost several ways to do something. And each of these ways can be successful if done well or be a disaster if done wrong. So instead of constantly adjusting to reality (which is what Agile should be) we spend a lot of time on ideological discussions and less time on action.
- specialist 7y ago
  I too have flipped my position on this. I used to be exhausted by so many libraries which all do more or less the same thing. I often imagined a fantasy penultimate implementation which would moot all the other partial or less optimal alternatives. I now believe that each use case entails very different tradeoffs. I now believe that fit and finish matter more than completeness. Further, I enthusiastically support reinventing the wheel, for self study, batting practice, or just for kicks.
- anderspitman 7y ago
  I agree that as read literally, it's too much. I interpreted the author's intent as, "there may be multiple correct ways to do something, but pick 1 simple way and enforce that being the way it's done in the future."
GR-O-ND 7y ago
This also reminds me of OpenBSD, in particular Ted Unangst. He's famous for deleting features that add complexity without any significant benefit or are only useful in a small number of edge cases. For instance, the replacement of sudo (with its massively complicated configuration syntax) with doas.
jagger27 7y ago
apk truly is a great package manager. Glad to see it mentioned here. It’s such a bummer going back to aptitude after using it in my lighter weight VMs.
pron 7y ago
Every new generation of programmers starts a crusade to simplify without first trying to understand why we're not "simple" despite the previous generation having done the same. Of course, one possible explanation could be that without a constant crusade for simplicity we'd be in a far worse place; the "permanent revolution" explanation. But is this the right explanation? Turing Award winning computer scientist Fred Brooks had this to say: > The complexity of software is an essential property, not an accidental one. Hence, descriptions of a software entity that abstract away its complexity often abstracts away its essence. (No Silver Bullet, 1986) > Complexity is the business we are in, and complexity is what limits us. (No Silver Bullet Refired, 1995) The reason "complexity is the business we are in" is that software doesn't live in a vacuum. Like the economy and like bureaucracy, it is built to serve a certain social purpose. Of course, there needs to be a constant struggle not to over-complicate, but it should be done with the understanding that over-simplification is just as problematic.
- adgasf 7y ago
  The question is: is this thing inherently complex or is it more complicated than it needs to be? In software there are many things that are more complex than they need to be.
  - nivenhuh 7y ago
    Software development is an additive practice, where opinions and ideas are usually added to a big-ole-shipping-ball of software. I think this is where most complexity comes from. Sometimes it can be a subtractive practice, where a person can delete / simplify, but this happens much less than it should.
    - ngneer 7y ago
      Same with security, unfortunately.
      - utopian3 7y ago
        Ironicaly, complexity is the enemy of security (as I’ve heard quoted a few times)
cocktailpeanuts 7y ago
Don't #2 and #3 contradict? > Constraining the user to simple tools encourages creativity and allows the system to be more quickly understood > There is only one correct way to do something, because two ways would be more complex When you encourage creativity with combinations of simple tools, creative people will come up with multiple ways of doing things.
- Jwarder 7y ago
  I read the "only one correct way" to be a per-tool guideline. When looking a tool to do a specific task then (ideally) the tool should just process input with minimal futzing with configuration options. If you need to do something special then you should have a special tool.
  - OrderlyTiamat 7y ago
    That seems reasonable. Though in the context of packages etc, i would like to then introduce the term "toolset". Just because a piece of software is a single package doesn't mean it has to be a single tool. It is much more simple to have a bunch of tools for related tasks collected in a single toolset rather then making seperate apps for each one- never mind the overhead that the last approach would create.
- oconnor663 7y ago
  Yeah "encourages creativity" struck me as the hand-waviest part of that document. It sounds like a euphemism for "requires more work".
AlexandrB 7y ago
What’s wrong with Perl? Also, with no C macros there are no C generics. I wish the author luck in maintaining that mess.
- HelloNurse 7y ago
  With no C macros there is no C at all. This kind of arbitrary simplification is particularly unfortunate because C is a professional, Dangerous tool; removing the main way to organize code is like simplifying a chainsaw by omitting power switch interlocks.
- anderspitman 7y ago
  Go doesn't have generics either, and I've found it to be incredibly useful and productive.
- etripe 7y ago
  > What’s wrong with Perl? Looking at their central axioms, I would guess: 1 - simple software breaks in simple ways: weak, dynamic typing means a lot of problems trivially solved by static and/or strong typing. 2 - simple tools: no idea. I remember cpan being fairly great and perldoc being excellent. 3 - one correct way to do thing versus perl's TMTOWTDI central theme 4 - dependencies are part of the system: lots of CPAN modules, so there's a tendency to import black box modules instead of writing it yourself and retaining ownership. 5 - standards are useful but full of cruft: perl has a much larger standard lib than, say, Go or Python as far as I understand. As to why it would be what's wrong with git: after a cursory glance at the git repo (0), I would guess the problem is that it still contains .perl files? [0]: https://github.com/git/git/search?l=Perl https://github.com/git/git/search?l=Perl
CptMauli 7y ago
Just from some discussions from the last weeks, I don't think simple is possible anymore: just Unicode and Font Rendering by themselves have a complexity which boggles the mind. If you then consider stuff like authentication/authorization, i18n and support for blind people its clear that "simple" just doesn't cut it.
- buboard 7y ago
  humans have a limited ability to think up complex stuff. our working memory can hold 7 parts at a time. so our systems must be hierarchically designed to be simple enough to be workable by humans. certain aspects of the "modern way of development" range from needlessly complex to batshit crazy, e.g. web development.
- lifthrasiir 7y ago
  A common excuse is that they target "expert users" and not everyone. While I can imagine a specific set of "expert users" that this excuse will work, not every "expert user" will agree to that.
fefe23 7y ago
I have come to believe that we are dealing not with a domain specific problem but with the human condition itself. I call this my gradient theory. Consider human learning as an optimization in the mathematical sense. Note that humans are good at learning things along a gradient. Now note that this is not just about how the learning works but also how far we go. For example, if a human thinks it is too cold, they turn the knob not where they want the temperature to be but much farther up, and then when the desired temperature is reached, they turn it back. Or consider how you find a page in a book. You overshoot and then go back. Or how you choose the speed when driving. You go as fast as you feel comfortable, and you find that by overshooting and correcting. I think this is inherent in humans. Evolution made us this way. The downside is that humans are bad in environments where there is no clear limit or where you can't correct after overshooting, for example driving too fast and then having an accident, or substance abuse. Now take this thought and apply it to programming. If you find me a way to work with complexity, for example modularization, abstracting it away, etc., it will not lead to us writing a good version of the software we had before. It will lead us to writing larger software that will then again be at the limit of what we can do with the technology available. So far it is just a theory, but I can see in my software selection that all the programs that I consider good and simple in the sense that this manifesto describes, all of those are old programs that were written when the functionality they offer was the limit of what was achievable with technology back then. The reason they did not metastasize into something unwieldly is that a) they did but it was still comparatively small or b) they already contain all the features anyone could think of. Try comparing two programs of your choice that do essentially the same. You will find that if there is an old and a new one, the newer one will be bigger and slower and usually work in less environments and have less features. It also turns out that no two people have the same idea of what "simple" means. For me, with software, simple means it does all I really need it to do, and nothing else. Other people usually need it to do other things and they don't need some of the stuff I need.
- naasking 7y ago
  > If you find me a way to work with complexity, for example modularization, abstracting it away, etc., it will not lead to us writing a good version of the software we had before. It will lead us to writing larger software that will then again be at the limit of what we can do with the technology available. So basically Parkinson's law applied to complexity rather than time. I think it's definitely true. More complex software is (ideally) more versatile, handles more cases of the problem domain, and so there's competitive pressure to make software as complex as is feasible to solve as many problem as possible, and thus, provide as much value as possible. The ceiling is exactly as you said: what level of complexity is manageable given the other constraints that must be satisfied (performance, robustness, etc.)? Edit: to be clear, I mean "essential complexity" above, not accidental complexity from poor designs. Being able to handle more essential complexity is a good thing.
gerbilly 7y ago
Ugh, I don't share this sentiment. Each new generation of programmers creates new tools to replace the 'complex' ones that came before without even bothering to understand them. In my 25 year career I've seen it multiple times. We are all going downhill. Attention spans in the smartphone era might be preventing people from reading the f*ing manual. This means that any system or library which has an operating model that must be understood before it can be effectively used¹ simply can't be understood by the majority of programmers today. 1: The currently popular things in software world are mostly the type of system that lack such a model and which can be 'mastered' by asking discrete questions on stack overflow. This lack of complexity causes a loss of expressive power.
- adamsea 7y ago
  I would also add that the economic conditions of the software industry are stacked against endeavoring to master and use a complex and thus powerful and expressive system / library
- phendrenad2 7y ago
  And no one even writes the manual anymore. Software project documentation is a disaster.
deleted 7y ago
[deleted]
pcr910303 7y ago
Every software has a reason to be complex. Often software authors desire to make simple software by removing such features regarded ‘complex’ without understanding why those features were introduced (mostly because they don’t use them). The consequences is that people who are in the minority can’t use the software. As a CJK person, the most prominent example is multilingual support in the FOSS community; I still have not seen any Linux GUI app with proper out-of-the-box IME support (and that includes DEs, WMs, etc...) mostly because for some reason (hint, most are from the western world) the devs of Linux distributions turn off IME support by default. Is it really ‘simple’ to turn off some features that you don’t use, resulting in total breakage of apps when the feature is in use? Really?
- AnIdiotOnTheNet 7y ago
  I tihnk that's just a symptom of how FOSS devs think about GUIs. GUI is largely not something FOSS developers actually use. The design of FOSS GUIs makes it seem as though "GUI" is something they've read about in text books and personally only see value in as a fancy tmux. Consequently, the only mental model they have for someone who actually uses a GUI is the kind of person who only needs a web kiosk.
  - PavlovsCat 7y ago
    > the only mental model they have for someone who actually uses a GUI is the kind of person who only needs a web kiosk They should check out Directory Opus -- and I mean really check out the documentation, scripting language, all of it. Now that is software. I suspect many have this mental model because it allows them to be lazy and make lame things, just like not taking 10 minutes to make the CSS nice is called "minimalistic" and not "fucking inept".
- Gunax 7y ago
  I think this is the most concise view of the problem I had read. I am going to use your comment as an analogy.
- anderspitman 7y ago
  > Every software has a reason to be complex Yep. The problem is that sometimes the reason is the authors are trying to do the last 80% of work required to add the last 20% of features, which 99% of users will never need.
frou_dh 7y ago
My related observation is that the phrase "simple yet powerful" is the biggest cliché in developer/techie-facing marketing of software: https://github.com/search?q=%22simple+yet+powerful%22&type=Code https://github.com/search?q=%22simple+yet+powerful%22&type=C... Is there any camp that DOESN'T consider their preferred way of doing thing to be simple yet powerful?
Koshkin 7y ago
It shouldn't be just about software. Hardware has become astonishingly complex as well. Forget about a high quality superhet radio containing 15 transistors, or a CPU with a manageable instruction set and an assembler that is a pleasure for a human to write in. No doubt modern systems are better than old ones, but I miss those times somehow...
- no_flags 7y ago
  Is that a bad thing though? Modern CPUs seem to be incredibly reliable. I think much of the complexity has to do with the the fact that all the low hanging performance improvements have long since been implemented. To continue to get faster, sometimes the only option is to increase the complexity of the design.
stiray 7y ago
My proposals, under high level programming something derived from: - thou shall learn how to use the wheel, thou shell not reimplement it instead - best software barely satisfies task it was made for - antipasta statement: no lasignas, no spaghetti and no raviolli - the code forming interface will be at max 20% of actual code written - no interface will be designed to solve all humanity problems for next millenia I think that all those were hugest pains I had within 23+ years of development. What were yours?
majewsky 7y ago
> We target C99 or C11 C is anything but simple. It looks simple on the outside, then beats you to death with undefined behavior and either overexplicitness (if you don't use macros) or nested-macros hell (if you do). Their choice of C is routed more in the authors coming from the Unix community, not in their desire for simple software. If anything, they should start with a truly simple programming language. Something like Go minus huge runtime and maybe plus basic generics.
- t0astbread 7y ago
  Or not make a choice about the underlying tech at all because it'll always be simple to some but complex to others.
- dkersten 7y ago
  I was going to say something similar. If you really want a simple system, maybe avoid C and stick with something memory-safe. Overall, I'm not sure what to make of this page. C is simple, git overdid it, etc. Oh ok.
- anderspitman 7y ago
  I disagree. I think C is simple, but not easy[0]. I actually see explicitness as a sign of simplicity. It makes things obvious. Folks always cite undefined behavior, but I can't recall a single instance over the past 12 years of this causing me a day-to-day problem. I'm sure it does bite people though, I just don't relate personally. [0] https://www.infoq.com/presentations/Simple-Made-Easy/ https://www.infoq.com/presentations/Simple-Made-Easy/
adamfeldman 7y ago
"Simple Made Easy", a talk by Rich Hickey https://news.ycombinator.com/item?id=4173854 https://news.ycombinator.com/item?id=4173854
ptah 7y ago
simple for developers != simple for users
bitwize 7y ago
Yet more suckless-style posing. Ho fucking hum. Software is complex because the real world is messy. That messiness cannot ever be "abstracted away", it can only be hidden. You can't derive a better software stack from first principles. What we have is the tireless work of many people, quite a few of whom are smarter than you. Rust and LLVM, for instance, are much more fit for purpose than "my pet compiler backend + my favorite C subset" because even the most disciplined C subset is still full of UB traps and Rust has had years going on a decade of work, by many hands, addressing the very cases where C falls flat on its ass. The same with LLVM vs. whatever brain fart J. Random Hacker thinks up as an ideal abstract machine,
- naasking 7y ago
  > That messiness cannot ever be "abstracted away", it can only be hidden. How would you hide something without hiding it behind an abstraction? > You can't derive a better software stack from first principles. What do you consider "first principles"?
blackbrokkoli 7y ago
> Constraining the user to simple tools encourages creativity and allows the system to be more quickly understood. This supports the removal of complicated features. Oh god, no. This horrible idea escalated so far that there is now a billion dollar industry (RPA) automating braindead tasks just because software can not be arsed any more to include API, code/CLI based access or, to steal the wording, complex tools at all. IMO this is another round of weirdly religious adherence to "UX" schemes which ends in massive damage, like the unconditional love for whitespace everywhere. Please stop using "simplicity" as a cop out to prevent having to build software that, for example, has basic things like stack deletion. The result will just suck.
bachmeier 7y ago
> Simple software manifesto Excellent! > There is only one correct way to do something !!! The correct way to do something depends on what else you're doing at the same time. > Simple software in practice > C Dear God
0x445442 7y ago
I suggest the biggest problem we have in the industry is a laziness towards engineering and an unwillingness by business to accept the law of fast, good and cheap. Very few organizations use real data and the scientific method to make decisions on architectures and design. Most rely on anecdotes, gut feel, politics and software cults to make these decisions. Consequently, there's rarely real proof on the advantages of one approach over another. The rigor, and thus cost, needed to make those determinations is perceived to be too great but the reality is, those perceptions are often unfounded when considering the total cost of software. This all hit me years ago when working for company that had to go through CMMI certification. As part of the effort, a consultant would come out quarterly to coach us along and monitor our progress. During that time period I noticed a significant portion of my time was now spent on the implementation of the process. When the consultant was out for a visit I told him I had concerns because we did not have a charge number for the extra time it was taking to implement the process. He asked why that would be necessary and I asked, how else could you make an objective determination on the benefit/cost ratio of implementing the process being greater than one. Disappointingly, the blank stare ensued.
faisalhackshah 7y ago
Why use C? Constrained with no macros? What about undefined behavior? Rewrite in Zig!
HelloNurse 7y ago
Simplistic software manifesto. 1. All software breaks, so let's avoid failure by not even trying. 2. Constraining the user to simple tools, because the user is an idiot. 3. There is only one correct way to do something, and it's mine. Coming up with one mediocre way to do things is already a great accomplishment; thinking about design tradeoffs is unthinkable. YOLO! 4. The dependencies of a system are not fun, so they are your responsibility. Good luck. 5. Standards are a source of inspiration, idiots (see #2 above) aren't going to run into interoperability problems, missing features, and other consequences of implementing only the "simple" parts of the standard. The cproc missing features list is a brief but very insightful example of this way of thinking (I mean, this way of not thinking).
Pete_D 7y ago
I would suggest sinit for init / supervisor: https://core.suckless.org/sinit/ https://core.suckless.org/sinit/
btbuildem 7y ago
I believe the complexity is inherent, and we haven't yet found a way to handle it gracefully. I'd like to note that "simple software" means a different thing to the developer, and to the user. And in the grand scheme of things, the developer and all the code he wrote is highly irrelevant. We'd like to think we are, but how much does it really matter what kind of trowel the mason used, and how clean he kept it? What matters is the cathedral he built, the feel of the space within, the durability of the walls. In my view, the complexity is closely related to scale. I'd like to draw a parallel with nature, where things scale linearly up to some critical point, at which a system goes through reorganization and only then continues to grow. I think mimicking this phenomenon can be a path towards software simplicity.
als0 7y ago
> POSIX should probably be replaced when the time is right. Everyone loves to bash POSIX. The idea of replacing it lingers on, but has anyone considered the idea of updating POSIX to remove the gnarly parts? This is a somewhat incompatible change and would have to be versioned appropriately.

82 points by Spakman 7y ago

Porthos9K 7y ago

This reminds me of suckless. https://suckless.org/philosophy/ https://suckless.org/philosophy/

Koshkin 7y ago
There is something weird about trying to put a layer of simple software on top of an astonishingly complex system kernel. (RiscOS, for example, looks more balanced in that regard.)
- Porthos9K 7y ago
  I'm tempted to suggest that the suckless people are on Linux because they can't handle OpenBSD or Plan 9, but that would be cruel.

nullspace 7y ago

> There is only one correct way to do something .... so take great care in doing it right the first time. I hear this a lot, in various contexts, and I even used say it a lot. But this has actually stopped making sense for me. I don’t think I’ve ever genuinely seen a case where there is only one obvious way to do something, or that there’s a way that is obviously the “right” way. Everything non-trivial is chock full of trade offs and hidden corners that could make it obviously wrong in hindsight. Does someone disagree? Can you share your perspective.

GR-O-ND 7y ago
This certainly seems a bit too idealistic. Not only is a problem with a single correct solution a rare thing indeed, but in my experience complexity often springs from shifting priorities and requirements for the software coming from sources outside of our control (ie, management or the client), and digging in to determine the most elegant solution is often not within the time budget for completing the project. While I agree that simplicity is always better than complexity, in practice it is an abstract target rather than a hard requirement.
ceautery 7y ago
I agree with you. If there is one correct way, then software writers are fungible, and software can be built with commodity parts. I don't think this is true. If it is, then we have an awful hard time finding correct ways; just look at how many sorting algorithms there are.
- gerbilly 7y ago
  > If there is one correct way, then software writers are fungible I don't believe that follows. For example, there is one 'correct way' to unscramble a rubiks cube, but humans unscramble them in a much more roundabout manner. Just because there is one correct way to do it doesn't imply that all rubiks cube solvers are fungible. This is because of the very high cognitive load of finding the correct way. Math, especially number theory, is full of conjectures that are easy to state but take hundreds of years to resolve, and at it's base computer science is math.
  - Supermancho 7y ago
    > For example, there is one 'correct way' to unscramble a rubiks cube Thats not true from a mechanical standpoint. From start, rotate an edge 180degrees. Now you can turn it right 180 or left 180. Making 2 coins show the same face (when they differ) doesnt have one correct algorithm, in the same vein. Developers necessarily interact with apis at this level and generalize from these choices.
    - gerbilly 7y ago
      The integrity of my rubik's cube analogy isn't critical to my argument, but... Even allowing for equivalent rotations as you mention, the method humans use to unscramble a rubik's cube is far far from optimal because we can't grok a scrambled rubik's cube then just execute the optimal solution. Also this is just pedantry because WLOG you could just name those equivalent 180 rotations as a single operation anyway.
      - Supermancho 7y ago
williamdclt 7y ago
Completely agree. I'd change this whole line to something like: "There is never only one way to do something. You can't know which is correct, so go for the simplest option that is easy to change later"
- AstralStorm 7y ago
  Unless you happen to know which is correct, such as when working with a full specification. Complete trumps simple. (Grumble grumble when parts of protocols are ignored for not even simplicity.)
- gerbilly 7y ago
  > go for the simplest option that is easy to change later And once customers get their hands on your simple thing, management won't let you change it to something better... (Also known as, "The demo becomes the product.") Your simple solution is embedded in a complex social reality. If you're not taking that into account, it probably won't stay simple for long: i.e. simple to maintain, simple to operate, simple to build new features on.
no_flags 7y ago
Perhaps the author meant something like: "There is only one correct way [for a user] to do something [with your software]"? That would kind of make more sense with the follow up remark that two ways is more complex. Otherwise I completely agree, every non-trivial design will involve tradeoffs.
Ididntdothis 7y ago
The thinking that there is only one correct way is very damaging. In reality there are almost several ways to do something. And each of these ways can be successful if done well or be a disaster if done wrong. So instead of constantly adjusting to reality (which is what Agile should be) we spend a lot of time on ideological discussions and less time on action.
specialist 7y ago
I too have flipped my position on this. I used to be exhausted by so many libraries which all do more or less the same thing. I often imagined a fantasy penultimate implementation which would moot all the other partial or less optimal alternatives. I now believe that each use case entails very different tradeoffs. I now believe that fit and finish matter more than completeness. Further, I enthusiastically support reinventing the wheel, for self study, batting practice, or just for kicks.
anderspitman 7y ago
I agree that as read literally, it's too much. I interpreted the author's intent as, "there may be multiple correct ways to do something, but pick 1 simple way and enforce that being the way it's done in the future."

GR-O-ND 7y ago

This also reminds me of OpenBSD, in particular Ted Unangst. He's famous for deleting features that add complexity without any significant benefit or are only useful in a small number of edge cases. For instance, the replacement of sudo (with its massively complicated configuration syntax) with doas.

jagger27 7y ago

apk truly is a great package manager. Glad to see it mentioned here. It’s such a bummer going back to aptitude after using it in my lighter weight VMs.

pron 7y ago

Every new generation of programmers starts a crusade to simplify without first trying to understand why we're not "simple" despite the previous generation having done the same. Of course, one possible explanation could be that without a constant crusade for simplicity we'd be in a far worse place; the "permanent revolution" explanation. But is this the right explanation? Turing Award winning computer scientist Fred Brooks had this to say: > The complexity of software is an essential property, not an accidental one. Hence, descriptions of a software entity that abstract away its complexity often abstracts away its essence. (No Silver Bullet, 1986) > Complexity is the business we are in, and complexity is what limits us. (No Silver Bullet Refired, 1995) The reason "complexity is the business we are in" is that software doesn't live in a vacuum. Like the economy and like bureaucracy, it is built to serve a certain social purpose. Of course, there needs to be a constant struggle not to over-complicate, but it should be done with the understanding that over-simplification is just as problematic.

adgasf 7y ago
The question is: is this thing inherently complex or is it more complicated than it needs to be? In software there are many things that are more complex than they need to be.
- nivenhuh 7y ago
  Software development is an additive practice, where opinions and ideas are usually added to a big-ole-shipping-ball of software. I think this is where most complexity comes from. Sometimes it can be a subtractive practice, where a person can delete / simplify, but this happens much less than it should.
  - ngneer 7y ago
    Same with security, unfortunately.
    - utopian3 7y ago
      Ironicaly, complexity is the enemy of security (as I’ve heard quoted a few times)

cocktailpeanuts 7y ago

Don't #2 and #3 contradict? > Constraining the user to simple tools encourages creativity and allows the system to be more quickly understood > There is only one correct way to do something, because two ways would be more complex When you encourage creativity with combinations of simple tools, creative people will come up with multiple ways of doing things.

Jwarder 7y ago
I read the "only one correct way" to be a per-tool guideline. When looking a tool to do a specific task then (ideally) the tool should just process input with minimal futzing with configuration options. If you need to do something special then you should have a special tool.
- OrderlyTiamat 7y ago
  That seems reasonable. Though in the context of packages etc, i would like to then introduce the term "toolset". Just because a piece of software is a single package doesn't mean it has to be a single tool. It is much more simple to have a bunch of tools for related tasks collected in a single toolset rather then making seperate apps for each one- never mind the overhead that the last approach would create.
oconnor663 7y ago
Yeah "encourages creativity" struck me as the hand-waviest part of that document. It sounds like a euphemism for "requires more work".

AlexandrB 7y ago

What’s wrong with Perl? Also, with no C macros there are no C generics. I wish the author luck in maintaining that mess.

HelloNurse 7y ago
With no C macros there is no C at all. This kind of arbitrary simplification is particularly unfortunate because C is a professional, Dangerous tool; removing the main way to organize code is like simplifying a chainsaw by omitting power switch interlocks.
anderspitman 7y ago
Go doesn't have generics either, and I've found it to be incredibly useful and productive.
etripe 7y ago
> What’s wrong with Perl? Looking at their central axioms, I would guess: 1 - simple software breaks in simple ways: weak, dynamic typing means a lot of problems trivially solved by static and/or strong typing. 2 - simple tools: no idea. I remember cpan being fairly great and perldoc being excellent. 3 - one correct way to do thing versus perl's TMTOWTDI central theme 4 - dependencies are part of the system: lots of CPAN modules, so there's a tendency to import black box modules instead of writing it yourself and retaining ownership. 5 - standards are useful but full of cruft: perl has a much larger standard lib than, say, Go or Python as far as I understand. As to why it would be what's wrong with git: after a cursory glance at the git repo (0), I would guess the problem is that it still contains .perl files? [0]: https://github.com/git/git/search?l=Perl https://github.com/git/git/search?l=Perl

CptMauli 7y ago

Just from some discussions from the last weeks, I don't think simple is possible anymore: just Unicode and Font Rendering by themselves have a complexity which boggles the mind. If you then consider stuff like authentication/authorization, i18n and support for blind people its clear that "simple" just doesn't cut it.

buboard 7y ago
humans have a limited ability to think up complex stuff. our working memory can hold 7 parts at a time. so our systems must be hierarchically designed to be simple enough to be workable by humans. certain aspects of the "modern way of development" range from needlessly complex to batshit crazy, e.g. web development.
lifthrasiir 7y ago
A common excuse is that they target "expert users" and not everyone. While I can imagine a specific set of "expert users" that this excuse will work, not every "expert user" will agree to that.

fefe23 7y ago

I have come to believe that we are dealing not with a domain specific problem but with the human condition itself. I call this my gradient theory. Consider human learning as an optimization in the mathematical sense. Note that humans are good at learning things along a gradient. Now note that this is not just about how the learning works but also how far we go. For example, if a human thinks it is too cold, they turn the knob not where they want the temperature to be but much farther up, and then when the desired temperature is reached, they turn it back. Or consider how you find a page in a book. You overshoot and then go back. Or how you choose the speed when driving. You go as fast as you feel comfortable, and you find that by overshooting and correcting. I think this is inherent in humans. Evolution made us this way. The downside is that humans are bad in environments where there is no clear limit or where you can't correct after overshooting, for example driving too fast and then having an accident, or substance abuse. Now take this thought and apply it to programming. If you find me a way to work with complexity, for example modularization, abstracting it away, etc., it will not lead to us writing a good version of the software we had before. It will lead us to writing larger software that will then again be at the limit of what we can do with the technology available. So far it is just a theory, but I can see in my software selection that all the programs that I consider good and simple in the sense that this manifesto describes, all of those are old programs that were written when the functionality they offer was the limit of what was achievable with technology back then. The reason they did not metastasize into something unwieldly is that a) they did but it was still comparatively small or b) they already contain all the features anyone could think of. Try comparing two programs of your choice that do essentially the same. You will find that if there is an old and a new one, the newer one will be bigger and slower and usually work in less environments and have less features. It also turns out that no two people have the same idea of what "simple" means. For me, with software, simple means it does all I really need it to do, and nothing else. Other people usually need it to do other things and they don't need some of the stuff I need.

naasking 7y ago
> If you find me a way to work with complexity, for example modularization, abstracting it away, etc., it will not lead to us writing a good version of the software we had before. It will lead us to writing larger software that will then again be at the limit of what we can do with the technology available. So basically Parkinson's law applied to complexity rather than time. I think it's definitely true. More complex software is (ideally) more versatile, handles more cases of the problem domain, and so there's competitive pressure to make software as complex as is feasible to solve as many problem as possible, and thus, provide as much value as possible. The ceiling is exactly as you said: what level of complexity is manageable given the other constraints that must be satisfied (performance, robustness, etc.)? Edit: to be clear, I mean "essential complexity" above, not accidental complexity from poor designs. Being able to handle more essential complexity is a good thing.

gerbilly 7y ago

Ugh, I don't share this sentiment. Each new generation of programmers creates new tools to replace the 'complex' ones that came before without even bothering to understand them. In my 25 year career I've seen it multiple times. We are all going downhill. Attention spans in the smartphone era might be preventing people from reading the f*ing manual. This means that any system or library which has an operating model that must be understood before it can be effectively used¹ simply can't be understood by the majority of programmers today. 1: The currently popular things in software world are mostly the type of system that lack such a model and which can be 'mastered' by asking discrete questions on stack overflow. This lack of complexity causes a loss of expressive power.

adamsea 7y ago
I would also add that the economic conditions of the software industry are stacked against endeavoring to master and use a complex and thus powerful and expressive system / library
phendrenad2 7y ago
And no one even writes the manual anymore. Software project documentation is a disaster.

deleted 7y ago

[deleted]

pcr910303 7y ago

Every software has a reason to be complex. Often software authors desire to make simple software by removing such features regarded ‘complex’ without understanding why those features were introduced (mostly because they don’t use them). The consequences is that people who are in the minority can’t use the software. As a CJK person, the most prominent example is multilingual support in the FOSS community; I still have not seen any Linux GUI app with proper out-of-the-box IME support (and that includes DEs, WMs, etc...) mostly because for some reason (hint, most are from the western world) the devs of Linux distributions turn off IME support by default. Is it really ‘simple’ to turn off some features that you don’t use, resulting in total breakage of apps when the feature is in use? Really?

AnIdiotOnTheNet 7y ago
I tihnk that's just a symptom of how FOSS devs think about GUIs. GUI is largely not something FOSS developers actually use. The design of FOSS GUIs makes it seem as though "GUI" is something they've read about in text books and personally only see value in as a fancy tmux. Consequently, the only mental model they have for someone who actually uses a GUI is the kind of person who only needs a web kiosk.
- PavlovsCat 7y ago
  > the only mental model they have for someone who actually uses a GUI is the kind of person who only needs a web kiosk They should check out Directory Opus -- and I mean really check out the documentation, scripting language, all of it. Now that is software. I suspect many have this mental model because it allows them to be lazy and make lame things, just like not taking 10 minutes to make the CSS nice is called "minimalistic" and not "fucking inept".
Gunax 7y ago
I think this is the most concise view of the problem I had read. I am going to use your comment as an analogy.
anderspitman 7y ago
> Every software has a reason to be complex Yep. The problem is that sometimes the reason is the authors are trying to do the last 80% of work required to add the last 20% of features, which 99% of users will never need.

frou_dh 7y ago

My related observation is that the phrase "simple yet powerful" is the biggest cliché in developer/techie-facing marketing of software: https://github.com/search?q=%22simple+yet+powerful%22&type=Code https://github.com/search?q=%22simple+yet+powerful%22&type=C... Is there any camp that DOESN'T consider their preferred way of doing thing to be simple yet powerful?

Koshkin 7y ago

It shouldn't be just about software. Hardware has become astonishingly complex as well. Forget about a high quality superhet radio containing 15 transistors, or a CPU with a manageable instruction set and an assembler that is a pleasure for a human to write in. No doubt modern systems are better than old ones, but I miss those times somehow...

no_flags 7y ago
Is that a bad thing though? Modern CPUs seem to be incredibly reliable. I think much of the complexity has to do with the the fact that all the low hanging performance improvements have long since been implemented. To continue to get faster, sometimes the only option is to increase the complexity of the design.

stiray 7y ago

My proposals, under high level programming something derived from: - thou shall learn how to use the wheel, thou shell not reimplement it instead - best software barely satisfies task it was made for - antipasta statement: no lasignas, no spaghetti and no raviolli - the code forming interface will be at max 20% of actual code written - no interface will be designed to solve all humanity problems for next millenia I think that all those were hugest pains I had within 23+ years of development. What were yours?

majewsky 7y ago

> We target C99 or C11 C is anything but simple. It looks simple on the outside, then beats you to death with undefined behavior and either overexplicitness (if you don't use macros) or nested-macros hell (if you do). Their choice of C is routed more in the authors coming from the Unix community, not in their desire for simple software. If anything, they should start with a truly simple programming language. Something like Go minus huge runtime and maybe plus basic generics.

t0astbread 7y ago
Or not make a choice about the underlying tech at all because it'll always be simple to some but complex to others.
dkersten 7y ago
I was going to say something similar. If you really want a simple system, maybe avoid C and stick with something memory-safe. Overall, I'm not sure what to make of this page. C is simple, git overdid it, etc. Oh ok.
anderspitman 7y ago
I disagree. I think C is simple, but not easy[0]. I actually see explicitness as a sign of simplicity. It makes things obvious. Folks always cite undefined behavior, but I can't recall a single instance over the past 12 years of this causing me a day-to-day problem. I'm sure it does bite people though, I just don't relate personally. [0] https://www.infoq.com/presentations/Simple-Made-Easy/ https://www.infoq.com/presentations/Simple-Made-Easy/

adamfeldman 7y ago

"Simple Made Easy", a talk by Rich Hickey https://news.ycombinator.com/item?id=4173854 https://news.ycombinator.com/item?id=4173854

ptah 7y ago

simple for developers != simple for users

bitwize 7y ago

Yet more suckless-style posing. Ho fucking hum. Software is complex because the real world is messy. That messiness cannot ever be "abstracted away", it can only be hidden. You can't derive a better software stack from first principles. What we have is the tireless work of many people, quite a few of whom are smarter than you. Rust and LLVM, for instance, are much more fit for purpose than "my pet compiler backend + my favorite C subset" because even the most disciplined C subset is still full of UB traps and Rust has had years going on a decade of work, by many hands, addressing the very cases where C falls flat on its ass. The same with LLVM vs. whatever brain fart J. Random Hacker thinks up as an ideal abstract machine,

naasking 7y ago
> That messiness cannot ever be "abstracted away", it can only be hidden. How would you hide something without hiding it behind an abstraction? > You can't derive a better software stack from first principles. What do you consider "first principles"?

blackbrokkoli 7y ago

> Constraining the user to simple tools encourages creativity and allows the system to be more quickly understood. This supports the removal of complicated features. Oh god, no. This horrible idea escalated so far that there is now a billion dollar industry (RPA) automating braindead tasks just because software can not be arsed any more to include API, code/CLI based access or, to steal the wording, complex tools at all. IMO this is another round of weirdly religious adherence to "UX" schemes which ends in massive damage, like the unconditional love for whitespace everywhere. Please stop using "simplicity" as a cop out to prevent having to build software that, for example, has basic things like stack deletion. The result will just suck.

bachmeier 7y ago

> Simple software manifesto Excellent! > There is only one correct way to do something !!! The correct way to do something depends on what else you're doing at the same time. > Simple software in practice > C Dear God

0x445442 7y ago

I suggest the biggest problem we have in the industry is a laziness towards engineering and an unwillingness by business to accept the law of fast, good and cheap. Very few organizations use real data and the scientific method to make decisions on architectures and design. Most rely on anecdotes, gut feel, politics and software cults to make these decisions. Consequently, there's rarely real proof on the advantages of one approach over another. The rigor, and thus cost, needed to make those determinations is perceived to be too great but the reality is, those perceptions are often unfounded when considering the total cost of software. This all hit me years ago when working for company that had to go through CMMI certification. As part of the effort, a consultant would come out quarterly to coach us along and monitor our progress. During that time period I noticed a significant portion of my time was now spent on the implementation of the process. When the consultant was out for a visit I told him I had concerns because we did not have a charge number for the extra time it was taking to implement the process. He asked why that would be necessary and I asked, how else could you make an objective determination on the benefit/cost ratio of implementing the process being greater than one. Disappointingly, the blank stare ensued.

faisalhackshah 7y ago

Why use C? Constrained with no macros? What about undefined behavior? Rewrite in Zig!

HelloNurse 7y ago

Simplistic software manifesto. 1. All software breaks, so let's avoid failure by not even trying. 2. Constraining the user to simple tools, because the user is an idiot. 3. There is only one correct way to do something, and it's mine. Coming up with one mediocre way to do things is already a great accomplishment; thinking about design tradeoffs is unthinkable. YOLO! 4. The dependencies of a system are not fun, so they are your responsibility. Good luck. 5. Standards are a source of inspiration, idiots (see #2 above) aren't going to run into interoperability problems, missing features, and other consequences of implementing only the "simple" parts of the standard. The cproc missing features list is a brief but very insightful example of this way of thinking (I mean, this way of not thinking).

Pete_D 7y ago

I would suggest sinit for init / supervisor: https://core.suckless.org/sinit/ https://core.suckless.org/sinit/

btbuildem 7y ago

I believe the complexity is inherent, and we haven't yet found a way to handle it gracefully. I'd like to note that "simple software" means a different thing to the developer, and to the user. And in the grand scheme of things, the developer and all the code he wrote is highly irrelevant. We'd like to think we are, but how much does it really matter what kind of trowel the mason used, and how clean he kept it? What matters is the cathedral he built, the feel of the space within, the durability of the walls. In my view, the complexity is closely related to scale. I'd like to draw a parallel with nature, where things scale linearly up to some critical point, at which a system goes through reorganization and only then continues to grow. I think mimicking this phenomenon can be a path towards software simplicity.

als0 7y ago

> POSIX should probably be replaced when the time is right. Everyone loves to bash POSIX. The idea of replacing it lingers on, but has anyone considered the idea of updating POSIX to remove the gnarly parts? This is a somewhat incompatible change and would have to be versioned appropriately.