Announcement

Collapse
No announcement yet.

Google Reaffirms Commitment To Kotlin Programming Language For Android

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

  • #41
    Originally posted by Aeder View Post
    It's funny that Google's reputation for killing products regardless of how loved they are leads to having to say things like "Yes, we will continue to support this growing programming language".
    My inner cynic just wonders whether they're scheming on switching to it as a way to get out of Oracle's litigious sights.

    Comment


    • #42
      Originally posted by tildearrow View Post

      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?
      I looked through the F-Droid apk and a lot of the size comes from multiple versions (for different screen densities) of a number of png images, all of which would be better represented with svg images (or even Google's own webp image format...).

      Even zstd does a better job of compressing those images than png...

      Comment


      • #43
        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.
        It depends on what you mean by "offline", but generally with tools like Maven or Gradle, the dependencies are downloaded and cached, so you don't need to be online if stuff isn't cached... e.g. you've changed dependencies, or you're working on a new project and don't have its dependencies cached yet. In large organisations, it's also common to have a local proxy, so that individual developers aren't downloading from the internet but from a local server... the build machine doesn't itself need internet access.

        As to "rely on it professionally", these tools have been the standard for the Java world — enterprise development — for many years now, so I'm not sure what you're thinking of... hundreds of thousands of developers _do_ rely on it professionally. And it generally _is_ deterministic, since dependencies don't change automatically... if some package you depend on releases a new version, you're not going to find yourself automatically upgraded. It's not impossible that someone could re-publish a modified artefact under a previously-released version, but that doesn't really happen, since people quickly stop trusting projects that do that kind of stuff.

        Comment


        • #44
          Originally posted by archsway View Post
          Even zstd does a better job of compressing those images than png...
          Really? OK, I'll make up my own format then: test.ppm.zstd

          Comment


          • #45
            Originally posted by uid313 View Post
            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.
            They have the major stuff like streams and lambdas, which make Java bearable. I'd love to have var, and ofc when I say modern Java is a good language I'm talking about the latest Java, but even Java 8 is such a massive improvement. Loosening the restrictions a bit and letting people just write lambdas instead of anonymous or inner classes is just amazing. I'm a lisp programmer at heart so anything that takes us a step closer to the functional paradigm is worthy of praise from me.

            The thing that most excites me is GraalVM, since I might be able to skip Java entirely and write Clojure without an application startup time or memory penalty. In fact, I love how we are moving towards targeting some kind of runtime/bytecode by default with WASM and the JVM. People should be able to write in their language of choice and get decent performance. You might save memory by not having to package a large runtime if you are using C, C++, or Rust, but regardless your code should execute with similar performance.

            Comment


            • #46
              Originally posted by tildearrow View Post

              Really? OK, I'll make up my own format then: test.ppm.zstd
              potrace did a pretty good job on most of the images, and when zipped, reduced 480k of images (there are more...) to 80k.

              When using squashfs, the converted svg images got compressed to 14k, a reduction of 34x!

              Comment


              • #47
                Originally posted by archsway View Post
                When using squashfs, the converted svg images got compressed to 14k, a reduction of 34x!
                But that's because XML (the language used in SVG) has a lot of words and hence is easy to compress.

                Comment

                Working...
                X