3 ms·

Java did improve over the years. But it still defaults to doing basically everything wrong by default. Parameters are non final, classes are open, things are mu

Java did improve over the years. But it still defaults to doing basically everything wrong by default. Parameters are non final, classes are open, things are mutable, etc. It's unsafe by default. And it's hard to fix because it breaks backwards compatibility. Kotlin doesn't have that problem and it has been doing the right thing by default for a long time. It's still getting better. I think on Android the choices are either to start from scratch or to migrate to Kotlin for Facebook. Sticking with Java on Android just makes everything harder. All the new frameworks are Kotlin centric. Most Android developers they'd be hiring would have been using Kotlin for years. Etc. So, I can see why Facebook is making the effort to keep their code base alive and future proof. Android is more Kotlin focused and has been for years. And that's only going to be more the case now that compose multi platform is a thing. Btw, most of the stuff you mention is probably more applicable to server side Java and less to Android. IMHO, Spring + Kotlin is a very nice combo on servers. Very well supported by Spring and they bundle a lot of convenient things for Kotlin. And I don't need any of the tools you mention because it does the right thing by default.

Tainnor 2y ago
> And I don't need any of the tools you mention because it does the right thing by default. I mostly agree with you, but Spring+Kotlin does require the allopen plugin, so it's kind of hacking Kotlin to do the wrong thing (all classes open) in order to support an arguably bad design choice by Spring.
- bberrry 2y ago
  Can't blame Kotlin for that. And it's a very minor sin frankly.. set-and-forget.
  - Tainnor 2y ago
    I don't blame Kotlin for it, I blame Spring for it.
- yearolinuxdsktp 2y ago
  all-open plug-in is the only sane way to operate Kotlin.
- yearolinuxdsktp 2y ago
  A whole lot of pie in the sky architects, which seems to be all of Kotlin authors and all of Kotlin-writing cadets, sure love to dream that closed by default is a good design choice and think of times when something open was extended or accessed that wasn’t actually consciously fore-thought of the intended points of extension. But they conveniently ignore the costs of these shackles to their business and agility, and I argue that the costs are far greater than the benefits, especially for non-library code. We just spent a couple of decades fighting the waterfall delusion of big design up front. Yet closed-by-default takes us back to the Stone Age that ignores the reality that there’s no way that the original code authors could’ve thought of all legitimate/sensible uses ahead of time. But good engineers tend to decompose code into smaller classes and functions, which often have a pretty good chance of being extended rather safely in practice. It is wild but such is the consequence of the culture that punishes explicit failure, and ignores failure to be able to ship fixes for the unpredicted situation and ignores failure to have a productive code base. I cry for the mounds of copy-pasted code that must result from this policy that treats its engineers code like radioactive garbage. Exception: final parameters. They should never be assignable.
  - Tainnor 2y ago
    Yeah, I disagree. Inheritance is the wrong tool for the job 99% of the time anyway.

Tainnor 2y ago

> And I don't need any of the tools you mention because it does the right thing by default. I mostly agree with you, but Spring+Kotlin does require the allopen plugin, so it's kind of hacking Kotlin to do the wrong thing (all classes open) in order to support an arguably bad design choice by Spring.

bberrry 2y ago
Can't blame Kotlin for that. And it's a very minor sin frankly.. set-and-forget.
- Tainnor 2y ago
  I don't blame Kotlin for it, I blame Spring for it.
yearolinuxdsktp 2y ago
all-open plug-in is the only sane way to operate Kotlin.
yearolinuxdsktp 2y ago
A whole lot of pie in the sky architects, which seems to be all of Kotlin authors and all of Kotlin-writing cadets, sure love to dream that closed by default is a good design choice and think of times when something open was extended or accessed that wasn’t actually consciously fore-thought of the intended points of extension. But they conveniently ignore the costs of these shackles to their business and agility, and I argue that the costs are far greater than the benefits, especially for non-library code. We just spent a couple of decades fighting the waterfall delusion of big design up front. Yet closed-by-default takes us back to the Stone Age that ignores the reality that there’s no way that the original code authors could’ve thought of all legitimate/sensible uses ahead of time. But good engineers tend to decompose code into smaller classes and functions, which often have a pretty good chance of being extended rather safely in practice. It is wild but such is the consequence of the culture that punishes explicit failure, and ignores failure to be able to ship fixes for the unpredicted situation and ignores failure to have a productive code base. I cry for the mounds of copy-pasted code that must result from this policy that treats its engineers code like radioactive garbage. Exception: final parameters. They should never be assignable.
- Tainnor 2y ago
  Yeah, I disagree. Inheritance is the wrong tool for the job 99% of the time anyway.