When I wanted to write a 3D engine, I first tried to use Direct3D. I tried for 2 years before I finally did it in OpenGL instead.
In theory, Direct3D is a clean object-oriented COM API to do things, whereas OpenGL is just a bunch of function calls that manipulate a hidden state machine. But it turns out that OpenGL was easier to deal with than Direct3D, especially in the early days.
For one, OpenGL had GLUT to make the initial “getting started” effort easier so that you could write a fairly trivial application in GLUT and a few OpenGL calls and pat yourself on the back for being a graphical genius. But, also, even though OpenGL was not designed for an object-oriented world, it was actually easier to build my own object-oriented framework that worked the way I wanted it to with an API that made no assumptions about what the code that talked to it would be structured like. In the end, Microsoft had to make Direct3D more like OpenGL before people would use it.
I believe this is one important point. A good API to talk to a fundamental system… the graphics card, or the windowing system, or the filesystem, or whatever… it needs to be able to be used all kinds of ways that only a super-genius programmer would even be able to list half of the possibilities. It’s also likely that what people want will change over time.
OpenGL and Direct3D both suck. But OpenGL sucks less in the ways that get in your way.
Now, look at some of the modern APIs. Notice how everybody who does any JavaScript programming always ends up writing a wrapper around the DOM? What would happen if the DOM worked like jQuery? Well, for apps that use jQuery, it would be great. But given that it took people years to go from DOM to jQuery, do you think there might be something better in a few more years? Do you really think everything you can do with DOM you’d want to do with jQuery?
Which reminds me of something I said a few years ago while knee deep in weird COM issues… I almost think that COM would be easy to use if somebody would make a wrapper around the base API in a way that ATL and COM both failed to do.
But, the way I see it, a base API doesn’t need to be easy to deal with. It doesn’t need to be simple. It just needs to be simple enough to gather a small bunch of users who can shake out a good wrapper from various repeated pieces of code and flexible enough that they can actually write something. So, writing an interface that sucks for the end user is not a crime… the real crime is making something that sucks so much that you can’t wrapper it properly
It’s a better solution, for an imperfect world, than trying to actually get things right for everybody right away. Just write your bare bones and get out of the way.