== Why Java is a compiled language and Python is not [[A commentator http://www.toptal.com/python/why-are-there-so-many-pythons#comment-1053628163]] on Charles Marsh's article [[Why are there so many Pythons http://www.toptal.com/python/why-are-there-so-many-pythons]] asked an interesting question: > [...] If both Java and Python produces Bytecodes which in-turn > is run by VM's why Java is called as Compiled language and Python > is called Interpreted language? [...] One comment's answer was 'marketing', which in a sense is correct; one reason we call Java a compiled language is that that's what Sun called it from the start. Another comment noted that Java has an explicit compilation phase that is separate from having the JVM execute your Java program by interpreting the bytecodes. All of this points us towards what I feel is the real answer: > ~~In Java, bytecode is a first class object. In Python it's an > internal implementation detail.~~ You've always been able to find specific documentation on the JVM and its bytecodes; as far as I know they were released along side the first definitions of Java the language. JVM bytecode has never been marked 'for internal use only' and in fact it's explicitly been a stable, public representation of Java programs. For example you don't download the source code for Java applets into your browser, you download the JVM bytecode (and in general JVM bytecode is the common delivery method of Java code even on servers). And the JVM guarantees that this will work regardless of what sort of machine you have (and in theory guarantees to make it work securely even in the face of maliciously generated bytecode). This public visibility, this treatment of bytecode as a real part of the language environment with its own documentation and guarantees and specifications, makes JVM bytecode a first class object in the overall Java ecosystem. In turn this makes it accurate to say that Java programs are (usually) compiled to JVM bytecode and then executed by an interpreter of that bytecode. This is especially so when the language's implementation makes these two explicitly separate steps with a whole collection of artifacts that are this compiled bytecode. In Python there is nothing like this; [[CPython's use of bytecode is just an internal detail of the interpreter implementation ../python/WhyCPythonBytecode]]. [[CPython ../python/CPythonVsPython]] bytecode is not part of Python semantics, it is not really documented, and you are not really supposed to generate your own. There's no guarantee of any cross-version compatibility, as CPython bytecode is expected to be consumed by the same interpreter that generated it. And so on. CPython bytecode is an interesting curiosity, not a first class part of (C)Python. (It's technically accurate to say that CPython compiles Python source to bytecodes and then interprets these bytecodes. But this is a narrow technicality, not how people really see CPython working, and can be said about any number of languages that we normally think of as interpreted.)