Visual programming means anyone can be a coder(newscientist.com)
newscientist.com
Visual programming means anyone can be a coder
http://www.newscientist.com/article/mg21528796.800-visual-programming-means-anyone-can-be-a-coder.html
18 comments
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.
Manifesto of the Programmer Liberation Front: http://alarmingdevelopment.org/?p=5%252523comment-151
About time!
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?
Yet another headline totally unsupported by the original source.
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.
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.
I think they're both just general terms that are roughly analogous. I think coder and [moreso] scripter both seem just ever so slightly negative, though that may be a subconscious association with terms like 'code monkey' and 'script kiddy.'
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 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.
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.
It would indeed be great to have some "higher bandwidth" way to interact with a program under development. And better graphical tools could clearly increase the bandwidth out from computer to programmer.
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.
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.
Depends on the language. Writing boilerplace C++ header files, which duplicate everything in the source is certainly a low-yield way to communiate with a computer.
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.
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'd suggest you learn how to touch type if you care about getting stuff out of your head fast.
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.
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.
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.
Except KISMET doesn't scale well. When I see the baroque contraptions game designers create it makes my blood boil at the inefficiency but that's the cost of a faster design->code turnaround. Runtime efficiency sacrificed for development time savings.
Part of that however is a symptom of Kismet's current implementation. I imagine an improved Kismet will greatly improve things.
As far as I understood him, some of the performance problems also stem from overly complex implementations by level designers. But I guess the big advantage of KISMET is that is allows level designers to do logic _at all_ without reading into the finer details of UScript or the scripting language at hand.
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.
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.
A huge cause ause of the overly complex implementations by level designers is a direct result of problems with Kismet. For instance, I had to put together a 5 node system just to compare two bools for equality.
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.
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 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".
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.
Except that bad LabView code takes spaghetti code to a whole new level: http://img.thedailywtf.com/images/201104/labview.jpg
Except that bad LabView code takes spaghetti code to a whole new level: http://img.thedailywtf.com/images/201104/labview.jpg
Indeed! I've seen stuff much like that. Not pretty. A prefect example of why visual programming is no silver bullet.
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.
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.
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:
http://recursivedrawing.com/draw.html
Not so sure that it will really "democratize programming"
http://recursivedrawing.com/draw.html
Not so sure that it will really "democratize programming"
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?
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 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.
Though I think we should keep trying.
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 met with Bret Victor for lunch while visiting SF a few years ago and I specifically argued against visual programming languages making anyone able to program. I mean I know that some people are more inclined to think in blocks and visual metaphors (Hell most programmers draw out ideas constantly cause we do too) but any sufficient program eventually gets complicated enough that visual programming kind of breaks down unless it gets more and more abstract to make reusable components and modules that you can navigate too etc. I pushed at the time and I'm not even sure he remembers at this point but for augmenting text based programming and making what's happening more visual and real-time. Which seems to be some of the direction he's taking which is combining his great ideas in visualization with traditional text based programming environments. I was also a huge fan of Javascript as the lingua franca despite it's deficiencies because web based IDEs and examples were inherently so much more shareable than code you had to download and try (There could be ways around this such as a desktop repository of code viewer, but that's a friction point to people actually checking out demos/examples interactively ala JSBin as such.)
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.
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.
Intuitions and anecdotes are fine, but there is actual research on visual programming languages, as well as on computer science education.
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).
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).
Some people are helped by visual metaphors. Others learn by hearing; other by reading.
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.
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.
Actually a lot of research over the past few decades has shown there is not really evidence for 'learning styles' - that one person might be a visual learner, and another an auditory learning, and so forth.
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.
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.
Oh come on - I personally know people who've hired readers in college because they absorb more efficiently through hearing it spoken aloud. Others despise pictures - they want written descriptions. Some the other way around.
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.
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.
Just listened to a Herding Code interview with a guy who was using APL to get domain experts programming.
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.
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.
Unlike the "workflow systems" you mention, non-programmers make audio-visual art using Max/MSP/Jitter and kids make stuff using Scratch/BYOB. Both have been rather successful in engaging non-programmers of various age groups. So we do have evidence of "visual" interactive programming working well for some people.
I don't deny it's a useful learning tool, my first exposure to programming was a Turtle robot you could program to draw stuff when I was 5 or 6!
It's just a very, very long distance yet from producing the kind of code that we all produce day-to-day now.
It's just a very, very long distance yet from producing the kind of code that we all produce day-to-day now.
I'm not sure what "kind of code that we all produce day-to-day" you're referring to, but Max being priced at $400 per license suggests it isn't only a "useful learning tool". Do checkout http://cycling74.com and see whether the long distance could be the other way for these kinds of applications.
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.
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.
I guess I tend to think about it like this: is the current state of the art for programming the best that we can ever do? If the answer is "no" (which it most certainly is), then what does the future look like? Great strides have been made in shortening the "edit, compile, run, test" feedback loop because it's recognized that this saps creativity and flow the longer the amount of time it is. The natural progression of that is instantaneous feedback (excitement about Christ Granger's Light Table shows this).
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.
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.
Any programming paradigm is going to at minimum have something like an if statement.
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.
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 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. :)
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. :)
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.
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.
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.
Alan Kay means anyone can be persuasive, but wrong.
Nothing against the artist or his project (which sounds kind of cool), but really, the title of the NS article is kind of ridiculous, now isn't it:
"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..."
"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..."
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.
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.
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 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).