There are so many programming languages in the world that if you were to do a quick google search you’d end up confused on which one to choose. But, there is a war on what type of language is more productive. Dynamic vs statically typed programming languages. If you’re not familiar with the differences, let’s break them down. Also, considering that GDScript for Godot has optional static typing, let’s get into why each type has its own way of making you more productive.
Dynamic Programming Languages
Did someone say production issue? They do not use a type system in order to assure that the code that you write is in the same category when you’re performing operations on it. For example, you can add a number and a string together. That probably doesn’t make much sense, but yes that’s how it works, which can lead to undefined behavior. To work with a dynamic language you have to understand it better than you understand yourself to not fall into common pitfalls. But, by their design, you can get a lot of work done fast without having to be held up by a type system. Often times, you don’t need to go through any complicated setup to start coding in a dynamic programming language. This makes it a lot easier to get productive work done without a lot of overhead. However, this can be an issue later.
If you’re not careful, typing in a dynamic programming language without tooling can be a nightmare. You can run into a lot of minor errors such as typos, invalid arguments, nulls, and improper use of a method or function. The worst part is that you probably won’t catch these errors until you test your code! And that’s where statically typed programming languages make their mark.
Statically Typed Languages
Statically typed languages are programming languages that use a type system. Some examples of statically typed languages are Java, C#, ReasonML, C, and more. But, as I said before, the best part of these languages are their type system.
A type system is simply a way for the developer and the program to create a contract on what the actual value is of a piece of code represents. This can be extremely helpful for larger teams because they don’t have to go searching through the entire codebase to understand what value they should be getting back from a function, and more. This can have other benefits in the form of type inference and intellisense.
Intellisense and type inference allows you to get help when writing your code. For example, you may write out the name of a property of an object and hit the period symbol, and you get a slew of properties that belong to that object; this is known as autocomplete or code completion. By having a strong type system either at the language level or as an add on, it makes it a lot easier for companies and individuals to provide you with this kind of feature when working with their libraries, preventing you from reading tons of documentation. Now, I don’t know about you, but I hate reading lots of documentation if I don’t have to. But, the majority of the languages in this category tend to be heavy.
Languages such as Java and C# usually require a lot of setup and understanding of how to get the setup to work together; this can lead to developer fatigue. Just to get a basic Java or C# project setup, you have to go through tons of dialogue boxes and make sure all of your dependencies match up. It is not a fun time.
So, we talked about both of the dynamic and statically typed languages, but which one should you choose to be productive?
The Real Productive Language
Just like in life, there are no easy answers to this question. But, I can give you some advice, since I’ve been writing code for so many years.
Most languages have a framework that allows them to cover just about any niche that you might need, so many times the choice for solving the problem is about comfort. Your productivity related more now to what language you’re most comfortable with. Now, granted this may change, but that’s only if you reach a performance bottleneck.
When you reach these bottlenecks, now you may have to consider either switching languages or refactoring the code, because the language may not have been the best choice, to begin with for the problem at hand, but that’s when it’s about scale to fit the demand of the application.
With that said, I hope this information helps you choose the best language for you and your game.
If you want some recommendations on languages to start with I recommend these:
Stay tuned for a deep dive on typed languages and type inference. Type inference can definitely help you understand how you can somewhat get the best of both worlds.