FAQ
In Progress
Purpose
Dear reader,
In the modern day, programming has become complex. Too complex for what most of the applications
can actually do.
One common theme that one will see mentioned in various topics, like building a rendering engine,
or even something as simple as a static website, is The Stack™: A collection of
libraries and frameworks for building solutions to problems the right way.
This is most commonly sourced from an aggregate of opinions, an admiration of complexity, even
sheer ego, but it rarely comes from the complexity or expansiveness of the problem itself.
And partially, it's to be expected; not just because software is affected by business decisions,
timelines, and all the various aspects of every-day life - but because it's easy to admire a
body of work that appears enormous. We are fascinated and astonished by big buildings and huge
imposing sculptures, because that's a signal of dedication and craftsmanship; to some, even
divine intervention.
The reality though, at least for software, is that in most situations complicated doesn't mean
good. For that matter, small and compact doesn't mean good either. There is few to no material about
how to provide solutions to specific problems, taking advantage of each problem's inherent or artificial
constraints, and optimizing for the common case. Additionally, the tools that we ourselves have built
are becoming increasingly more difficult to use: even a simple web project nowadays has 500 dependencies,
and other build tool specific scripts which download libraries off the internet, and end up importing a big
complex library that usually introduces more problems than it solves.
Let me be clear; I don't mean that everyone should go back to C, or program in Assembly,
and I don't expect anyone to do so, because this pattern of library overuse
is present in every programming field. The only reason that there aren't that many instances of
C/C++ programmers doing it (mainly C now...) is that it's harder to source external libraries
than to actually write them yourself.
I encourage you to take a look at any modern project of say, a calculator,
and try to tell me that it doesn't look a tad too complicated. Because, in most cases you
will see:
- Some kind of package manager manifest
- A UI library (depending on the language context)
- Some kind of math library
- And right after the important ones, a ton of other small libraries that do random things
- Not to mention that each package has dependencies which all get resolved into at least a medium size codebase
I don't necessarily disagree with this take. I will just point out, that usually, for most of the dependencies these projects bring in into the codebase, they only use a small fraction of the functionalities they provide.
And if you, dear reader, think that because you program in C/C++, you are exempted from this, please consider that there are a ton of projects out there that bring in a huge dependency, like SDL (I've got nothing against SDL, just using it as an example), and then proceed to use C++ threads, spdlog, printf,
std::cout, instead of the portable functions that SDL already provides.
I won't say that those projects are doing something inherently wrong; if it works, it works. But I will say that there are hidden or unnoticeable costs to bringing in any dependency into a project.
And here we come back to the first point of this section. Why do people use SDL, and what do they use it for?
I'll wager that most people use it because that's what they've been told to do, or because someone told them the Win32 API is too complicated, or even convinced them that it'll be better to bring it in early, because then their application will be cross-platform without much work.
(Note that I'm using Win32 API as an example here, but this is the same for any platform.)
It's not. Really. It's not that complicated, and you can make a wrapper for it in 5 days at most, that will get you 99% of the way there and cover what all of these libraries do for the common case. And you will not have to learn another API to use this one, or look out for updates, or have to fiddle with those libraries' deprecations and introcacies.
So then, why are those libraries so big? The answer is simple: they do considerably more stuff than what you use them for; in essence, they just provide a layer of abstraction over the underlying one. A heavily limited layer, because it must be defined as the common denominator between the platforms it supports, which means that your problem isn't actually solved; you still have the same problem, but now you have a different language to express its solution.
And this is the purpose of the libraries in here. As I'm writing my stuff, I've wrapped the functionality I actually want into libraries that provide solutions to specific problems, and not general ones. What this means, is that I try to optimize each library's ergonomics to solve the common case in the best way possible for the platforms & use cases it supports.
I encourage everyone to read the code themselves, not because it's the best or the most bug free, but because I want you, dear reader, to see how simple things can be, even for someone who's not a massive genius or expert in the field.
About Me
Hi, I'm Michael Dodis.
A software engineer from Greece, and I love working on low-level stuff,
graphics especially.