3 ms·

Every API is Flawed

3 points by zackmorris 15y ago

akkartik 15y ago
I agree with your premise: "..we route around the damage and encapsulate it away inside our own APIs. ..if a system API is good enough, then we don’t need a library." ..but don't see how it leads to your conclusion: "Since APIs are guaranteed to be flawed, let’s accept that and work on encapsulation. Let’s replace authority with merit." Instead, my reaction is to be anti-abstraction and anti-backwards-compatibility. "Don't get suckered by interface guarantees; debug code." Implications: a) As a library/platform builder, I tell my users I make ZERO guarantees of backwards compatibility. I release no version numbers, only commits that they can pull if they want. If you build on my code, write tests or God help you. b) As a library user, I am extremely conservative about introducing new dependencies. When I do I pull it in once, write lots of tests for my application that will warn me if something breaks, or they change their interface. Basically I never make assumptions of backwards compatibility. But I never wrap dependencies in my own layers either. I try to never upgrade a dependency blindly without understanding what changed, and I rely on my tests to tell me when things break, and then I fix them to use the new interface. This is all a work in progress. I'm still playing with these ideas and working through their consequences. http://github.com/akkartik/wart/tree/unstable http://github.com/akkartik/wart/tree/unstable is built in this spirit. But the goal is clear: to attack the cruft that accumulates (like weeds) in the interstices around abstraction boundaries.
- zackmorris 15y ago
  Ya sometimes my posts get a little long and I draw conclusions that may not mesh with my original hypothesis. I should have probably written something more like: let's create our own environment and treat existing APIs with the same skepticism we would have for any other library. Right now the biggest cost to my time happens whenever I have to interface with other people's code. I race ahead very quickly on my own, but find numerous bugs either in the implementation or even the overall approach that libraries take. Show my any library, anywhere, and I'll give you anywhere from a couple to a few dozen flaws in a short time. I've actually pondered making a database of library flaws hahah.

3 points by zackmorris 15y ago

I agree with your premise: "..we route around the damage and encapsulate it away inside our own APIs. ..if a system API is good enough, then we don’t need a library." ..but don't see how it leads to your conclusion: "Since APIs are guaranteed to be flawed, let’s accept that and work on encapsulation. Let’s replace authority with merit." Instead, my reaction is to be anti-abstraction and anti-backwards-compatibility. "Don't get suckered by interface guarantees; debug code." Implications: a) As a library/platform builder, I tell my users I make ZERO guarantees of backwards compatibility. I release no version numbers, only commits that they can pull if they want. If you build on my code, write tests or God help you. b) As a library user, I am extremely conservative about introducing new dependencies. When I do I pull it in once, write lots of tests for my application that will warn me if something breaks, or they change their interface. Basically I never make assumptions of backwards compatibility. But I never wrap dependencies in my own layers either. I try to never upgrade a dependency blindly without understanding what changed, and I rely on my tests to tell me when things break, and then I fix them to use the new interface. This is all a work in progress. I'm still playing with these ideas and working through their consequences. http://github.com/akkartik/wart/tree/unstable http://github.com/akkartik/wart/tree/unstable is built in this spirit. But the goal is clear: to attack the cruft that accumulates (like weeds) in the interstices around abstraction boundaries.

zackmorris 15y ago
Ya sometimes my posts get a little long and I draw conclusions that may not mesh with my original hypothesis. I should have probably written something more like: let's create our own environment and treat existing APIs with the same skepticism we would have for any other library. Right now the biggest cost to my time happens whenever I have to interface with other people's code. I race ahead very quickly on my own, but find numerous bugs either in the implementation or even the overall approach that libraries take. Show my any library, anywhere, and I'll give you anywhere from a couple to a few dozen flaws in a short time. I've actually pondered making a database of library flaws hahah.