From Java to Kotlin and Back Again

From Java to Kotlin and Back Again
allegro.tech

T! being a little odd is a fair criticism--or would be if it wasn't literally inescapable when working with languages that are, like Java, guilty of Hoare's mistake. For my money they do a better job of it than Scala does, that they address it at all when Java doesn't is admirable, and I think it generally works pretty well. I think Kotlin should make every T! a T? and force you to deal with the null cases, to be honest, but that would probably make the author upset because it'd splat `!!` all over the place.

Companion objects are objects, not special-cased static...things, and are significantly more useful than static methods and fields once you have put in a few seconds of chin-stroking to consider why people as smart as the Kotlin crew would have gone that way. Making useful things out of classes in Java sucks, whereas in other environments (something like Ruby comes to mind--as an example, Sidekiq::Worker provides meta-information to Sidekiq because of the configuration of your job class) it's fluid and natural. Kotlin tries--it's not perfect, but within the bounds of playing-nice-with-Java it tries--to improve that. Treating companion objects as useful things in Kotlin is solid.

And I have no problem writing a program entrypoint from memory, on the rare occasion I have to. Probably because I understand what everything in it actually...does? And I'm not a Kotlin specialist or anything, I just take the time to understand my tools when I use them.

Option/Maybe types are a good idea. I've used Kotlin-specific ones in Kotlin and it was...fine, but the "oh, look at this `let` thing, isn't it so much harder than the Java one?" thing is a head-scratcher. It smells like another case of "I expect things to look like Java so I throw a rod when it doesn't".

Data classes are great. That C# doesn't have them is one of the reasons I dunk on the language so much (along with the `static` mistake, but like Java, they were young and foolish). Closed-by-default classes--meh, whatever. Have that argument if you care that much, but we're a tool-using species, set your linter to complain about closed classes if you really care that much.

Don't get me wrong: I think one is probably wasting one's time to be using Java preferentially in 2018, but use what makes sense to you. Have decent reasons for it, though, and a lot of this seems like "this is different and therefore scary and therefore bad." Like--steep learning curve? Man, I was writing mostly-idiomatic Kotlin that plugged right into Java libraries in a couple hours.

This whole article reads like a weird lazy lament: that changes are hard, seeking new local maxima of correctness and productivity is uncomfortable sometimes, and challenging that discomfort isn't awesome. And maybe Kotlin is worse for the author's particular flavor of code--but, having written a lot of Java and a lot of Kotlin, I really doubt it. Kotlin is spectacular for me specifically because it does not force me into Java's lowest-common-denominator design. It gives me room to be smarter about the stuff I write while still using the often-very-good libraries available through Java on the JVM. I don't get to write as much of it as I'd like, these days...but doing so is consistently fantastic.

EDIT: Actually, while I'm at it, I'll give my one real grinds-my-gears thing with Kotlin: I think the way they do blocks is odd. I think that the braces should encapsulate the body of the block, not the variable expression as well; I get the resemblance to Ruby but I think their choice of `->` makes it read oddly. But that's a minor nit compared to the real one: `it` is a wart. I think you should have to name your enclosed variables and I don't think you should be able to shadow them. Heck, the reason I read this article in its entirety in the first place is because the author's first point about name shadowing is a good one...