> This is inaccurate of my views. It's not that "visual programming is bad" it's that everything we call visual programming is not actually visual! Scratch is n

> This is inaccurate of my views. It's not that "visual programming is bad" it's that everything we call visual programming is not actually visual! Scratch is not visual. It's just text programming with more steps. Certainly "Visual" is a spectrum, not an on/off switch. Adding syntax coloring to a textual program is a step towards adding visual cues that improve recognition of its parts. Scratch adds over an imperative language a more detailed visual syntax that conveys the types of control structures and the relations between actions and parameters, and allows filling them in by interactive recognition rather than pure recall; so it's a step further in transforming a classic language into a visual one. Further steps in that direction include changing paradigms to functional or logic programs, that more explicitly represent changes in state through visual cues, relieving you from having to work them out in your short-term memory. Everything about visual languages is built towards adding expressiveness to the actual representation to convey as much information about the running program as possible. > I still don't think this is a visual language, but it is maybe more visual than traditional visual languages. A spreadsheet is something like a visual layout on top of a program. Programs are visual entities - they have a very concrete physical structure of a tree. That's why good indentation is essential even when the parser doesn't care about it at all. A program Abstract Syntax Tree is composed of very, well, abstract components; a program keywords represent objects quite separated of their final form during runtime, i.e. their actual values, but their connections can be often understood in terms of their spatial relations. Our brain is really very good at that, even for textual representations. > Even with a true visual language I don't think the need for a mental model can be removed. Completely agree. But building a mental model is way easier when working at several levels of abstraction at the same time, i.e. both concrete values and the abstractions that tie together those values in a concept encompassing them (see the concept of the Ladder of Abstraction).[1] And being able to actually see the values of variables and the connections between processes that change them, instead of having to imagine all those by running the program in your head, is a large advantage. The debugger is the quintessential visual tool, letting you inspect the true relations and processes of a running program through interactive manipulation, even for languages that otherwise lack any visual cues while being built. [1] http://worrydream.com/LadderOfAbstraction/ http://worrydream.com/LadderOfAbstraction/