-
Why would any software developer use an API? Well, it's not to get rid of that shirt stain you had for the last three days that's for sure. Instead, we crazy bunch use APIs to progress our software development at a faster rate. I don't really want to work with the Windows API nor do I care to open the rotten can of sardines that is the X11 API. But, thankfully, I don't have to. There are plenty of APIs that handle that for me. And they handle it very nicely too. GLFW is one of these APIs. Easy to use, fast to set up, and overall doesn't have any overhead. Handles window creation, input, and any operating system-specific stuff. It solves a clear and appropriate problem. Left pad, however, is the complete opposite. Does it solve a problem? Sure it does... if you were hit on the head with a baseball bat 17 times. Can't I at least add padding to any direction? No? Does it just have to be the left? Even though we C++ folks can say that the JavaScript weirdos are the only ones who would do such a heinous thing, that wouldn't be the entire story. It would be hypocritical even to assume that all of the useless APIs exist only in the JS ecosystem. Although being hypocritical is my strong point, even I would stop you right there. If there is an ecosystem that would be perfect for breeding unnecessarily complex, widely inefficient, and completely useless libraries, it would be C++... Rust would come at a close second but C++ is the mother of all useless and complex libraries.
-
CodeRabbit
CodeRabbit: AI Code Reviews for Developers. Revolutionize your code reviews with AI. CodeRabbit offers PR summaries, code walkthroughs, 1-click suggestions, and AST-based analysis. Boost productivity and code quality across all major languages with each PR.
-
I can give many examples of APIs that have this exact problem... but I won't. Instead, I'll be making an example of myself. Long ago (like, maybe 4 months ago), I made an API called Gravel. It was supposed to be a game framework that abstracts away all of the window creation code, input handling, rendering with OpenGL, and so on. I thought I was the king. I was getting ready to become bald, wear glasses, and call myself Bill Jobs III. I thought the API was so good. I thought it was so good, in fact, that I decided to use it and create a game. The game was called The Problem Solver. The game was supposed to be simple. I made a 3D game from scratch before. Pfft. How hard can it be? Especially now that I have this amazing API that I created... I hope you can tell there's gonna be foreshadowing here.
-
Let's take a look at an API that I extremely love and enjoy working with, stb. And specifically, stb_image. This is a library that will help you with loading image files like PNG, TIF, JPEG, and so on. It is a necessity if you're trying to make a game engine or any photo-related programs for that matter. It has one purpose: give you the pixel data--plus some information like the width and height--of the image loaded. That's it. Does it try to add some nice effects? No. Does it try to write pixel data to an image? No. Stb has another library for that single purpose. Does it try to sleep with your mom? No. That's my purpose.
-
Let's take a look at another API. Raylib. Now Raylib does a little bit more than just load images. Raylib is more of a game framework than a single-purpose library. It will create a window, handle input, load images, render pixels, handle loading and rendering fonts, and so on. Even though Raylib does multiple things, it doesn't go overboard. It tries to be simple yet robust. There's a clear vision for the library. They didn't try to force a GUI editor into the API or an alternative string type. It had one goal and that is to become a game framework. What happens when Raylib has added all the features it needs to add? Well, call it feature-complete and just move on. There's no need to bloat an API for no reason other than you "felt like it".
