I think he has the answer in a follow up "there's probably some Curse of Lisp stuff going on here; maybe the problem is that this project attracts people who are interested in "solving" the abstract problem of syntax manipulation but don't feel strongly about any specific use cases"

One of the factors, I'd say, is that the terminal interface does not offer the best environment for structured (or graphical) editing, and that the GUIs have always been very weak in their rich-text (or structured text) abilities. As a result, there was no substrate on which to grow a tool that would become widespread. However, with the DOM/CSS and the modern Web APIs (like content editable) we're getting closer to a viable infrastructure for building rich, structured visual editors.

talks some about how many projectional editors break sequentiality and undo and such that you have in text It is not of course obvious that backwards compatibility with text as strict as "any syntactically valid sequence of characters and edits should produce the same result" is necessary, but lack of it is certainly a factor in adoption - compare paredit with parinfer

If you make a syntax directed editor for a popular text-based programming language (C, Python, Javascript, etc), it probably won't be popular, because developers using those languages have already developed muscle memory for writing code using their favourite text editor, and have learned idioms for editing and transforming code using a convention text editor that won't work in a syntax directed editor. Likewise, a wire-and-node visual programming interface to a conventional style programming language won't be popular with conventional developers, because if you've already made the commitment to memorizing the syntax of a conventional text based language, then a node-and-wire interface will be slow and unproductive by comparison. Node-and-wire visual programming environments are popular for niche applications: music, video synthesis and graphics. Musicians and visual artists don't have the same interest in memorizing the syntax of a text based language. A GUI interface can make all of the useful nodes easily discoverable using standard GUI idioms (eg, popup menu or a toolbar), and the mastering the syntax is far easier (you just drag wires between nodes).

I wouldn't characterize node and wire interfaces as a matter of operator sophistication, but rather that successful instances are primarily data entry interfaces rather than programming ones. Max-MSP, nodewerk, sunvox, physical modular synths, XCode Interface Builder: they look at a first glance as an AST of nodes with immediate visualizations of the value at each node, and they ~ are ~ that but the nodes aren't things like

if

or

let

but rather high-level functions with 2-20 numerical parameters per link. (In the audiovisual case, each one is an implicit foreach, and some of them contain fairly direct `if`s in the form of "pick" ternary operators - kind of like APL actually)

My project is a language for procedurally generated visual art. It works well for my personal needs, and some people on the internet use it. I've talked to a lot of artists in my local community, and not many local artists can program. Those that do mostly use node-and-wire languages. One artist said that he could modify existing GLSL source code (for doing GPU shader effects in the Magic node-and-wire language), but he can't write this kind of source code from scratch. But node-and-wire programming is not a problem. I don't use node-and-wire languages myself. To test your claim about no if or let, I opened the Wikipedia page for Max-MSP. There is a screenshot of a Max program. It contains a large switch statement: There is a "key" node, and the output value flows into many "select" nodes, each of which are individual cases in the switch. There are also several "if" nodes. "Let" nodes for binding local variables seem unnecessary because the output of one node can be routed via branching wires to multiple inputs. To me, the Max code is ugly and unstructured: it looks like a plate of spaghetti. I analysed the code into a hierarchical structure within my minds eye, including an imagined 'switch statement', but there's no hierarchy on the screen, just spaghetti. But not everybody's brain is wired the same way. I am very comfortable with text, grammar, mathematics, structure, hierarchy. I meet visual artists who can effortlessly draw in a way that feels beyond my abilities. I show some of these artists my code, and they just see gibberish. One of the questions that interests me is, how to design a programming environment for artists? How does your brain work if you can rapidly draw a realistic figurative scene, but grammar is not your thing? You have relatively more grey matter for processing visual scenes, relatively less for parsing text. The node-and-wire presentation might be a lot easier for you to process.

@Doug Moen sounds like you might enjoy Jennifer Jacob's work if you haven't seen it yet http://web.media.mit.edu/~jacobsj/#_research

@stevekrouse Thanks for the link to Jennifer Jacob: it looks quite relevant.