Why We Chose Formulas Over Drag-and-Drop for ML

Every visual ML tool, from Azure ML Studio to Node-RED to dozens of startups, uses the same paradigm: drag nodes onto a canvas, connect them with wires. It's intuitive. It's visual. And we think it's the wrong abstraction for most ML work.

This post explains the reasoning behind our decision to use mathematical formulas as the primary interface for building models in MathExec.

The problem with nodes

Node-based editors are great for pipelines: sequential data processing steps where each stage has clear inputs and outputs. ETL workflows, audio processing chains, CI/CD pipelines. They work well when the graph structure is the logic.

But most ML models aren't pipelines. They're functions.

A 2-layer neural network is:

y = σ(W₂ · ReLU(W₁x + b₁) + b₂)

In a node editor, that's 6+ nodes and 5+ connections. You need an input node, a linear transform node, a bias addition node, a ReLU node, another linear transform, another bias, a sigmoid, and an output. Then you need to wire them all together in the right order.

In math, it's one line.

The node representation spreads a simple concept across a large visual space without adding any information. Every connection is obvious from the formula. The nesting structure tells you the execution order. The function names tell you the operations. The node graph is strictly more verbose and no more expressive.

The visual overhead scales badly

For a simple model like logistic regression (y = σ(Wx + b)), the node overhead is annoying but manageable. For a real architecture, it becomes a serious problem.

Consider a ResNet-style block:

y = ReLU(W₂ · ReLU(W₁x + b₁) + b₂ + x)

The + x at the end is a skip connection. In formula notation, it's two characters. In a node editor, it requires routing a connection from the input all the way around the main path to an addition node at the end. On a crowded canvas, this becomes a visual mess of crossing wires.

Now imagine writing a whole paper's worth of architectures this way. Researchers would spend more time arranging nodes than thinking about models.

The formula is the model

There's a deeper reason we prefer formulas. In machine learning, the mathematical expression is the model. It's not a description of the model or a diagram of the model. The formula y = σ(Wx + b) contains every piece of information needed to construct, initialize, and train a logistic regression classifier.

When we use formulas as the interface, there's no translation step. The thing you type is the thing you get. This directness eliminates an entire category of bugs and misunderstandings that come from mapping between two different representations (visual graph and mathematical function).

When we do use visual connections

MathExec isn't anti-visual. Our canvas supports connecting formula blocks with arrows to build graph architectures, where one formula's output feeds into another. This is useful for:

• Ensemble models: Multiple formulas each process the input, and their outputs are combined
• Multi-stage pipelines: Preprocessing formula → model formula → postprocessing formula
• Comparative analysis: Same data, different formulas, side by side on the canvas

But the individual building blocks are formulas, not generic "nodes." Each block contains a complete mathematical expression that fully defines its computation. The arrows only define data flow between blocks, not the computation within them.

This is an important distinction. In a node editor, each node is a primitive operation (add, multiply, activate). In MathExec, each block is a complete model. The visual graph exists at a higher level of abstraction.

The speed argument

Our moat is workflow speed. We're competing with "I'll open a notebook later." When a researcher has an idea, we want them to test it in 60 seconds, not 10 minutes.

Formulas are faster to express than node graphs. A researcher can type y = σ(Wx + b) in 3 seconds. Dragging 3 nodes and connecting 2 wires takes 15-20 seconds, assuming you know where to find the right nodes in the sidebar. That 5x speed difference compounds over a workday of experimentation.

Speed also matters for iteration. When you want to try a variant (swap ReLU for tanh, add a layer, change the output activation), editing a formula takes a few keystrokes. In a node graph, you need to delete nodes, add new ones, and rewire connections. The formula change is atomic and immediate.

The literacy argument

Mathematical notation is a universal language in science and engineering. Every ML paper uses it. Every textbook uses it. Every whiteboard sketch uses it. Every lecture uses it.

By making formulas the primary interface, we let users go from paper to model with zero translation. The formula in the paper is the same formula in MathExec. No need to figure out which nodes correspond to which terms, or how to express a subscript in a dropdown menu.

This also means that MathExec formulas are portable outside of MathExec. You can paste them into a paper, a Slack message, or a whiteboard. Try doing that with a screenshot of a node graph.

What users actually do

We've watched dozens of people use MathExec, and the formula-first approach changes how they work in ways we didn't fully anticipate.

They iterate faster. Because typing a formula is fast, people try more variants. Instead of committing to one architecture and spending 30 minutes implementing it, they'll try 5-6 formulas in 10 minutes and compare results. The experiment history makes this practical.

They think in math first. New users sometimes start by asking "where's the linear layer node?" But within a few minutes, they shift to thinking about the math directly. "What if I add a tanh here?" becomes a natural question instead of a UI problem.

They compare more. Side-by-side experiment comparison is one of the most-used features. Because the cost of trying a new formula is so low (10 seconds to type and train), people routinely compare 3-4 approaches before picking one. In a notebook workflow, most people would try one approach and move on.

They use the canvas for communication, not just computation. The canvas with formula blocks and arrows has become a way for teams to discuss model architectures. It's visual enough to be understood at a glance, but precise enough to be directly executable. Several users told us they use MathExec screenshots in presentations and design documents.

What we sacrifice

Formulas have real limitations, and we want to be honest about them:

Not beginner-friendly. You need to know what σ(Wx + b) means before you can use it. MathExec doesn't teach you machine learning. If you're new to ML, you'll need to learn the notation from a textbook or course first. We think this is an acceptable tradeoff for our target audience, but it does narrow who can pick up the tool cold.

Limited expressiveness. Some architectures are awkward in formula notation. Attention mechanisms (softmax(QK^T / √d)V) are borderline. Convolutions don't have a clean mathematical form for the spatial operations. Recurrent networks involve temporal subscripts that get messy. We're working on extending the compiler to handle these, but it's an ongoing challenge.

No visual data flow. You can't "see" data flowing through a formula the way you can through a node graph. Node editors often show tensor shapes and intermediate values at each node, which is genuinely useful for debugging. We compensate for this by showing detailed training metrics and allowing formula-level debugging, but it's not the same as watching data flow through a visual pipeline.

Steep learning curve for complex formulas. While y = mx + b is easy for anyone, expressions like y = softmax(W₃ · BN(ReLU(W₂ · BN(ReLU(W₁x + b₁)) + b₂)) + b₃) are dense and hard to read. At some point, formula complexity hits a wall where a visual representation would genuinely be clearer.

The hybrid approach

We landed on a hybrid: formulas for individual model components, visual connections for wiring components together. This gives us the conciseness of mathematical notation for the parts that benefit from it, and the clarity of visual graphs for the parts that benefit from that.

A single model is a formula. A pipeline of models is a visual graph. We think this hits the right balance between speed and clarity.

Other tools have made similar decisions. Desmos uses formula input for graphing rather than point-and-click curve builders. Wolfram Alpha takes mathematical expressions as text input. LaTeX itself is a text-based approach to a visual problem (typesetting). In each case, the text-based approach won in communities where users are comfortable with the notation. We're betting on the same dynamic for ML.

Formulas aren't the right interface for everyone. But for people who think in math, and that's most of the ML community, they're faster, more precise, and more natural than any visual alternative.

---

Try writing a formula in MathExec. If you can write it on a whiteboard, you can train it here.