Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

From Java to Kotlin and Back Again

allegro.tech

Post reply on HN
Print view View original

191–199 of 199 posts

Re: From Java to Kotlin and Back Again

#191

Post by apatrida »

choward wrote: post #126
tabs_masterrace wrote: post #59

Man i gotta disagree with almost all points in this article. Name-Shadowing is confusing? Should be common sense to not have multiple variables with the same name in the same scope. Optionals are ugly in Java-Interop, so we decided to just use Java instead. Great reasoning.

> Name-Shadowing is confusing? Should be common sense to not have multiple variables with the same name in the same scope. You're saying name-shadowing isn't confusing because it should be common sense not to use it? Then why not just enforce that in the language?

There is an issue in the Kotlin issue tracker to be able to turn warnings into errors, and it was created by a Kotlin team member specifically for this name-shadowing case. So, you will be able to turn any specific warning into an error once this is implemented. Which is nice, I like 0 warnings.

Re: From Java to Kotlin and Back Again

#193

Post by foolfoolz »

on_and_off wrote: post #192
foolfoolz wrote: post #43

companion objects are one of the best things about modern programming languages. it’s really helpful to think about static and dynamic this way

Could you elaborate please ? What do they bring on top of static fields and methods ?

they don’t bring any functionality but it is clearer separation. i think it’s easier when you read these components in different scope blocks. they do very logically different things and importing static into instance makes more sense than keeping it all in one. maybe it was just me but i didn’t undserstand static vs dynamic after 4 years of school and into my first job. it took a while to grasp. but now that i know the differences i’d rather keep them isolated

Re: From Java to Kotlin and Back Again

#194

Post by lmm »

eropple wrote: post #184
lmm wrote: post #130

Earlier quoted context omitted.

The claims about null-safety are pure FUD; once you get past thinking about the literal string enn-you-ell-ell, Kotlin and Scala are exactly as null-safe as each other in all the ways that matter (e.g. as shown in the article, Java interop in Kotlin has exactly the same null-safety issues as in Scala).

Java interop in well-designed Kotlin or Scala is pushed to the edges of the application and fenced off. Kotlin makes null safety a much more practical proposition at that point where Scala doesn't. To be frank, Kotlin's null-handling is one of the bigger reasons I think lesser-skilled developers should use it over Java. And Scala's is good enough, but it's not as good as Kotlin's. Scala has plenty of other beams in i…

> Kotlin makes null safety a much more practical proposition at that point where Scala doesn't.

Nonsense. Putting Option() around any Java-interop calls is no harder than putting explicit "?" types on their return types.

Re: From Java to Kotlin and Back Again

#195

Post by Sharlin »

V-2 wrote: post #171
Sharlin wrote: post #168

Earlier quoted context omitted.

Yeah, but to me not having Optional with the same interface, and instead language-level syntax for working with nullables, does smell like bad design.

To me java.util.Optional is a crutch; an afterthought. I think it would never come to exist if nullability was done right to begin with. Native approach feels cleaner... to me, of course. For starters - in the context of the quoted code example - what sense does it make to have to allocate a new object (via Optional.ofNullable) every single time parseAndInc calculation is performed?? Wrapper types always involve over…

Optional/Option/Maybe is the proper way to implement "may not exist". Null is a crutch and language features that try to make it more reasonable to use are crutches on top of crutches. But I agree that in a language that already has null and can't get rid of it, Optional cannot ever be as useful as in a language that was designed properly in the first place.

Wrapper types currently incur overhead in Java. If/when value types are finally implemented, this overhead will become negligible. In languages such as Rust and C++, Optional is already a zero-cost abstraction.

From a type theoretic point of view it's clear that Optional has a monad structure, and all the usual combinators make perfect sense for it and are actually a joy to use in languages that support them, including Java. After all, it's perfectly isomorphic to a list with either 0 or 1 elements.

Re: From Java to Kotlin and Back Again

#196

Post by ysleepy »

Rapzid wrote: post #88
ysleepy wrote: post #86

Earlier quoted context omitted.

I agree, all the language server stuff is a win for the scripting and IDE-less ecosystems, but for languages with proper IDE support it is such a monumental step back. So much that nobody working with the existing tooling/IDEs will invest time to implement a language server backend.

I've got a couple languages in mind that have "proper IDE" support, and the vscode experience with them is pretty fantastic as well, even if not perfect.

Could you name one or two? By proper IDE support, I mean support for advanced and precise refactoring, build integration, debugging and so on. Dot autocomplete is only a litte part of it.

Re: From Java to Kotlin and Back Again

#197

Post by lmm »

kllrnohj wrote: post #181
btschaegg wrote: post #172

Earlier quoted context omitted.

For the same reason that being able to write val rather than var matters. With perfect discipline you can write pure functional code in any language, but [...] Strongly agree with you there. This is one of the main gripes I've got with many languages. People just have a "well don't do it" attitude and refuse to see the benefit in the possibility of forbidding mutation. A very important point here is the realization t…

If you truly need an immutable list there's no shortage of them available. It's more a "is this such a strong, common need that everyone must have it?" So far I've never needed guaranteed immutability, I've just used kotlin's List (which is an immutable view). If that's the only thing anyone gets then it's functionally guaranteed immutable even though it's not sitting on an immutable implementation.

It's not a case of need versus not; it's that all your lists being mutable creates an extra cognitive drag on everything you do. It's one extra possibility to think about when debugging and trying to understand what's going on when something "impossible" happens (which is what a lot of bugs look like when you're investigating them), right when you can least afford to spare any extra brainpower.

(Kerrigan: Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.)

Re: From Java to Kotlin and Back Again

#198

Post by eropple »

lmm wrote: post #194
eropple wrote: post #184

Earlier quoted context omitted.

Java interop in well-designed Kotlin or Scala is pushed to the edges of the application and fenced off. Kotlin makes null safety a much more practical proposition at that point where Scala doesn't. To be frank, Kotlin's null-handling is one of the bigger reasons I think lesser-skilled developers should use it over Java. And Scala's is good enough, but it's not as good as Kotlin's. Scala has plenty of other beams in i…

> Kotlin makes null safety a much more practical proposition at that point where Scala doesn't. Nonsense. Putting Option() around any Java-interop calls is no harder than putting explicit "?" types on their return types.

I think it's rather significantly different. The range of inputs to a function in Scala are Some[T], None, and null, whereas in Kotlin they become T and null. Kotlin also uses annotations that exist in libraries--and it understands a lot of them--to turn T! into T or T? directly when it can, which Scala doesn't.

Can you explain how this is so similar to Scala in a way that leaves it up to you to be contemptuous and spit stuff like "nonsense" at people looking to discuss the topic in good faith?

Re: From Java to Kotlin and Back Again

#199

Post by lmm »

eropple wrote: post #198
lmm wrote: post #194

Earlier quoted context omitted.

> Kotlin makes null safety a much more practical proposition at that point where Scala doesn't. Nonsense. Putting Option() around any Java-interop calls is no harder than putting explicit "?" types on their return types.

I think it's rather significantly different. The range of inputs to a function in Scala are Some[T], None, and null, whereas in Kotlin they become T and null. Kotlin also uses annotations that exist in libraries--and it understands a lot of them--to turn T! into T or T? directly when it can, which Scala doesn't. Can you explain how this is so similar to Scala in a way that leaves it up to you to be contemptuous and s…

> The range of inputs to a function in Scala are Some[T], None, and null

null is not a legitimate value in Scala. There is no reason to ever use it in a legitimate program; in a situation where you would use null in Kotlin, you use None in Scala. The languages are exactly equivalent (except that Kotlin has confusing inconsistent behaviour when you start nesting possibly-absent types, particularly in the presence of generics), people just get confused because they fixate on the literal source string "null" (and Kotlin marketing encourages this confusion). If you really can't stop yourself from typing n-u-l-l for some reason, use wartremover.

> Kotlin also uses annotations that exist in libraries--and it understands a lot of them--to turn T! into T or T? directly when it can, which Scala doesn't.

Those annotations are often unchecked and therefore unreliable, in the cases where they're even present at all (which are unlikely to be the cases where you need to interop with Java - popular mainstream libraries have them, but those are precisely the libraries for which there tends to be a native Kotlin/Scala replacement available). In any case, the original article is talking about the case where there aren't such annotations.

> Can you explain how this is so similar to Scala in a way that leaves it up to you to be contemptuous and spit stuff like "nonsense" at people looking to discuss the topic in good faith?

Sorry. I've seen enough bad faith from Kotlin people on this topic (and when talking about Scala generally) that I find myself unable to assume good faith.

Post reply on HN