4 ms·

To those who've done a lot of Kotlin, does it actually alter your programs' design and structure? Your approach to problem solving? Does it open new doors in ho

To those who've done a lot of Kotlin, does it actually alter your programs' design and structure? Your approach to problem solving? Does it open new doors in how you choose to think about and attack a problem? In a nutshell, do you think your programs are better because you chose Kotlin over Java and why?

jillesvangurp 7y ago
I've converted a lot of Java backend code to Kotlin. You usually start out with the intellij converter. I tend to go class by class. That leaves you with something that nearly compiles but not quite. After addressing that, you typically end up with some needlessly nullable types, lots of mutable types, some misguided generics and a few other java-isms that are easily fixed. So, far you've not really changed the structure of the code, you're merely improving it and making it more safe to use. I usually get the process above over in a few minutes for a single class; it's not hard and I would argue the resulting code is already massively better than what you started with. After that, there are probably a few places where idiomatic use of Kotlin library and extension functions can improve things. I tend to that as I stumble on opportunities to do so. This stuff is great for getting rid of boiler plate. E.g. Kotlin's internal DSL language features can replace a lot of ugly builder pattern code. Also having constructors with default arguments removes the need for having builders or having multiple constructors. Same for functions. Converting streams to sequences and restructuring statements with nested returns to return the result of a complex expression helps to. Using when instead of if makes things nicer. Etc. Lots of stuff to use. My programs are definitely shorter in Kotlin and safer (e.g. nullability). Shorter is correlated with lower maintenance cost in literature on software engineering. Some things that Java is ok with are compile errors in Kotlin. So, safer is better in my book as well.

jillesvangurp 7y ago

I've converted a lot of Java backend code to Kotlin. You usually start out with the intellij converter. I tend to go class by class. That leaves you with something that nearly compiles but not quite. After addressing that, you typically end up with some needlessly nullable types, lots of mutable types, some misguided generics and a few other java-isms that are easily fixed. So, far you've not really changed the structure of the code, you're merely improving it and making it more safe to use. I usually get the process above over in a few minutes for a single class; it's not hard and I would argue the resulting code is already massively better than what you started with. After that, there are probably a few places where idiomatic use of Kotlin library and extension functions can improve things. I tend to that as I stumble on opportunities to do so. This stuff is great for getting rid of boiler plate. E.g. Kotlin's internal DSL language features can replace a lot of ugly builder pattern code. Also having constructors with default arguments removes the need for having builders or having multiple constructors. Same for functions. Converting streams to sequences and restructuring statements with nested returns to return the result of a complex expression helps to. Using when instead of if makes things nicer. Etc. Lots of stuff to use. My programs are definitely shorter in Kotlin and safer (e.g. nullability). Shorter is correlated with lower maintenance cost in literature on software engineering. Some things that Java is ok with are compile errors in Kotlin. So, safer is better in my book as well.