We Who Value Simplicity Have Built Incomprehensible Machines
What insight does the author have to offer with this essay?  It's easy to complain about complexity, harder to offer a simpler but equally capable alternative.<p>The author makes it sound like simple is easy.  As if it's just a matter of saying no to complexity, like saying no to memcpy() whenever we have a memmove() that's good enough.<p>This is not the case.  Simple is not easy.  On the contrary, simple is <i>hard</i>.  So you think "ls" has too many command-line flags; how are you going to cut the number in half?  Which ones do we keep and which ones get axed?  How are you going to provide for all the same use cases that those 35 flags were added for?<p>I'm not saying it's impossible and in fact I think it's a very worthwhile and noble cause.  But it's long, tedious, hard work, and I say this as someone who has a nearly obsessive devotion to writing small and simple software.<p>Let me tell you what it's like to design small and simple software that is practical enough to actually use.  The most important part <i>by far</i> is to leave out anything you possibly can.  If there is a feature or abstraction that could be implemented on top of your software with equal efficiency as what you could do by implementing it internally, LEAVE IT OUT.  The feature that seems so cool to you now is going to get in someone's way later on.  Your attempts to be "helpful" are going to be the next generation's bloat.<p>This is where I think the famous Worse Is Better essay (<a href="http://www.jwz.org/doc/worse-is-better.html" rel="nofollow">http://www.jwz.org/doc/worse-is-better.html</a>) goes wrong.  To the MIT guy the "right thing" is for the system to implement complex recovery logic to hide from the user that a system routine was interrupted.  And why?  So the user doesn't have to check and retry themselves?  The code to do this is trivial and can trivially be implemented in a library that everyone can then share.<p>The key to long-term simplicity is LAYERING.  The lowest layers should implement a very general and reusable abstraction, and be as absolutely non-opinionated as possible.  Layers on top can tend more towards policy.  If a higher layer is too opinionated, a user can always drop down to a lower layer.<p>I haven't actually used libpng, but from a glance at the sample code that the author is complaining about I'm inclined to say that the author's complaint is misdirected.  It looks like png is a well-designed, though very low-level API.  Using low-level APIs often requires a lot of steps; this is because the overall task is broken down into its most primitive steps.  Unless some of these steps are redundant this does <i>not</i> mean that the software is too complex.  Rather it means that the author would prefer a high-level API instead of the low-level one.  But don't demand that the lower-level API be hidden in the name of "simplicity" -- that will make someone else's life harder when their use case is not what the designers of the high-level API had in mind.