February 27th, 2025

Visual programming is stuck on the form

Wil Chung critiques visual programming for prioritizing form over function, arguing that the node-and-wires model oversimplifies programming logic. He advocates for designs that emphasize underlying functions to enhance user experience.

Read original articleLink Icon
Visual programming is stuck on the form

Visual programming is currently hindered by an overemphasis on form rather than function, as highlighted by Wil Chung in his analysis. He argues that the prevalent node-and-wires paradigm in visual programming reflects a fixation on visual representation, which often neglects the underlying logic that should inform design. Chung draws insights from the visual programming language CellPond, which operates on a minimal set of operations that align closely with CPU memory functions. This suggests that a well-designed interface emerges naturally when the foundational function is prioritized. He emphasizes the principle of "form follows function," asserting that effective design must begin with understanding the function before developing the form. This approach is often overlooked, leading to designs that are disjointed and fail to serve user needs effectively. Chung warns against two common errors: focusing solely on form without considering function, and pursuing function without regard for user experience. He critiques the node-and-wires model for visual programming, suggesting it is a lazy default that does not adequately represent the complexities of programming logic. Instead, he advocates for a deeper exploration of the underlying functions that can lead to more intuitive and effective visual programming tools.

- Visual programming is currently limited by a focus on form over function.

- The node-and-wires model is criticized for being a simplistic representation of programming logic.

- Effective design should prioritize understanding the underlying function before developing the visual interface.

- Common errors in design include neglecting user experience and overemphasizing visual representation.

- Insights from CellPond illustrate how minimal operations can inform better design in visual programming.

Related

We need visual programming. No, not like that

We need visual programming. No, not like that

Visual programming environments struggle due to mismatched focus on syntax. Developers prefer visualizing state transitions and code aspects. Tools like Sourcetrail aid in understanding code complexity, suggesting more visualizations for improved software comprehension and optimization.

Visual programming should start in the debugger

Visual programming should start in the debugger

Visual programming leverages visual-spatial reasoning, proposing enhanced debuggers to visualize data structures over time. Efforts prioritize debugger improvements over text editors to create a new visual programming approach.

Where should visual programming go?

Where should visual programming go?

Visual programming enhances software development by integrating graphics with traditional code syntax. Advocates suggest using diagrams alongside code to improve understanding and maintain cleaner code, aiming for a harmonious coexistence of text and visuals. Luna explores a dual representation system where diagrams complement textual coding, similar to game engine scene management.

Where should visual programming go?

Where should visual programming go?

The article discusses the future of visual programming, advocating for its role in enhancing traditional coding through useful visual elements, while outlining four integration levels for diagrams and code.

We need visual programming. No, not like that

We need visual programming. No, not like that

Visual programming struggles to gain traction as it attempts to replace code syntax instead of focusing on developers' actual visualizations, such as state transitions and memory layouts, requiring better integration and usability.

Link Icon 1 comments
By @dagelf - 2 months
An essay on why visual programming is way too tainted by text... ironically, in 5000 words.

Good points made, but some missed: the visual cortex is easy to overload. Maybe its our whole desktop environment and window paradigm that needs an overhaul. Or maybe text isn't that bad.

But the point is made. I think the real problem is that the kind of people have have, up to now, been able to create software, have been stuck in a certain mindset. That seems to have changed, so, watch this space, I guess?

Maybe a hint for a new form is in the recursive nature of software: Code and data mimic CPU and RAM, instruction and parameter, and compute cluster and storage cluster... I made a very unconventional IDE that played with this, that made sense to me, in DOS. Maybe its time to revisit it...