InkdownInkdown
Start writing

Study

59 files·8 subfolders

Shared Workspace

Study
core

programming-language-concepts

Shared from "Study" on Inkdown

Programming Language Concepts - Comprehensive Guide

Table of Contents

  1. Core Programming Concepts
  2. Compile Time vs Runtime
  3. Interpreters
  4. V8 Engine
  5. JIT Compilation
  6. Python vs JavaScript Engines
  7. Universal Engine Pipeline

Core Programming Concepts

Native Binaries vs Interpreted Languages
programming-language-concepts.md
zero-language-explanation.md
DB
01-introduction.md
02-relational-databases.md
03-database-design.md
04-indexing.md
05-transactions-acid.md
06-nosql-databases.md
07-query-optimization.md
08-replication-ha.md
09-sharding-partitioning.md
10-caching-strategies.md
11-cap-theorem.md
12-connection-pooling.md
13-backup-recovery.md
14-monitoring.md
15-database-selection.md
README.md
JS
Event loop
Merlin Backend
01-Orchestration.md
02-DeepResearch.md
03-Search.md
04-Scraping.md
05-Streaming.md
06-MultiProviderLLM.md
07-MemoryAndContext.md
08-ErrorHandling.md
09-RateLimiting.md
10-TaskQueue.md
11-SecurityAndAuth.md
Orchestration-2nd-draft
OpenAI Agents Python
00_OVERVIEW.md
01_AGENT_SYSTEM.md
02_RUNNER_SYSTEM.md
03_TOOL_SYSTEM.md
04_ITEMS_SYSTEM.md
05_GUARDRAILS.md
06_HANDOFFS.md
07_MEMORY_SESSIONS.md
08_MODEL_PROVIDERS.md
09_SANDBOX_SYSTEM.md
10_TRACING.md
11_RUN_STATE.md
12_CONTEXT.md
13_LIFECYCLE_HOOKS.md
14_CONFIGURATION.md
15_ERROR_HANDLING.md
16_STREAMING.md
17_EXTENSIONS.md
18_MCP_INTEGRATION.md
19_BEST_PRACTICES.md
20_ARCHITECTURE_PATTERNS.md
opencode-study
context-handling
core
Python
Alembic
Basics
sqlalchemy - fastapi
SQLAlchemy overview
tweets
system_design_for_agentic_apps.md

Think of programming languages as recipes for a computer:

Interpreted Languages (Python, JavaScript):

Python
# You write this:
print("Hello World")

# The computer needs an "interpreter" (like a translator)
# to read and execute line by line at runtime
  • Needs a runtime environment (Node.js, Python interpreter) installed
  • Slower execution (translation happens every time you run)
  • More portable (same code runs anywhere with the interpreter)

Compiled to Native Binaries (C, Rust, Go):

C
// You write this:
printf("Hello World");

// Compiler converts it to MACHINE CODE:
// 01001000 01100101 01101100 01101100 01101111
  • Runs directly on the CPU (no middleman needed)
  • Much faster execution
  • The binary is specific to your CPU type
Garbage Collection (GC)

What is it? Automatic memory cleanup. When you create variables, they use RAM. GC automatically frees that memory when no longer needed.

Python
# Python (has GC):
x = "hello world"  # Memory allocated
x = None           # Old string automatically cleaned up by GC

Languages WITH GC: Python, JavaScript, Java, Go Languages WITHOUT GC: C, C++, Rust

Why no GC?

  • GC causes random performance pauses (your program freezes briefly)
  • In systems programming (operating systems, game engines), you need predictable performance
  • Languages like Rust use "borrow checking" instead to manage memory safely without GC

Compile Time vs Runtime

Simple Explanation

Think of it like building a house vs living in it:

Compile Time = Blueprint → Built House

This happens before the program runs. The compiler checks your code, finds errors, and converts it into executable form.

Plain text
Your Code (.rs, .c, .go)
     ↓
[COMPILER does its work]          ← THIS IS COMPILE TIME
     ↓
Binary (.exe) — ready to run
Runtime = Actually Running the Program

This is when you execute the compiled binary. The program is doing its actual job.

Plain text
Double-click .exe → Program runs → Shows output
                         ↑
                    THIS IS RUNTIME
Simple Code Example
Python
# PYTHON (Interpreted - different flow)
x = 10
y = 0
result = x / y    # CRASH at RUNTIME
                  # No compile time for Python!
                  # Error happens when line executes
C
// C (Compiled)
int main() {
    int x = 10;
    int y = 0;
    int result = x / y;  // COMPILES fine (no syntax error)
                         // But CRASHES at RUNTIME (divide by zero!)
    return 0;
}
Rust
// RUST (Compiled with strict checks)
fn main() {
    let x = 10;
    let y = 0;
    let result = x / y;  // COMPILE ERROR!
                         // Rust warns: "this operation will panic at runtime"
                         // Error caught BEFORE running!
}
What Happens at Each Stage
Compile TimeRuntime
Check syntaxExecute instructions
Type checkingUser input
Memory analysisNetwork requests
Error code generationFile reading/writing
Optimize codeDatabase queries
Produce binaryCrash if bug exists
Real-World Analogy
StageCooking AnalogyProgramming
Compile TimeReading recipe, checking ingredients, prepping kitchenCompiler reads code, checks for errors, builds executable
RuntimeActually cooking and eatingProgram runs, interacts with user, does real work
Visual Timeline
Plain text
WRITE CODE                    RUN PROGRAM
   ↓                              ↓
[Check syntax]                 [User clicks app]
   ↓                              ↓
[Check types]                  [Read input]
   ↓                              ↓
[Optimize]                     [Calculate result]
   ↓                              ↓
[Build binary]                 [Show output]
   ↓                              ↓
✅ Compile Time Done        ❌ Crash if bug
The 3 Distinct Phases
Plain text
┌──────────────┐     ┌──────────────┐     ┌──────────────┐
│ 1. EDITING   │ ──▶ │ 2. COMPILE   │ ──▶ │ 3. RUNTIME   │
│              │     │              │     │              │
│ You write    │     │ You run      │     │ You execute  │
│ code in IDE  │     │ compiler     │     │ the binary   │
│              │     │ explicitly   │     │              │
└──────────────┘     └──────────────┘     └──────────────┘
   (Just typing)       (Build step)         (Program runs)
Where the Confusion Comes From

Modern IDEs blur the line:

What You SeeWhat's Actually Happening
Red squiggly lines while typingIDE secretly runs compiler in background
"Problems" panel auto-updatingLanguage server doing mini-compile checks
Auto-complete suggestionsIDE parsing your code continuously

This feels like "real-time compilation," but it's just your IDE being helpful. The actual compile time is still the explicit build step.

Quick Test to Tell the Difference

Ask yourself: Does the compiler produce a runnable program?

ScenarioPhase
Typing code, seeing red underlinesEditing (+ IDE background checks)
Running cargo build, getting errorsCompile time
Double-clicking .exe, program crashesRuntime
Simple Analogy
PhaseEssay Writing Analogy
EditingWriting the essay in Word
Compile timeGrammar/spell check + printing to PDF
RuntimeSomeone actually reads the printed essay

So: writing ≠ compiling. Compile time is the deliberate step where your code gets turned into an executable.

Interpreters

What Interpreters Do

An interpreter is a program that executes your code line-by-line without compiling it first.

How It Works
Plain text
Your Source Code
      ↓
┌─────────────┐
│ INTERPRETER │  ← Reads one line, executes it, then moves to next
└─────────────┘
      ↓
   Output
Example: Python Interpreter
Python
# hello.py
print("Hello")
x = 10
print(x)

When you run:

Bash
$ python hello.py

The Python interpreter:

  1. Reads print("Hello") → executes it → prints "Hello"
  2. Reads x = 10 → executes it → stores 10 in memory
  3. Reads print(x) → executes it → prints "10"

All happens at runtime, no compilation step.

Interpreter vs Compiler
AspectInterpreter (Python, JS)Compiler (C, Rust)
ProcessRead & execute line-by-lineCompile once, then run binary
SpeedSlower (translation every run)Faster (no translation at runtime)
OutputNo binary fileProduces .exe / binary
Error detectionRuntime onlyCompile time (mostly)
DistributionNeed interpreter installedJust need the binary
What Environment Do Interpreters Work In?

Interpreters run on your machine as a program itself:

Plain text
Your Computer
    ├─ Operating System (macOS/Windows/Linux)
    │    └─ Python Interpreter (you installed this)
    │         └─ Your Python script runs INSIDE this
    │
    └─ Node.js Interpreter (you installed this)
         └─ Your JavaScript runs INSIDE this
Installation Required

Before running interpreted code, you must install the interpreter:

Bash
# Install Python interpreter
$ brew install python

# Install Node.js interpreter
$ brew install node

# Now you can run scripts
$ python script.py
$ node script.js
Visual: Where Interpreters Live
Plain text
┌─────────────────────────────────────────────────┐
│                YOUR COMPUTER                    │
├─────────────────────────────────────────────────┤
│  Operating System (macOS)                      │
│  ├─ Applications                               │
│  │  ├─ Python 3.11 (INTERPRETER)               │
│  │  │  └─ Reads & runs .py files               │
│  │  │                                          │
│  │  └─ Node.js 20 (INTERPRETER)                │
│  │     └─ Reads & runs .js files               │
│  │                                             │
│  └─ Compiled Programs                          │
│     ├─ Safari (compiled binary)                │
│     └─ VS Code (compiled binary)               │
└─────────────────────────────────────────────────┘
Real-World Example

JavaScript in Browser:

Plain text
Your Browser has a JS Interpreter (V8 for Chrome, SpiderMonkey for Firefox)

When you visit a website:
1. Browser downloads .js file
2. Built-in interpreter reads it
3. Executes line-by-line
4. Website becomes interactive

No compilation needed - browser has interpreter built-in
Summary

Interpreter = A program that runs your other programs

  • Works on your computer (you install it like any app)
  • Reads your code, executes it immediately
  • No compilation step
  • Examples: Python interpreter, Node.js, browser JS engines
  • Environment: Runs inside the interpreter you installed

V8 Engine

What V8 Does

V8 is Google's JavaScript engine. It's the interpreter + JIT compiler that runs JavaScript in Chrome and Node.js.

What V8 Actually Does
Plain text
Your JavaScript Code
        ↓
┌─────────────────┐
│     V8 ENGINE   │
├─────────────────┤
│ 1. Parser       │  → Reads your JS code
│ 2. Interpreter  │  → Executes it line-by-line (slow)
│ 3. JIT Compiler │  → Compiles hot code to machine code (fast)
│ 4. Garbage      │  → Cleans up unused memory
│    Collector    │
└─────────────────┘
        ↓
   Executed Code
Why V8 is Special (Not Just a Simple Interpreter)

V8 is a hybrid — it's both interpreter AND compiler:

Phase 1: Interpreter (Ignition)

JavaScript
function add(a, b) {
    return a + b;
}

add(1, 2);  // V8 interprets this line-by-line
add(3, 4);  // Still interpreting

Phase 2: JIT Compiler (TurboFan)

JavaScript
add(1, 2);  // V8: "This function runs a lot!"
add(3, 4);  // V8: "I'll compile it to machine code for speed"

// Now add() runs as fast as C code!

JIT = Just-In-Time compilation. It compiles code while running based on usage patterns.

Where V8 Lives
Plain text
┌─────────────────────────────────────────────┐
│              CHROME BROWSER                 │
├─────────────────────────────────────────────┤
│  ┌───────────────────────────────────────┐  │
│  │  V8 Engine (built into Chrome)       │  │
│  │  ┌─────────────────────────────────┐  │  │
│  │  │ Your JavaScript runs here       │  │  │
│  │  │ (web pages, React, etc.)         │  │  │
│  │  └─────────────────────────────────┘  │  │
│  └───────────────────────────────────────┘  │
│                                             │
│  ┌───────────────────────────────────────┐  │
│  │  Blink (renders HTML/CSS)            │  │
│  └───────────────────────────────────────┘  │
└─────────────────────────────────────────────┘
Plain text
┌─────────────────────────────────────────────┐
│             NODE.JS (Server)                 │
├─────────────────────────────────────────────┤
│  ┌───────────────────────────────────────┐  │
│  │  V8 Engine (built into Node.js)      │  │
│  │  ┌─────────────────────────────────┐  │  │
│  │  │ Your JavaScript runs here       │  │  │
│  │  │ (Express, server code, etc.)     │  │  │
│  │  └─────────────────────────────────┘  │
│  └───────────────────────────────────────┘  │
│                                             │
│  ┌───────────────────────────────────────┐  │
│  │  libuv (handles I/O, filesystem)     │  │
│  └───────────────────────────────────────┘  │
└─────────────────────────────────────────────┘
V8 vs Simple Interpreter
FeatureSimple InterpreterV8 Engine
Executes JSYesYes
Compiles to machine codeNoYes (JIT)
Fast executionNoYes (after JIT)
Garbage collectionYesYes
OptimizationsNoYes (inline, etc.)
Why JavaScript is Fast Today

Old days (2008): JavaScript was slow (pure interpretation)

Today (V8): JavaScript is almost as fast as compiled languages because:

  1. Interprets cold code (fast startup)
  2. Compiles hot code to machine code (JIT)
  3. Optimizes based on runtime behavior
  4. Deoptimizes if assumptions break
Summary

V8 = JavaScript engine that:

  • Lives in Chrome browser and Node.js
  • Interprets your JavaScript code
  • Compiles frequently-used code to machine code (JIT)
  • Manages memory with garbage collection
  • Makes JavaScript fast enough for real applications

Without V8, JavaScript would be slow like old Python. With V8, it's fast enough to run Gmail, Facebook, and VS Code.

JIT Compilation

What JIT Does

JIT (Just-In-Time) compilation turns the most repeated code into binary machine code while the program is running.

Simple Explanation

JIT (Just-In-Time) = Compiles frequently-used code to machine code while the program is running

Example:

JavaScript
function calculate() {
    return Math.sqrt(100 * 50);
}

// First few runs:
calculate();  // V8 interprets (slow)
calculate();  // V8 interprets (slow)
calculate();  // V8 interprets (slow)
calculate();  // V8: "This is hot code!" → Compiles to machine code

// Now it's compiled:
calculate();  // Runs as fast as C (machine code)
calculate();  // Runs as fast as C

The key word is "repeated" — V8 watches which functions run often and optimizes those specifically. Code that runs once stays interpreted.

JIT vs Ahead-of-Time (AOT)
TypeWhen Compilation HappensExample
AOTBefore runningC, Rust, Go
JITWhile runningV8 (JavaScript)
BytecodeBefore running, to intermediatePython, Java
How JIT Works Step by Step
  1. Cold Code: First time a function runs, it's interpreted (slow)
  2. Hot Code: If function runs many times, JIT compiler kicks in
  3. Compilation: Function is compiled to machine code
  4. Optimized Execution: Future calls use the compiled version (fast)
  5. Deoptimization: If assumptions break, fall back to interpretation
Why JIT is Important
  • Fast startup: No waiting for full compilation before running
  • Progressive optimization: Only optimize code that actually runs
  • Adaptive: Can adjust based on runtime behavior
  • Memory efficient: Don't compile code that never runs

Python vs JavaScript Engines

Python (CPython) - What's Inside
Plain text
Your Python Code
        ↓
┌─────────────────┐
│  CPython Engine │
├─────────────────┤
│ 1. Lexer/Parser │  → Breaks code into tokens, builds AST
│ 2. Compiler     │  → Compiles to BYTECODE (.pyc files)
│ 3. Interpreter  │  → Executes bytecode on Python VM
│ 4. Garbage      │  → Reference counting GC
│    Collector    │
│ 5. Memory       │  → Object allocator
│    Manager      │
└─────────────────┘

Key difference from V8: Python compiles to bytecode (not machine code), then interprets that bytecode.

Python's Compilation Step
Python
# script.py
def add(a, b):
    return a + b

print(add(1, 2))

When you run python script.py:

  1. Parser reads the code, builds syntax tree
  2. Compiler converts to bytecode (simplified instructions)
  3. Saves bytecode to __pycache__/script.cpython-311.pyc
  4. Interpreter runs the bytecode on Python Virtual Machine

The bytecode looks like this:

Python
# Disassembly of script.py
  1           0 RESUME                   0

  2           2 LOAD_FAST                0 (a)
              4 LOAD_FAST                1 (b)
              6 BINARY_OP                0 (+)
             10 RETURN_VALUE
V8 vs Python - Component Comparison
ComponentV8 (JavaScript)Python (CPython)
ParserYesYes
CompilerYes (to machine code)Yes (to bytecode)
InterpreterYesYes
JIT CompilerYes (TurboFan)No
Garbage CollectorYesYes
Virtual MachineNo (direct CPU)Yes (Python VM)

Universal Engine Pipeline

The Universal Flow - All Language Engines Follow This
Plain text
┌─────────────────────────────────────────────────────────────────┐
│                  UNIVERSAL ENGINE PIPELINE                      │
└─────────────────────────────────────────────────────────────────┘

Source Code
    ↓
[LEXER / TOKENIZER]  → Breaks text into tokens
    ↓
[PARSER]             → Builds Abstract Syntax Tree (AST)
    ↓
[SEMANTIC ANALYSIS]  → Checks types, scope, rules
    ↓
[CODE GENERATION]    → Converts to executable form
    ↓
[EXECUTION]          → Runs the code
    ↓
[MEMORY MANAGEMENT]  → Cleans up
Step-by-Step Breakdown
1. Lexer / Tokenizer

Input: Raw text

Python
def add(a, b):
    return a + b

Output: Tokens

Python
[DEF, IDENTIFIER(add), LPAREN, IDENTIFIER(a), COMMA, IDENTIFIER(b), RPAREN, 
 COLON, RETURN, IDENTIFIER(a), PLUS, IDENTIFIER(b)]
2. Parser

Input: Tokens Output: Abstract Syntax Tree (AST)

Plain text
        FunctionDef
       /    |      \
     def   add    Body
                 /   \
          Return      BinaryOp
           |           /    \
         Identifier  Identifier  +
             a         a        b
3. Semantic Analysis

What it checks:

  • Are variables declared before use?
  • Are types compatible?
  • Are functions called with correct arguments?
  • Are scopes valid?
Python
x = 10
y = x + "hello"  # Error: Can't add int + string
4. Code Generation

This is where engines diverge:

EngineGeneratesThen Executes Via
CPythonBytecodePython VM
V8Machine code (for hot code)Direct CPU
RustMachine codeDirect CPU
JavaBytecodeJVM
GoMachine codeDirect CPU
5. Execution

Bytecode engines (Python, Java):

Plain text
Bytecode → Virtual Machine → CPU

Native engines (C, Rust, V8-compiled):

Plain text
Machine Code → CPU (direct)
6. Memory Management

Two approaches:

Automatic (GC):

  • Python: Reference counting
  • V8: Tracing GC
  • Java: Tracing GC

Manual:

  • C: malloc/free
  • C++: new/delete
  • Rust: Ownership system (compile-time)
The Complete Flow - Visual
Plain text
┌─────────────────────────────────────────────────────────────────┐
│                        YOUR CODE                                │
│                    def add(a, b): return a + b                   │
└─────────────────────────────────────────────────────────────────┘
                            ↓
┌─────────────────────────────────────────────────────────────────┐
│                      LEXER (Tokenizing)                         │
│              [def, add, (, a, ,, b, ), :, return, a, +, b]      │
└─────────────────────────────────────────────────────────────────┘
                            ↓
┌─────────────────────────────────────────────────────────────────┐
│                       PARSER (AST)                              │
│                    ┌─────────────┐                              │
│                    │ FunctionDef │                              │
│                    └─────────────┘                              │
└─────────────────────────────────────────────────────────────────┘
                            ↓
┌─────────────────────────────────────────────────────────────────┐
│                   SEMANTIC ANALYSIS                             │
│              ✓ Variables defined? ✓ Types match?                │
└─────────────────────────────────────────────────────────────────┘
                            ↓
┌─────────────────────────────────────────────────────────────────┐
│                     CODE GENERATION                             │
│              ↓↓↓ ENGINE DECISION POINT ↓↓↓                      │
│                                                             │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐        │
│  │  Bytecode    │  │ Machine Code │  │  Machine Code │        │
│  │  (Python)    │  │  (V8, Rust)  │  │  (C, Go)     │        │
│  └──────────────┘  └──────────────┘  └──────────────┘        │
└─────────────────────────────────────────────────────────────────┘
                            ↓
┌─────────────────────────────────────────────────────────────────┐
│                       EXECUTION                                 │
│              ↓↓↓ HOW IT RUNS ↓↓↓                               │
│                                                             │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐        │
│  │   VM → CPU   │  │  Direct CPU  │  │  Direct CPU  │        │
│  │  (Python)    │  │  (V8, Rust)  │  │  (C, Go)     │        │
│  └──────────────┘  └──────────────┘  └──────────────┘        │
└─────────────────────────────────────────────────────────────────┘
                            ↓
┌─────────────────────────────────────────────────────────────────┐
│                    MEMORY MANAGEMENT                            │
│              ↓↓↓ CLEANUP ↓↓↓                                   │
│                                                             │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐        │
│  │     GC       │  │     GC       │  │   Ownership  │        │
│  │  (Python)    │  │  (V8, JS)    │  │   (Rust)     │        │
│  └──────────────┘  └──────────────┘  └──────────────┘        │
└─────────────────────────────────────────────────────────────────┘
                            ↓
                      PROGRAM OUTPUT
The Root Difference

All engines follow the same flow. The only difference is:

Step 4 (Code Generation) + Step 5 (Execution) + Step 6 (Memory Management)

That's where each engine makes its design choice:

  • Bytecode vs Machine code
  • VM vs Direct CPU
  • GC vs Manual vs Ownership

Everything else (lexing, parsing, semantic analysis) is essentially the same across all languages.

Summary: Language Engines

Common Terminology
LanguageEngine NameWhat We Call It
PythonCPythonPython interpreter / Python engine
JavaScript (Chrome/Node)V8JavaScript engine
JavaScript (Safari)JavaScriptCoreJavaScript engine
JavaScript (Firefox)SpiderMonkeyJavaScript engine
JavaHotSpot JVMJava Virtual Machine
RubyCRubyRuby interpreter
GogcGo compiler

Note: The terms "engine," "interpreter," "runtime," and "VM" are sometimes used interchangeably, but they all mean the same thing: the software that makes your code run.

The Pattern

Every language needs one piece of software that:

  1. Reads your code
  2. Checks for errors
  3. Converts it to executable form
  4. Runs it
  5. Manages memory

That software is the engine/interpreter/runtime.

For Python → CPython For JavaScript (Chrome) → V8 For JavaScript (Safari) → JavaScriptCore For Java → JVM

Quick Reference

Compile Time vs Runtime
PhaseWhat HappensWhen
Compile TimeCode is checked, converted to executableWhen you run build command
RuntimeProgram actually executesWhen you run the binary
Compiled vs Interpreted
TypeProcessExample
CompiledSource → Compiler → Binary → CPUC, Rust, Go
InterpretedSource → Interpreter → CPUPython, JavaScript
Memory Management
ApproachLanguagePros/Cons
GCPython, JS, JavaAutomatic but pauses performance
ManualC, C++Fast but error-prone
OwnershipRustSafe and fast, compile-time checked
Engine Components
ComponentPurposePresent In
LexerBreaks code into tokensAll engines
ParserBuilds ASTAll engines
Semantic AnalysisType/scope checkingAll engines
Code GeneratorConverts to executable formAll engines
JIT CompilerOptimizes hot codeV8, some others
GCAutomatic memory cleanupPython, V8, Java
VMExecutes bytecodePython, Java

Final Notes

This guide covers the fundamental concepts of how programming languages work under the hood. Understanding these concepts will help you:

  • Choose the right language for your use case
  • Understand performance characteristics
  • Debug compilation and runtime issues
  • Appreciate the engineering behind language design

The key takeaway: All languages follow the same basic pipeline, but differ in their specific design choices at the code generation and execution stages. These choices determine the language's performance, safety, and ease of use.