Since its inception, Microsoft Excel has changed how people organize, analyze, and visualize their data, providing a basis for decision-making for the flying billionaires heads up in the clouds who don’t give a fuck for life offtheline

        • Phrodo_00@lemmy.world
          link
          fedilink
          English
          arrow-up
          10
          arrow-down
          1
          ·
          edit-2
          1 year ago

          If you go that detailed, then the jvm is JIT compiler, not an interpreter, so Java code still mostly runs natively on the processor. Java is quite fast achieving pretty close performance to C++, the only noticeable problems are on desktop because of the slow jvm startup and slow GUI libraries compared to native ones.

            • wolf@lemmy.zip
              link
              fedilink
              English
              arrow-up
              6
              ·
              1 year ago

              Factual errors:

              • Interpreters neither need nor usually have a compilation step
              • Even processors are nowadays virtual machines, modern hardware only understands microcode AFAIK

              Words which have a common understanding in the current compiler construction world, which you define in IMHO a non standard way

              • Compiler is commonly used to refer to tools which translate higher level languages (e.g. Java, C, Python, JavaScript) to a machine representation (e.g. JVM, Arm64, x86_64, MIPS…)
              • Even in academia Java is referred to as compiled/interpreted language (at the same time)

              Factual errors about Java:

              • We have ahead of time compilers for a very long time now (GraalVM etc)
              • There are chips which implement the JVM in hardware
            • Phrodo_00@lemmy.world
              link
              fedilink
              English
              arrow-up
              1
              arrow-down
              1
              ·
              1 year ago

              all interpreters have a compilation step that produces machine code

              Very much not a thing. JIT interpreters are actually not that common. Most interpreters parse code to an AST in memory and then run execute said AST, without any compilation to machine code.

              the output of the standard javac compiler is not machine code that a processor understands. This is what makes Java not a compiled language.

              Listen to yourself the output of the compiler makes it not a compiled language. Java is a compiled language, and jvm bytecode can be compiled (see graalvm), or interpreted (and when interpreted it can be JITd)

            • Aceticon@lemmy.world
              link
              fedilink
              English
              arrow-up
              1
              arrow-down
              1
              ·
              edit-2
              1 year ago

              I think you’re used to modern interpreted languages and are unaware of how the runtimes of interpreted languages used to work.

              Something like Basic (to use a properly old example) was constantly interpreting source code during the entire run.

              If I’m not mistaken Python was the first major interpreted language which by default interpreted the code into a binary format and then just ran the binary (and, if I remember it correctly, that wasn’t the case in its first version). By this point Java already JIT compilation in its VM for a while.

              I think you’re committing the error of comparing modern interpreted languages with how Java worked 2 decades ago.

        • Aceticon@lemmy.world
          link
          fedilink
          English
          arrow-up
          6
          ·
          1 year ago

          There is another compilation step inside the Java Virtual Machine which “compiles” the VM Assembly code to native code at runtime.

          This is what’s called JIT compilation and has been part of the standard Java Virtual Machine for about 2 decades and the default - at least server side - for almost as long (i.e. you have to explicitly pass a parameter to disable it at startup if you want the old runtime interpreted VM opcode behaviour).

          Source: I used to design and develop mission critical high performance distributed server systems in Java for banks since before 2008 and it definitelly is capable of handling it (the bottleneck tended to be the TB-size database, not the Java application).

      • Captain Aggravated@sh.itjust.works
        link
        fedilink
        English
        arrow-up
        5
        arrow-down
        4
        ·
        1 year ago

        Eh…Java source code compiles into bytecode which runs in a virtual machine. Compare this to a language like C which compiles to native machine code. Java still gets interpreted.

        • qaz@lemmy.world
          link
          fedilink
          English
          arrow-up
          6
          arrow-down
          1
          ·
          1 year ago

          The bytecode is turned into native code before execution

          • Aatube@kbin.socialOP
            link
            fedilink
            arrow-up
            1
            arrow-down
            2
            ·
            edit-2
            1 year ago

            That’s not how it works. If that really was how it worked there’d be no point even having bytecode; you’d just straight up get the native code. Unless you’re talking about JIT, but your wording seems to be implying that all the bytecode turns into native code at once.

            • qaz@lemmy.world
              link
              fedilink
              English
              arrow-up
              4
              ·
              edit-2
              1 year ago

              I was referring to JIT but there are also other options like GraalVM for AOT compilation.

          • 31337@sh.itjust.works
            link
            fedilink
            English
            arrow-up
            2
            ·
            1 year ago

            Yeah, in my personal experience (with numerical compute-heavy code), normal python code, ran in the normal python interpreter, is much slower than the equivalent normal Java code with the normal Java VM (like 50x). Then C/Fortran is ~2x faster than Java (with gcc + optimization flags).

            I think Java is a good middle-ground between coding speed and execution speed. Sadly, it seems to be dying. And JavaFX is shit for trying emulate full-stack web-dev. The fucking ancient Swing is even better.

            Scala and Kotlin are OK, but I think they are making the mistake of feature-creep that causes large projects with many people to contain multiple programming paradigms that only some of the team can grok well, instead of a restricted OOP Java codebase that encourages Gang of Four style code. Though, I guess GoF-style code resulted in that crazy complicated “enterprise” Java shit.

            • Aceticon@lemmy.world
              link
              fedilink
              English
              arrow-up
              3
              ·
              edit-2
              1 year ago

              Last I checked Java was alive and well in the server-side for things like middleware and backend, especially because the whole development ecosystem is incredibly mature and significantly more stable and well integrated with corporate-category systems than pretty much anything else (good luck managing a single reliable transaction across, say, 2 different databases in 2 different sites and 1 MQ system with Python).

              Absolutelly, it’s been mostly limping in a half-dead state on the UI ever since day 1 and even Google using it with Android didn’t exactly help (because Google’s architectural design of the entire Android framework is, well, shit, and has become worse over time).

              It also lost it’s proeminence in dynamic web page generation at around the early 00s to actual templating languages (such as PHP) with a much lower learning curve and later to Python.

              The ecosystem for Java is rock-solid and in widespread use in corporate multi-tier architectures that require reliable operation (were, for example, it’s native multi-threading synchronisation support and core libraries make a huge difference) and integration with professional backend systems, but for the rest, not so much (I did both that stuff and Android, and the latter is like the amateur-hour of Java ecosystems in comparison with the former).

                • Aceticon@lemmy.world
                  link
                  fedilink
                  English
                  arrow-up
                  1
                  ·
                  1 year ago

                  The problem in Android has always been that the framework design is pretty bad in design and technical architecture terms and its evolution over time has made its glaring flaws more obvious and actually made it even messier, rather than the language (Java is fine as languages go and UI stuff only has to run in user-time, so response times of 100ms are fine and bleeding edge performance is not required).

                  Further, splitting the user base into two languages, by introducing a new language that is not used anywhere else (hence you’re not going to find Kotlin programmers from outside Android development whilst you will find plenty of Java programmers) is one of the stupidest technical architecture decisions I’ve seen, and I’ve been in the industry for over 2 decades.

                  Last but not least, the gains from the small programming-time efficiency advantages of Kotlin over Java are a drop in the ocean next to the losses due to the Android Framework itself being badly designed (something as simple as not having functions in different core classes that do the same thing named the same).

                  Even for programmers going for Kotlin is a less than wise career move: as an Android-only language those who specialize in it are locking themselves into programming for Android only and have fewer career options - hands up anybody who expects to still be programming Android in 10 years time! The great thing of generic languages is that there are a lot of lateral career moves you can make without the high likelihood of failure that comes from hiring managers naturaly prefering people with several years of experience in the programming language used in their projects over people who say “I’ve mainly done Kotlin but I can learn that easilly”.

                  What many years of experience in the industry tells me is that you don’t want your career to hang on the ficklness of a vendor, any vendor, especially the likes of Google who will drop massivelly hyped systems with tons of 3rd party investment whenever they feel like: just ask everybody who invested in developing for Stadia.

                  • Aatube@kbin.socialOP
                    link
                    fedilink
                    arrow-up
                    1
                    ·
                    1 year ago

                    I code Kotlin for a hobby and have never heard of Android frameworks. While the largest use case is still Android it IS a very good language, and there are a LOT of things online about Kotlin being used outside of Android. Kotlin is a generic language; you don’t need Android stuff at all to use it.