Visual programming means anyone can be a coder
newscientist.com
newscientist.com
One of the key points in his talk that made me think about this more is that there are whole avenues of exploration that are completely inaccessible when the feedback loop is as long as it is with current programming techniques.
I think it depends highly on the kind of programming you do. The more closely related your programming is to math (e.g. engineering simulations or stats), the less likely you are to see an issue because you're directly manipulating the "stuff" you're working on. But if you write software that operates more in the human space (e.g. something like an email client), then you're acutely aware of how far removed the code is from the user and what the program does. You basically have to keep a giant mental model in your head as you code. That is a huge cognitive load that all of us take for granted as part of "programming" but why must this be so?
Oh, and who can forget the wonderful workflow systems that were all the rage soon after? There seemed to be a new one released every week.
I invite you to go try MS's WWF, that's 'visual'. What a nightmare that is.
They don't work. You need a programmer involved because edge cases rapidly become complicated and that's the hard bit, not visualizing a workflow. And these tools deprive you the programmer of the fine grained control you sorely need or worse generate code that's so hard to read and work with that it's faster coding from scratch even for amateurs.
I love Bret Victor's vision, but because of what it means for programmers, not the fuzzy 'creatives' in the article. I know some animation guys and yes, you can visually automate things like animation now, but logic flow? No.
Though I think we should keep trying.
I'm personally loving what Kahn academy is doing that John Resig credits Bret Victor's talk on Inventing on Principle (http://vimeo.com/36579366) as a major inspiration. See article where he announces and explains their in browser interaction learning of CS course material: http://ejohn.org/blog/introducing-khan-cs/
In closing to name a view limitations of most visual programming languages: the naming problem (Most parts of your system need to be named in order to be able to talk about them), text based is stronger at this. Instantiation of reuseable code is pretty abstract to do visually. Eventually all programming gets complicated enough that text based approach really is easier to work with. Not to mention all the tools you can't leverage comparitvely to text based such as version control, REPLs, etc. I guess I think visual programming is idealized and people are spending all this time learning something that isn't as useful to know in the long term compared to traditional programming because all the important platforms have much richer support for text based programming (iOS, linux, C/C++ for games). But combining visualization of code execution is the perfect balance and would lead to basically replacing much commenting with an actual intuitive visualization of runtime complex structures/state. And definitely real time feedback of tuning /visual parameters is great. In the game industry all of this is very standard and I do feel there is a little more awe for his work than would be given by your typical graphics, art tool, or demo scene programming devs. Most game development toosl for say level editing and animation are all highly visual and real time interactive. Same goes for any serious AI dev they have debugging tools for visualizing all planning for entities communication, path planning, animation states, and more.
Anyway, just my thoughts. Still think Bret Victor is one of the most compelling thinkers in this space.
He had a very interesting and elegant solution to the problem: You let the domain experts take charge of implementing their domain logic. But as soon as you hit a point where what they're doing needs to be shared with the rest of the company, you bring in a software engineer to sit down with them and review the code. They take charge of making sure it's robust and reliable, and work with the domain expert to refactor it into something that will be more maintainable.
That seemed like a reasonable solution to me. And the thing that was striking was that he wasn't doing it with any newfangled visual languages or anything like that. It's already being done successfully in a business environment using APL.
Visualizations, animations, and metaphors do help beginners learning programming and understand programming concepts. Scratch is currently probably the most well known tool for beginning students to use for programming (used with kindergartners all the way up to college freshmen).
And then there was that thread about some people never, ever 'getting it' and being as hopeless after a semester class as the first day. I've even met folks who, after years of computer classes, still hadn't figured out that code is executed in sequence.
Learning isn't just about sensing (hearing, viewing), anyway, it is more about action. What are the students actually doing, and what can students do with a particular tool. Actually everything we perceive is tied to what we do (see: enactivism, embodied cognition, ecological psychology).
Many students aren't 'getting' programming in CS classes partly because it is not taught well (if instructors switched from lectures to active learning techniques, student retention and learning might double or triple, based on research in other domains), partly because the tools themselves are not designed especially well or are not designed with beginners in mind (including python and java), partly because it is often taught devoid of any context (see, situated learning and situated cognition), partly because of low student self-efficacy (what you mentioned - thinking they just can't learn this stuff), and tons of other reasons.
Rationalize it any way you want - they learn faster and better one way than another, measurably.
And about bad teaching: the whole class gets it, but a few. The teacher is clearly not addressing their needs, but they are also clearly not doing it 'wrong' - many do understand just fine.
It's just a very, very long distance yet from producing the kind of code that we all produce day-to-day now.
As such, I think 'visual' programming might be great to rope people in, but it isn't enough. Had I not taken it to the next level, I would have gotten bored, simply because I couldn't do that much with the tools I knew about. Drilling down a bit was hard, but necessary. In the case of Hypercard, of course I had to drill down because the tools for putting together complicated stuff visually weren't there. But, there is a reason they weren't there, that being that Hypertalk, while having a steeper learning curve than buttons and slides, was a more efficient and concise way to represent more complex stuff.
There's really no way around that. At its best, visual programming can be a way for non-programmers to put together really, really, simple stuff that they think they need. (It can be much worse than this, I've worked with a framework that was originally designed for this purpose or something like it, for middle office banking software - worse 18 months of my fucking life, and the worst part was none of the non-programmers it was originally targeted towards would go near it.) For everything else we need more robust tools.
And let's not forget that the hard part of programming isn't even the syntax anyway. It's the concepts. Even if you could design a visual programming 'language' just as rich as any text-based one, anyone who wanted to do anything with it would still have to learn all the same concepts. And that's the hard part.
Once you have instantaneous feedback, the next logical step is some kind of direct manipulation. Visual programming (at least as currently imagined) may not be the right kind of direct manipulation, but there simply has to be a better way than typing text in one window and seeing the output in another.
I think lots of the comments here are thinking too much about visual programming metaphors that have been bolted onto existing programming paradigms. I suspect those are clunky because existing programming paradigms are clunky when represented visually. I'm not sure that means that in the universe of possible programming paradigms, there doesn't exist some form that is better when represented visually.
Say you wanted to do something when two items compare equal, in text you could write something like: if (a == b) { ... }
With a visual metaphor, you are going to have to have some way of setting up entities representing the 'if', and the '==' predicate, along with references to wherever 'a' and 'b' are defined, and a way of getting to the block of code that executes when the condition is true.
I find it hard to conceive that any kind of direct manipulation of code at this level is going to be better than text, whether you're trying to understand it or modify it.
I grant you visual tools for manipulating higher level stuff like data schema's, gui's, and so forth work well, but I'm guessing they'll always need text for the underlying logic.
I loved Bret Victor's talk. And this recursive drawing thing is neat too. But both of those are dealing with programs that are primarily visual in their own output. I can't help but think, "That's neat, but not broadly applicable." Honestly, how many people are there out there dying to write programs to make fractal-like pictures?
Perhaps I'm just not visionary enough to see the potential, but I don't believe these techniques will really "democratize programming." Whether or not doing so is desirable in the first place is another debate altogether.
That's obviously true, but the emphasis must still be on the "can". There's nothing stopping you, but there never was. The difficulty in programming is not writing words, it's understanding what the machine can do and how you can use that to do what people want to get done.
LabVIEW is an example of a visual programming language that has been around for 20+ years. It is very popular in manufacturing test and laboratory applications. It was supposed to make certain kinds of programming accessible to non-programmers. Did it do that? To some extent, yes. However to do anything even remotely large or complex with it you're still stuck with the same old problems of software development that the general public sucks at. The best LabVIEW "programmers" _are_ "programmers".
Except that bad LabView code takes spaghetti code to a whole new level: http://img.thedailywtf.com/images/201104/labview.jpg
I've used a variety of "visual" tools for designing everything from ETL tools to synthesizers. They are great for POC designs, but I generally find them difficult to use for the complex stuff. Configuration and properties and logic are much more suited to code in my very biased opinion. :)
http://recursivedrawing.com/draw.html
Not so sure that it will really "democratize programming"
Its motivation that matters - and until it is taught to 5 year olds as a matter of course, then seeing the world eaten by software will provide motivation enough.
Imagine you lived next door to that Gutenberg guy and his new-fangled press. You would want to be learning to read now - not waiting for someone to invent the comic.
I still cannot get ideas out of my head and into the computer as fast as I "need" to. I believe something graphical, visual, or the like is going the right direction. I want graphical touch programming (not typing syntax) for organizing logic into programs but I need the power to manipulate details.
To me, it's not a question of ability to learn syntax, it's about speed- how fast can I get this great new idea into an app? I believe ultimately it will be by manipulating objects on a touchscreen or in some 3D holographic thing.
Just because it has a graphical interface doesn't mean the process of telling the computer what to do will be faster. The reason for this is simple - there are still just as much stuff you need to tell the computer for it to be able to do what it must.
But for bandwidth into the computer, there's still nothing that can compete with text. Consider the space of meaningful words you can type at 100wpm, and how awkward it would be to offer a similar number of choices at a similar speed on two (or even three) dimensional display.
Graphics could help there; let me drag methods up and down the hierarchy and have it automatically refactor (change arguments and scope of references without me typing). Create new fields with a right-click and choose a type with a default name; drag a reference to a closure etc.
Even this: if I could navigate different views on the same source e.g. without comments; without debugging prints and asserts; with references and scopes delineated. This can make it faster to find where to type. But I guess thats bandwidth out again; ok.
I must admit, my only experience with level building was some amateur work in UnrealEdit - the original, 1998 one. And there, I found triggers and stuff really annoying.
Additionally UnrealScript isn't really made for "scripting" particularly not for the level. For instance, the whole game/editor needs to be shutdown/reloaded to recompile scripts. In that sense it's much less script and much more virtual machine'd language with gameplay specific features.
I write code at work. But it's one-off or personal use programs, mainly scripts to automate some repetitive or mathematical task I don't want to do by hand constantly. Contrast this with our development staff, who write code used by their customers (internally and externally), follow a program design model, conduct meetings to discuss the program, do code review, and attend application development council meetings to make sure all the disparate programmers at the company follow the same design/development principles. They program for a living, and it's serious business. My code merely makes my job easier, but I could work without it.
I can bang out five lines or five hundred lines in any language I want, any design I want, any amount of bugs I am willing to accept, and without approval or review by anyone. I think it's important to differentiate between those who actually program and those who merely write code.
I do agree though that the title is a ridiculous assertion though (because everyone can already program, and visual programming is in no way going to stop people from having to become domain experts to do anything really interesting).
So flip the concept on its head: writing imperative code with lines of characters means that almost nobody can be a coder.
After wasting most of my life chasing bugs down rabbit holes, I can honestly say that I'm not joking. Visual programming may suck now, but someday it's going to run circles around the crap we're stuck with today.
"Visual interfaces for writing musical notation means anyone can be a composer."
"Drag-and-drop interfaces for text composition means anyone can be a writer."
"Magnetic poetry kits on every kitchen refrigerator door mean..."