We don't have a lingua franca for diagrams like we do for text files.*
What is UML, then? If you feel stuck with this then maybe you need to look outside the text = code bubble and get some input on tool design from other sources. I agree that text is a convenient serialization and storage format, but it's a terrible design and analysis medium.
I mean, consider CSound, which is a tool for writing music with computers that has a venerable heritage going back to the 1970s. You have one set of code for defining the charactersistics of the sound, and another for defining the characteristic of the ntoes you play with those sounds: http://www.csounds.com/man/qr/score.htm and http://www.csounds.com/manual/html/index.html
CSound is a moderately good teaching tool, and given its heritage it's an impressive piece of technology. But nobody writes music in Csound except a few computer music professors and the students in their departments that have to do as part of their assignments, and 99% of music composed in CSound is a) dreadful and b) could have been done much faster on either a modular synthesizer or with Max/MSP. Electronic musicians feel the same way about CSound that you as a programmer would feel about an elderly relative that keeps talking about when everything was done with vacuum tubes and toggle switches...you respect it but it seems laughably primitive and has nothing to do with solving actual problems. The very few people that need low-level control on specific hardware platforms work in C or assembler.
I think this is pretty relevant here because one of Bret Victor's more impressive achievements is having written some very impressive operating software for a series of synthesizers from Alesis. I'd be pretty astonished if he even considered CSound for the task.
Far from being stuck in a bubble, I actually spent a couple years developing code in a UML-driven development environment (as in, I spent my days drawing UML diagrams that automatically turned into executable code). First of all, you cannot write any nontrivial program in UML alone. It is not nearly specific enough. UML is to a working program as a table of contents is to a technical manual. And in case you think I'm extrapolating from one bad experience, I've also used LabView have seen the parallel difficulties in that language.
Now, I agree that higher levels of abstraction will be needed in the future, but I disagree that visual programming is an obviously superior abstraction. In fact, I believe that people have been earnestly barking up that tree for decades with little success for reasons unrelated to old-fashioned attitudes. There are practical and technical reasons why developing visual programming tools and ecosystems will always be more difficult than developing text-based ones.
Take merging for example. Merging two versions of a source file is many times over a solved problem (not that there aren't new developments to be made). In contrast, merging two versions of a UML diagram is very much a manual process (to the extent that it's possible at all). Now consider creating a change management tool allows you to branch and merge UML diagrams. This is orders of magnitude harder yet. These are essential and straightforward use cases that are much more complex in a visual medium. Without these basic features, visual programming will not scale well to even medium-size teams.
I can go into more detail about issues with visual programming if I still haven't made my case. And I would love to hear from people with visual programming experience that have contradicting opinions. It's always possible that I missed something.
I appreciate the additional context and totally get where you're coming from. The only nitpick I'd make is this:
Merging two versions of a source file is many times over a solved problem
Granted - but isn't this also a limiting factor? It's not that I don't think anything should ever be reducible to code form, but why is that visual mapping of a complete program isn't a standard everyday tool? I mean, it's all very well that we have syntax highlighters showing keywords, variables and so on, but why is it that when I open a program there isn't a tool to automatically show me loops, arrays and so on?
Loops are one of the simplest programming structures; 90% of loops look like:
LOOP foo FROM bar to baz:
something
something
something
profit
foo = foo + 1
END LOOP
I mean, software engineering shouldn't be about syntax, it should be about structure, and yet there don't seem to be many tools around that open up a source file and build branching diagrams and loop modules automatically. Why is that? Why don't we even have structural highlighting rather than syntax highlighting?
Can you elaborate. I see the structure, in the indenting. My IDE (Visual Studio) has little lines and + boxes that allow me to collapse and expand code like this. It's useless, because the most part I kind of care what "something" is, and the collapse is not replaced with a nice pseudocode "frange the kibbleflits" statement. I have tools that can generate diagrams showing me class hierarchies, call stacks, and so on. I rarely (almost never) find the useful. Maybe you have something different in mind?
A mischaracertization. Software like Reaktor is extremely successful in its domain and widely deployed: http://www.native-instruments.com/en/products/komplete/synth... as is Max/MSP: http://cycling74.com/videos/product/
We don't have a lingua franca for diagrams like we do for text files.*
What is UML, then? If you feel stuck with this then maybe you need to look outside the text = code bubble and get some input on tool design from other sources. I agree that text is a convenient serialization and storage format, but it's a terrible design and analysis medium.
I mean, consider CSound, which is a tool for writing music with computers that has a venerable heritage going back to the 1970s. You have one set of code for defining the charactersistics of the sound, and another for defining the characteristic of the ntoes you play with those sounds: http://www.csounds.com/man/qr/score.htm and http://www.csounds.com/manual/html/index.html
CSound is a moderately good teaching tool, and given its heritage it's an impressive piece of technology. But nobody writes music in Csound except a few computer music professors and the students in their departments that have to do as part of their assignments, and 99% of music composed in CSound is a) dreadful and b) could have been done much faster on either a modular synthesizer or with Max/MSP. Electronic musicians feel the same way about CSound that you as a programmer would feel about an elderly relative that keeps talking about when everything was done with vacuum tubes and toggle switches...you respect it but it seems laughably primitive and has nothing to do with solving actual problems. The very few people that need low-level control on specific hardware platforms work in C or assembler.
I think this is pretty relevant here because one of Bret Victor's more impressive achievements is having written some very impressive operating software for a series of synthesizers from Alesis. I'd be pretty astonished if he even considered CSound for the task.