Google Reaffirms Commitment To Kotlin Programming Language For Android

[bug77]

Yes, I do...
But why would Material Design be an extra weight? Extra libraries?
I mean, isn't it supposed to be simpler than the old one?

If anything, Material Design should shrink the size of an app, because most assets are now preinstalled, eliminating the need to package them.

Is its even possible to build an Android Kotlin project offline? Last time I checked, the whole system was so incredibly dependent on external information (thus non-deterministic), you could never rely on it professionally.

Nah, NDK cross compiler and Makefiles for us. Android's "build system" (if you can call it that) and internet consumer tech like Kotlin are a waste of time.

??? It depends on how you specify your dependencies.

The Gradle build system is also quite deterministic, especially if you use the Gradle wrapper. You get the same build on every machine, regardless of OS and performance.

[bug77]

Good point, I always forget the update situation on Android since I used a Nexus/Pixel when I was using that platform.

I doubt it's as bad as Guest claims. About 25% of the phones out there run Lollipop or older Android versions (https://developer.android.com/about/dashboards) and those that do are probably sporting old enough hardware that they wouldn't be able to run modern apps anyway.
Sure, I'd like to see 90%+ of the devices running the latest version as much as the next guy, I'm saying, it's not that grim, all things considered,.

Oh, yeah I kind find that part of Kotlin a bit weird. Kotlin is a bit weird.
I kind of like the "There should be one—and preferably only one—obvious way to do it." philosophy of Python.

I like the whole Zen of Python (for those that don't know it: https://www.python.org/dev/peps/pep-0020/). I like the second and third to last best.

[uid313]

The Android SDK supports Java 8 now. I don’t see the point of Kotlin really. Modern Java is nicer to look at, it just needs support for records to get approved to help eliminate some more boilerplate and it’ll be in a good place.

I think it is only a subset of Java 8, not all of it. Also Java 8 is outdated, now there is Java 13.
It doesn't support type interference, so the code gets repetitive since you can't use the var keyword. It doesn't have support for properties with getter/setters either. I much prefer C# over Java.

[uid313]

That part's optional - it's more of a convenience - if you only have a single, simple constructor with a few arguments, you can define it right there.

Oh, yeah I kind find that part of Kotlin a bit weird. Kotlin is a bit weird.
I kind of like the "There should be one—and preferably only one—obvious way to do it." philosophy of Python.

[cynical]

It's only supported on Android 7.0+ - Google Play itself supports a minimum of Android 4.0, and most app developers probably have Lollipop/Kitkat/Jellybean as their minSDK.

Good point, I always forget the update situation on Android since I used a Nexus/Pixel when I was using that platform.

[tildearrow]

Remember back before "Material Design" when Android apps were often only a couple hundred kilobytes?

Yes, I do...
But why would Material Design be an extra weight? Extra libraries?
I mean, isn't it supposed to be simpler than the old one?

[Vistaus]

Why does it feel like this argument leads to the next problem static- vs dynamic-executables vs light interpreters (wasm/bytecode)?



Things like protobuf helps to extend the life of bloated languages allowing for quick reuse of existing code/libraries in massive ecosystems. I agree with your statement that it is and hopefully will continue to be harder to sell in microservices and other environments that actually create incentive to write good code.

That said, people don't understand the advantages of bloated applications (increased productivity while maintaining backwards compatibility). Imagine being able to run your favorite legacy GTK+ or QT based application without having any build or runtime issues.. I know I'd have crazy old beryl or superkarambas themes all over my screen. Most apps isn't expected to last very long since we have lost the ability to plan for the future and break backwards compatibility to reduce bloat (amongst other things). Simply base all our short term plans on market reaction and if it works out try to make your bloated framework or language last as long as it can possibly can. In this regard to bloated apps are the best fit for the market demands.

In all honesty related to the reason above I prefer robust native apps over feature rich, modern UX. Like discord vs IRC. I'm simply stating that I'm the minority... by far.

SuperKaramba works fine on Plasma if you install TQt (TDE's Qt fork).

[bug77]

I was also talking about that.

https://android-developers.googleblog.com/2019/04/improving-app-performance-with-art.html

No, you weren't:

improves the application startup time after a new install or update

There's a difference between doing it after the install and doing it before downloading

[flashmozzg]

Right now you get the whole bytecode that is translated into executable code upon install. I was talking about doing all that on the server (based on the phone model) and push just the resulting executable to the phone. Smaller download, less time to install

Hell, I think it can be done for Kotlin today, because Kotlin already has a native backend. But I'm not sure how well it works for various SoCs out there.

I was also talking about that.

https://android-developers.googleblog.com/2019/04/improving-app-performance-with-art.html