It's pretty much a given that the first few libraries solving problem X will have a sub-optimal API, especially if they aim to be both general (say read and dis

It's pretty much a given that the first few libraries solving problem X will have a sub-optimal API, especially if they aim to be both general (say read and display JPEG) and full-featured (support all the optional bits of the format or work efficiently in low-memory embedded situations, etc.) at the same time. All of that while preserving the feel and idioms of the host language. This is key since it invalidates a lot of prior experience with similar APIs. So until the "right" API coalesces from collective experience with the problem domain and APIs for similar libraries (read and display {TIFF, GIF, PNG, etc.} in $LANGUAGE) backward compatibility is not a feature you want. Wait for the second or third wave of libraries where the problem is solved and understood in a nice idiomatic way for the language and its quirks.