Compilation and Immutability

We’ll spend some time on our first discussion of Kotlin internals. Specifically, we’ll explain more about what happens when your code is run. Then we’ll discuss immutability in Kotlin.

Warm Up Debugging Challenge

Warm Up Debugging Challenge

Let’s warm up with another debugging challenge!

Compilation and Execution

Compilation and Execution

Our focus in this class is on teaching you to think computationally and express those thoughts coherently in the Kotlin programming language. Once you do that, you’ll be able to learn other programming languages easily and accomplish other computational tasks.

So we don’t spend a lot of time on exactly what is going on under the hood when Kotlin executes the code that you submit. On some level, it doesn’t matter. As long as the core language constructs have a stable meaning, the internals of how things work don’t matter. When I write:

I expect to see a message displayed 8 times. Kotlin could and might completely change exactly how that is accomplished, but as long as it is accomplished, I’m not going to notice. This is a powerful idea in computer science, even if at times the methods of implementation are somewhat less than practical.

But! In this case having a bit of an understanding of what is happening is actually useful. And, what is actually happening is quite interesting! So let’s peek under the hood…

Two Steps

Two Steps

When you run a Kotlin program there are actually two distinct steps that are taking place:

1. Compilation: in this step your Kotlin source code is compiled or translated into a different set of simpler instructions. The compiler can and does catch certain kinds of errors at this stage.
2. Execution: the Kotlin compiler produces a file containing bytecode, which can then be executed. This is when you program actually runs and does whatever you’ve instructed it to do. There are other errors that can occur at this stage.

Compilation

Compilation

Let’s talk a bit about when compilation happens, what is produced, and the kind of errors that the compiler can produce during this step.

Execution

Execution

Now let’s return to the same environment and discuss the execution step and the kind of errors that can occur at that point.

Development v. Production

Development v. Production

One of the reasons understanding these steps is so important is that they have a relationship to the difference between development and production:

• Development: the phase of software development where the programmers are writing and testing new code.
• Production: the point at which the software program has been released to its actual users

Compiler errors generally only happen in development. That means that only developers see them! In contrast, runtime errors can happen in production! That means they might affect actual users.

Software developers acquire a high degree of patience with broken and crashy software. Users do not. That means that, if you can reduce runtime errors and catch them during development, you will produce better software.

Kotlin represents a new generation of compilers that harnesses the power of today’s computers to help catch errors in your code before they affect users. So while Java allows you to do this—this code generates a runtime error:

Kotlin does not—this code generates a compiler error:

Immutability in Kotlin

Immutability in Kotlin

Before we conclude, we’ll introduce an important idea in Kotlin: immutability.

We’ve discussed previously how to declare and initialize variables in Kotlin:

We’ve also pointed out that, due to Kotlin’s powerful type inference, even the Kotlin tracks and enforces variable types, we usually don’t need to explicitly provide types. In the example above, Kotlin will figure out what type i is from the type of the initial assignment. 8 is an Int literal, so i will be inferred to have type Int. We know this.

val and Immutable Variables

val and Immutable Variables

But what is this var keyword that we are using above? It seems somewhat unnecessary at this point. Using it does help us distinguish between variable declaration and reassignment:

However, var actually hints at a deeper and more fundamental feature of Kotlin: immutability. To see how this works, let’s examine var’s counterpart, val:

if Expressions

if Expressions

In addition to val to declare an immutable variable, Kotlin provides a number of other features to support immutability in our code.

Consider the following snippet:

isHot is entirely dependent on the value of temperature, which in the code above is a val and so cannot change. But, because we need to set the value of isHot inside an if statement, we have to declare it as a var so that we can change it in the if branch.

Happily Kotlin provides a very elegant way around this problem: if expressions. Previously we’ve seen if statements. if expressions are very similar, except that they can be used on the right side of an assignment! Let’s explore this idea together:

if expressions turn out to be incredibly useful and powerful, and we’ll use them whenever we need to initialize a variable based on a condition. Not only are they clear and expressive, but they frequently allow us to mark the initialized variable as val if it does not need to change after the assignment.

Why Immutability

Why Immutability

Kotlin’s use of var and val promote immutability to a first-class citizen in the language. (Simliar behavior is possible in Java, which Kotlin interoperates with, through the final keyword. But it is less central to the design of the language.) Each time you create a variable you must decide if it can be reassigned (var) or not (val).

You may think that this is a bit strange. After all, it’s a variable! Shouldn’t its value be able to change? Sometimes change is necessary. But often it turns out not to be. And, by reducing the number of variables that can change in our programs, we end up writing code that is easier to understand.

Put it this way. When I create and initialize a val, I know immediately what its value is and always will be. In contrast, when I create and initialize a var, I have to keep an eye out for any places that its value could change unexpectedly in the code that follows. That makes my code harder to understand.

Immutability is an important software design principle. So while it may not seem completely clear why this is so important now, starting now we’ll try and take advantages of val and Kotlin’s other immutability features to reduce the amount of mutability in our code.

More Practice

Need more practice? Head over to the practice page.