We're going to revert to type, just a little bit, for today. I want to develop an idea that has been developing for a while in software engineering. Specifically, I want to tackle the idea that, in order to be a successful software engineer "YOU NEED TO LEARN LANGUAGE XYZ".
What I've found is, instead, it's less about specific languages and more about specific "slots" in your toolbelt. There are specific roles that different languages will provide, largely categorized by how they are used. So, today we're going to break down the three "levels" of programming languages that you will want to learn and use.
Let's start with a specific example of such a "stack", based on languages I've used a lot of in my own experience.
It's a great collection of interviews with different programming language designers, and (in addition to fun quotes of GvR trash-talking Java, and Java designers trash-talking C++ and Bjarne Stroustrup, etc.) it illuminates just how strongly the design of different languages are shaped by:
Personalities, preferences, heuristics
Original design purposes
Problems/objectives to solve
Constraints of the time
In particular, let's consider the following diagram that defines an engine evolution that represents the boundary between beginner-intermediate game development efforts and intermediate-advanced.
The engine is focused on performance and reusability, but it is not focused on implementing the mechanics of a specific game. The game logic, specific models, and other things that are developed to realize a specific game publication, are probably written "on top of" (or at least in conjunction with) the lower-level engine code.
But, there's another level beyond this. If you've ever written add-ons in World of Warcraft, for example, you know that there's an interpreter embedded within the game mechanics (with specific events you can subscribe to and assets you can extend or customize). Lua is a great example of this higher-level "scripting" usecase that can be used by the community to customize and extend different behaviors.
If you only know languages that quality for each of these three layers, you're going to do pretty well. But there are at least three other languages that will come in handy. This will be true regardless of what your "tech stack" selection of languages looks like from the first three "layers", whether it's C++/Python/Javascript, or Zig/Go/Lua, or anything else.
Interestingly, Python started out as a cross-platform scripting language for the scientific computing community! While it's since grown into a GPL (a lot of languages do this, much like Zig is growing into a GPL having started out as a systems-programming language), it still has very potent capacity as a scripting language for automation (think about the os, sys, threading, and subprocess core modules, for example). Bonus points for crossing off two categories with the same language, of course!
Domain-Specific Languages
In contrast to "general-purpose" programming languages, there are "domain-specific" languages that are uniquely suited (and designed around) the defining usecase of a specific domain. MATLAB is a good example here, which you will likely need to learn to perform heavy lifting in numerical algorithms and tensor manipulation.
Tensorflow is also an example of a DSL, even though it's used and manipulated in other languages, because there's a specific grammar and syntax to the manner in which neural networks are constructed, configured, and trained/utilized. You could learn Terraform as a DSL for large-scale static infrastructure-as-code (IAC) automation, for example, if you do a lot of cloud engineering. If you like crypto/blockchain, you'll likely pick up something like Solidity at some point.
But by definition your DSL will likely be a function of what specific domain you find yourself. Just be aware that you're probably going go benefit from picking up a DSL at some point.
Structured Query Language
The way you interact with (and understand) data, data-oriented development, and data-driven engineering is largely facilitated by learning SQL.
No other category in this article requires you to choose a specific language. There are many candidates for scripting languages, general-purpose languages, etc.
But you need to learn SQL. Because it rewires your brain in an incredibly helpful way.
You need to understand how queries work; how data is sorted and filtered; how tables and schemas are structured; how relational references work; how different "JOIN" logic interacts; how ACID assurances affect how data manipulation and mutation takes place.
And NoSQL and document stores are fine things to know as well. It's helpful to learn how OpenAPI and JSONSchemas work. These are all specific data structures and interfaces, more than specific programming languages. But regardless of whether you like to use PostreSQL or MySQL, you should learn SQL.
SQLite is a great place to start, by the way. Among other things, you can manipulate SQL directly within a memory store, or directly against a specific file, and it's API is built into common languages like Python. (This, by the way, is one of the ways you can tell how good a general-purpose language is--by what kind of tools it gives you "out of the box" to interact with common data and procedure interoperability requirements).
So. Choose any other language for any other category on this page. But learn SQL.
Conclusion
Let's review. There are three "layers" of languages that you should learn at least one candidate for:
"Low-level languages" that are typically platform-specific, compiled, and "direct"--that is, free of garbage collection or other resource abstractions. (Sometimes you'll hear the term "systems programming languages" used here as well, by the way, though that is more specific.)
"General-purpose languages" that are quick and easy to use, typically interpreted in byte code, and come with a healthy package management ecosystem for reusable tools. (Your operating system will not be written in a GPL. But the main mechanics of your favorite game might be.)
"UI/scripting languages" that help easily bind high-level UI interactions and other events with basic behaviors and interactions that "glue" together other languages and resources.
By the way, there are specific ways for each of these layers to "interoperate" with one another, as well. Whether it's REST and WebSocket interactions between the top two layers, or C ABI and structure-sharing between the lower two layers, the "health" of your "stack" will likely depend on how well you can combine specific tools in each of these categories.
There are also three categories of languages beyond these "layers" that can be very helpful to consider.
Some form of scripting language for automating programs and other system interactions for your operating system
Some form of domain-specific language, or DSL, that is specific to your particular field or problem set
SQL, in order to learn how to "think" in data-oriented operations and structures.
So that's about it. Learn them and love them! A good combination of these categories will take you all the way through your career. Unless you decide to dabble in the dark arts of functional programming, at least.
SOCIAL SHARE CARD GENERATOR