3 ms·

A softer phrase that might work better is "All Software is Experimental". It has less pejorative connotations, and could be a shibboleth among seasoned develope

by milesf 11y ago

A softer phrase that might work better is "All Software is Experimental". It has less pejorative connotations, and could be a shibboleth among seasoned developers.

akkartik 11y ago
Yeah, exactly. But what does it mean if even seasoned developers rely on interfaces in all this experimental software staying fixed for all time? The article falls for this disconnect as well, with its great enumeration of the problems contrasting with the repeated references to interfaces as a solution. Interfaces are part of the problem. (Or more precisely, our propensity to freeze interfaces, and our reluctance to rethink interfaces at will.) My favorite bit of the article is something I've been thinking about for years: ..paradoxically the cleaner and saner your interface the more likely it is to succeed and thus more likely to become constrained by its users, to solidify. I've been idly dreaming of a future where we decouple modules not by their interfaces but by their behavior. The major failure mode of our age is premature freezing of interfaces, and it happens because it's hard to judge how done the interface is from the outside. An interface that looks really clean can be exposed by a detailed look at the implementation that covers a corner case that hasn't been addressed yet. I'm trying instead to think about the input space of a function. I'd like in future to be able to make guarantees like this: > The behavior of this function is fixed when argument foo is less than 5. However, for larger values we're still nailing down some details. The argument foo might shift from being the first to the third, or its type may change in some subtle way (that still preserves previous guarantees). So upgrading will often cause some pain. However, the upside is that the pain is bounded. You never end up in some 1% situation where upgrading your OS borks up your Rails app and takes days to fix, or breaks things in subtle ways that you don't notice for months. You know that the upgrade effort will be bounded because you know that as long as you pass in the right value into the right slot, and as long as it's less than 5, behavior won't change and all your tests will pass. That seems like it might be superior to an interface, even if it adds a little extra work up-front. More details, in case you have any thoughts: http://akkartik.name/about http://akkartik.name/about http://akkartik.name/post/libraries2 http://akkartik.name/post/libraries2
- akkartik 11y ago
  I've been chatting with the author over email about my no-freezing-interfaces idea, and the discussion helped uncover two situations I haven't considered sufficiently: a) Security issues. We need some way to allow people to quickly apply certain tiny changes without having to worry about the possibility of an interface change, while ignoring all the others. b) Clients sometimes end up in situations where they can't control when upgrades happen. That would break things even worse with my approach than it already does. My proposal really relies on people being able to control when they upgrade. Back to the drawing board..

by milesf 11y ago

A softer phrase that might work better is "All Software is Experimental". It has less pejorative connotations, and could be a shibboleth among seasoned developers.

akkartik 11y ago

Yeah, exactly. But what does it mean if even seasoned developers rely on interfaces in all this experimental software staying fixed for all time? The article falls for this disconnect as well, with its great enumeration of the problems contrasting with the repeated references to interfaces as a solution. Interfaces are part of the problem. (Or more precisely, our propensity to freeze interfaces, and our reluctance to rethink interfaces at will.) My favorite bit of the article is something I've been thinking about for years: ..paradoxically the cleaner and saner your interface the more likely it is to succeed and thus more likely to become constrained by its users, to solidify. I've been idly dreaming of a future where we decouple modules not by their interfaces but by their behavior. The major failure mode of our age is premature freezing of interfaces, and it happens because it's hard to judge how done the interface is from the outside. An interface that looks really clean can be exposed by a detailed look at the implementation that covers a corner case that hasn't been addressed yet. I'm trying instead to think about the input space of a function. I'd like in future to be able to make guarantees like this: > The behavior of this function is fixed when argument foo is less than 5. However, for larger values we're still nailing down some details. The argument foo might shift from being the first to the third, or its type may change in some subtle way (that still preserves previous guarantees). So upgrading will often cause some pain. However, the upside is that the pain is bounded. You never end up in some 1% situation where upgrading your OS borks up your Rails app and takes days to fix, or breaks things in subtle ways that you don't notice for months. You know that the upgrade effort will be bounded because you know that as long as you pass in the right value into the right slot, and as long as it's less than 5, behavior won't change and all your tests will pass. That seems like it might be superior to an interface, even if it adds a little extra work up-front. More details, in case you have any thoughts: http://akkartik.name/about http://akkartik.name/about http://akkartik.name/post/libraries2 http://akkartik.name/post/libraries2

akkartik 11y ago
I've been chatting with the author over email about my no-freezing-interfaces idea, and the discussion helped uncover two situations I haven't considered sufficiently: a) Security issues. We need some way to allow people to quickly apply certain tiny changes without having to worry about the possibility of an interface change, while ignoring all the others. b) Clients sometimes end up in situations where they can't control when upgrades happen. That would break things even worse with my approach than it already does. My proposal really relies on people being able to control when they upgrade. Back to the drawing board..