Debugging as a discipline

Getting stuck on an unfamiliar bug is a common experience, even for seasoned engineers. Success in those moments often has less to do with what you know and more to do with how you probe the unknown. Mathematician George Polya's How to Solve It lays out a four-stage approach that maps well onto debugging: understand the problem, devise a plan, carry it out, and then look back at what worked. The first two stages in particular are where the hard exploratory work happens.

Understand the problem before you touch the code

It is tempting to call a program "broken" and start poking at it. That only leads to thrashing. Start by getting a precise, factual description of what is wrong, stripped of any assumptions about the cause:

Our audit program detected that users can double-withdraw cash from their accounts.

From that, you can drill down to the specific conditions under which the error occurs, what the affected data looks like, and what the code path is supposed to accomplish. Narrowing the failing behavior to a single function is a huge step forward:

The balance transfer function sometimes doesn't increase or decrease the account values correctly.

Isolate the preconditions and the boundaries of the failure. Find cases where the code works fine and where it doesn't. Ask what the function's inputs and outputs should be for the problematic arguments. If your code relies on mutable state — an atom, a ref, an agent — you must account for what those references hold at read and write time. That is a strong argument for keeping mutable state out of your design as much as possible, since each mutable variable multiplies the set of paths your program can take. Adding (prn x) statements to print the sequence of value changes can be surprisingly effective to see the problem in action:

Each balance is stored in a separate atom. When two transfers happen at the same time involving the same accounts, the new value of one or both atoms may not reflect the transfer correctly.

Look for the invariants that should hold across the entire system. A total balance that is supposed to be constant is a classic one. Find the specific step at which the invariant breaks; if it doesn't hold at every step, what should restore it?

Use diagrams. Visualizing the program's state—drawing the vector boxes, drawing the tree node by node—can move a problem from the abstract to the tangible. It might not crack the case, but writing down the state transitions gives your pattern-matching subconscious the raw material it needs while you rest.

Devise a plan grounded in your description

Once you have a the problem accurately described, the task becomes finding a viable route to a fix. Numerous moves can help:

  • Rotate your viewpoint. Represent the problem in a way your intuition can handle. Is it similar to a classic concurrency or transaction issue?
  • Prepare a verification method. A regression test that you can run on your isolated function gives you feedback loops while you experiment.
  • Solve a variant. If you can't solve the general case, can you make a guarantee that's weaker but still acceptable, or serialize the contentious part with a lock or a transaction log?
  • Audit your assumptions. Check whether a library or language feature actually guarantees what you expect for your input range. When debugging, question your application code first, then work downward through the stack layers.
  • Seek existing machinery. A library, database, or language feature may handle transaction semantics for you. Integrating it could be cheaper than owning the bug.
  • Search and ask. Search terms that combine the library name, the exception type, and the error message can lead you to relevant GitHub issues and mailing lists. If you do ask elsewhere, provide a minimal repro, sources and versions (java -version, project.clj), and the actual stacktrace. Public issue trackers like GitHub and Jira, community IRC channels (Libera.chat), and mailing lists all have their place; for conversational debugging, IRC offers the fastest turnaround, but be precise and paste the full description into a service like Gist rather than spamming the channel.

There is a special caveat about community help. Some people in these spaces face harassment or exclusion, and it's not your responsibility to endure that to get support. If an interaction makes you uncomfortable, feel free to leave. Sometimes the problem is cultural context, and a well-meaning individual may not realize the impact of their words — explaining your perspective can help. But if they are just hostile, you can report the behavior to a moderator or channel operator. Again, none of that is an obligation. Be kind, pay it forward when you can, but prioritize your own well-being if the situation turns toxic.

Some problems seem to vanish the moment you instrument them. They remain the most intractable and, sometimes, the most enlightening. Use the diagnostic steps to gather data only when you are ready to handle what the code path is really doing. Ultimately, the most reliable thing you can do is take the time to bring a shapeless frustration into sharp focus before reaching for a fix.

From Stacktrace to Fix

Once a bug is reproduced, the fix often still needs care. For anything beyond a one-line correction, build a quick, repeatable test case that runs in seconds and check your work against it as you iterate.

Persisting through a tricky problem means mixing focused experiments with deliberate planning. If you're not making progress, change tactics: save your current approach in a comment or with git stash and start fresh. Consider whether a different concurrency primitive or a rephrased data structure fits better. Review the documentation for the library in question, and read the source code of the functions you call—even a rough understanding of what happens beneath the surface can reveal why things behave unexpectedly.

Explaining the problem to someone else, even if they know nothing about the codebase, often surfaces blind spots in your own reasoning. And if nothing sticks, step away. A walk, a workout, or a night's sleep gives your unconscious mind room to work. Many developers find that re-examining the problem after real time away—not just a few minutes—yields the fresh insight needed.

Locking In the Fix

When the program finally works, resist the urge to move on immediately. A passing test doesn't guarantee the root cause is gone—just that the symptom didn't appear this time. Push harder: run a randomized test over a broader input space, or point it at a copy of the production workload before you deploy.

Take the time to understand why the new code works. Copying a fix from StackOverflow gets you through the day but won't prepare you for the next encounter with a similar problem. Ask whether the issue you hit is a symptom of a more general flaw, and whether the technique you used could be generalized or packaged into a reusable helper.

Document your understanding in the source code itself. Write a comment explaining what went wrong and how the change prevents it. Use the same description in your commit message so other developers can trace your reasoning later.

Reading Clojure Stacktraces

Clojure's stacktraces can be intimidating, but a systematic read pays off. Consider a small program that computes cake baking time and marks certain products as "done":

(ns scratch.debugging)

(defn bake
  "Bakes a cake for a certain amount of time, returning a cake with a new
  :tastiness level."
  [pie temp time]
  (assoc pie :tastiness
         (condp (* temp time) <
           400 :burned
           350 :perfect
           300 :soggy)))

Evaluating it in the REPL produces a terse error:

user=> (bake {:flavor :blackberry} 375 10.25)

ClassCastException java.lang.Double cannot be cast to clojure.lang.IFn  scratch.debugging/bake (debugging.clj:8)

That's not much to go on. Printing the full stacktrace with pst reveals more:

user=> (pst)
ClassCastException java.lang.Double cannot be cast to clojure.lang.IFn
	scratch.debugging/bake (debugging.clj:8)
	user/eval1223 (form-init4495957503656407289.clj:1)
	clojure.lang.Compiler.eval (Compiler.java:6619)
	clojure.lang.Compiler.eval (Compiler.java:6582)
	clojure.core/eval (core.clj:2852)
	clojure.main/repl/read-eval-print--6588/fn--6591 (main.clj:259)
	clojure.main/repl/read-eval-print--6588 (main.clj:259)
	clojure.main/repl/fn--6597 (main.clj:277)
	clojure.main/repl (main.clj:277)
	clojure.tools.nrepl.middleware.interruptible-eval/evaluate/fn--591 (interruptible_eval.clj:56)
	clojure.core/apply (core.clj:617)
	clojure.core/with-bindings* (core.clj:1788)

The first line names the exception type: a ClassCastException. The message says a java.lang.Double cannot be cast to a clojure.lang.IFn. Each indented line traces the call chain, with the deepest frame—where the error originated—at the top. That's the bake function in the scratch.debugging namespace, at debugging.clj line 8. Below it, each frame shows the function that called the previous one. Frames from the REPL itself, with generated names like user/eval1223, and later compiler internals, can be ignored.

The general rule for Clojure: focus on the deepest frame in a namespace you own. If the stacktrace dives deep into a library, skim toward the first frame that mentions your code—that's where your invocation goes wrong. In our example, the suspect is clear:

         (condp (* temp time) <

Now for the message itself. Double is the Java type that Clojure uses for decimal literals, as a quick REPL check confirms:

user=> (type 4)
java.lang.Long
user=> (type 4.5)
java.lang.Double

An IFn is Clojure's interface for anything invokable—functions, macros, special forms. The error means our code tried to call something that is a number, not a function.

In the condp expression, the arguments are reversed. Looking at the documented signature for condp:

user=> (doc condp)
-------------------------
clojure.core/condp
([pred expr & clauses])
Macro
  Takes a binary predicate, an expression, and a set of clauses.
  Each clause can take the form of either:

  test-expr result-expr

  test-expr :>> result-fn

  Note :>> is an ordinary keyword.

  For each clause, (pred test-expr expr) is evaluated. If it returns
  logical true, the clause is a match. If a binary clause matches, the
  result-expr is returned, if a ternary clause matches, its result-fn,
  which must be a unary function, is called with the result of the
  predicate as its argument, the result of that call being the return
  value of condp. A single default expression can follow the clauses,
  and its value will be returned if no clause matches. If no default
  expression is provided and no clause matches, an
  IllegalArgumentException is thrown.clj

The predicate should be a function applied to the test expression and each clause value. Writing (* temp time) as the predicate makes condp attempt a call like:

((* temp time) 400 <)

which tries to invoke a Double as a function. The fix is to swap the order:

(defn bake
  "Bakes a cake for a certain amount of time, returning a cake with a new
  :tastiness level."
  [pie temp time]
  (assoc pie :tastiness
         (condp < (* temp time)
           400 :burned
           350 :perfect
           300 :soggy)))

With that correction:

user=> (use 'scratch.debugging :reload)
nil
user=> (bake {:flavor :chocolate} 375 10.25)
{:tastiness :burned, :flavor :chocolate}
user=> (bake {:flavor :chocolate} 450 0.8)
{:tastiness :perfect, :flavor :chocolate}

The recovery worked because we followed the stacktrace as a path: identify the deepest frame in your own code, examine the values at that point, and verify assumptions against the REPL and documentation. The fix then becomes obvious.

One note on type systems: Clojure's dynamic typing means the compiler won't catch these mismatches at compile time. The flexibility is valuable, but it shifts the burden to rigorous testing—and to your ability to read an error message that arrives at runtime rather than edit time.

Reading non-linear traces

Stacktraces show a path through the program, but that path is not always a straight line. When data—or functions—are handed off between parts of the program, the trace can obscure the true origin of an error. Higher-order functions and lazy sequences in particular create traces that look nothing like the source code that produced them.

Consider a program that calculates wood needed for picture frames. It defines a frame function that takes a mat width and a photo dimension, computes the rectangle around the photo, and returns the wood segments needed:

(defn perimeter
  "Given a rectangle, returns a vector of its edge lengths."
  [rect]
  [(:x rect)
   (:y rect)
   (:z rect)
   (:y rect)])

(defn frame
  "Given a mat width, and a photo rectangle, figure out the size of the frame
  required by adding the mat width around all edges of the photo."
  [mat-width rect]
  (let [margin (* 2 rect)]
    {:x (+ margin (:x rect))
     :y (+ margin (:y rect))}))

(def failure-rate
  "Sometimes the wood is knotty or we screw up a cut. We'll assume we need a
  spare segment once every 8."
  1/8)

(defn spares
  "Given a list of segments, figure out roughly how many of each distinct size
  will go bad, and emit a sequence of spare segments, assuming we screw up
  `failure-rate` of them."
  [segments]
  (->> segments
       ; Compute a map of each segment length to the number of
       ; segments we'll need of that size.
       frequencies
       ; Make a list of spares for each segment length,
       ; based on how often we think we'll screw up.
       (mapcat (fn [ [segment n]]
                 (repeat (* failure-rate n)
                         segment)))))

(def cut-size
  "How much extra wood do we need for each cut? Let's say a mitred cut for a
  1-inch frame needs a full inch."
  1)

(defn total-wood
  [mat-width photos]
  "Given a mat width and a collection of photos, compute the total linear
  amount of wood we need to buy in order to make frames for each, given a
  2-inch mat."
  (let [segments (->> photos
                      ; Convert photos to frame dimensions
                      (map (partial frame mat-width))
                      ; Convert frames to segments
                      (mapcat perimeter))]

    ; Now, take segments
    (->> segments
         ; Add the spares
         (concat (spares segments))
         ; Include a cut between each segment
         (interpose cut-size)
         ; And sum the whole shebang.
         (reduce +))))

(->> [{:x 8
       :y 10}
      {:x 10
       :y 8}
      {:x 20
       :y 30}]
     (total-wood 2)
     (println "total inches:"))

Running this produces a stacktrace with an unusual structure. Printing the full trace for the last exception *e with .printStackTrace reveals two parts:

user=> (.printStackTrace *e)
java.lang.ClassCastException: clojure.lang.PersistentArrayMap cannot be cast to java.lang.Number, compiling:(scratch/debugging.clj:73:23)
	at clojure.lang.Compiler.load(Compiler.java:7142)
	at clojure.lang.RT.loadResourceScript(RT.java:370)
	at clojure.lang.RT.loadResourceScript(RT.java:361)
	at clojure.lang.RT.load(RT.java:440)
	at clojure.lang.RT.load(RT.java:411)
        ...
  	at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.ClassCastException: clojure.lang.PersistentArrayMap cannot be cast to java.lang.Number
	at clojure.lang.Numbers.multiply(Numbers.java:146)
	at clojure.lang.Numbers.multiply(Numbers.java:3659)
	at scratch.debugging$frame.invoke(debugging.clj:26)
	at clojure.lang.AFn.applyToHelper(AFn.java:156)
	at clojure.lang.AFn.applyTo(AFn.java:144)
	at clojure.core$apply.invoke(core.clj:626)
	at clojure.core$partial$fn__4228.doInvoke(core.clj:2468)
	at clojure.lang.RestFn.invoke(RestFn.java:408)
	at clojure.core$map$fn__4245.invoke(core.clj:2557)
	at clojure.lang.LazySeq.sval(LazySeq.java:40)
	at clojure.lang.LazySeq.seq(LazySeq.java:49)
	at clojure.lang.RT.seq(RT.java:484)
	at clojure.core$seq.invoke(core.clj:133)
	at clojure.core$map$fn__4245.invoke(core.clj:2551)
	at clojure.lang.LazySeq.sval(LazySeq.java:40)
	at clojure.lang.LazySeq.seq(LazySeq.java:49)
	at clojure.lang.RT.seq(RT.java:484)
	at clojure.core$seq.invoke(core.clj:133)
	at clojure.core$apply.invoke(core.clj:624)
	at clojure.core$mapcat.doInvoke(core.clj:2586)
	at clojure.lang.RestFn.invoke(RestFn.java:423)
	at scratch.debugging$total_wood.invoke(debugging.clj:62)
        ...

The top-level error is a CompilerException, followed by the exception that caused it: a ClassCastException. This makes the trace read out of order—the deepest part of the stack appears in the first line of the last exception. Reading order goes C B A, then F E D. This is an old Java convention, and a frequent source of confusion.

This representation is also less friendly than what pst shows. We see the JVM's internal names for Clojure functions, such as clojure.core$partial$fn__4228.doInvoke. That corresponds to the namespace clojure.core, the function partial, and an anonymous function inside it named fn__4228. Calling a Clojure function appears in the JVM as .invoke or .doInvoke.

The root cause is a ClassCastException: Clojure expected a java.lang.Number but found a PersistentArrayMap. Given the map we passed in, that's a strong clue:

user=> (type {:x 1})
clojure.lang.PersistentArrayMap

Reading down the trace for our scratch.debugging namespace shows the error occurred at scratch.debugging$frame, on line 26:

  (let [margin (* 2 rect)]

That's the multiplication *, which presumably expands to clojure.lang.Numbers.multiply. But the path to the error is odd:

                 (->> photos
                      ; Convert photos to frame dimensions
                      (map (partial frame mat-width))

In total-wood, we immediately call (map (partial frame mat-width) photos), so the trace should go from total-wood to map to frame. Instead, total-wood invokes RestFn—internal Clojure plumbing—which calls mapcat. total-wood did call map, but map never applies its function when called. It returns a lazy sequence: frame is only applied when elements are requested.

	at clojure.core$mapcat.doInvoke(core.clj:2586)
	at clojure.lang.RestFn.invoke(RestFn.java:423)
   	at scratch.debugging$total_wood.invoke(debugging.clj:62)

Each LazySeq holds a box containing a function. When asked for its first value, it calls that function to produce a new sequence—and that's when frame is invoked. The trace shows this internal machinery: mapcat asks the LazySeq for a value, and the LazySeq asks map to generate it.

user=> (type (map inc (range 10)))
clojure.lang.LazySeq

We pass through laziness twice here. A look at (source mapcat) shows it expands into its own map call, and then there's the second map from total-wood. After that, we hit clojure.core$partial$fn__4228:

	at clojure.core$partial$fn__4228.doInvoke(core.clj:2468)
	at clojure.lang.RestFn.invoke(RestFn.java:408)
	at clojure.core$map$fn__4245.invoke(core.clj:2557)
	at clojure.lang.LazySeq.sval(LazySeq.java:40)
	at clojure.lang.LazySeq.seq(LazySeq.java:49)
	at clojure.lang.RT.seq(RT.java:484)
	at clojure.core$seq.invoke(core.clj:133)
	at clojure.core$map$fn__4245.invoke(core.clj:2551)
	at clojure.lang.LazySeq.sval(LazySeq.java:40)
	at clojure.lang.LazySeq.seq(LazySeq.java:49)
	at clojure.lang.RT.seq(RT.java:484)
	at clojure.core$seq.invoke(core.clj:133)
	at clojure.core$apply.invoke(core.clj:624)
	at clojure.core$mapcat.doInvoke(core.clj:2586)
	at clojure.lang.RestFn.invoke(RestFn.java:423)
	at scratch.debugging$total_wood.invoke(debugging.clj:62)

  (map (partial frame mat-width) photos)

frame takes two arguments: mat width and photo. We want a one-argument function. (partial frame mat-width) captures mat-width and generates a new function that takes one argument—photo—and calls (frame mat-width photo). That generated function is what map invokes lazily on demand:

user=> (partial + 1)
#<core$partial$fn__4228 clojure.core$partial$fn__4228@243634f2>
user=> ((partial + 1) 4)
5

Control thus flows through clojure.core$partial$fn__4228—an anonymous function inside clojure.core/partial—on the way to frame. And there's the suspect: scratch.debugging/frame, line 26.

Caused by: java.lang.ClassCastException: clojure.lang.PersistentArrayMap cannot be cast to java.lang.Number
	at clojure.lang.Numbers.multiply(Numbers.java:146)
	at clojure.lang.Numbers.multiply(Numbers.java:3659)
	at scratch.debugging$frame.invoke(debugging.clj:26)
	at clojure.lang.AFn.applyToHelper(AFn.java:156)
	at clojure.lang.AFn.applyTo(AFn.java:144)
	at clojure.core$apply.invoke(core.clj:626)
	at clojure.core$partial$fn__4228.doInvoke(core.clj:2468)

* multiplies, and 2 is clearly a number, but rect is a map. We meant to double the mat-width, not the rectangle:

  (let [margin (* 2 rect)]

With that fixed, the program runs—but another bug lurks. This one has a much shorter stacktrace:

(defn frame
  "Given a mat width, and a photo rectangle, figure out the size of the frame
  required by adding the mat width around all edges of the photo."
  [mat-width rect]
  (let [margin (* 2 mat-width)]
    {:x (+ margin (:x rect))
     :y (+ margin (:y rect))}))

Tracking down a mystery nil

On line 69, total-wood calls reduce, which dives through clojure.core.protocols functions before emerging in +. reduce is combining two wood segments with +, but one of them was nil. Clojure raises a NullPointerException. The segments were built this way:

user=> (use 'scratch.debugging :reload)

CompilerException java.lang.NullPointerException, compiling:(scratch/debugging.clj:73:23) 
user=> (pst)
CompilerException java.lang.NullPointerException, compiling:(scratch/debugging.clj:73:23)
	clojure.lang.Compiler.load (Compiler.java:7142)
	clojure.lang.RT.loadResourceScript (RT.java:370)
	clojure.lang.RT.loadResourceScript (RT.java:361)
	clojure.lang.RT.load (RT.java:440)
	clojure.lang.RT.load (RT.java:411)
	clojure.core/load/fn--5066 (core.clj:5641)
	clojure.core/load (core.clj:5640)
	clojure.core/load-one (core.clj:5446)
	clojure.core/load-lib/fn--5015 (core.clj:5486)
	clojure.core/load-lib (core.clj:5485)
	clojure.core/apply (core.clj:626)
	clojure.core/load-libs (core.clj:5524)
Caused by:
NullPointerException 
	clojure.lang.Numbers.ops (Numbers.java:961)
	clojure.lang.Numbers.add (Numbers.java:126)
	clojure.core/+ (core.clj:951)
	clojure.core.protocols/fn--6086 (protocols.clj:143)
	clojure.core.protocols/fn--6057/G--6052--6066 (protocols.clj:19)
	clojure.core.protocols/seq-reduce (protocols.clj:27)
	clojure.core.protocols/fn--6078 (protocols.clj:53)
	clojure.core.protocols/fn--6031/G--6026--6044 (protocols.clj:13)
	clojure.core/reduce (core.clj:6287)
	scratch.debugging/total-wood (debugging.clj:69)
	scratch.debugging/eval1560 (debugging.clj:81)
	clojure.lang.Compiler.eval (Compiler.java:6703)

Where did the nil come from? The stacktrace doesn't say. The sequence reduce traverses had no problem producing the nil—reduce asked, and the sequence delivered. The problem only surfaced when combining that nil with the next value.

This kind of trace is a murder mystery: the program died in the reducer, shot with a +, and the bullet was a nil. But the bullet's origin is unknown. Static type systems largely prevent this class of error—though a typed Option[A] propagating through functions can produce similarly difficult localization problems.

We need more forensic information. Printing state as reduce goes along reveals:

  (let [segments (->> photos
                      ; Convert photos to frame dimensions
                      (map (partial frame mat-width))
                      ; Convert frames to segments
                      (mapcat perimeter))]

    ; Now, take segments
    (->> segments
         ; Add the spares
         (concat (spares segments))
         ; Include a cut between each segment
         (interpose cut-size)
         ; And sum the whole shebang.
         (reduce +))))

    (->> segments
         ; Add the spares
         (concat (spares segments))
         ; Include a cut between each segment
         (interpose cut-size)
         ; And sum the whole shebang.
         (reduce (fn [acc x] (prn acc x) (+ acc x))))))

Not every value is nil. There's a 14, a plausible segment for a frame, plus two one-inch buffers from cut-size. We can rule out interpose: it consistently inserts 1, and that reduces fine. Is the nil coming from segments or from (spares segments)?

user=> (use 'scratch.debugging :reload)
12 1
13 14
27 1
28 nil

CompilerException java.lang.NullPointerException, compiling:(scratch/debugging.clj:73:56) 

  (let [segments (->> photos
                      ; Convert photos to frame dimensions
                      (map (partial frame mat-width))
                      ; Convert frames to segments
                      (mapcat perimeter))]

    (prn :segments segments)

It's present in segments itself. Tracing backwards through the sequence's construction, it would help to have a version of prn that returns its input, so we can spy on values flowing through the ->> macro:

user=> (use 'scratch.debugging :reload)
:segments (12 14 nil 14 14 12 nil 12 24 34 nil 34)

(defn spy
  [& args]
  (apply prn args)
  (last args))

  (let [segments (->> photos
                      ; Convert photos to frame dimensions
                      (map (partial frame mat-width))
                      (spy :frames)
                      ; Convert frames to segments
                      (mapcat perimeter))]

Frames are intact, but perimeters are bad. Examining perimeter:

user=> (use 'scratch.debugging :reload)
:frames ({:x 12, :y 14} {:x 14, :y 12} {:x 24, :y 34})
:segments (12 14 nil 14 14 12 nil 12 24 34 nil 34)

The typo is :z where :x was intended. Since the frame has no :z field, the lookup returned nil. That nil propagated through the sequence construction, surfaced only when reduce tried to add it. With the fix in place, the program runs correctly:

(defn perimeter
  "Given a rectangle, returns a vector of its edge lengths."
  [rect]
  [(:x rect)
   (:y rect)
   (:z rect)
   (:y rect)])

Debugging as exploration

Experience makes debugging faster: skipping irrelevant log data, identifying the offending input, knowing what to search for. But unexpected bugs call for a systematic approach. Explore the problem thoroughly, localizing it to a specific function, variable, or input set. Identify boundaries, carving away parts that work as expected. Develop precise characterizations of the problem space.

Once identified, search for extant solutions—issue trackers, mailing lists, forums, or academic resources for theoretical problems. If nothing surfaces, rephrase the problem, relax constraints, add logging, solve smaller subproblems. When all else fails, ask peers or the wider community, or take a break.

Clojure stacktraces are a trail to the error location, but not all trails are linear. Lazy operations and higher-order functions create inversions and intermediate layers. Values distant from the trace—like that nil—require adding logging and working progressively closer to the origin.

Languages and their users engage in a dialogue. Formal, verbose specifications with types and assertions let the program assist when things go wrong—but those specifications harden programs into rigid structures. Clojure trades that rigidity for flexibility, paying for it with errors that are harder to trace. The compiler catches misspelled variables, but without something like core.typed, it won't catch incorrect type assumptions. Even rigid languages like Haskell miss errors such as reversed subtraction arguments. Some testing is always necessary.

Whatever language we write in, we balance types and tests to validate our assumptions at compile time and runtime. Errors aren't rebukes—they're hints pointing toward a deeper understanding of the program. They may be cryptic, but reading them well is a skill that improves with practice.