Thoughts on languages
2023 has been a year where I ventured away from C# and the Unity game engine into other languages and frameworks.
C++
So to this point, I have primarily been using C# in behavior scripting for my games. I also do a little Python in my day job. I started learning C++ because its used extensively in GameDev in a lot of places and more importantly I wanted to feel like a grey beard or like I am John Carmack or something. C++ is easy to learn and hard to master which is super compelling for me. Header files are annoying but I have largely not run into the primary issues most people who use it complain about. (pointers, templates, etc..) This is probably because I work alone on all of my stuff so I don’t have some other more senior/junior group of people adding to the code base and trying to interpret what is going on in what I wrote. I do feel that Unity and Python both have better error logging tooling when it comes to tracking down bugs. Seeing a stack trace of what errored-out and when is so helpful and its not like you can’t have that in C++, but you do have to do it yourself. (Which i almost never do unless there is a problem) That said, in programming, you are always going to have those situations where a super generic error is thrown and the static analysis tools, Stack Overflow, and ChatGPT are not going to be able to tell you what wrong with your code exactly. You just sort of have to look at what you changed last and work backwards until you find some issue in your logic. The thing I love most about C++ is that it enables straight-line problem solving. In the early days of game engine development, the game engine was the game rather than being a huge suite of tools that like sidecar onto the runtime. My biggest time sink in making my video games has been over-engineering some system that I end up not using or that didn’t need to be that complicated.
I hate package managers
I can see the value in being able to leverage the work of others (for free) and having their work updated and merged into my own in an automated fashion. That is the dream of package managers- to stand on the shoulders of giants and make new an interesting things without having to worry about what is going on upstream of you. For example, the Pandas library has been a huge win for me and the fact that I only have to “-py pip install pandas” on whatever machine I am on to get up and running is amazing. Most people would not consider a language modern if it didn’t have some automated way to handle dependencies. I should also say that I love managing packages with flatpak/snap/apt/yum on linux. I feel like that is necessary in the context of the OS because you have a way larger surface area.
There are downsides to package managers and the flaws were not so apparent to me until I moved into the C++ ecosystem. To add a new library to your project: you have to go out and find the Github or whatever that’s holding the code you want to use. Then you have to either have to run git or download a zip file to move it into the directory you are looking for. Then you have to tell your build tools where the files are. Only then, can you include it in your project. Once you do that, you have that version of SQLite, Asio, or whatever until you go and re-download it again. Most people would say that is a lot of friction but I think you should really weigh pros/cons before you just start building this entire stack of dependencies.
For instance, I don’t think that production systems really have their dependencies updated regularly even though they should. Sometimes you can also get stuck on a version of something because you haven’t had time to do a re-write to accommodate something that changed upstream of you. (ex. in pandas ‘append’ was deprecated for ‘concat’) You can also just get carried away with this stuff which I will go into later on the Flutter section.
There is also something to be said to having that dependency right inside your Visual Studio/Clion project solution. Since I got started with C++, there have been countless times where I was able to figure out how something worked in the library I was using by just opening the file that had the function in it. Usually whoever maintains the library gets what its like to be a c++ developer and has written something meaningful as how something works or what errors are common when that code shows up in the debugger window.
Getting Started with Flutter
After praising the merits of C++, you might be wondering why I am getting into Flutter rather than just working in one of the myriad of C++ libraries made for building user interfaces. It really boils down to two things: Cross platform availability and Flutter’s default libraries don’t look like something out of 2006. I have learned over my time as a hobbyist that frameworks matter more than languages. If I were working with I group of people my answer would change, but in terms of getting a finished product out as one person- the framework/tooling is everything.
Javascript Bullshit
I do feel that Dart is not up to par with C++, Python, or C#. I am only here for Flutter. You can see the React/Node.js influences on Dart as a language and Flutter as a framework. Downloading a package to manage state for you seems like overkill to me. Downloading a package to have a new theme or change the color gradient on a button is just asinine to me. Jonathan Blow said something that has really stuck with me:
“Most programmers don’t realize that computers are extremely fast.”