My thoughts on language design


This topic might seem really unrelated to gamedev or me. But I’d argue, that programming is one of the core components of huge mess thing, called game development. And I’ve been playing around with making programming languages for quite a while now, so I have a few things to say in this field.


We have a lot of amazing languages today, why imagine another one? Well, to start off, it’s a great exercise. Not to note that it also a really good topic for discussion, and I’ve been collecting my ideas for ages now.

Modern languages and syntax

I really like C-family programming languages. Especially I like C#, Java, and JavaScript. C# is one of the most modern languages out there, yet I still see a bunch of space for improvement.

Access modifiers

Let’s say we open a typical C# file, what do we see interesting about those lines?

private static readonly Vector2 zeroVector = new Vector2(0f, 0f);
private static readonly Vector2 unitVector = new Vector2(1f, 1f);
private static readonly Vector2 unitXVector = new Vector2(1f, 0f);
private static readonly Vector2 unitYVector = new Vector2(0f, 1f);

Yes, half of the whole code is the same phrase private static readonly Vector2 repeated 4 times. And it’s a pretty fine example, I often see files with tons of constant declaration, and it gets even worse than this. A solution, that I came up for this, is just to put everything into brackets:

private static readonly Vector2 {
    zeroVector = new Vector2(0f, 0f);
    unitVector = new Vector2(1f, 1f);
    unitXVector = new Vector2(1f, 0f);
    unitYVector = new Vector2(0f, 1f);

And now, first of all, you have to type much less (even with all your modern IDE’s), plus it looks… not so scary and messy?


Ok, this is a big one. Why, why do most of the modern languages still have ;? The only reason, that I see, is for parsing return statements:

public void function() {
    if ( {
        print("test"); // Ok, but why do you even have something 
        // after the return statement?

And yes, by just not allowing any statements after return statement, this can be easily solved.

Null/nil safety and optional types

I think we all can agree, NullPointerException’s are annoying. It’s something, that I never can be fully sure about. Null’s are around 99% of the exceptions, I run into.
So why to even have null? Someone thought exactly the same way, and created, so called optional types. It means this:

pseudo code

public void heal(Player player) {

public void kill(Player? player) {
    if (player) {

public void healAndKill(Player player) {
    heal(player); // Works just fine, null just doesn't exist, 
    // player is 100% a real instance.

    kill(null); // Won't crash, because the program knows,
    // that there might be a null.

    heal(null); // This won't work,
    // because null isn't a valid instance.

Might seem complex. But the idea as simple, like this: you can not pass null (or nothing), except if the argument/variable type is ending with ?. And this will save you from infinite amounts of null-checks, because 99.99% of the times, you do not want to get a null as an argument. Brilliant. This is coming to C# 8, by the way! <3

Parenthesis everywhere

Let’s say you have a nice lil if-statement:

if (weatherIsGood() && moodIsFine() && teaIsReady()) {

Everything is nice looking, but then, it turns out, that you needed to invert the whole expression:

if (!(weatherIsGood() && moodIsFine() && teaIsReady())) {

Starts looking messy, huh? That’s just the start. But let’s say, what if you were able to just remove the parenthesis around if? They don’t really mean anything anyway:

if !(weatherIsGood() && moodIsFine() && teaIsReady()) {

if musicIsGood() {

And we can go even further, removing unneeded parenthesis around other statements!

while fallingAsleep() {

for var i in 10 .. 32 {

Really nice, isn’t it? And you can still use old-school () around everything, because it will be just a wrapping expression, and that’s it!


While we are on topic of parenthesis, I wanted to quickly go over another common reason, why they look so messy. Consider this example:

var owner = (Player) ((Creature) entity).getOwner()

Not super pretty. And to be honest, I didn’t really figure out a better syntax for casting, but maybe you have any thoughts on this? Please let me know in the comments!
Another way to write cast expression is something like this:

var owner = entity::Creature.getOwner()

I have to say, it looks much prettier to me, and it’s much easier to type (no need to move your cursor around), yet it still might be pretty confusing sometimes? Not sure about this one.

Setters and getters

C# introduced setters and getters a long time ago. And they are really cool. Yet, I feel, like they are like a half baked bread: a cool concept, but it did not get fully built. So the basic syntax for them is:

private int _frame;

public int Frame {
    get {
        return _frame + 1;

    set {
        _frame = value % 6;

It’s much better than writing getters and setters in the old-school way, yet why not to go a tiny bit further? If we have a shortcut for getters-only:

public float Area => Width * Height;

Why not to introduce short setters, or even allow combing them?

public int SecretSetting <= value * 100;
private int _frame;

public int Frame {
    get => _frame + 1;
    set <= value % 6;

Sweet. Yet I still see a big thing, that we can improve: why do you still have to declare _frame? Why not to build it into the getter-setter?

public int Frame {
    get => value + 1;
    set <= value % 6;

And just like that we went from 11 lines of code to only 4!!!

Maybe one day, the world see a language, that has all of those improvements or at least a few… Maybe you have other ideas for modern syntax improvements? Please tell me in the comments!

You might also find interesting

Join the discussion!