If you are a skeptic on this, I really urge you to listen to Bret Victor. I have generally been skeptical of these kinds of things in the past, but just in the last week Bret Victor's talk (http://youtu.be/PUv66718DII) combined with his excellent 2006 paper that digs into related concepts (http://worrydream.com/MagicInk/) has made me re-think that position.
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?
I'm skeptical because I don't see how visual programming models are even possible for the type of development I routinely perform (my day job is writing a high-performance distributed, parallel implementation of the well-known 'make' tool). Even if it is theoretically possible, for some parts of my project, I imagine it would take nearly as long to create the visual programming environment, and I'm not sure it would be particularly reusable.
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.
I'm skeptical because I remember the RAD tools of the early 00s that were going to let businessmen program.
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.
I first got into programming using Hypercard on the machines at my middle school. I started out just visually building simple stacks that didn't really do much, until a teacher showed me some of the stuff older kids had built by manipulating the Hypertalk language underneath. It was like learning about the Matrix. I looked at what they did and copied it for my own stuff, eventually learning a significant portion of the Hypertalk language. Fun times.
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.
Because since everyone can hold a pencil or paint brush, everyone can be an artist!
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.
The essential difficulty in programming is not to do with syntax. That's just the first thing an "outsider" sees that makes it seem unapproachable. The programming-for-the-rest-of-us thing has been tried more than a few times. Outside of specialized domains, I don't think it has ever gone anywhere.
Also, "visual languages" even when restricted to very specific domains (think of DSP blocks, a tried&tested domain where visual languages are abundantly abused) tend to get very messy already when only very simple logic is involved. I wouldn't classify simple IFS systems in recursive painting programs to be "programming" at all. Where's branching, for instance?
I think that exploring alternative ways of creating programs is an excellent worthwhile activity. But while it might "open up" programming as discipline for _some_ people that would otherwise not do it, it doesn't follow that "everyone" will be able to program.
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".
> 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.
I think that VB6 was probably one of the most productive programming environments ever, until a project grows larger than a couple of business rules. You cant deny the immediacy of dragging a text box, a button and some other controls onto a form and having an "instant" application to automate things.
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. :)
When I hear "visual programming" I tend to think of Microsoft IDEs or GUI drag-and-drop tools, but this article cites a really interesting project posted previously to HN (http://news.ycombinator.com/item?id=3951255). It's kind of mind-bending from a UI standpoint. See:
We do not need to invent visual programming languages that will "encourage" people to program. Most people are quite capable right now.
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 don't think the audience for this exists. People with a mind capable of programming are also capable of learning syntax, especially since there are so many languages now with lightweight syntax. I fear these attempts shall remain confined to educational toys for kids, which are really cool, but I don't see them used widely in schools.
I'm a programmer. I started learning syntax as a kid. I write code all the time. I adapt to new language concepts and syntax. I can use vim effectively. I can tolerate an IDE.
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.
Isn't KISMET (http://www.unrealengine.com/features/kismet/) an example that there is a real need for that? Game scripts are definitely non-trivial, but they are not that complex either. Also, in the case of KISMET, the programming involved is flow-oriented, where visual representations might definitely give you more clarity.
May be a bit off topic. But I do notice that those people who are not tech-savvy or totally computer illiterate tend to use the term 'coder' a lot to refer to us who can program. Is there a subtle difference in meaning between a 'coder' and a 'programmer'? Or is just myself being a bit over-sensitive?
Personally (and in my circles) the term coder refers to someone who writes code, whereas the term programmer refers to someone who actually designs and executes their application development as a structurally trained computer programmer.
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.
Perhaps people see "coder" as a larger term encompassing programmers (where "program" would be an application), scripters (things like javascript, php, python) and maybe hackers? I'm not sure.
What I think is missed by a lot of people here is the opportunity for 'visual programming' to help with visual tasks, which is a lot of what people do on computers (making games, CAD, maps/GIS, images, 3d models, etc.). It will help because at the moment there's no way to 'see what you are doing' and code/program it at the same time in any of these areas in a realtime way. When this changes it will cause massive ramifications through these industries.
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).
I remember the first time I learned Excel after graduating college with a Computer Engineering degree from UIUC. When it finally clicked for me what functional programming actually did, how every problem can be reduced to a series of relationships, I looked back on my computer sciences classes and thought WTF.
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.
Jonathan Edwards of MIT's CSAIl published a Manifesto of the Programmer Liberation Front a while back that makes an interesting case for exploring alternatives like graphical programming for replacing text-only languages.
The real value in tools like these is pedagogical. They don't replace "real" programming, but they may introduce a wider audience to the concepts needed to do real programming.
Alan Kay and others pioneers brought us object-orientation almost 40 years ago now, a set of organizing abstractions to enable people to conceptualize systems that could map to real world domains. What if there are even a higher order of abstractions that could place systems into semantic contexts? Perhaps this is where graphical abstractions could be useful to manage this complexity through visual constraints, thus transition the software engineering 'art' towards a true systems engineering 'discipline.' What fundamental properties restrict software engineering from such higher order tool evolution considering that visualizations have been applied to virtually every other scientific, business, and art domain?
[+] [-] JunkDNA|13 years ago|reply
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?
[+] [-] emelski|13 years ago|reply
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.
[+] [-] mattmanser|13 years ago|reply
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.
[+] [-] bluedanieru|13 years ago|reply
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.
[+] [-] unwind|13 years ago|reply
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.
[+] [-] recursive|13 years ago|reply
[+] [-] supar|13 years ago|reply
[+] [-] angdis|13 years ago|reply
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".
[+] [-] freyrs3|13 years ago|reply
Except that bad LabView code takes spaghetti code to a whole new level: http://img.thedailywtf.com/images/201104/labview.jpg
[+] [-] S_A_P|13 years ago|reply
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. :)
[+] [-] EzGraphs|13 years ago|reply
http://recursivedrawing.com/draw.html
Not so sure that it will really "democratize programming"
[+] [-] lifeisstillgood|13 years ago|reply
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.
[+] [-] Paul_S|13 years ago|reply
[+] [-] delinka|13 years ago|reply
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.
[+] [-] Argorak|13 years ago|reply
[+] [-] cygwin98|13 years ago|reply
[+] [-] freehunter|13 years ago|reply
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.
[+] [-] eslachance|13 years ago|reply
[+] [-] twelvechairs|13 years ago|reply
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).
[+] [-] zackmorris|13 years ago|reply
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.
[+] [-] toomuchcoffee|13 years ago|reply
"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..."
[+] [-] Sandy_Klausner|13 years ago|reply
[+] [-] Sandy_Klausner|13 years ago|reply
[+] [-] ef4|13 years ago|reply
[+] [-] jeremyjh|13 years ago|reply
[+] [-] vegas|13 years ago|reply
[+] [-] chartburst|13 years ago|reply
[+] [-] Sandy_Klausner|13 years ago|reply