What ITERATE Taught Me About Fractal Logic in Parametric Design
Running a workshop on recursion and fractal logic for B.Arch and M.Arch students surfaced a gap that is easy to miss when you already think recursively. The hard part was never the code.
ITERATE was a workshop built around a simple premise. Fractal and recursive logic isn't just a visual style in parametric design, it's a different way of describing a rule. Instead of drawing the final form, you describe the step that repeats, and the form emerges from how many times and how it repeats. Running it for B.Arch and M.Arch students, using Grasshopper with Python and WASP for the aggregation side, surfaced something I hadn't fully anticipated going in.
The gap wasn't technical
Every student in the room could follow a for loop. The gap wasn't understanding recursion as a programming concept. It was translating a design intention into a recursive rule in the first place. Given a target form, most students' first instinct was to try to describe the whole shape at once, the same way they'd approach it in a direct modeling tool. Recursive thinking asks a completely different question. Not what does the final thing look like, but what is the one operation that, repeated, produces this. That reframe was the actual teaching challenge, far more than any Grasshopper syntax.
Where WASP earned its place in the curriculum
WASP's aggregation by rule approach turned out to be a good bridge for this, because it forces the same reframe structurally. You don't place parts, you define connection rules between parts and let the aggregation run. Students who were stuck trying to design the whole thing in Grasshopper often unstuck themselves faster once they'd worked through a WASP exercise, because the tool itself doesn't let you skip straight to the final form. You're forced to think in terms of the repeating unit and its connection logic from the start.
The mistake worth naming
The most common actual mistake wasn't a bad rule, it was an unconstrained one. A recursive or aggregation rule with no termination condition or growth limit produces geometry that technically satisfies the rule and is completely unusable, growing forever or exploding in complexity within a few iterations. Getting students to build a stopping condition into their rule from the start, rather than bolting one on after watching Grasshopper struggle to solve an unbounded aggregation, was one of the more useful small habits to instill early.
What carried over into how I teach computational design generally
The bigger lesson wasn't really about fractals specifically. The hardest part of teaching computational design tools usually isn't the tool. Students pick up components and syntax reasonably fast. It's teaching the reframe from describe the object to describe the rule that generates the object, and that reframe needs its own deliberate exercises, not just harder and harder examples of the same kind of thinking.