
Visual programming means anyone can be a coder - ukdm
http://www.newscientist.com/article/mg21528796.800-visual-programming-means-anyone-can-be-a-coder.html
======
JunkDNA
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?

~~~
mattmanser
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
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.

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

~~~
JoeAltmaier
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.

~~~
edtechdev
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.

~~~
JoeAltmaier
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.

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

------
recursive
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
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?

------
angdis
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
> 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>

~~~
angdis
Indeed! I've seen stuff much like that. Not pretty. A prefect example of why
visual programming is no silver bullet.

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

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

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

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

~~~
ef4
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.

~~~
JoeAltmaier
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.

------
cygwin98
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
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
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.'

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

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

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

------
Sandy_Klausner
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
Manifesto of the Programmer Liberation Front:
<http://alarmingdevelopment.org/?p=5%252523comment-151>

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

------
jeremyjh
Yet another headline totally unsupported by the original source.

------
vegas
Alan Kay means anyone can be persuasive, but wrong.

------
chartburst
About time!

~~~
Sandy_Klausner
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?

