interp or compile

Java is "compiled", Python is "interpreted". Really?

Both are compiled to byte code, and then put through a compiler.... so they are more similar than different. Why is the distinction still made between these two popular modern languages?

Java → .java source → compiled by javac → .class bytecode → executed by the JVM (Java Virtual Machine).

Python → .py source → compiled by CPython → .pyc bytecode → executed by the Python Virtual Machine (part of CPython).

Historical context & tooling

Java was designed (mid-90s) to look and feel like a "compiled" systems language. The javac compiler is explicit: you run it first, it outputs .class files. These can be distributed separately from the source.
Python, by contrast, was historically pitched as an "interpreted scripting language": you run python script.py, and the compilation step (to .pyc) happens implicitly and transparently.

That difference in developer workflow shaped how they're described.

2. Optimization & JIT

The JVM usually doesn’t just interpret bytecode — it uses JIT (Just-In-Time) compilation: hot parts of the code are recompiled into native machine code at runtime. This makes Java behave more like a "compiled" language in performance characteristics.
CPython, the most common Python runtime, interprets bytecode without JIT. So execution stays in the "interpreted" territory. (Although there are projects like PyPy or Pyston that add JITs.)

3. Distribution & abstraction

In Java, the compiled .class or .jar files are the main distributable. You don’t need the .java source.
In Python, the .py source files are typically distributed, and .pyc is more of a cache than a primary artifact. Most people don’t even think about them.

4. Cultural / categorical shorthand

When people say “compiled language”, they usually mean:

Requires an explicit compile step.
Produces distributable binaries (or bytecode).
Usually optimized ahead of time (AOT) or with JIT.

When people say “interpreted language”, they usually mean:

You just run the source directly.
Compilation is implicit/hidden.
Execution tends to be slower (no JIT or AOT by default).

Technically:
Both Java and Python compile to bytecode and then interpret it.
But Java leans more toward "compiled" in practice (explicit compiler, JIT, distributable bytecode), while Python leans toward "interpreted" (implicit compilation, direct source execution, no default JIT).

The C# / .NET Pipeline

Source code → written in C# (.cs).
Compilation → compiled by csc (or Roslyn) into CIL/IL (Common Intermediate Language) → stored in .dll or .exe.
Execution → the CLR (Common Language Runtime) loads the IL.
- At runtime, the CLR’s JIT compiler translates IL into native machine code.
- For repeated/hot code paths, the JIT can optimize aggressively (similar to Java’s HotSpot VM).

There’s also AOT (Ahead-Of-Time) compilation in newer .NET versions (Core/5/6/7+), where IL can be precompiled into native binaries before shipping.

Key Takeaways

C# and Java are almost twins: both compile to bytecode/IL and both rely on a VM with JIT.
Python also compiles to bytecode, but because:
- compilation is implicit/hidden,
- .pyc is treated as a cache, not the main artifact,
- and CPython doesn’t JIT by default, it gets the “interpreted” label.
C# (modern .NET) actually blurs the line even more than Java:
- You can ship IL assemblies (like Java bytecode).
- Or precompile to native with .NET Native / AOT for faster startup and no JIT overhead.
- So C# is both a compiled and JIT-interpreted language, depending on configuration.

How JavaScript Runs

Historically (early Netscape days):

JS was purely interpreted: source code → parsed → executed line by line in the browser.
This was simple but very slow.

Modern engines (V8 in Chrome/Node, SpiderMonkey in Firefox, JavaScriptCore in Safari) use a multi-tier pipeline:

Parsing → source code → Abstract Syntax Tree (AST).
Baseline Compiler → quickly turns JS into bytecode for a lightweight VM.
Interpreter → runs the bytecode immediately (fast startup).
JIT Compiler(s):
- Detects "hot" functions/loops.
- Compiles them into optimized native machine code.
- Uses profiling feedback (types, shapes of objects, etc.) to specialize code.
- If assumptions fail, de-optimizes back to the interpreter.

This is called tiered JIT or speculative JIT — it’s why JS can sometimes approach C-like performance in hot loops.

Why JS is still called “interpreted”

Historically true (early browsers = interpreted only).
You still write and run directly from source (like Python).
There’s no explicit “compile step” a developer invokes — it’s all hidden in the runtime.

But under the hood, JS today is closer to Java/C# than to Python:

Heavy reliance on JIT.
Hot paths get optimized into machine code.
Profiling + deoptimization techniques are much more advanced than Java or C# JITs.

Spectrum with JS included:

C (AOT native)

─── Java / C# (bytecode + JIT/AOT)

─── JavaScript (source → JIT tiers, very optimized)

─── Python (bytecode, no JIT by default)

Comparison

In summary:

C optimises goes straight to native code via AOT.
Java/C# both go through bytecode/IL, then optimise at runtime with JIT (or AOT in .NET) to native.
Python compiles to bytecode, has no default optimisation and stays interpreted.
JavaScript has the most layered pipeline, with both interpretation and heavy tiered JIT optimisation.

Use the following keys to get a better vision of where optimisation occurs:

🔵 Light Blue = Source
🟡 Yellow = Bytecode / IL stage
🟢 Green = AOT or JIT Optimization
🟠 Orange = Native Machine Code
🔴 Red = Interpreted (no JIT)

Execution Pipelines with Optimisation

C (AOT native)

🔵 Source code
→ 🟢 Compiler (AOT Optimization)
→ 🟠 Native Machine Code

Java

🔵 Source code
→ 🟡 javac → Bytecode (.class)
→ 🟢 JVM JIT Optimization
→ 🟠 Native Machine Code

C# / .NET

🔵 Source code
→ 🟡 csc → IL (.dll / .exe)
→ 🟢 CLR JIT or AOT Optimization
→ 🟠 Native Machine Code

Python (CPython)

🔵 Source code
→ 🟡 Implicit compile → Bytecode (.pyc)
→ 🔴 Interpreter (no JIT)

JavaScript (modern engines)

🔵 Source code
→ 🟡 Parser → Bytecode
→ 🔴 Interpreter (fast startup)
→ 🟢 Tiered JIT Optimization
→ 🟠 Native Machine Code

Summary

C: all optimisation is before running → very fast once compiled, but startup cost at compile time.
Java/C#: hybrid → quick distribution as bytecode/IL, then JIT kicks in for long-running performance.
Python: no JIT, so slower but simpler and very dynamic.
JavaScript: mix of interpreter (fast startup) + speculative JIT (high performance in hot code).

Page updated

Google Sites

Report abuse