Announcement

Collapse
No announcement yet.

Google Reaffirms Commitment To Kotlin Programming Language For Android

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    Originally posted by uid313 View Post

    Yeah, and there are other weird things, like how the constructor for a class is defined in the class declaration or something weird like that.
    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.

    Comment


    • #22
      Originally posted by cynical View Post

      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.
      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.

      Comment


      • #23
        Originally posted by sandy8925 View Post
        Only some apps are bloated
        Yes I know. I said Android apps are bloated because in an overwhelming amount of cases the developers are either noobs or don't care to optimize and the tools they use tend to use the "ADD ALL DEPENDENCIES" approach for the sake of helping the noob.

        Decent quality apps are more likely to be found in opensource repos like F-Droid as the developer has a better grasp of what he is doing.

        Comment


        • #24
          Originally posted by sandy8925 View Post

          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.
          It's primarily for stuff like data classes, where you're not writing a constructor as such — you're defining a set of fields with an implied constructor to populate them.

          Comment


          • #25
            Originally posted by flashmozzg View Post

            It's been a thing for some time.
            Originally posted by cynical View Post

            They did that five years ago when they replaced Dalvik with ART. The compilation happens on app installation.
            Originally posted by sandy8925 View Post

            Android's had AoT compilation since Android 5.0 ...........
            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.

            Comment


            • #26
              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.

              Comment


              • #27
                Originally posted by kpedersen View Post
                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.
                What do you mean by building offline? Kotlin projects are built with Gradle that does have an offline mode. But I have a feeling you're not talking about that.

                Edit: There also seem to be a number of people that actually rely on it professionally: https://www.appbrain.com/stats/libra.../kotlin/kotlin
                Last edited by bug77; 12-07-2019, 12:07 PM.

                Comment


                • #28
                  Originally posted by bug77 View Post
                  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.googleblo...-with-art.html

                  Comment


                  • #29
                    Originally posted by flashmozzg View Post
                    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

                    Comment


                    • #30
                      Originally posted by Jabberwocky View Post

                      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).

                      Comment

                      Working...
                      X