Live data from Hacker News

From Java to Kotlin and Back Again

allegro.tech

151–160 of 199 posts

Re: From Java to Kotlin and Back Again

#151
post #147

Earlier quoted context omitted.

You can do something like this: class MyTransaction { fun begin() {} fun commit() {} } fun MyTransaction.query() {} fun MyTransaction.update() {} inline fun transaction(tblock: MyTransaction.() -> R): R { val t = MyTransaction() t.begin() try { return t.tblock() } finally { t.commit() } } fun test() { // update() doesn't compile, no such method val hello = transaction { query() update() query() "Hello" } println("$he…

I must admit I don't entirely understand how your approach works, but it seems like it requires all the functions you want to use in transactions to live on MyTransaction (even if only as extension methods)? I want to be able to write normal functions including quite high-level ones that take some business objects and return MustHappenInTransaction[SomeOtherBusinessObject], and pass these return values through generi…

    typealias MustBeInTransaction = MyTransaction.() -> Unit
    
    fun makeObject(i: Int): MustBeInTransaction {
        return { /* do something with i or whatever in a transaction */ }
    }
    
    fun test() {
        var genericArray = arrayOf(1, 2, 3).map { makeObject(it) }
        //genericArray.forEach { it() } // fails to compile
        transaction {
            genericArray.forEach { it() }
        }
    }
Like that?

Re: From Java to Kotlin and Back Again

#152
post #99
post #45

Is it me, or does the article feel like it is written by someone who didn’t actually bother to learn Kotlin. Instead they learnt the bare minimum syntax and tried to write Java in Kotlin. The author complains a lot about how Kotlin is different from Java. Err.. it is a new language — it is supposed to be different — otherwise why bother? > I have my favorite set of JVM languages. Java in /main and Groovy in /test are…

> The author complains a lot about how Kotlin is different from Java. Err.. it is a new language — it is supposed to be different — otherwise why bother? Kotlin advocates try to have it both ways. If it's a full new language, to be evaluated as a full language, then why would you adopt it when it's missing important features compared to Scala? The narrative is that it's a set of small enhancements to Java that are ea…

"Kotlin advocates try to have it both ways"

Kotlin is a new language. Several of its deficiencies are a result of primarily targeting the JVM. There are no universal Kotlin "advocates" claiming otherwise, and that is fundamental a distracting strawman.

As to Kotlin -vs- "other language", Kotlin has fantastic, broad tooling (being designed by a very competent tooling company gave it quite a speedy start). In an instant it beats out most competitors that force much more of a compromise.

Re: From Java to Kotlin and Back Again

#153

My 5 cents: It seems to me that the author did not spent enough time to learn Kotlin. The way he mixes Java types (Integer.parseInt) inside pure Kotlin code and then complains about lack of Null-Safety? It is enough to use an extension function String.toInt() to stick to Null-Safety and compiler will do the rest. His main() function? Another weird argument because Kotlin's documentation has some examples on how to wr…

I have to agree. Sometimes you do find developers with so much tunnel vision of the "one true way" that it becomes difficult to open their minds to doing things slightly differently. For example, the null safety example and the complaint that having `!`, `?`, `!!` is "too Scala like" and too complex. I wonder if the author ever had to reason about or in Java (e.g. https://briangordon.github.io/2014/09/covariance-and-…

First let me tell you that I agree with you, and I just have a small comment.

The type bounds in Java are there for a reason. Kotlin's syntax is simpler but it it unable to express all the types that the Java model can.

I have found myself in situations where I want unable to express the proper type information in Kotlin simply because the designers of the language decided that having full support was too complicated.

Re: From Java to Kotlin and Back Again

#154
When I saw the first compliant he had, about variable shadowing, I was asking myself: This guy works for Allegro and he doesn't understand shadowing? It's used all the time in Lisp.

Then I realised it's a different Allegro.

Another case where knowing Lisp makes you a better programmer, no matter the language you use.

Re: From Java to Kotlin and Back Again

#155

My 5 cents: It seems to me that the author did not spent enough time to learn Kotlin. The way he mixes Java types (Integer.parseInt) inside pure Kotlin code and then complains about lack of Null-Safety? It is enough to use an extension function String.toInt() to stick to Null-Safety and compiler will do the rest. His main() function? Another weird argument because Kotlin's documentation has some examples on how to wr…

I have to agree. Sometimes you do find developers with so much tunnel vision of the "one true way" that it becomes difficult to open their minds to doing things slightly differently. For example, the null safety example and the complaint that having `!`, `?`, `!!` is "too Scala like" and too complex. I wonder if the author ever had to reason about or in Java (e.g. https://briangordon.github.io/2014/09/covariance-and-…

Scala does have wildcard types.

List is List[_ >: T]

List is List[_ Scala leave a feature out? Psht...always room for one more.

Re: From Java to Kotlin and Back Again

#156
post #147

Earlier quoted context omitted.

I must admit I don't entirely understand how your approach works, but it seems like it requires all the functions you want to use in transactions to live on MyTransaction (even if only as extension methods)? I want to be able to write normal functions including quite high-level ones that take some business objects and return MustHappenInTransaction[SomeOtherBusinessObject], and pass these return values through generi…

typealias MustBeInTransaction = MyTransaction.() -> Unit fun makeObject(i: Int): MustBeInTransaction { return { /* do something with i or whatever in a transaction */ } } fun test() { var genericArray = arrayOf(1, 2, 3).map { makeObject(it) } //genericArray.forEach { it() } // fails to compile transaction { genericArray.forEach { it() } } } Like that?

It just dawned on me that Kotlin receivers[1] and extension methods[2] are basically the equivalent to Scala implicit params and conversions respectively. Although it appears that receivers can only really be used with anonymous functions. This appears to be similar to implicit function types proposed for Dotty[3]. So the Dotty equivalent to the above would be:

    type MustBeInTransaction = implicit MyTransaction => Unit

    def makeObject(i: Int): MustBeInTransaction = {
        return { /* do something with i or whatever in a transaction */ }
    }
    
    def test(): Unit = {
        var genericArray = Array(1, 2, 3).map(makeObject)
        //genericArray.forEach { _() } // fails to compile
        transaction {
            genericArray.forEach { _() }
        }
    }
EDIT - I just noticed that this is almost exactly the same as the example used in the function types link below

[1] https://stackoverflow.com/questions/45875491/what-is-a-recei...

[2] https://kotlinlang.org/docs/reference/extensions.html

[3] https://www.scala-lang.org/blog/2016/12/07/implicit-function...

Re: From Java to Kotlin and Back Again

#157

Earlier quoted context omitted.

> 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 can't find an example of what I imagine you're saying. Can you link to an example from here the reference docs? https://kotlinlang.org/docs/reference

I believe they are referring to the lambda syntax: https://kotlinlang.org/docs/reference/lambdas.html // Lambdas are code blocks enclosed in curly braces. items.fold(0, { // When a lambda has parameters, they go first, followed by '->' acc: Int, i: Int -> print("acc = $acc, i = $i, ") val result = acc + i println("result = $result") // The last expression in a lambda is considered the return value: result })

Correct. It looks bizarre. Ruby at least sets off the arguments with pipes.

Re: From Java to Kotlin and Back Again

#158
post #63
post #49

Earlier quoted context omitted.

"didn't bother" "bitching" "no clue" "another gem" "hateful" There's really nothing in the article that warrants any of this.

On the other hand, there's not much of anything in the "article" that warrants much of anything different IMO. It's just not serious.

I learn more about languages from articles like these slagging them --- including languages I end up liking and working in --- than I learn from articles that try to promote languages. I learned more about Kotlin from this than I... wait, no, everything I know about Kotlin I learned from this post.

Re: From Java to Kotlin and Back Again

#159

Earlier quoted context omitted.

I have to agree. Sometimes you do find developers with so much tunnel vision of the "one true way" that it becomes difficult to open their minds to doing things slightly differently. For example, the null safety example and the complaint that having `!`, `?`, `!!` is "too Scala like" and too complex. I wonder if the author ever had to reason about or in Java (e.g. https://briangordon.github.io/2014/09/covariance-and-…

Scala does have wildcard types. List is List[_ >: T] List is List[_ Scala leave a feature out? Psht...always room for one more.

Right, you can use _ as the placeholder for a type and it works with the bounds syntax. I probably did not make it clear enough - my point was that Java is also not as "simple" (for some definition of "simple" the author could use) as you'd expect. For good reasons too - these bounds are useful to have sometimes!

Re: From Java to Kotlin and Back Again

#160

I work in Kotlin and Java and have opinions on both. Some feedback... I disagree about the name shadowing issue. In fact, I wish Kotlin didn't suck so hard and not allow me to ignore those warnings specifically. My primary use for name shadowing is so that I don't use the previous variable. This may be a bit strange, but in highly functional contexts with immutable variables, shadowing a name is reasonable especially…

> Can't cite type inference in Java if one of its most popular platforms doesn't support it. May be ok for you, not ok for everyone though. We might wish Android would keep up, but in the meantime we have practicality concerns.

Google and their J++.

Post reply on HN