6 ms·

Visual programming means anyone can be a coder

24 points by ukdm 14y ago

chartburst 14y ago
About time!
- Sandy_Klausner 14y ago
  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?
jeremyjh 14y ago
Yet another headline totally unsupported by the original source.
cygwin98 14y ago
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?
- eslachance 14y ago
  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.
  - zevyoura 14y ago
    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.'
- freehunter 14y ago
  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.
recursive 14y ago
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.
- supar 14y ago
  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?
Paul_S 14y ago
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.
- delinka 14y ago
  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.
  - yxhuvud 14y ago
    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.
  - ef4 14y ago
    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.
    - 14y ago
angdis 14y ago
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".
- freyrs3 14y ago
  > 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 http://img.thedailywtf.com/images/201104/labview.jpg
  - angdis 14y ago
    Indeed! I've seen stuff much like that. Not pretty. A prefect example of why visual programming is no silver bullet.
unwind 14y ago
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.
EzGraphs 14y ago
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 http://news.ycombinator.com/item?id=3951255). It's kind of mind-bending from a UI standpoint. See: http://recursivedrawing.com/draw.html http://recursivedrawing.com/draw.html Not so sure that it will really "democratize programming"
JunkDNA 14y ago
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 http://youtu.be/PUv66718DII) combined with his excellent 2006 paper that digs into related concepts (http://worrydream.com/MagicInk/ 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?
- mattmanser 14y ago
  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.
  - endergen 14y ago
    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 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/ 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.
S_A_P 14y ago
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. :)
ef4 14y ago
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.
lifeisstillgood 14y ago
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.
vegas 14y ago
Alan Kay means anyone can be persuasive, but wrong.
toomuchcoffee 14y ago
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..."
zackmorris 14y ago
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.
twelvechairs 14y ago
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).
Sandy_Klausner 14y ago
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.
Sandy_Klausner 14y ago
Manifesto of the Programmer Liberation Front: http://alarmingdevelopment.org/?p=5%252523comment-151 http://alarmingdevelopment.org/?p=5%252523comment-151

24 points by ukdm 14y ago

chartburst 14y ago

About time!

Sandy_Klausner 14y ago
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?

jeremyjh 14y ago

Yet another headline totally unsupported by the original source.

cygwin98 14y ago

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?

eslachance 14y ago
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.
- zevyoura 14y ago
  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.'
freehunter 14y ago
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.

recursive 14y ago

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.

supar 14y ago
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?

Paul_S 14y ago

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.

delinka 14y ago
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.
- yxhuvud 14y ago
  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.
- ef4 14y ago
  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.
  - 14y ago

angdis 14y ago

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".

freyrs3 14y ago
> 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 http://img.thedailywtf.com/images/201104/labview.jpg
- angdis 14y ago
  Indeed! I've seen stuff much like that. Not pretty. A prefect example of why visual programming is no silver bullet.

unwind 14y ago

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.

EzGraphs 14y ago

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 http://news.ycombinator.com/item?id=3951255). It's kind of mind-bending from a UI standpoint. See: http://recursivedrawing.com/draw.html http://recursivedrawing.com/draw.html Not so sure that it will really "democratize programming"

JunkDNA 14y ago

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 http://youtu.be/PUv66718DII) combined with his excellent 2006 paper that digs into related concepts (http://worrydream.com/MagicInk/ 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?

mattmanser 14y ago
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.
- endergen 14y ago
  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 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/ 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.

S_A_P 14y ago

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. :)

ef4 14y ago

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.

lifeisstillgood 14y ago

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.

vegas 14y ago

Alan Kay means anyone can be persuasive, but wrong.

toomuchcoffee 14y ago

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..."

zackmorris 14y ago

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.

twelvechairs 14y ago

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).

Sandy_Klausner 14y ago

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.

Sandy_Klausner 14y ago

Manifesto of the Programmer Liberation Front: http://alarmingdevelopment.org/?p=5%252523comment-151 http://alarmingdevelopment.org/?p=5%252523comment-151