4 ms·

Are you claiming the world is working-as-intended? Since bad API designers so outnumber good ones, and bad APIs get used more than they should, perhaps we shou

Are you claiming the world is working-as-intended? Since bad API designers so outnumber good ones, and bad APIs get used more than they should, perhaps we should just avoid the hard problems of API design by getting users to take a little of the load off? I consider 'standard body' to be a term of insult, synonymous with 'committee that designs'. They're great at bolt-on features, bad at rethinking or expiring designs. So the ANSI C standard still contains overflow-susceptible strcpy, and Common Lisp ends up with monstrosities like mismatch (http://www.lispworks.com/documentation/HyperSpec/Body/f_mismat.htm http://www.lispworks.com/documentation/HyperSpec/Body/f_mism...; http://dreamsongs.net/Files/PatternsOfSoftware.pdf http://dreamsongs.net/Files/PatternsOfSoftware.pdf, pg 25). All standards serve to do is perpetuate the canard that we can rely on dependencies while remaining ignorant of them.

ChuckMcM 14y ago
"Are you claiming the world is working-as-intended?" I don't think I mentioned intent. And perhaps that is where we share different world views. The current state of API design an implementation is an artifact of the processes used in designing software. I don't think there is an 'intent' any more than scarcity of a good "intentionally" drives up its price. You're blog entry is a call to action to design better APIs but you also want the rapid evolution and flexibility that you employ in delivering product. My observation is that good API design practice by its nature takes time, just like gestating a human child takes 9 months. So choose, better API or faster code evolution? Hard choice. Most folks are over in the "faster evolution" camp.
- akkartik 14y ago
  Thanks for the clarification. Hmm, I think I'm still not phrasing this clearly. I didn't mean to call for better-designed APIs, just unfrozen interfaces. When things break, make a change and put it out there. I don't think this has to be a faster/better dichotomy. Imagine a world without the notion of a stable API. Over time, some interfaces may accumulate changes and gradually remain unchanged for longer and longer periods. Eventually they stay stable so long that we can de facto start treating them like APIs. It seems a perfectly natural evolution.
  - ChuckMcM 14y ago
    That is pretty clear, it's the 'rapidly evolving' path. And it works fine except that you end up with API's with things like ReadFromStream, ReadFromMemoryOrStream, ReadFromStreamGeneric, Etc. which one might "want" to say ok the generic is "ReadFromStream" and the various sub-classes of that can be differentiated within the structure of the first argument. And after a few months, years (depending on evolution speed) you get an API that has a number of slightly different APIs, many deprecated, and none "the best", and someone new comes along and gets frustrated and writes a whole new library with a new generic API. And this process doesn't feel too bad to the folks who are primary users but the secondary users of an API see a lot of churn which keeps requiring them to rebuild and re-release code that isn't otherwise changed and for them it is painful. I'm not sure what your experience is like in this area but my most recent one has been trying to do 'outside of X11' graphics on an embedded ARM system running Linux. All of them can mmap /dev/fb0 and do very slow drawing, some use EGL, some drm/kms, some Wayland or an OpenGL ES library. But all different and yet all, in theory, running Linux. There are many competing camps making 'APIs' for direct render graphics and they all have their own quirks and goals. But there isn't any way for everyone to sit down and say, "Ok, lets see what is what." and design a reasonably clean and yet extensible API with nice versioning and a core set of features.
    - akkartik 14y ago
      Most interesting. Are all the different options open source? I'd love pointers to them all, so I can try to put myself in your shoes.
dietrichepp 14y ago
I think it's just part of the natural lifecycle of products. The purpose of a committee is not to keep the API fresh by rethinking the design. They're bad at it, but that's okay because it's not their goal. The purpose of a committee is to change the current API as little as possible, while smoothing out the concerns that stakeholders on both sides (users and implementors) have. It's something that individuals are often really bad at by comparison. The strcpy() function has to stay, because the committee cares about legacy code. This isn't a problem, because it's one function, the namespace is big, and you can always switch to Go/Rust/C#/Haskell/etc. if you don't care about legacy code.
- akkartik 14y ago
  Yeah I can coexist with standards bodies. I just disagree that the APIs they come up with can ever be 'a delight'.

ChuckMcM 14y ago

"Are you claiming the world is working-as-intended?" I don't think I mentioned intent. And perhaps that is where we share different world views. The current state of API design an implementation is an artifact of the processes used in designing software. I don't think there is an 'intent' any more than scarcity of a good "intentionally" drives up its price. You're blog entry is a call to action to design better APIs but you also want the rapid evolution and flexibility that you employ in delivering product. My observation is that good API design practice by its nature takes time, just like gestating a human child takes 9 months. So choose, better API or faster code evolution? Hard choice. Most folks are over in the "faster evolution" camp.

akkartik 14y ago
Thanks for the clarification. Hmm, I think I'm still not phrasing this clearly. I didn't mean to call for better-designed APIs, just unfrozen interfaces. When things break, make a change and put it out there. I don't think this has to be a faster/better dichotomy. Imagine a world without the notion of a stable API. Over time, some interfaces may accumulate changes and gradually remain unchanged for longer and longer periods. Eventually they stay stable so long that we can de facto start treating them like APIs. It seems a perfectly natural evolution.
- ChuckMcM 14y ago
  That is pretty clear, it's the 'rapidly evolving' path. And it works fine except that you end up with API's with things like ReadFromStream, ReadFromMemoryOrStream, ReadFromStreamGeneric, Etc. which one might "want" to say ok the generic is "ReadFromStream" and the various sub-classes of that can be differentiated within the structure of the first argument. And after a few months, years (depending on evolution speed) you get an API that has a number of slightly different APIs, many deprecated, and none "the best", and someone new comes along and gets frustrated and writes a whole new library with a new generic API. And this process doesn't feel too bad to the folks who are primary users but the secondary users of an API see a lot of churn which keeps requiring them to rebuild and re-release code that isn't otherwise changed and for them it is painful. I'm not sure what your experience is like in this area but my most recent one has been trying to do 'outside of X11' graphics on an embedded ARM system running Linux. All of them can mmap /dev/fb0 and do very slow drawing, some use EGL, some drm/kms, some Wayland or an OpenGL ES library. But all different and yet all, in theory, running Linux. There are many competing camps making 'APIs' for direct render graphics and they all have their own quirks and goals. But there isn't any way for everyone to sit down and say, "Ok, lets see what is what." and design a reasonably clean and yet extensible API with nice versioning and a core set of features.
  - akkartik 14y ago
    Most interesting. Are all the different options open source? I'd love pointers to them all, so I can try to put myself in your shoes.

dietrichepp 14y ago

I think it's just part of the natural lifecycle of products. The purpose of a committee is not to keep the API fresh by rethinking the design. They're bad at it, but that's okay because it's not their goal. The purpose of a committee is to change the current API as little as possible, while smoothing out the concerns that stakeholders on both sides (users and implementors) have. It's something that individuals are often really bad at by comparison. The strcpy() function has to stay, because the committee cares about legacy code. This isn't a problem, because it's one function, the namespace is big, and you can always switch to Go/Rust/C#/Haskell/etc. if you don't care about legacy code.

akkartik 14y ago
Yeah I can coexist with standards bodies. I just disagree that the APIs they come up with can ever be 'a delight'.