7 ms·

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.

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. 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. This is not the case. Simple is not easy. On the contrary, simple is hard. 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? 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. 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 by far 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. This is where I think the famous Worse Is Better essay (http://www.jwz.org/doc/worse-is-better.html http://www.jwz.org/doc/worse-is-better.html) 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. 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. 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 not 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.

david927 14y ago
The failure isn't in that we're adding too much complexity (we have to be able to create complex structures) or that we're not layering it enough (leaky abstractions build up). It's a general, and much more far-reaching, problem: our abstraction mechanisms are failing us. We need to stop complaining and put more effort into research. There are four or five projects working on this and, literally, hundreds of photo-sharing startups.
- ntoshev 14y ago
  Any links to such projects?
  - ehsanu1 14y ago
    VPRI's STEPS project is one such project: http://www.vpri.org/pdf/tr2011004_steps11.pdf http://www.vpri.org/pdf/tr2011004_steps11.pdf
- raverbashing 14y ago
  "our abstraction mechanisms are failing us... There are four or five projects working on this and, literally, hundreds of photo-sharing startups." But it's the same thing! It's the same problems And IMHO in the technical places it's getting worse every day. The reason some photo sharing apps are bought by a billion dollar is the same as why lots os people use PHP even though "it sucks". User experience and ease of use. You don't need to limit yourself to a high level abstraction (like gnome) or provide the whole "under the hood" controls like you're flying an aircraft. Complexity has to be managed and split into stages. C'mon, even VIM has a smooth learning curve (and not a learning abyss, or being shut out) And stop the very prevalent mentality in technical circles of "if you're technical you have to read the manual". User experience has a place even when editing .conf files or using a command line tool, but some people make it out of the way harder just to make it accessible only "to the true believers".
  - david927 14y ago
    Yes, everything is mixture of complexity. When an artist paints, she has to decide how simple or complex to make the work. But what we're talking about here is that once you pick up a PHP brush, you're screwed. That's why it sucks. You can't change brushes; you have a big fat crayon. And while that works for filling in the sky, you can't get any detail on the faces, for example. (Choose a fine brush and you have a different problem of spending all your time on the sky.) What I'm talking about when I say "our abstraction mechanisms are failing us" is the need to use any size brush at any time. And, as an aside, photo sharing apps are bought for billions for the same reason that tulips used to be worth a fortune. Uploading pictures of your cat is about as valuable as a 'Carnaval de Nice'.

david927 14y ago

The failure isn't in that we're adding too much complexity (we have to be able to create complex structures) or that we're not layering it enough (leaky abstractions build up). It's a general, and much more far-reaching, problem: our abstraction mechanisms are failing us. We need to stop complaining and put more effort into research. There are four or five projects working on this and, literally, hundreds of photo-sharing startups.

ntoshev 14y ago
Any links to such projects?
- ehsanu1 14y ago
  VPRI's STEPS project is one such project: http://www.vpri.org/pdf/tr2011004_steps11.pdf http://www.vpri.org/pdf/tr2011004_steps11.pdf
raverbashing 14y ago
"our abstraction mechanisms are failing us... There are four or five projects working on this and, literally, hundreds of photo-sharing startups." But it's the same thing! It's the same problems And IMHO in the technical places it's getting worse every day. The reason some photo sharing apps are bought by a billion dollar is the same as why lots os people use PHP even though "it sucks". User experience and ease of use. You don't need to limit yourself to a high level abstraction (like gnome) or provide the whole "under the hood" controls like you're flying an aircraft. Complexity has to be managed and split into stages. C'mon, even VIM has a smooth learning curve (and not a learning abyss, or being shut out) And stop the very prevalent mentality in technical circles of "if you're technical you have to read the manual". User experience has a place even when editing .conf files or using a command line tool, but some people make it out of the way harder just to make it accessible only "to the true believers".
- david927 14y ago
  Yes, everything is mixture of complexity. When an artist paints, she has to decide how simple or complex to make the work. But what we're talking about here is that once you pick up a PHP brush, you're screwed. That's why it sucks. You can't change brushes; you have a big fat crayon. And while that works for filling in the sky, you can't get any detail on the faces, for example. (Choose a fine brush and you have a different problem of spending all your time on the sky.) What I'm talking about when I say "our abstraction mechanisms are failing us" is the need to use any size brush at any time. And, as an aside, photo sharing apps are bought for billions for the same reason that tulips used to be worth a fortune. Uploading pictures of your cat is about as valuable as a 'Carnaval de Nice'.