From Java to Kotlin and Back Again
There exist really, really good arguments for the structure of a programming language. Obvious example: I think Perl-as-is-generally-written is line noise. But complaints like &quot;the type comes after the variable name [so that we can consistently define types, including in arguments, without inconsistent syntax like Java is now forced into]&quot;...aren&#x27;t good. You might not be comfortable with it off the jump; it&#x27;s more consistent, it reads fine, it improves implicit typing because you don&#x27;t need special-case syntax, and it should not be bothering you past the first hour with the language.<p>T! being a little odd is a fair criticism--or would be if it wasn&#x27;t <i>literally inescapable</i> when working with languages that are, like Java, guilty of Hoare&#x27;s mistake. For my money they do a better job of it than Scala does, that they address it at all when Java doesn&#x27;t is admirable, and I think it generally works pretty well. I think Kotlin should make every T! a T? and <i>force</i> you to deal with the null cases, to be honest, but that would probably make the author upset because it&#x27;d splat `!!` all over the place.<p>Companion objects are <i>objects</i>, 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 <i>sucks</i>, 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&#x27;s fluid and natural. Kotlin tries--it&#x27;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.<p>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&#x27;m not a Kotlin specialist or anything, I just take the time to understand my tools when I use them.<p>Option&#x2F;Maybe types are a good idea. I&#x27;ve used Kotlin-specific ones in Kotlin and it was...fine, but the &quot;oh, look at this `let` thing, isn&#x27;t it <i>so much harder</i> than the Java one?&quot; thing is a head-scratcher. It smells like another case of &quot;I expect things to look like Java so I throw a rod when it doesn&#x27;t&quot;.<p>Data classes are great. That C# doesn&#x27;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&#x27;re a tool-using species, set your linter to complain about closed classes if you really care that much.<p>Don&#x27;t get me wrong: I think one is probably wasting one&#x27;s time to be using Java preferentially in 2018, but use what makes sense to you. Have <i>decent reasons</i> for it, though, and a lot of this seems like &quot;this is different and therefore scary and therefore bad.&quot; Like--steep learning curve? Man, I was writing mostly-idiomatic Kotlin that plugged right into Java libraries in a couple <i>hours</i>.<p>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&#x27;t awesome. And maybe Kotlin is worse for the author&#x27;s particular flavor of code--but, having written a lot of Java and a lot of Kotlin, <i>I really doubt it</i>. Kotlin is spectacular for me specifically because it does not force me into Java&#x27;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&#x27;t get to write as much of it as I&#x27;d like, these days...but doing so is consistently fantastic.<p>EDIT: Actually, while I&#x27;m at it, I&#x27;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 `-&gt;` makes it read oddly. But that&#x27;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&#x27;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&#x27;s first point about name shadowing is a good one...