4 ms·

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 K

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.

Scarbutt 9y ago
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 9y ago
  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 9y ago
    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 9y ago
  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 9y ago
  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.
jackmott 9y ago
extension methods may be what provides him the ability to fix the api to his liking.
Larrikin 9y ago
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 9y ago
  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 https://news.ycombinator.com/item?id=14365317
  - fauigerzigerk 9y ago
    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.
seanalltogether 9y ago
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.
wtetzner 9y ago
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.

Scarbutt 9y ago

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 9y ago
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 9y ago
  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 9y ago
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 9y ago
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.

jackmott 9y ago

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

Larrikin 9y ago

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 9y ago
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 https://news.ycombinator.com/item?id=14365317
- fauigerzigerk 9y ago
  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.

seanalltogether 9y ago

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.

wtetzner 9y ago

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.