|
This is an interesting article, but seems to fail to complete the point being made. Yes, having a very flexible API that has lots of possible entry points and extensions is useful to experts, but risks overwhelming those new to the API, especially if they are also new to the domain. Likewise having a convienent, inflexible API can lead to short term adoption at the expense of long term commitment. Despite making both of these points, and even then going as far as to say you can package a more flexible API into less flexible but more immediately convienent parts arbitrarily, it doesn't quite complete the point by indicating what you really want to aim for is a layered API that allows you to start off with a convienent, high level wrapper and as you need more flexibility, peel off that layer specifically in the place you need it. As ever, talking in the abstract about such things make them seem easier than they are, but still a worthwhile goal. It's slightly surprising the post doesn't quite make this point, considering that they directly link to Casey Muratori's talk on exactly this as a footnote: https://caseymuratori.com/blog_0024. Separately, I also find it interesting that there are domains that seem to be deliberately eskewing the layered approach within a single API in favour of requiring separate users to write the higher level convience libraries. Notably some of the modern graphics APIs, including WebGL and WebGPU, which provide the 'lower level' access to graphics functionality, but expect most users to use a higher level library for interacting with them (BGFX, Raylib, BabylonJS, ThreeJS etc.). |