This often takes a long time for people to understand. Java applications are not "native". Think of it in terms of human languages. C and C++ (and many - but

This often takes a long time for people to understand. Java applications are not "native". Think of it in terms of human languages. C and C++ (and many - but not all - compiled languages) get compiled into Native program, so they get compiled into instructions that talk the computer's language, and when they get run they talk directly to your computer... albeit with a thick accent. So a linux machine can only talk to your machine via the linux kernel, a windows machine talks with a windows accent, macs... you get the idea. Because of this thick accent, programs cannot be shared between different operating systems (though there are some amazing projects out there that either do some accent translation, or more recently, do clever things to avoid any accent at all. There are almost always limitations to what can be done here though.) That's not to say that sometimes, they don't need help. These "helpers" (or Shared Libraries - aka DLLs or .so files) might be absolutely necessary for a certain program to run, because the developers don't want to reinvent the wheel. So as someone else pointed out, even with native programs you sometimes need to download extra bits to get them running. But as you've noted, this is a lot more rare, and it doesn't usually change HOW you run the program, merely what needs to be installed first. PHP, Ruby, Bash etc are Interpreted - so they need a special program that does the talking to the machine (again, via the kernel). This means they don't need to be compiled, which makes them quicker for developers to write, and easier to run on windows / linux / mac using the same codebase. But like with a human interpreter, it generally takes at least 2x as much energy to get the message across, which usually means a sometimes significant slowdown. Note that this is not the same as having a Shared Library - and in fact these programs sometimes do use Shared Libraries directly. With interpreted languages, the interpreter starts first, it gathers together some core resources and ideas that it will need to be able to do its interpretation, and then it will load the human-readable program. Some shared libraries will be loaded by the interpreter, and some will be loaded later once the interpreter has seen the code. Java is in a special category. It is both interpreted and compiled - that is to say, it compiles to something that looks a bit like a native program, but it still has this interpretive layer that gathers together core resources and ideas that the compiled program can then use - we call this part of the interpreter a VM, or Virtual Machine. It then loads a program that is very much not human-readable into that VM, which then does all the translating. The theory is, Java could be the best of both worlds. It can have speed closer to a compiled language (and in fact, can sometimes be a little faster in places, as the VM contains some nifty tricks to move things around on certain machines) and yet the compiled languages can be run on any machine that has the Java Runtime installed (I believe they coined the phrase "Write once, run everywhere" which very soon got corrupted to "Write once, test everywhere" because the first few versions of the Java VM were spectacularly buggy) As for that dislike of Java, I will point out that I spent 5 years writing Java programs. Once I was no longer forced to write Java programs, I stopped, and haven't touched it for at least 10 years. Because while Java could be the best of both worlds, it wasn't then. And it might be much better now... maybe. I cannot forgive it for the years of my life that it stole; and am now very happy in the arms of pretty much any other language.