[cromwellian]

The only problem with Steve's rant is that he starts out describing his experience with APIs, but then it turns into an issue of better languages.

Presumably Kotlin doesn't wrap the entire Android API with some kind of better API, but most Android API calls would be direct Kotlin->Java calls, so how does Kotlin solve the nasty API issue?

Really, this seems to be another Java critique by Steve. He's also written critiques against typed languages in general, including Scala.

Android's API issues are language independent I think. Compare the design of Guava vs Android, you can make well designed and easy to use Java APIs, it just takes thoughtfulness.

[Larrikin]

Extension functions as mentioned are extremely useful. There's just some functionality you need on different types of Android classes (especially views, activites, and fragments) very often but it really isn't worth it to subclass it since not all views or activites need all of the functionality.

The improvement to findViewById was met with tepid applause today because its hardly used anymore due to there being a lot of better options. Kotlin's Android Extensions for the most part has completely eliminated one of big use cases I had for the data binding library, which was refactoring a view where an id and/or the type of view changes and also not needing to constantly have the xml open to directly compare which ID I need to use. I assume its also true for people using a tool like Butterknife. The autocomplete in the IDE could use a little help but its still great.

Anko makes the awfulness of dealing with SQLite on Android almost bearable, although I've only briefly experimented with it. Creating views in code also seems like it is a much more pleasant experience with Anko, although I also have only briefly experimented with it. My day job had me creating fairly complicated views where a preview was absolutely needed, but a lot of apps don't have that complicated a view hierarchy and would probably benefit.

This is just off the top of my head without even looking through the codebase or at my experiments.

Edit: Forgot to mention being able to write an async task like

    async() {
        val thing = ...
        uiThread {
            method(thing)
        }
    }

Is just lovely

[cel1ne]

If you got time, play around with extensions with multiple receivers, you can do pretty neat stuff with them.

See my comment here: https://news.ycombinator.com/item?id=14365317

[fauigerzigerk]

What's the advantage of extension functions compared to plain functions?

  fun String.shout() = this + "!!!"

  fun shout(s: String) = s + "!!!"

Looks pretty much the same to me. Extension functions use static dispatch so what's the point of using member syntax?

Also, extension functions can be overwritten by a member function with the same signature. That seems quite fragile to me considering the class and the extension function very likely have different authors.

That said, I don't know Kotlin very well. So perhaps you can set me straigt on any misconceptions I may have.

[skrebbel]

Besides what Larrikin said, discoverability. Discoverability is the killer feature of languages designed for IDE support that you just won't understand if you haven't seen it. It's a big reason of why Kotlin beats Scala in practice, IMO (1).

I code Elixir a lot these days and spend a lot of time looking at hexdocs.pm and occasional library source code. With Kotlin or C#, this is seldomly necessary, because the IDE's autocomplete tells you everything you can do with this object. It doesn't guess, it knows. If it's in the list, you can do it, if it's not, you can't.

Now, if I have a string object called "str", and I write "str.", I want to see a list of everything I can do with it. But a MyStringUtils.shout() is never in that list, because it does not come after the dot.

With extension functions, this becomes possible with userland extensions to existing classes and interfaces. All you need is a single import on top, and good IDEs (eg. visual studio) can also auto-import that one if you use a function from it once.

(1) Last I tried, Scala was too slow to compile to provide 100% perfect autocomplete within a few milliseconds. IntelliJ did some Python-esque guesswork to mitigate that, but that effectively reduces the feature to "save me some keystrokes", i.e. not very useful. Maybe this has been fixed since.

[cel1ne]

I used extensions with multiple receivers for adding context inside data-structures.

Example: I have a layout-algorithm for a grid that takes sections:

    interface Section {
        val title: String
        fun something()
    }

Then I have the grid-algorithm. Inside I store expanded/collapsed state for each section. When I use a member-extension with both receivers I can write that pretty conveniently:

    class GridLayout(sections: List<Section>) {

        /* the state */
        val expandedSections = mutableSetOf<Section>()

        /* the extensions I need in this context */
        val Section.isExpanded get() = this@Section in expandedSections
  
        fun Section.expand() = expandedSections += this@Section

        
        fun compute() {
            ...
            if (!section1.isExpanded) {
                section2.expand()
            }
            ...
        }

    }

[fauigerzigerk]

This looks neither clear nor convenient to me.

[Larrikin]

I use extension functions on classes I don't own to add functionality I think the class should have had or would be extremely useful for my project if a certain type of class had the functionality. Your example would require a static utility class in Java or an object in Kotlin to use every where, the extension functions can just be inside of a kotlin file.

So the difference would be in Kotlin

  object StringUtilClass() {
    fun shout(s: String) = s + "!!!""
  }

  import StringUtilClass.*
  StringUtilClass.shout("I'm mad")

vs

  fun String.shout() = this + "!!!"

  import StringExtensions.*
  "I'm mad".shout()

Kotlin doesn't always add brand new functionality, it also strives to make it faster to read and write code.

[fauigerzigerk]

That surprises me. I would have thought that you could do this in Kotlin just as you can in Java with static import:

  import StringUtilClass.*
  shout("I'm mad")

[Larrikin]

Personally I find that less clear where shout is coming from and how to use it. It would also make autocomplete less useful as mentioned

[cel1ne]

Members can be chained, which improves readability a lot.

[Scarbutt]

I was asking myself the same question, then he wrote:

Kotlin manages to help you route around just about all of Android's Red Lights, and turns the experience into something that on the whole I now find superior to iOS development.

I haven't done any android and don't know kotlin either, so maybe someone here who does can expand on this.

[andybak]

And this paragraph:

> I was first in line to throw the Android book at the wall and give up last summer, but now with Kotlin I'm finding Android programming is, dare I say it -- enjoyable? I think this suggests that Android's "bad" APIs weren't all that bad to begin with, but rather that Java has been masking Android's neat functionality with a bunch of Java-y cruft.

[cromwellian]

I don't think it's Java fault per se, just the API design. Java8 streams, RxJava, BufferKnife injection, Guava, etc are pretty nice to use, especially in combination with Java8. There's no async/await, but if you use ReactiveX, you don't really need it.

Kotlin looks very nice, I'm just pointing out that if the Android View/Fragment lifecycle design is an issue, language design isn't the cause or solution, and most likely, you will need a middleware/facade to mitigate it.

[stevenwoo]

I don't know Kotlin but I have done both IOS and Android programming and they both have their plusses and minuses compared to each other. I am not a superstar programmer like Yegge, learned IOS first and Android seemed really weird coming from that background but I eventually grokked it and converted existing IOS app to Android, and next few apps we did I wrote it for Android first.

One key obstacle for me to get over is that some of the stuff one learns by attempting to learn through Google's documentation and copying their examples is pretty horrible in a non-toy app. IIRC I had to learn this the hard way by making an app and finding it getting geometrically harder in complexity when adding features one by one with image downloading async tied to activities and message passing from service to activity tied to message number/activity number.

[hota_mazi]

I think Steve is unjustly being harsh on the Android API, probably because he's not very experience with it, and I suspect that he'll be hard pressed to produce an example of an API that's completely ugly with Java but is somehow good with a Kotlin wrapper.

[wtetzner]

Well, he does say this:

> but now with Kotlin I'm finding Android programming is, dare I say it -- enjoyable? I think this suggests that Android's "bad" APIs weren't all that bad to begin with, but rather that Java has been masking Android's neat functionality with a bunch of Java-y cruft.

[seanalltogether]

I agree. The Activity and Fragment lifecycles that create such a pain are based on architecture decisions, not language. Kotlin can't overcome the fundamental fact that activities are stateless, and all the knock-on effects this creates.

[jackmott]

extension methods may be what provides him the ability to fix the api to his liking.