On the Java skills required to learn Kotlin

Hi, friends!

When non-programmers or beginners ask me if they should learn Java or a different language, I usually respond that Java is a great second language to learn. Java is so heavily used that you can count on finding decent programming jobs once you’re good at it, and it has a huge, reliable ecosystem of libraries and frameworks to build real-world applications, and you will find tons of tutorials, classes and communities to help you learn.
I wouldn’t recommend it as first language though, because it’s so heavy-weight. Did you ever have to ask a beginner to type in “public-class-Something-public-static-void-main-Stringarray-args” before writing the first line of code that means something? The benefit of a light-weight language like Python or JavaScript (or back in my school days: TurboPascal) is that the beginner can focus on learning about variables, loops and conditions and immediately and understand them by watching the output.
The whole concept of object oriented programming and Java’s language constructs is useful to organize large code bases in smaller, coherent chunks; the natural way of learning that is to start out with a small, growing code base and at some point in time experience the need for better organization. And suddenly you will understand how public-static-void-main helps.

Kotlin as a first programming language

Many articles and tutorials on Kotlin (including mine) are targeted towards Java developers, demonstrating how Kotlin is the more advanced language and worthy successor of Java: Whatever you want to do in Java, you can do the same in Kotlin, but shorter and better most of the time.
Getters and setters for your properties are implictly there, generated into the byte code by the compiler; and only if you want unusual behavior, you write a custom setter explicitly that will replace the implicit one… sounds powerful, but pretty advanced, right? You have to know your Java very well, in order to be able to use Kotlin?

Sursprisingly, what I said in the beginning about good first programming languages to learn, holds for Kotlin as well! Let’s teach a beginner how a loop works!
Remember how that is painful in Java?

public class Something {
  public static void main(String[] args) {
    for (int i = 0; i < 5; i++) {
      System.out.println(“Hello, world! “ + i);
    }
  }
}

Watch the same code in Kotlin:

fun main(args: Array<String>) {
  for (i in 0..4)
    println(“Hello, World! $i”)
}

Instead of explaining to the beginner what class, public, static and void mean (or telling them to ignore it for now), we tell them: “The function main is the entry point of every program, and we could pass arguments to the program with that args stuff, but we don’t need that in the beginning.”, and then we can focus on teaching, loops, conditions, variables.

Even better, once they reach the point where custom datatypes with multiple properties are useful, we can introduce classes like

data class Book(
 val title: String,
 val authors: List<String>,
 val isbn: String,
 val publishingYear: Int)

without talking about constructors, getters and setters. This is pretty understandable, isn’t it? And you can put it into the same file with you main program, where you see it all the time. No talking about imports and packages.

My main objection against the OOP classes at college (and most Java beginners programming books and classes) is that they put so much effort in letting the students memorize all that syntax, public, private, static, getters, setters, varios constructors, inheritance, interfaces… while the students have not yet fully anticipated what classes are for! They have hardly written any code that is using classes, but they are asked to write classes with all these modifiers in the exams on paper.

In my opinion, this is so wrong! Please, let them write lots of (procedural) programs first and teach them problem solving, they can learn OOP later once they experienced the problems OOP is solving!
Once you are used to use classes as dumb data containers, it’s not a huge jump to introduce methods to add behavior…

Immutable natives

But what about the distinction between nullable and non-nullable and mutable and non-mutable variables? Isn’t that additional complexity for a beginner to learn, which is not there in Java?
Maybe. On the other hand, does a programming beginner need to be tought about nullable types and mutable variables? For Java programmers, it takes some learning to make full use of non-nullable and immutable stuff and get the value that these concepts are adding to the code.
It sound’s crazy, but think about not explaining the concept of null to a beginner and pretend every type is non-nullable. And pretend every variable is immutable. Can you think of problems that this programmer is not able to solve? I mean, you are going to teach this eventually, because they need to understand these concepts for working with legacy code and other languages. But isn’t it possible to let them program a year or so without nulls and mutability, and will their code not be better readable and less error prone from day one? I’d love to hear your opinion!

Kotlin for mediocre Java developers

When I started to write this article, it was not planned to be about beginners in the first place. I got somewhat off track, but I’m glad about it! ;-)
Let me still come back to the point I was going to make in the first place:
For an experienced Java developer, the annoying part about learning Kotlin is probably to remember some special stuff: How do I write a custom setter? Can I still declare that property in the default constructor? How do I write two custom constructors with different parameters, sharing some custom initialization lofic? Why can I not use inheritance with data classes?
From that perspective, it feels that you need to know your Java pretty well, because there is that weird stuff to learn for Kotlin and you imagine you would get lost learning the standard-Java-like parts and that weird special syntax at the same time.

But I think it’s the other way around: The less you know about Java, the better for learning Kotlin. If you had never heard about getters and setters, you would never encounter the idea of writing a non-standard setter, hence you don’t need to remember the syntax for writing custom getters. Does it hurt to assume properties of a class are just what they look loke, plain fields?
If you had never seen a class with multiple constuctors, you will still get the notion of providing default values for some arguments in your primary constructor, won’t you? Why would you need to know that the compiler outputs different construcors in the byte code?

My conclusion: Whenever you hear somebody say “I’d like to learn Kotlin, but I should get better in Java first, I don’t feel ready to learn an other language.” then shake him hardly and tell him not to learn bad habits first, just in order to have to get rid of them later.