Recto: In Case Programming Isn’t Hard Enough

What Is Recto, Exactly?

Recto is a 2D programming language created by Masato Hagiwara. Its core idea is simple to describe and deceptively hard to implement: instead of expressing structure as a one-dimensional stream of tokens (like most programming languages do), Recto encodes structure directly in space using nested rectangles.

That means scope, grouping, and recursion are not represented primarily by parentheses, braces, or indentation. They’re represented by rectangular boundaries that can contain values, expressions, and other rectangles. Recto also supports typed rectangles such as dictionary, set, and matrix forms, which makes the language especially interesting for thinking about structured and multidimensional data.

If you’re hearing “Lisp, but after a dramatic architecture school semester,” you’re not totally off. Even the creator describes Recto’s execution model as Lisp-inspired in how function calls are evaluated, while some control-flow styling resembles Python.

Recto TL;DR, nested rectangles, typed rects, Lisp-inspired execution, Python-like control flow are documented on the author page.

Why Recto Feels Different From Typical “Visual Programming”

A lot of “visual programming” tools are visual in the same way a nice restaurant menu is visual: the presentation changes, but the kitchen is still doing familiar work behind the scenes. Many systems use blocks, diagrams, or builders as an interface layer, while the executable meaning remains rooted in line-based code or serialized structures.

Recto is trying to do something more radical. The layout is not decoration. The layout is syntax. The geometry is not just helping you read the program; it is part of what the program is. That distinction matters, because it changes what parsing, editing, versioning, and even AI assistance would need to understand.

This is exactly why Recto is so fascinating: it isn’t merely a coding toy or a teaching UI. It’s a serious experiment in language design that pokes at an assumption most developers never questionthat code must flow in one dimension.

Hackaday explicitly contrasts Recto with graphical environments that still map to line-based code, and the Recto page emphasizes spatial syntax/semantics.

How Recto Works (Without Turning This Into a Geometry Midterm)

1) Rectangles as Syntax Units

Recto defines “rects” using corner markers. Inside a rect, you place elements separated by spaces or tabs. There are regular rectangles, single-row rects (list-like), and single-column rects (vector-like). Rects can nest inside other rects, which is how Recto expresses structured expressions and recursion.

2) Row-Major Parsing Still ExistsBut It’s Not the Whole Story

Recto uses row-major order when reading elements (left-to-right across rows, then top-to-bottom), but that doesn’t reduce the language back to “just text with extra steps.” The parser still has to reason about ownership in two dimensions: what belongs to which rectangle, how boundaries align, and whether a shape is well-formed.

The author describes a multi-stack parsing approach: not just a row-wise stack, but column-wise stacks as well, to track x-coordinates and resolve nested or overlapping structure. Translation: your parser now has to think in both axes instead of pretending the y-axis is only there to keep line numbers employed.

3) Typed Rectangles Add Semantics

Recto supports typed rectangles for structures like dictionaries (/d), sets (/s), and matrices (/m). The matrix form is particularly notable because the spatial layout directly corresponds to rows and columns, making it feel more native for math-heavy domains than a flattened list syntax.

4) Execution Model: Lisp Vibes, Python Flavors

Function calls in Recto are evaluated with a Lisp-like “first element is the function, rest are arguments” pattern. Meanwhile, control structures such as if and for are presented in a style the author compares to Pythonbut defined spatially by rectangle boundaries instead of indentation or braces.

Grammar markers, row-major parsing, multi-stack parser, typed rects, and execution/control-flow descriptions come from the Recto documentation.

The Real Punchline: Recto Makes Tooling the Main Character

Recto’s funniest feature is also its most important one: it exposes how much modern software tooling assumes code is line-based text. IDEs, version control diffs, code review workflows, linting, autocomplete, formatting, and many AI coding tools are all optimized for a top-to-bottom stream of characters.

Hagiwara openly calls this out and even describes early Recto authoring via Google Sheetsplacing symbols in cells and copying rangesto simulate spatial code. It worked, but it was understandably clunky. That led to the creation of Recto Pad, a browser-based grid editor for drawing Recto structures and importing/exporting plain text.

This is where Recto stops being “weird syntax art” and becomes a genuinely useful thought experiment for the future of programming tools. If a language is spatial, maybe the editor should act more like a canvas than a text buffer. Suddenly, design-tool ideas like pan/zoom navigation, spatial grouping, and region-based collaboration start sounding less like gimmicks and more like necessities.

Writing/editing challenges, Google Sheets prototype, Recto Pad capabilities, and tooling assumptions are from the Recto page; Hackaday also mentions spreadsheet authoring and browser editor/compiler.

Recto vs. Visual Programming Platforms We Already Know

To understand why Recto is interesting, it helps to compare it with established visual programming and graphical modeling toolsnot because Recto is trying to replace them, but because it highlights a different design goal.

Scratch, Blockly, and App Inventor: Accessible Visual Programming

Blockly popularized drag-and-drop block editing as a practical engine for teaching and building coding experiences, and Google’s own documentation notes that Blockly powers major education products. Scratch and MIT App Inventor, in turn, show how powerful block-based interfaces can be for learning and rapid creation.

Scratch’s reach is massive, and that matters: it proves visual representations can help millions of people learn programming concepts. App Inventor similarly separates interface design (Designer) from behavior logic (Blocks Editor), which is fantastic for building apps quickly.

But Recto is aiming at a different target. It isn’t primarily trying to simplify onboarding. It is testing whether a language can encode structure natively in 2D space without treating visuals as a front-end layer.

Blockly capabilities and its role in CS education; Scratch scale; App Inventor Designer vs Blocks Editor.

MakeCode: A Great Example of Bridging Blocks and Text

Microsoft MakeCode is a strong example of a hybrid approach: blocks for accessibility, plus JavaScript and Python for deeper control. The docs show explicit support for blocks, JavaScript, and Python references, and MakeCode’s guidance around “grey JavaScript blocks” is especially revealing: some text code patterns simply can’t map cleanly back into blocks.

That limitation is not a flawit’s a feature of representation boundaries. And it’s exactly the kind of thing Recto pushes into the spotlight. Every notation makes some structures easy and others awkward. Recto asks: what happens if we choose a notation where spatial structure is native and linear text is the awkward one?

MakeCode platform and docs, plus JavaScript block conversion limits, are from Microsoft MakeCode pages.

LabVIEW and Simulink: Proof That Graphical Programming Can Be Serious

If anyone still thinks “graphical programming” means “for kids only,” LabVIEW and Simulink would like a word. NI positions LabVIEW as a graphical programming environment for test and measurement, while MathWorks describes Simulink as a graphical modeling and simulation environment where blocks represent system parts and connect via inputs and outputs.

These tools prove that graphical representations can be industrial-strength. Recto differs again, though: LabVIEW and Simulink are domain-focused graphical environments with specific execution and modeling paradigms, while Recto is experimenting at the level of general language syntax.

NI LabVIEW and MathWorks Simulink pages document their graphical programming/modeling positioning.

What Developers on the Internet Immediately Argued About (Naturally)

Recto sparked the kind of discussion that only language design can produce: half delight, half philosophy, and at least one person saying “this is just parentheses with extra steps” before coffee.

Hacker News reactions captured a useful criticism: even if syntax is 2D, interpreters often compile to an internal representation that isn’t visibly spatial anymore. That doesn’t invalidate Recto, but it does force a sharper question: is the 2D form improving human authoring, machine parsing, or both?

That’s a healthy debate. Experiments like Recto are valuable precisely because they surface these questions. A language does not need to “win” to be important; it can still expand the design space and expose hidden assumptions in our current tools.

HN thread includes both enthusiasm and skepticism about parser/interpreter representation and practical usability.

Who Should Care About Recto?

Recto is not (yet) the thing you should deploy to production if your team needs to ship a payment service by Friday. But if you care about programming languages, developer tooling, human-computer interaction, education, spatial interfaces, or AI-assisted coding, Recto is absolutely worth paying attention to.

Here’s why:

• Language designers can study how syntax and layout interact when space becomes semantic.
• Tool builders can rethink editors, diffs, and collaboration for non-linear code structures.
• Educators can compare what “visual” means across blocks, diagrams, and true spatial syntax.
• AI researchers can explore what coding assistance looks like when line-based token streams are a poor fit.
• Curious developers get a delightful reminder that programming still has room for weird ideas.

And frankly, the weird ideas are where many of the best future tools begin.

Recto’s Biggest Strength and Biggest Risk

Biggest Strength: Spatial Structure Is the Point

Recto’s core strength is conceptual clarity: it treats structure as something you can literally see in space. For nested logic, matrices, and other multidimensional relationships, that can be more natural than squeezing everything into a line-oriented representation and hoping indentation is enough.

Biggest Risk: The Ecosystem Is Built for Lines

The challenge is not just syntax design; it’s ecosystem gravity. Everything from code review habits to git diffs to autocomplete UIs assumes linear text. Even modern AI coding systems are optimized for sequence modeling first. Recto can absolutely exist, but it needs tools that meet it on its own terms.

That’s why Recto feels less like “a new language to learn this weekend” and more like “a prototype from the future that accidentally time-traveled into our text-editor era.”

Author explicitly notes tooling/AI assumptions around 1D code and mentions sequence-oriented models; Hackaday echoes the practical write/draw issue and editor/compiler status.

Extended Experience Notes: What It Feels Like to Think in Rectangles (Approx. )

The most interesting “experience” with Rectowhether you are actually using Recto Pad or just mentally simulating the languageis that it changes what your brain pays attention to. In line-based code, your eye tracks sequence first and structure second. You scan top to bottom, decode tokens, and rely on indentation, braces, or syntax highlighting to reconstruct the hierarchy. With Recto, hierarchy tries to jump to the front of the line (ironically, without a line).

That feels exciting for about five minutes, then humbling for the next twenty. Why? Because most of us are trained to debug by reading streams. We are very good at mentally flattening complexity into “first this, then that.” Recto asks you to maintain a spatial map while also reasoning about evaluation. It can feel less like coding and more like arranging furniture in a studio apartment where the sofa is also a function call.

The first emotional reaction is usually delight. The second is friction. The third is curiosity. That third stage is where Recto becomes valuable. You start noticing how many habits you thought were “programming” are really just “text-editor habits.” For example, in line-based languages, moving code around often means cut, paste, and re-indent. In a spatial system, the natural instinct is to move regions as shapes. You stop asking “which line should this be on?” and start asking “which region does this belong to?” That is a deep shift.

There is also an unexpected readability effect. Some structures become easier to grasp at a glance because the boundary itself communicates grouping. But other things become harder, especially when your mental model expects a clear execution path. In a line-based language, the next token is usually nearby in reading order. In a spatial language, the next meaningful unit may be adjacent visually but conceptually nested, or far away but semantically sequential. It’s a different kind of literacy.

Teamwork is another thought-provoking angle. If Recto-like tooling evolved into a proper canvas experience, collaborative coding could become more region-oriented: one person editing a data-transform block while another refines a control-flow region elsewhere in the same visual program. That sounds amazing. It also sounds like a nightmare for merge conflicts until the tooling grows up. Which, to be fair, is exactly what people once said about graphical design collaboration before modern cloud tools normalized it.

My biggest takeaway from the Recto concept is not “this will replace Python” (it won’t, at least not before your keyboard files a complaint). It’s that Recto makes programming feel experimental again. It reminds us that syntax is a design choice, not a law of nature. And even if Recto remains a niche esolang, the questions it raisesabout structure, tooling, collaboration, and machine understandingare the kind that often lead to genuinely useful breakthroughs later.