In the beginning JavaScript was created. This has made a lot of people very angry and has been widely regarded as a bad move.
> widely regarded as a bad move.
By who? You? Because there’s tens (hundreds) of thousands of programmers and thousands of companies working on JavaScript. Just because many here consider JavaScript bad doesn’t mean everyone does. JavaScript has many problems, but it’s not “widely regarded” as bad.
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.
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.
Remember, Sun needed Netscape to make Java successful. Today Java is a server-side technology, but that's not how it started its life. Java started its life as a technology to build more powerful web pages (using embedded applets). Sun needed Netscape to bundle Java into its browser. So if Netscape wanted to leverage the hype that existed around Java at that time then Sun had to let them.
>Java started its life as a technology to build more powerful web pages I'm pretty sure Java came from the work James Gosling did on Oak, which was mostly used for embedded systems. I remember a lot of the early documentation being OO designs for devices like microwaves and CD players.
> I'm pretty sure Java came from the work James Gosling did on Oak, which was mostly used for embedded systems.
Yes, when it was conceived it was indeed intended for embedded systems but when it was released it was intended as a tech for building client-side smarts into web pages.
Java was originally conceived as Sun's response to General Magic's intelligent agent technology. Microsoft's response to General Magic was Microsoft Bob, because they saw General Magic's social interface as a threat to Windows.
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)
I feel like "requires compilation" is a good first order differentiator. And "has a somewhat sane type system" is another.
Well, C++ can be interpreted (sort of, see CINT) and can certainly be semi-transparently jitted (see cling). Although it's certainly not designed for that!
C# 9 added “top level statements” which seems to be the first steps towards usage in a script environment.
Which became dominant for a while, but cgi scripts on the server-side were also hot. Enter Perl and PhP server-side. Then there was JSP, ASP, and ColdFusion, all server-side. Rails! Also server-side. Then back to JS.
Rails is like 10 years later tho... everything else you mentioned was already around by 2000.
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.
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.
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”.