I have been playing with the thought of converting (some of) the code of StreetComplete to Kotlin, starting with the quests and quest forms. I have been working with Kotlin in my company for more or less half a year now and it feels definitely like an upgrade from Java.
My goal here would be to make the code shorter and better readable, to maybe lower the bar a bit to implement an own quest type for contributors. Furthermore, I have the notion that moving to Kotlin may increase attractiveness for contributors in the future as that language seems to be the future of the Android platform, so, in other words, future-proofing the codebase against feeling out-dated.
So, I would like to hear the opinion of current and future code contributors about the idea as well, especially @matkoniecz and @ENT8R
If you haven't touched Kotlin, I converted some (simple) quest type classes so you can have a look how it reads: https://github.com/westnordost/StreetComplete/commit/77a15cc5340239ab8437214e46680b07744a94b8
Certainly, the quest type classes are likely those classes that will profit the most from the more concise syntax, but that is also the reason why my plan would be first and foremost to convert all those to Kotlin. (Kotlin and Java can be intermixed)
Wow, I didn't expect that it would shorten the code that much.
In https://github.com/westnordost/StreetComplete/issues/1142#issuecomment-406317952 I was (totally) against converting the project to Kotlin but you are totally right that we don't need to convert the whole project at once :smile:. The future argument is also a good one towards actually using it. So more or less I changed my opinion about it in the last 5 months and I think it might make totally sense to use it as the majority of arguments speaks for using it :+1:
I also didn't wrote that much in Kotlin yet but I think I might learn it over time so from my point of view there are no big barriers :smile:
I have never used Kotlin so far, but I would be happy to start using it.
Especially with "it feels definitely like an upgrade from Java."
You mean, you take my word for it, or you looked at Kotlin code yourself?
Wow, I didn't expect that it would shorten the code that much.
Well, Kotlin officially suggests code style guidelines, so I thought it is a good idea to stick to them from the start and one item is that opening braces after if or function names start on the same line. That makes it shorter especially in classes with one-liners as implementations (many quests).
You mean, you take my word for it, or you looked at Kotlin code yourself?
I looked at some examples of Java vs Kotlin code, including kotlin branch on this repo. It was enough to make me interested in Kotlin. But
npm package manager that handles bug reports on a forum rather than a proper bug tracker).And to form own opinion on such topic one would need to work with a tool for at least months, so in this case I take your word for it.
Bashing npm nearby, lovely… :laughing:
From what I read (ugh… https://github.com/westnordost/StreetComplete/issues/1142), it is e.g. built-in into Android Studio, so IDE support for it here should be good, at least. :smile:
One thing that I like less about Kotlin is that the idiomatic (well, I think) way to write certain things I find less readable than the Java variant. (Of course it is possible to write Java-like code in Kotlin). Example:
Java:
for(String key: OBJECTS_WITH_NAMES.keySet()) {
query += " or (" +key + " ~ " + TextUtils.join("|",OBJECTS_WITH_NAMES.get(key)) + " )";
}
Kotlin:
query += OBJECTS_WITH_NAMES.map {
it.key + " ~ " + it.value.joinToString("|")
}.joinToString(" or ")
and the same code as in Java but in Kotlin:
for (key in OBJECTS_WITH_NAMES.keys) {
query += " or (" + key + " ~ " + TextUtils.join("|", OBJECTS_WITH_NAMES[key]) + " )"
}
Or is it?
Edit: Actually, changed my mind. Coming from pre Java 8, one just needs to wrap his head around this kind of functional syntax.
Well… it's more like the functional way JavaScript also goes. I think one gets accustomed to it. :smile: Especially if GitHub's code highlighting would not suck so much… (the first Kotlin example, line 2 is mostly just whole line purple)
convert frenzy
ref #1315
@HolgerJeromin Thanks, would possibly have missed that, if you did not comment. 😃