var insertMe = "Reader"
println("Hello $insertMe") //Prints >>Hello Reader<< on Console
println("Hello ${insertMe.toUpperCase()}") //Prints >>Hello READER<< on Console

Methoden: Default-Wert für Parameter und benannte Argumente

In Java ist es oft notwendig eine Methode mehrfach zu überladen, um verschiedene API-Varianten bereitzustellen, bspw. wenn einer der Parameter nicht zwingend angegeben werden muss. Die Methode existiert dann mit und ohne diesen Parameter. Eine deutlich lesbarere Alternative ist in Kotlin möglich:

Default-Werte

fun myMethod(notOptional: String, optional: String = "defaultValForOptionalString"){
    println("myMethod called with $notOptional and $optional")
}

//Possible Calls
myMethod("arg1", "arg2")
myMethod("arg1")

Benannte Argumente

//You choose your own arg sequence
myMethod(notOptional = "arg1", optional = "arg2")
myMethod(optional = "arg2", notOptional = "arg1")

val multiply = { x: Int, y: Int -> x * y } //Typ: (Int, Int) -> Int
val res = multiply(3,5)

val ints = 1..4
//a) & b) filter() has only one parameter of type Int -> Boolean
ints.filter { it > 0 }
val map = mapOf(Pair(1,"val1"),Pair(2, "val2"))
//c) Key of Map-Entry is not used!
map.forEach { _, value -> println("$value!") }

//Determine Names of all Males in people-collection
val namesOfMaleMembers = people.filter { it.gender == Person.Sex.MALE }
                                .map { it.name }

Ich denke, diese Frage kann man prinzipiell mit Nein beantworten. Allerdings erlaubt Kotlin gewisse Freiheiten, die mit Bedacht verwendet werden sollten. Es ist beispielsweise so, dass Kotlin es erlaubt, Funktionen und Variablen in Dateien zu definieren, die keiner Klasse zugeordnet sind, wie es in Java immer der Fall wäre. Diese können unqualifiziert an beliebiger Stelle referenziert werden ^[4]. Ein sinnvoller Anwendungsbereich sind statische Utility-Methoden (z.B. Collections). Die Frage ist: Wer darf, an welcher Stelle, solche Dinge innerhalb des Projekts definieren? Man sollte sich meiner Meinung nach projektintern absprechen, wie mit solchen Dingen umzugehen ist und bestenfalls eine zentrale Stelle definieren.

Ähnliches gilt für „Extension-Functions“: Dies sind im Prinzip Methoden, die einer Klasse von außen hinzugefügt werden. Beispielsweise könnte man die Klasse String mit beliebigen Methoden erweitern, obwohl sie eigentlich final ist und nicht per Vererbung erweiterbar wäre ^[5]. Genau genommen ist dies der absolut richtige Ansatz, ganz nach dem Open/Closed-Prinzip, welches hierdurch durchgesetzt wird. Für den Aufrufer ist leider nicht direkt ersichtlich, ob eine Member-Funktion oder eine künstliche Erweiterung aufgerufen wird. Allerdings gilt auch hier, dass ein Import notwendig wird, wodurch die Kritik etwas gemildert wird. In meinen Augen ist auch dies trotzdem ein mit Vorsicht zu nutzendes Feature. Ähnlich wie bei Top-Level Funktionen sollte klar festgelegt sein, wo solche Funktionen zu definieren sind.

Ist Kotlin eine ernstzunehmende Alternative zu Java?

Meiner Meinung nach ist Kotlin aktuell die JVM-Sprache, die es schaffen kann, Java ernsthaft Konkurrenz zu bieten. Kotlin ermöglicht das Erstellen von Applikationen für die JVM, Android, den Browser und bald sogar nativer Art. Jüngste Ereignisse im Zusammenhang mit Google und der Bekanntgabe, dass neben Java nun auch Kotlin offiziell zur Programmierung von Android-Apps herangezogen werden kann, hat das Potenzial einen Hype auszulösen und die Sprache damit bekannter zu machen. Bereits viele Unternehmen nutzen Kotlin produktiv, es entsteht eine Community und die erste Konferenz ist für dieses Jahr geplant. Anders als viele andere JVM-Sprachen hat Kotlin den grandiosen Vorteil, dass es zu 100% mit Java interoperabel ist. Konkret bedeutet das, dass die vielen verfügbaren Java-Libraries und Frameworks problemlos genutzt werden können und bestehende Codebasen nicht vollständig migriert werden müssen.