Compiled vs Interpreted: Two Ways to Run Text

A program starts life as text in a file. Text does nothing on its own. To make it run, one of two things happens: a compiler translates the whole file into machine instructions ahead of time, or an interpreter reads the text and carries out each instruction on the fly, every time you run it.

The compiler: translate once, run the translation

A compiler reads your entire source file, checks it, and produces a second file full of low-level instructions. You then ship and run that second file. The original text stays on your machine. Languages like Go, C, and Rust work this way, and Java compiles to an intermediate form called bytecode that a virtual machine runs.

It is like translating a novel into another language once, then printing thousands of copies of the translation. The translation work happens one time, up front, and readers never see the original manuscript.

The interpreter: read and perform, live

An interpreter is a program that runs your program. It reads your source text, works out what each statement means, and does it, statement by statement, every time. Lua, Python, JavaScript, PHP, and Ruby all run this way in their most common setups. It is flexible and fast to iterate on, and it has one enormous consequence for code protection.

Interpreted languages ship the source. If your product is a Lua script, a Python tool, or a JavaScript file, your customers receive the exact readable text you wrote. Every buyer is holding your source code. That single fact is why code obfuscation exists as an industry.

The line between the two camps is blurrier than the labels suggest. Most serious interpreters first compile your source to an internal bytecode and then interpret that, which is faster than re-reading text. Just-in-time compilers go further and translate hot bytecode into real machine code while the program runs. LuaJIT and every modern JavaScript engine do this. The protection story does not change though: whatever happens inside the engine, what you distributed was the readable text.

Compiled binaries are not safe from reading either, they are just harder to read. A binary can be disassembled and decompiled back into approximate source, which is why obfuscation exists for compiled targets too. The difference is the starting altitude: an attacker with your Lua file starts from your actual names and structure, while an attacker with a stripped binary starts from machine code. Level 5 covers both.

Why this split matters in this academy

• Interpreted code ships readable, so protecting it means transforming the text itself. That is Levels 3 and 5.
• The interpreter idea, a program that runs a program, is exactly how bytecode virtualization protects code in Level 7. You will build up to a machine within a machine.
• The compile step, turning text into a lower-level form, is the pipeline you will watch happen live in Level 3.

Summary: a compiler translates once and ships the translation, an interpreter performs your text live, which means interpreted products ship their readable source. Neither path makes code unreadable on its own. The split only sets the starting altitude for whoever decides to read what you shipped.

Frequently asked questions