When I was working on a natural language processing system at Johns Hopkins during the summer of 2005, I remember having a minor epiphany: I realized that the strategy our research team was using was essentially just a way of converting an intractably complex problem into a series of computable smaller problems. It didn’t take me long to make the jump to realizing that this is an essential part of all science and engineering.
I was reminded of this when watching a Steve Jobs video recording from 1997 (via daringfireball). Steve is talking about why he thinks better developer tools and APIs are so important to progress (around 25 minutes into the video):
It’s all about managing complexity. It’s like scaffolding, right? You erect some scaffolding and if you keep going up and up and up, eventually the scaffolding collapses of its own weight. That’s what building software is. It’s how much scaffolding you can erect before the whole thing collapses of its own weight. It doesn’t matter how many people you have working on it — doesn’t matter if you’re Microsoft, with 500 people on a team — it will collapse under its own weight.… These [new developer tools] allow you to not have to worry about 90% of the stuff you worry about, so that you can erect your 5 stories of scaffolding, but starting at story number 23 instead of starting at story number 6. You can get a lot higher.
This is related to the fundamental notion of abstraction, and to “the mythical man-month” (which Steve also references). It’s a good reminder.
In a related section, Steve responds to a question asking about how visual programming tools might fit into this. His answer (around 42 minutes in):
Here’s the deal. The way you get programmer productivity is not by increasing the lines of code per programmer per day. That doesn’t work. The way you get programmer productivity is by eliminating lines of code you have to write. The line of code that’s fastest to write, that never breaks, that doesn’t need maintenance, is the line you never had to write! So the goal here is to eliminate 80% of the code that you have to write for your app. That’s the goal. So along the way, if we can provide vizi-this and vizi-that and visual this and visual that, well that’s fine, but the high-order bit is to eliminate 80% of the code. When you ‘draw the line’ in interface builder, you’re eliminating code of one form. But that only goes so far. Maybe we can go further. I’ve seen a lot of demos of things that try to take it all the way back into the algorithmic part of the codebase, and none of them have ever been any good. If there are any good ones out there, show them to me — I’d love to see them.
In other words, abstraction is far more important to productivity than whether a language is visual or textual. Making languages visual is only a win if it can help solve the “higher order” issues: bugs, maintenance, and complexity. Steve’s 1997 claim is that he has not seen compelling demos of this in the visual programming space.
I think this is crucially important to keep in mind when thinking about visual programming languages that could be generally adopted. They have to provide an advantage in terms of abstraction. It seems that so far the opposite has been true: abstraction has been the main weakness of visual programming systems.