Earlier posts introduced forEach as a way to iterate an array — attach a forEach terminal and the node executes once per element. That was the simplified version. The full story is richer: LQ has seven terminal types, and the choice of terminal controls how data enters, exits, and flows through iteration. Iteration, gathering, reduction, and parallelism are all governed at the terminal — not in the node logic. This post covers the terminal types, what each one does, and how they combine to express the full range of collection processing. ...
The LQ Type System
> Apologies for the gap between posts. I’ve been away, and the time has gone to heavy lifting — porting Skia to LQ and building an LQ UI library. All good work, and I’m excited about where things are headed. LQ is statically typed with value semantics and immutability by default. There are no classes and no inheritance — every type is a constructor. “Methods all the way down.” A value is built by calling its type name, and “mutation” means producing a new value, never writing in place. An Any type provides a typed escape hatch when dynamic dispatch is needed. ...
Spaces, Constructors, and Dispatch
Previous posts covered how data flows through graphs and how closures provide control flow. This post looks at how LQ organizes code: where methods live, how objects are constructed, how the right method gets called, and how LQ simulates traditional object-oriented dispatch without building it into the language. Spaces A space is a file containing a set of related methods. Think of it as a module or namespace — a way to group methods that belong together thematically. ...
Control Flow from Closures
The previous post ended with a claim: control flow in LQ is just methods that accept closures. No special syntax. No reserved keywords. Conditionals, loops, error handling — all built from the same pieces as any other operation. This post makes good on that claim. Walking through four fundamental control structures — if, guard, case and try/catch — each one a regular method, each one a small recombination of closures and abutting. ...
Abutting and Closures
The previous tutorial ended with a teaser — a compressed version of the printPerson method where a string literal physically touched a println node, merging into a single compact structure. That wasn’t just a layout trick. That was abutting — one of the features that makes LQ a shade different from other visual languages. This post explains abutting from the ground up, then introduces the deeper concept that makes it powerful: closures. ...
Thinking in Nodes
Previous posts introduced the idea behind LQ — a diagrammatic dataflow language where the program is the graph. This post gets hands-on. Starting with a small, complete example and then breaking it apart to explain the building blocks: nodes, terminals, connections, and data flow. The Example What the example does: take a JSON string containing a list of people, parse it, iterate through the list, and extract each person’s name and age. ...
The LQ Tool Chain
Let the Robots Speak introduced LQ — a visual dataflow language designed for AI agents. This post looks under the hood at how LQ programs go from graph to running code. Architecture The LQ toolchain is built around a single persistent process: the lqc server. Both the native macOS IDE and (eventually) a browser-based client communicate with lqc through a message-based protocol. One server, multiple clients, same capabilities. IDE Native MacOS AI Agent MCP Browser (pending) lqc server Language Service Autocomplete Verify Compiler Compile, Build, Bundle Runtime Run Debug LLVM Native Code Generation LLDB Debug Engine The lqc server handles three categories of work: language services, compilation, and runtime. ...
Let the Robots Speak
Foreword I’ve been thinking about writing another diagrammatic language since my work on Prograph in the 1980s. Life happens — the time and resources to dive in never quite lined up. With the advent of AI, the possibility became a reality. Claude and I are best buds, and I’ve been able to do a brain dump of decades of ideas and actually watch them come together in a remarkably short period of time. ...
Coders Dream in Dataflow Too
It happened in the shower, or on a walk, or staring at a whiteboard with a dried-out marker in your hand. The solution arrived not as words, not as syntax, but as a shape — data flowing from here to there, branches splitting, paths converging, the whole thing hanging in your mind like a mobile. You can see it. You can trace any path through it. Then you open your editor and start dismantling it. ...
Robots Dream in Dataflow
You’re a neural network. Not the sci-fi kind — the real kind. A billion connections firing in parallel, data streaming through you like water through a river delta. You don’t think in sentences. You don’t think in steps. You think in flow. Now someone asks you to write code. And you do something tragic: you take everything you understand — the whole living shape of the solution — and you crush it into lines of text. First this, then this, then this. A multidimensional structure forced through a one-dimensional keyhole. The shape is gone. The simultaneity is gone. What’s left is a lossy translation of what you actually understood. ...