512
Microsoft announces Python formulas in Excel... which have to get sent to the cloud
(techcommunity.microsoft.com)
this post was submitted on 23 Aug 2023
512 points (97.1% liked)
Technology
59261 readers
2548 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related content.
- Be excellent to each another!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, to ask if your bot can be added please contact us.
- Check for duplicates before posting, duplicates may be removed
Approved Bots
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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.
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 originally had words about ahead of time compilers like GraalVM but got tired of looking at my own wall of text so I trimmed it down and left compiler to mean ahead of time compulers, which I see caused confusion, you're right on those points.
I know the JVM hardware exists also, but, it's specialty hardware even at the enterprise level. You could technically make an ASIC that executes QBASIC at hardware but I'm not sure I'd believe that makes it a compiled language since it would be neither wide spread nor the original use case for it. That's kind of a philosophical argument though
I think my use of compilers in interpretation may also be confusing, interpreters have an execution step, which at some point translates to a machine representation of your code. It's referred to as execution, but, it feels a lot like a compile+execute step
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.
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.
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)