DEV Community: I Want To Learn Programming

Code Challenge of the Day — First occurrence (leftmost) (medium)

I Want To Learn Programming — Mon, 29 Jun 2026 14:00:05 +0000

Picks up where Binary search left off.

You wrote binary search. Extend it: with duplicates, return the leftmost index of target, or -1.
Write first_occurrence(nums, target).

Starter:

def first_occurrence(nums, target):
    # TODO
    pass

Solve it interactively in your browser (no setup), check your answer instantly, and keep your daily streak going on IWTLP: https://iwtlp.com/challenge

Build your own search engine, inverted index and TF-IDF

I Want To Learn Programming — Mon, 29 Jun 2026 14:00:03 +0000

Type into a search box, get back the most relevant documents, instantly, out of millions. It feels like something only Google can do. But the engine behind ordinary full-text search, the thing inside Elasticsearch, Lucene, and your site's search bar, rests on two ideas you can build in about 30 lines: an inverted index to find matching documents fast, and TF-IDF to rank them by relevance.

The one idea: flip the data around

The naive way to search is to scan every document for the query word. That's O(documents × length), hopeless at scale. The fix is to build the index backwards.

A normal index maps document → its words. An inverted index maps the other way: word → the documents that contain it (and how often). Now "find documents containing python" is a single dictionary lookup instead of a scan. Flipping the mapping is the entire reason search is fast.

from collections import defaultdict

def tokenize(text):
    return text.lower().split()        # real engines also strip punctuation, stem, etc.

def build_index(docs):
    index = defaultdict(dict)          # term -> {doc_id: term_frequency}
    for doc_id, text in enumerate(docs):
        for term in tokenize(text):
            index[term][doc_id] = index[term].get(doc_id, 0) + 1
    return index

docs = [
    "python is a great language for data",
    "search engines rank documents by relevance",
    "python powers data science and search",
]
index = build_index(docs)
print(index["python"])     # {0: 1, 2: 1}  -> docs 0 and 2, once each
print(index["search"])     # {1: 1, 2: 1}

One lookup gives you every document containing a term, plus the term frequency, which we'll need for ranking.

The second idea: rank by relevance with TF-IDF

Matching isn't enough, you need the best matches first. TF-IDF scores how important a term is to a document with two intuitions:

TF (term frequency): a document that uses the query word more is more about it. More mentions, higher score.
IDF (inverse document frequency): a word that appears in every document (like "the") tells you nothing, so it should count for little. A rare word that appears in few documents is highly discriminating, so it should count for a lot. IDF is log(total_docs / docs_containing_term), big for rare words, near zero for ubiquitous ones.

Multiply them: a term scores high in a document when it appears often there but rarely overall. That's the insight that makes results feel relevant, it automatically downweights common filler and rewards distinctive matches.

import math

def search(query, index, n_docs):
    scores = defaultdict(float)
    for term in tokenize(query):
        if term not in index:
            continue
        df  = len(index[term])              # how many docs contain the term
        idf = math.log(n_docs / df)         # rare terms -> larger idf
        for doc_id, tf in index[term].items():
            scores[doc_id] += tf * idf      # accumulate TF-IDF across query terms
    return sorted(scores.items(), key=lambda kv: kv[1], reverse=True)

print(search("python data", index, len(docs)))
# docs 0 and 2 rank top: they match both query terms

Two details that matter:

We only score documents in the index for the query terms. Thanks to the inverted index, we never touch documents that don't match. The cost scales with how many docs contain your words, not your whole corpus, the reason this is fast.
Scores accumulate across query terms. A document matching both "python" and "data" outranks one matching only one of them. Multi-word relevance falls right out of the sum.

From this to a real engine

This 30-line core is genuinely how production search starts. The rest is refinement, not new ideas:

Better tokenization: lowercasing, removing punctuation, stemming ("running" → "run") so variants match, dropping stop words.
Better ranking: BM25, a tuned evolution of TF-IDF that handles document length and term saturation, this is what Elasticsearch/Lucene actually use by default.
Phrase and boolean queries, using the positions of terms (store position lists in the index, not just counts).
Scale: sharding the index across machines, the inverted-index structure is what makes that distribution possible.

Every one of those sits on top of "word → documents" plus "score by TF-IDF." Even modern semantic search with vectors is usually combined with this keyword index, not a replacement for it.

Why this is worth building

Search is one of those capabilities that looks like deep infrastructure and turns out to be two clean ideas: invert the mapping so lookups are instant, and score by TF-IDF so the best matches rise. Build it once and Elasticsearch stops being a black box, it's this, hardened and distributed.

Taking it further, BM25, positional queries, stemming, and the bridge to embeddings, is exactly the path the NLP track follows, building the search engine instead of configuring one.

Code Challenge of the Day — Palindrome, ignoring case and noise (medium)

I Want To Learn Programming — Sun, 28 Jun 2026 14:00:09 +0000

Picks up where Palindrome check left off.

You checked simple palindromes. Now ignore case and any non-alphanumeric characters, then check.
Write is_clean_palindrome(s).

Starter:

def is_clean_palindrome(s):
    # TODO
    pass

Solve it interactively in your browser (no setup), check your answer instantly, and keep your daily streak going on IWTLP: https://iwtlp.com/challenge

Simpson's paradox, and a detector for it in 20 lines

I Want To Learn Programming — Sun, 28 Jun 2026 14:00:04 +0000

Here is a dataset that lies. Sixty-six people, each with two numbers: hours of exercise per week, and blood cholesterol. Fit a single straight line to all of them and the slope is positive: more exercise, more cholesterol. That is absurd, and it is also what the data says, until you split the points by age. Within every age band the slope is negative, the sane direction. Same points, opposite conclusion, depending only on whether you looked at the whole or the parts.

This is Simpson's paradox, and it is not a curiosity. In 1973 it nearly turned into a lawsuit.

The slope is two sums

You do not need a stats library to see this happen. The slope of a least-squares line is the covariance of x and y divided by the variance of x, and both are just sums:

def slope(xs, ys):
    mx, my = sum(xs) / len(xs), sum(ys) / len(ys)
    cov = sum((x - mx) * (y - my) for x, y in zip(xs, ys))
    var = sum((x - mx) ** 2 for x in xs)
    return cov / var

Run it on everyone pooled together and you get +12. Run it on each age band and every one comes back negative. Nothing is wrong with the math; the same function gives both answers.

Why pooling flips the sign

The reason is a clean identity. Total covariance decomposes into a within-group part and a between-group part:

cov_total = (average within-group covariance) + (covariance of the group means)

The within-group term is the honest signal: inside a fixed age, more exercise tracks with less cholesterol, so it is negative. The between-group term measures where the groups sit. Older people exercise more, because retirement, and older people also have higher cholesterol, so the group centroids climb to the right and upward together. That between-group covariance is large and positive, and when you pool, it swamps the within-group signal. The pooled line is mostly tracing the path through the group centroids, not the slope inside any group.

Age is doing two jobs at once: it moves a point along the x-axis and along the y-axis. That is the definition of a confounder, a variable tied to both axes, and a confounder is exactly what it takes to reverse a trend.

A detector in twenty lines

If the danger is that the pooled trend disagrees with every group, you can just check for it:

def reverses(rows, group_of):
    xs = [r[0] for r in rows]
    ys = [r[1] for r in rows]
    pooled = slope(xs, ys)

    groups = {}
    for r in rows:
        groups.setdefault(group_of(r), []).append(r)

    parts = []
    for g, members in groups.items():
        if len(members) < 3:
            continue
        gx = [m[0] for m in members]
        gy = [m[1] for m in members]
        parts.append(slope(gx, gy))

    flipped = all((p > 0) != (pooled > 0) for p in parts)
    return flipped, pooled, parts

Feed it the exercise data grouped by age and it returns True, with pooled = +12 and three negative group slopes. Before trusting any pooled trend, run this against your plausible confounders: age, region, device, customer tier, time period. If it fires, the aggregate is hiding something.

The same trap in rates

It is not only about regression lines. In 1973 the University of California, Berkeley looked like it was rejecting women from graduate school: across the university, men were admitted at about 44 percent and women at about 30. It looked like clear bias. But split the applicants by department and women were admitted at an equal or higher rate in four of the six largest departments. Women were applying in larger numbers to the more competitive departments, the ones with low admit rates for everyone. Department was the confounder, moving both who applied and the admit rate. The aggregate reversed the truth. Same paradox, counted in percentages instead of slopes.

Why the detector is a smoke alarm, not a verdict

Here is the part most write-ups skip, and the part that matters most. The detector tells you that a reversal exists. It does not tell you which view is correct. That is a causal question, not a statistical one, and the honest answer depends on what the grouping variable actually is.

If the group is a genuine confounder that sits upstream of both variables, like age here, then the within-group slopes are the truth and the pooled slope is the artifact. But if you split on the wrong variable you make things worse. Condition on a collider, a variable that both x and y cause, and you can manufacture a paradox out of unrelated quantities. Condition on something that sits downstream of the treatment, a mediator, and you erase the very effect you were trying to measure. The math of reverses() cannot tell these cases apart; they all look like a sign flip.

So the rule is not "always trust the groups." It is "a reversal means stop and draw the causal arrows." The detector is the smoke alarm. The causal diagram is the investigation. If you want the formal version of all this, look up the d-separation rules for causal graphs; Simpson's paradox is what they were built to resolve.

The toy is worth building anyway, because once you have watched the same slope() function return +12 and a row of negatives on the same data, you stop trusting any single aggregate on sight. That instinct is most of what good data analysis is.

Code Challenge of the Day — Count two-sum pairs (medium)

I Want To Learn Programming — Sat, 27 Jun 2026 14:00:09 +0000

Picks up where Two-sum indices left off.

Same setup as two-sum, but count how many index pairs (i<j) sum to target.
Write count_pairs(nums, target).

Starter:

def count_pairs(nums, target):
    # TODO
    pass

Solve it interactively in your browser (no setup), check your answer instantly, and keep your daily streak going on IWTLP: https://iwtlp.com/challenge

Rust's rewrite wave, why C is being replaced in the places that matter

I Want To Learn Programming — Sat, 27 Jun 2026 14:00:06 +0000

In 2026 the Rust rewrite wave reached the load-bearing parts of computing: the Linux kernel ships Rust drivers, browsers and databases have Rust cores, and Rust runs in production infrastructure at Microsoft, Google, Amazon, and Cloudflare. Rust also tops developer surveys with an ~82% admiration rating, the most-loved language for years running. That combination, beloved and being put in the most critical code, is unusual and worth understanding.

The motivation is not fashion. It is one specific, measurable problem.

The one idea: most critical-software bugs are memory bugs

For decades the systems world ran on C and C++: fast, close to the metal, and trusting the programmer to manage memory by hand. The trouble is that humans are bad at it. Use-after-free, buffer overflows, dangling pointers, data races, these memory-safety bugs are not exotic. Studies from Microsoft and Google repeatedly found that roughly 70% of serious security vulnerabilities in large C/C++ codebases are memory-safety issues.

That is the number driving the rewrite. If you could eliminate that category of bug, you'd remove most of your security vulnerabilities at a stroke. Rust's entire reason to exist is to make those bugs impossible to compile.

How Rust gets safety without a garbage collector

The usual way to get memory safety is a garbage collector (Java, Go, Python): a runtime that tracks and frees memory for you. But a GC adds overhead and unpredictable pauses, unacceptable in a kernel or a high-frequency trading path. That's why those domains stuck with C.

Rust's breakthrough is getting memory safety at compile time, with no runtime cost. Its borrow checker enforces ownership rules, one owner per value, and "shared XOR mutable" references, that make use-after-free and data races compile errors. The checks happen during compilation and then vanish; the running program is as lean as C. You get C's performance and the safety of a managed language, without choosing between them. That "no GC, no memory bugs" combination is exactly what the critical-infrastructure crowd was waiting for.

Why now, and not five years ago

Rust has been safe for a decade, so why the 2026 wave? Three things matured at once:

The ecosystem hit critical mass. Production-grade libraries, Tokio (async), Axum (web), SQLx (databases), mean you can build real systems without reinventing everything.
The tooling and ergonomics improved. Compile times for incremental builds dropped dramatically (from ~35s to ~8s on medium projects between 2024 and 2026), and the error messages became genuinely teacherly. The language got approachable, which is what the admiration rating reflects.
Policy pressure. Government and industry security guidance began explicitly recommending memory-safe languages for new critical software. The 70% number became a mandate, not just a statistic.

What the rewrite wave is not

Worth being honest, because the hype overshoots:

It is not "rewrite everything in Rust." The migration targets new components and the highest-risk existing ones (parsers, network-facing code, kernel drivers). Vast amounts of working C will run for decades. A rewrite is expensive and risky; you do it where the safety payoff is largest.
Rust is not always the right tool. For a quick script, Python wins. For a simple network service where a GC pause is fine, Go's simplicity often wins. Rust's borrow checker is a real cost you pay for a real guarantee; it's worth it when the guarantee matters and overkill when it doesn't.
Safe Rust isn't all Rust. unsafe blocks exist for the cases that need manual control (hardware, FFI), and bugs can still live there. The win is shrinking the unsafe surface to a small, auditable fraction.

Why this matters even if you never write Rust

The rewrite wave is a signal about where the industry's pain actually is: not in writing code, but in writing correct code that doesn't corrupt memory or ship vulnerabilities. Rust is the current best answer, but the underlying lesson is bigger, that moving the discovery of whole bug classes from runtime to compile time is enormously valuable, which is the same reason typed languages keep gaining ground.

Understanding why Rust is winning, the 70% number, the no-GC safety, the compile-time guarantee, tells you more than any syntax tutorial. And the only way to really feel it is to write Rust until the borrow checker stops fighting you and starts feeling like a safety net. That's the Rust track, built ownership-first because that's the idea everything else hangs on.

Sources

Code Challenge of the Day — Clamp a value (easy)

I Want To Learn Programming — Fri, 26 Jun 2026 14:00:06 +0000

Return x limited to the range [lo, hi].
Write clamp(x, lo, hi).

Starter:

def clamp(x, lo, hi):
    # TODO
    pass

Solve it interactively in your browser (no setup), check your answer instantly, and keep your daily streak going on IWTLP: https://iwtlp.com/challenge

Gradient descent, explained by rolling downhill

I Want To Learn Programming — Fri, 26 Jun 2026 14:00:03 +0000

Behind every trained model, the attention layers, the giant language models, the small on-device ones, is a single training algorithm: gradient descent. It sounds like calculus you'd rather forget, but the idea is a ball rolling downhill, and the code is about three lines. Build it once and "training a model" stops being mysterious.

The one idea: follow the slope downhill

Suppose you have a function that measures how wrong your model is, the loss. Training means finding the inputs that make the loss as small as possible: the bottom of the valley. You can't see the whole landscape, but at any point you can feel the slope under your feet. So you take a small step in the downhill direction, and repeat. Roll downhill, step by step, until you reach the bottom.

The slope is the gradient (the derivative): it points in the direction the function increases fastest. So to go down, you step in the opposite direction of the gradient. That's the whole algorithm.

Minimize a parabola

Take f(x) = (x - 3)². Its lowest point is obviously at x = 3. Its slope is f'(x) = 2(x - 3). Gradient descent finds the minimum without knowing the answer in advance:

def gradient_descent(grad, x, lr=0.1, steps=50):
    for _ in range(steps):
        x = x - lr * grad(x)     # step opposite the slope
    return x

print(gradient_descent(lambda x: 2 * (x - 3), x=0.0))   # -> ~3.0

Start at 0, and each step nudges x toward 3, the bottom of the bowl. That single line, x = x - lr * grad(x), is gradient descent. Everything else in machine learning is computing grad for more complicated functions.

Two details that matter:

The learning rate lr is your step size. Too small and it crawls; too large and it overshoots the bottom and can bounce out to infinity. Tuning it is most of the practical art.
You step against the gradient. The minus sign is the whole point. Flip it and you'd climb the hill, maximizing the loss, which is exactly backwards.

Fit a line to data

Now the real thing. Given points, find the line y = mx + b that best fits them. "Best" means smallest mean squared error. The loss is mean((mx + b − y)²), and its gradients with respect to m and b are standard:

def fit_line(xs, ys, lr=0.01, steps=2000):
    m, b, n = 0.0, 0.0, len(xs)
    for _ in range(steps):
        errs = [(m * x + b) - y for x, y in zip(xs, ys)]   # prediction minus truth
        dm = (2 / n) * sum(e * x for e, x in zip(errs, xs))  # slope wrt m
        db = (2 / n) * sum(errs)                              # slope wrt b
        m -= lr * dm
        b -= lr * db
    return m, b

xs = [1, 2, 3, 4, 5]
ys = [2, 4, 6, 8, 10]          # perfectly y = 2x
print(fit_line(xs, ys))        # -> (~2.0, ~0.0)

No formula for the answer, no library. We started with a flat line (m=0, b=0), measured how wrong it was, and rolled downhill in m and b until it matched. That is linear regression, trained, and it is the same loop that trains a neural network, just with millions of parameters instead of two.

From two parameters to a billion

A neural network is the exact same idea at scale:

The model has millions or billions of parameters instead of m and b.
The loss measures how wrong its predictions are.
Backpropagation is just an efficient way to compute the gradient of the loss with respect to every parameter at once (we build it from scratch in backpropagation explained by coding it).
Then the same update runs: param -= lr * grad, for every parameter, over and over.

That's it. "Training GPT" and "fitting a line" are the same algorithm; only the number of parameters and the way you compute the gradient differ.

Why this is worth building

Gradient descent is the one algorithm that connects a textbook parabola to the largest models on Earth. Once you've watched x = x - lr * grad(x) walk to the bottom of a bowl, the whole field reorganizes around it: a model is a function with parameters, a loss says how wrong it is, and training is rolling those parameters downhill. The learning rate, overfitting, why training "diverges", all of it makes sense from this picture.

If you want to build outward from here, backprop, real networks, the optimizers that improve on plain descent, that path is the AI track, where you train the thing from the gradient up instead of importing .fit().

Code Challenge of the Day — Letter grade (easy)

I Want To Learn Programming — Thu, 25 Jun 2026 14:00:06 +0000

Return 'A' for >=90, 'B' for >=80, 'C' for >=70, 'D' for >=60, else 'F'.
Write grade(score).

Starter:

def grade(score):
    # TODO
    pass

Solve it interactively in your browser (no setup), check your answer instantly, and keep your daily streak going on IWTLP: https://iwtlp.com/challenge

Build your own shell, and learn how every program gets started

I Want To Learn Programming — Thu, 25 Jun 2026 14:00:03 +0000

You type ls, press enter, and a program runs. The shell that made that happen feels like deep operating-system magic. It isn't. A real, working shell, one that can run any program on your system, is about 30 lines of C, and writing it teaches you the single most important pattern in operating systems: how one program starts another.

That pattern is three system calls: fork, exec, and wait. Every program you have ever launched, from your editor to your browser, was started this way.

The one idea: fork then exec

To run a program, a Unix shell does something that sounds strange the first time: it clones itself, and then the clone replaces itself with the program you asked for.

fork() creates a near-identical copy of the current process (the child). Now there are two processes running the same code.
exec() replaces the calling process's memory with a new program. The child stops being a copy of the shell and becomes ls.
wait() lets the parent (the shell) pause until the child finishes, so it can prompt you again.

Clone, transform, wait. That separation, fork to make a process, exec to choose what it runs, is the deepest idea in how operating systems launch programs.

The loop

A shell is a read-eval-print loop: read a line, run it, repeat.

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <sys/wait.h>

int main(void) {
    char line[1024];
    while (1) {
        printf("> ");
        if (!fgets(line, sizeof line, stdin)) break;   // Ctrl-D / EOF: exit
        line[strcspn(line, "\n")] = '\0';              // strip the newline
        if (line[0] == '\0') continue;                 // empty line

        // split the line into words: args[0]=command, rest=arguments
        char *args[64];
        int n = 0;
        for (char *tok = strtok(line, " "); tok && n < 63; tok = strtok(NULL, " "))
            args[n++] = tok;
        args[n] = NULL;                                // execvp needs a NULL terminator

        if (strcmp(args[0], "exit") == 0) break;       // a builtin, handled by the shell itself

        run(args);
    }
    return 0;
}

Two details that matter already:

args must end in NULL. execvp reads the argument list until it hits a NULL pointer. Forget it and you get garbage or a crash.
exit is a builtin. It can't be a separate program, because a child process exiting wouldn't end the shell. Builtins are commands the shell must run itself, the same reason cd has to be a builtin (a child can't change the parent's directory).

The heart: fork, exec, wait

void run(char **args) {
    pid_t pid = fork();                 // clone this process

    if (pid == 0) {
        // --- child: become the requested program ---
        execvp(args[0], args);          // replaces this process; searches PATH for args[0]
        perror("exec");                 // only runs if exec FAILED (e.g. command not found)
        _exit(127);
    } else if (pid > 0) {
        // --- parent (the shell): wait for the child to finish ---
        waitpid(pid, NULL, 0);
    } else {
        perror("fork");                 // fork itself failed
    }
}

This is the whole engine. Compile it (cc shell.c -o myshell), run ./myshell, and you have a prompt that executes ls, echo hello, cat file.txt, any program on your PATH.

Three details that matter, and they are the entire concept:

fork() returns twice. Once in the parent (returning the child's PID, a positive number) and once in the child (returning 0). That single return value is how each process knows which one it is. This is the line that surprises everyone the first time.
The code after execvp only runs on failure. A successful exec replaces the process, so there is no "after." Reaching perror("exec") means the command wasn't found, which is exactly how your real shell prints "command not found."
execvp searches PATH for you (the p) and takes a vector of arguments (the v). That is why you can type ls instead of /bin/ls.

What you just built, and where it goes

You have a real shell. The features you use every day are extensions of this core:

Pipes (ls | grep x): create a pipe(), fork two children, wire one's stdout to the other's stdin with dup2.
Redirection (> file): before exec, open the file and dup2 it onto stdout.
Background jobs (&): just don't wait for the child.
Signals (Ctrl-C): handle SIGINT so it interrupts the child, not the shell.

Every one of those is a small addition around the same fork/exec/wait skeleton. The terminal stops being magic once you've written the loop that launches a process, because that loop is, quite literally, how your operating system runs everything.

If you want to build the rest, pipes, job control, signals, a real mini-shell, that is one of the projects in the operating systems track, where you build the internals instead of just using them.

Code Challenge of the Day — Decode ways (hard)

I Want To Learn Programming — Wed, 24 Jun 2026 14:00:07 +0000

A digit string maps to letters (1-26). Return the number of ways to decode it.
Write decode_ways(s).

Starter:

def decode_ways(s):
    # TODO
    pass

Solve it interactively in your browser (no setup), check your answer instantly, and keep your daily streak going on IWTLP: https://iwtlp.com/challenge

Build your own bytecode VM, and see how languages really run

I Want To Learn Programming — Wed, 24 Jun 2026 14:00:04 +0000

When you run a Python file, Python does not execute your text. It first compiles it to bytecode, a compact list of simple instructions, and then runs that bytecode on a virtual machine. Java does the same (the JVM), so does C# (the CLR). "Virtual machine" sounds like a deep systems topic, but the core of a bytecode VM is almost embarrassingly small: a loop that reads instructions and pushes and pops a stack.

Build one and the phrase "compiles to bytecode" stops being mysterious. We will write a VM in about 30 lines, then a tiny compiler that turns an expression into bytecode for it to run.

The one idea: a stack machine

Most bytecode VMs are stack machines. There are no variables in the engine itself, just a stack and a handful of instructions that manipulate it:

PUSH x puts a value on the stack.
ADD pops the top two, pushes their sum.
MUL pops the top two, pushes their product.
PRINT shows the top of the stack.

To compute (2 + 3) * 4, you push 2, push 3, add (stack now has 5), push 4, multiply (stack now has 20). The expression became a flat list of stack operations. That flattening is the whole trick, and it is why bytecode is fast: each instruction is a tiny, fixed operation.

The VM: a loop over instructions

def run(program):
    stack = []
    for op, *arg in program:
        if op == "PUSH":
            stack.append(arg[0])
        elif op == "ADD":
            b = stack.pop(); a = stack.pop(); stack.append(a + b)
        elif op == "MUL":
            b = stack.pop(); a = stack.pop(); stack.append(a * b)
        elif op == "SUB":
            b = stack.pop(); a = stack.pop(); stack.append(a - b)
        elif op == "PRINT":
            print(stack[-1])
        else:
            raise ValueError(f"unknown op {op}")
    return stack

That is a working virtual machine. Run our example:

run([("PUSH", 2), ("PUSH", 3), ("ADD",), ("PUSH", 4), ("MUL",), ("PRINT",)])
# prints 20

Two details that matter:

Order matters for non-commutative ops. In SUB, we pop b then a and compute a - b, because a was pushed first and sits below b. Get this backward and 5 - 3 becomes -2. The stack's last-in-first-out order is the whole reason the compiler must emit operands before operators.
The VM is dumb on purpose. It has no idea what an expression is; it just executes tiny steps. All the cleverness lives in whatever produces the bytecode. That separation, smart compiler, simple VM, is exactly how real language runtimes are built.

The compiler: from a tree to bytecode

Nobody writes bytecode by hand. A compiler turns a parsed expression (an abstract syntax tree) into it. Represent the tree as nested tuples, and compile it with a post-order walk, children first, then the operator, which is precisely the push-operands-then-operate order the stack needs:

def compile_expr(node):
    if isinstance(node, (int, float)):
        return [("PUSH", node)]
    op, left, right = node                 # e.g. ("+", 2, ("*", 3, 4))
    code = compile_expr(left) + compile_expr(right)
    code.append({"+": ("ADD",), "-": ("SUB",), "*": ("MUL",)}[op])
    return code

tree = ("*", ("+", 2, 3), 4)              # (2 + 3) * 4
program = compile_expr(tree) + [("PRINT",)]
print(program)
# [('PUSH', 2), ('PUSH', 3), ('ADD',), ('PUSH', 4), ('MUL',), ('PRINT',)]
run(program)                              # 20

The recursion mirrors the tree, and because it emits children before their operator, the bytecode comes out in exactly the order the stack machine wants. This is the same shape as the JSON parser's recursion, one function walking a recursive structure, applied to code generation instead of parsing.

Why a VM at all?

Why not just walk the tree and evaluate it directly? Three reasons, and they are why real languages bother:

Speed. A flat array of simple instructions is far faster to execute repeatedly than re-walking a tree of objects. This is why CPython compiles to bytecode once and runs it many times.
Portability. Bytecode is the same regardless of CPU. Compile once, run the VM anywhere, which is Java's entire "write once, run anywhere" promise.
A clean seam. The compiler and the runtime are decoupled, so you can optimize the bytecode, or even JIT-compile it to machine code later, without touching the language's front end.

What you just built

A stack, a loop, and a recursive compiler is the heart of how Python, Java, and C# actually run. Add instructions and you grow a real language: LOAD/STORE for variables, JUMP/JUMP_IF_FALSE for control flow, CALL/RETURN for functions. Each is a few more lines in the same loop. The fearsome "virtual machine" is just this, scaled up.

If you want to take it all the way, from source text to tokens to a tree to bytecode to a running language, that is exactly the arc the compilers track walks, and it starts with a loop over a stack just like this one.