Back in January, I wrote a post about some changes I would love to see in the Java language that would make me like it a lot more (and would make it more modern). A lot of people suggested a lot of JVM languages, but I largely dismissed them because that’s not what I was looking for. I wanted Java to be different in these ways, since I’m not likely to convince my workplace to let me use something other than Java. And besides, most of the JVM languages suggested have some syntactic ideas that are simply difficult for my eyes to pick up on.
But…
But, then I found Kotlin. It’s a JVM language made by JetBrains, the creators of IntelliJ, PyCharm and a few other IDEs and tools. For the most part, I feel like these guys read my mind about what I wanted from my language. They missed a few things on my post, but they have so many things I had forgotten or didn’t even think about.
Comparison To My Old List
First, we’ll compare what they did and didn’t have to the list in my old post.
Get Rid of Semicolons
Kotlin isn’t semicolon-less, but there are very few cases where they’re required. For the most part, you can omit semicolons at the end of lines.
Remove the Curly Braces
Sadly, they didn’t do this. I’ll live.
Operator Overloading
Yes, they have operator overload, and lots of it. Unlike Python, they have the increment and decrement operator, a positive and negative marker, and a negation operator (like python’s __bool__(), but with an automatic translation to the opposite. They also have an operator for creating a range of the objects (1..3), but both numbers are meant to be inclusive in Kotlin, which, while often easier to read, makes for more intermediate calculations much of the time, which is why many languages prefer to make the end be exclusive.
Lastly, you define your own “operators”, but they have to be boolean infix operators. In actuality, you’re not defining your own operators so much as the language is providing a slight syntactic sugar when calling methods with one parameter. Any method md of object a, when called with parameter b (i.e. a.md(b)) can be written more simply as a md b.
Tuples and/or Data Structures
In a sense, Kotlin has both of these, but in a sense, it has neither.
They have a class called Pair, which can be used as a 2-tuple, and they have a nice syntactic sugar system for turning essentially any class into also being a named tuple. You can refer to the fields via their positions or via the name of the field. For more information, check out their documentation about Multi-Declarations.
As for Data Structures, they went the classes-with-properties route, which is fine and dandy. But the really nice thing about their data structure classes is the simplicity in defining them. An example declaration being data class User(val name: String, val age: Int). This not only sets up all the properties for you, but it also automatically defines equals(), hashCode(), toString() (of the form "User(name=John, age=42)"), and a special copy() function, which is discussed here.
Properties
Kotlin certainly has properties. In fact, it’s easier to use properties than it is to have a simple public field. Their properties automatically create the backing field for you, having the same name as the property, but with a leading underscore.
Default to public
When it comes to methods, this is the case, and I’m glad. Yay!
Type Objects
Yes, they have removed direct access to primitives and you only use type objects (and made it safer than usual due to their null safety practices, which I will be brought up a little later.
List, Dictionary, and Set Literals
Alas, Kotlin didn’t make collection literals. ‘Tis saddening, but, with some of the features in Kotlin, you could likely create really easy ways to inline their creation.
Things I Forgot About
These are a couple things I knew I’d like in a Java, but forgot to put into the old post
Control Flow Expressions
I like it when control flow structures in a language can be made into an expression (returns a value). Sure, Java (and many other languages) have the ternary operator that allows for a sense of an if-else block being an expression, but it’s limited to a single “if” check. It doesn’t allow “else if” blocks without difficult-to-read nesting.
But Kotlin doesn’t stop with if blocks; they also do try-catch expressions and “when” expressions (explained in the next section). With try-catch being an expression, you can shorten some assignments that require a try-catch block around the calculation. So instead of
Integer a;
try
{
a = Integer.parseInt(input);
}
catch(NumberFormatException e)
{
a = null;
}you could just type
Integer a =
try { Integer.parseInt(input); }
catch (NumberFormatException e) { null; }Obviously, you don’t need to be using them as expressions. You can still use them the old-fashioned way all you want.
Pattern Matching
The “when” expression was mentioned before, but now we’re really going to be digging in. It’s used in Kotlin for pattern matching and replaces switch-case blocks with a more streamlined syntax that can also work like a if-else expression, but with wider uses. It can function similarly to switch blocks in that it can continue to next “case”, but it must be done with an explicit continue command (it’s about time that the default of a “switch” is to NOT continue flowing, but even that isn’t needed as much as usual, since you can simply separate multiple possibilities by comma for all of them to take the same branch. Check it out here.
It’s not quite pattern matching as some functional languages define it, but it’s the best you can do in OO languages, as far as I can tell. I’m also sad to report that despite having decent pattern matching, which is great for recursive functions, Kotlin doesn’t seem to have Tail Call Optimization. Yet(?). Kotlin is still pretty young. Maybe it’ll get it somewhere down the line.
Class Extensions
No Checked ExceptionsI certainly don’t mind having declarations of possible exceptions thrown, and maybe a compiler warning letting us know that we’re not dealing with or declaring a possible exception being thrown, but I certainly don’t want to be forced to “deal with” exceptions that won’t actually be thrown. So, I’m glad Kotlin doesn’t have any.
Named and Default Parameters
Overloading functions is almost pointless when you can use default values for parameters, and being able to name the parameters as you’re passing in arguments can make reading function calls easier when the meaning of the argument isn’t obvious.
Things I Never Realized
Now, I will list some of the coolest things that Kotlin offers that I’d never even realized would be a good idea.
Null Safety
An object cannot be set to null unless its type specifically states that it’s null. In Kotlin, and object of type List cannot be null, but, if it’s of type List?, it can. This, along with some simple syntaxes that allow you to safely work around nullable objects, works to make a much more pleasant language to work with, all but eliminating the possibility of NPEs.
Functions As Expressions
This one isn’t a big one, but it can reduce the simple functions to take up less space in a legible way. If the body of a function is simply one expression (whether it’s a simple expression or a complex one like a “when” expression), you can skip the braces surrounding the body and instead precede it with =. For example this:
fun powerOf(number: Int, exponent: Int): Int
{
return Math.pow(number, exponent)
}can become this instead:
fun powerOf(number: Int, exponent: Int): Int = Math.pow(number, exponent)
This isn’t a big deal, but I like that it doesn’t just let you switch out the braces for =, but it also lets you skip the use of a return statement.
Outro
So, that’s what I’m loving about Kotlin. You should check it out at their official page and let me know what you think of it. I’m pretty excited about it and plan to switch over to it after I’m done with my current project, which you can expect hear a little about in my post next week.
| Reference: | I Found My Java Remake! from our JCG partner Jacob Zimmerman at the Programming Ideas With Jake blog. |
