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
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
java isn’t slow
I mean, whatever speed java has or doesn’t have, what the other person said was emulate, you’ll have your os then on top of that the JVM then on top of that your python implementation, then finally the python code. If that’s faster than os->python imp…
Just like Python doesn’t run from the source code through the interpreter all the time (instead, if I’m not mistaken, the interpreter pass converts the code to a binary runtime form, so interpretation of the source is done only once), so does “modern” Java (I put modern between quotes because it’s been like that for almost 20 years) convert the code in VM format to binary assembly code in the local system (the technology is called JIT, for Just-In-Time compiler).
It’s Jython and it’s like 25 years old
Still on python2 as well (Stable version )
If you need python 3 there’s also graalvm but its python support is still “experimental”.
Plus Java IS slow, quite slower than compiled languages at least
java is a compiled language
That’s not really what people mean when they’re talking about interpreted versus compiled languages. Java’s compilation step produces an intermediate language that still has to be interpreted before it’s executed.
It turns Java code into something that can be interpreted faster, but not into something your processor directly understands. The key here is that it doesn’t produce an output that can be fed directly to the processor without additional work at runtime.
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 fats achieving pretty close performance to C++, the only noticeable problems are on desktop because of the slow jam startup and slow GUI libraries compared to native ones.
I think you’re missing that all interpreters have a compilation step that produces machine code, that’s a requirement to produce programs.
Java’s JIT compiler is the final compilation step of Java’s interpreting path running in a separate thread that turns the intermediate language to machine code. To be very clear though, the output of the standard javac compiler is not machine code that a processor understands. This is what makes Java not a compiled language. It depends on additional processes at runtime to turn the code you wrote into something a processor understands.
On the performance front, well written Java is fast enough as long as you have sufficient resources for the overhead of JVM and as long as you don’t have strict latency requirements. That makes it good for a pretty wide variety of computing tasks, but, also not a good choice for a lot of others.
Factual errors:
Words which have a common understanding in the current compiler construction world, which you define in IMHO a non standard way
Factual errors about Java:
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.
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).
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.
The bytecode is turned into native code before execution
Performance of non-native bytecode such as Web Assembly can reach quite close (80%-ish) to machine code.
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.
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).