Hacker News new | ask | show | jobs
by mlyle 2027 days ago
How could one consider Java a scripting language? It's compiled to .class files, has no reasonable interactivity, strict structure enforced upon the code, etc. E.g. the antithesis of what makes us call something a scripting language in basically every category.
2 comments

So JavaScript meant "complement to Java, but converted to machine language in the browser, instead of compiled?"

(Thank you, genuine question)

JavaScript is "logically" run line by line from the beginning of the script. This may not be exactly true anymore for performance reasons, but it's the logical model behind it. A single set of expressions to run in order "a=1+1;" is a conformant JavaScript script; hence, it's a scripting language. It doesn't take much imagination about how to have a JavaScript console that operates interactively from user input.

Java code has lots of structure required to write a minimal program. Java is transformed by compilation into a set of .class files. Then, in turn, a loader loads, resolves all the classes, and begins transforming and executing code.

These distinctions can be muddy sometimes.

> So JavaScript meant "complement to Java

The whole JavaScript thing was just marketing. In 1995, Java was THE hottest thing so associating it with Java might fuel adoption/acception.

There is an old saying; Java is to JavaScript what Car is to to Carpet.

Re. your compiled question. It's up to the browser on how to execute JavaScript. E.g. Chrome has the V8 engine. This is the VM that compiles and executes JavaScript within Chrome. Other browsers might have different engines.

https://en.wikipedia.org/wiki/V8_(JavaScript_engine)

More like interpreted rather than compiled. (I'm pretty sure a google search on "interpreted versus compiled" will get you up to speed with the basics on this point.) This is generally seen as one of the main differences between "scripting" and "serious" languages.

The twist is that the JVM (Java Virtual Machine) is also a kind of interpreter, but can do on-the-spot ("just-in-time") compilation of parts of the code as well.

Sorry I am not an expert in Java, but doesn’t the jvm execute the .class files like bash would execute the .sh scripts.
Class files contain compiled bytecode, not source code like shell scripts do. “Script” implies human-readable source code. Java bytecode is binary, a kind of portable machine language.
Of course, there's murky things like Python which make bytecode compiled forms behind the scene.

But there's a lot of magic involved in transforming Java to class files, and then there's a lot of further magic in resolving, loading, and eventually executing classes.

PHP does the same. It’s compiled to a bytecode before execution. But I don’t think it’s cached anywhere like Python (but that may have changed in the decade since I’ve used it)
PHP has had an OPCache as an add-on since 5.1.0(around 2004), and by default since 5.5.0: https://www.php.net/manual/en/intro.opcache.php
It better be cached or else that would be a total tradegy... why wouldn't you automatically want to cache the prerendered pages whenever possible?

It's not like writing a basic cache is very hard...or just "borrow" one from an OS implementation.

Does this mean java .class falls in the middle of scripts and native executables? Is this analogy correct? For example, I think of native executable as Microsoft Word where you can doubleclick and launch it. Whereas with .class you have to run it on top of a jvm.
No. If you must insist on thinking of them as distinct from native executables, then consider them foreign executable instead—object files written for a different machine architecture and a different loader convention. There's really no middle ground they're occupying.
This is a very good way to put it.

The super pedant in me, of course, would say they're a sliver in the middle because they're targeted at running in a software-implemented VM instead of on a real machine architecture, and that this isn't all that different from in-memory interpreter bytecode or something like a .pyc written to disk...

But then something like the more complicated loaders for native executables is a sliver in the middle, too. And then you look at something like the AS/400 with super-high level "instructions" and these distinctions get super, super muddy.

Not exactly. For one, class files are just components of a program, so more akin to .o or .so files, not executables. That set aside, they are binaries for a virtual machine, the JVM. One difference to real machines is that the bytecode doesn’t have access to untyped memory and to the hardware (not even “virtual” hardware), and some instructions have more complex semantics than you usually have in real hardware, but otherwise it’s not so much different from actual machine code. Overall it’s closer to native than to script, and therefore I wouldn’t quite say that it’s in the “middle”.
Often even a "native" executable is opened by something like the ELF interpreter, relocated, etc. Yes, a JVM is a lot more heavyweight than these services, but...
A scripting language is generally thought as a language suitable for quick easy project, less so for large scale software engineering. Verbosity of syntax, compilation, presence of boilerplate code, static typing are all things that make java unattractive as a scripting language.

Java is great at what it does, which is not scripting.

I’d like to instead say “static typing without type inference” to be pedantic. I quite like writing scripty stuff in Haskell, and the type system helps in it actually running correctly sooner.