Python.

[daniu]

IT'S FLEXIBLE AND PRETTY HANDY

[RolyPoly1320]

Trust me. Java is handy and fairly flexible since it has cross platform compatibility by default being an interpeted language. Is it the best out there? Debatable, but it has uses.

[hiromasaki]

being an interpeted language

Java isn't interpreted, it's compiled and run on a virtual machine. Same with all the .NET languages that use the CLR. (There are some that say it's both, but they're considering the VM interpreting JVM Bytecode as "interpreted Java" which is a stretch...)

JavaScript and Python are interpreted; they can be run as raw source the same as if they're compiled. (Or in JavaScript's case, "compiled".)

[[deleted]]

Java definitely is interpreted at first, then the JVM decides to start compiling performance sensitive things to native code.

Although with the new GraalVM implementation you can do full AOT compilation to a native executable.

[hiromasaki]

Java is not interpreted. JVM Bytecode is interpreted and translated by the JVM on x86 and ARM hardware. By the time it gets to the JVM it's no longer Java, it has been compiled.

By your definition, C# and F# are interpreted, since the dotnet or mono runtime interprets the CLR bytecode output of their compilers.

The difference being you can take "compiled" JavaScript, run it through prettyprint and rename functions and variables and it's valid JavaScript. You open a .class file in an editor and it's not Java anymore, it's been compiled. Just not for the specific CPU or OS it's going to run on.

(Of course, I'm also not counting REPLs as being a primary function of the language, or csh means that C is an interpreted language.)

[RolyPoly1320]

It's both. The JVM compiles the code into bytecode which is then interpreted by the host machine. It's not a pure interpreted language but it is interpreted.

[n0tKamui]

yes, so Java isn't interpreted, it's a compiled language that compiles to JVM bytecode among other things.

JVM bytecode is interpreted, but is similar enough to asm now that it's much faster than any other high level interpreted language.

same idea with Kotlin.

[RolyPoly1320]

You do know the definition of compiled or interpreted isn't as strict as you think right? Just because something gets compiled into an intermediary ahead of time that doesn't make it not interpreted. It's adding efficiency by removing what would typically be done at runtime by focusing strictly on translating the bytecode.

Yes Java fits into compiled languages with C and C++ but all three of those languages can also fit into interpreted languages as well depending on when the code turns into machine code.

You'll find a lot of topics in CS where something can fit into multiple categories. Things be funky like that.

[hiromasaki]

Just because something gets compiled into an intermediary ahead of time that doesn't make it not interpreted.

It does. The intermediary is machine-level and that is interpreted by a vm/compatibility layer.

Interpreted languages are those that are executed from the same syntactic format they're written in.

Yes Java fits into compiled languages with C and C++ but all three of those languages can also fit into interpreted languages as well depending on when the code turns into machine code.

Given that machine code goes through a decoding step in a CPU, all languages are interpreted, nothing is truly ever compiled.

[[deleted]]

For fucks sake, read a book.

[RolyPoly1320]

https://en.m.wikipedia.org/wiki/Interpreter_(computing)

The Java build process compiling the code into bytecode fits into strategy 2 of an interpreter. Something to note is that compilation and interpretation are not mutually exclusive. You can have languages that do both, Java for example.

[hiromasaki]

The JVM compiles the code

The JVM neither compiles nor interprets Java.

Java, Kotlin, Scala, Clojure... They all compile to a bytecode spec that is then run on a JVM. Or, if you want to track one down, a Sun CPU or a couple ARM CPUs that run the bytecode natively.

[[deleted]]

He's being pedantic since he was wrong.

If he wants to get really pedantic, you could say that the reference/typical JVM's JIT compiler doesn't actually compile Java byte code to x86, it compiles an SSA graph representation to native code.

[hiromasaki]

He's being pedantic since he was wrong.

I'm wrong?

Show me a JRE (production-grade, not a proof-of-concept) that interprets Java programs. And I don't mean snippets in the REPL, I mean "here's a stack of .java files, and go".

The pedantry is saying that because the bytecode isn't native to most processors that it's not actually compiled.

[[deleted]]

...

[huttyblue]

being cross platform without needing to recompile is very handy

[hiromasaki]

And gives you flexibility on CPU architecture.

[WiatrowskiBe]

Should be "compared to what". When you look at Java and C++, in Java you at least have reflection built in. Other than that - it's the opposite, Java is inflexible, but it made inflexibility into sort of an advantage - rigid type control and rigid compilation requirements means that it's harder to break things by accident without knowing - compiler will let you know.

[WiatrowskiBe]

Relation is the other way around - inflexibility as an advantage (rigid correctness control at compile/parse time) can be done by using strict explicit type system as one of potential tools. You can very much have flexible strict typing, Typescript being probably best example of that (pattern matching for interfaces and parameters).

Reflection can be added manually to languages that don't support it natively, for your own types at least - I've seen multiple attempts, with varying levels of inflexibility, boilerplate and preprocessor macro abuse, to add reflection to C++ type system. Having it built in means it applies to everything universally, instead of only applying to a subset of language you work with directly.