Skip to main content

The Narratives Around Visual Programming

We need to train new developers, and we need to make programming approachable by more people, if only to get their attention before they dive deeper. I'm not speaking anything new hear, but I think there are some gaps in many of the common narratives.

Narrative 1: We need to teach kids and more adults to program


I agree! We need to get the attention of adults who might be interested in a career change, and we need to capture the imagination of children who can grow up and build the future software ecosystems we'll use in our retirements.

But there is a gap in this narrative, between the learning to code and the actually being an active experienced developer.

At least in many of these cases, education is given in some more approachable fashion, but it isn't given in a way that a clear path exists from start to finish. We hook them, and then we rely on a common trait of developers to get them through the harder bits. I'm going to use Python and games as an example, because it is a common one. The Young Coders class is amazing, but I have a big problem with it: we are setting these children up for major frustration and major disappointment. We teach them to code in a wonderful language, on a great environment that fosters creativity and experimentation. We give them a comfortable start that pulls them in, hooks them, and sets them on a path to self driven education beyond all the course material.

They're going to leave these classes, already sold on everything they learned, and realize they can't send these games to their friends easier. They want to brag, and we won't let them. We've made it harder on them. "Just go install Python, and PyGame, oh and PyOpenGL because i used that, too. Then unzip my game and it should run!" they're going to tell their friends, who will look at them strangely.

We can't start developers on a path with these kinds of walls.

Either we need to break down those walls (make distributing Python projects with binary dependencies easier!) or we need to start them down a different path (like web-based coding).


Narrative 2: UNIX vs IDE Culture


The war is old and the battles have been fought over all sorts of territory, from compiler performance to language preferences to testing methodologies. But, what is the distinction between these two mindsets is really only beginning?

I have been firmly in the UNIX school for a long time, but i'm not stranger to IDE culture, either. I started my programming education with a stack of books from the library and seven Borland C++ floppies from my cousin (software piracy for the 90s), before upgrading to an actually purchased copy of Visual Studio 6.0, for I still have all my installation media.

The narrative in this divide is between a developer who gets his hands dirty and developers who let's the machine do the gritty parts for them. The UNIX developer says the IDE devotee doesn't actually understand what goes on "under the hood". The IDE developer says the UNIX devotee wastes their time doing things manually and using under-powered tools. But, both of these groups see themselves as developers, and the others as "devotees", tied hopelessly to their weird tools against all practical arguments.

If you ask a Python developer what a kid should use when getting started, they aren't going to start talking about Git, VIM, or writing setup.py files. They'll mention IDLE, where a student can naturally shift from playing in the REPL to saving a script to run against later. Where a natural progression will exist from those first steps to writing a little game they save and run again when a friend is near. But we don't look at IDLE as a "real" tool. For the most part, we only look at it as a toy. No Python developer I know looks at IDLE as a serious development tool that anyone should continue using past the learning stage.

And this is basically how many of them look at IDEs and IDE culture, as well. "Grow up and learn the command line options for the tools your GUI has been hiding from you!" they'll say. And there is an idea of power in this, that the IDE devotee is missing out on a deep well of powerful tools and options at their finger tips. We'll make this claim, and then go back to our garbage-collected, run-time compiled, dynamically-typed language.


Narrative 3: Visual Programming is a Silly Toy


While seen usually as a novelty, there are actually a huge number of visual programming options around. The thing is, they exist with a very two sided attitude from traditional developers. On the whole, they are seen positively within specific contexts of learning and education, but completely disregarded when suggested for "serious work". You can see this mirrors the narrative from UNIX developers towards IDE developers, and yet this attitude is common in both camps.

Effectively there are no "real developers" who consider visual programming viable for what they would call "real programming".

But who are the real developers and who gets to make that distinction? What is real programming and how do we identify "toy programming"? These aren't clear, and they serve largely so "other" approaches we don't like, often for fairly emotional reasons more than clear and practical ones.

It is true, there are obvious and often stark differences between a stable, mature C codebase and a project file in Scratch. Clearly, these are two very different things. But, we don't need to extrapolate from this that all text-coded programming is inherently better than any graphical-coded programming. We need to recognize a cross over, and when we do we'll enable that intersection to grow.

Good IDEs and good toolsets are important, and visual programming may be an extension of that. If this is the case, we may continue to prefer our own style but we are being dishonest if we don't label it as another camp in the same woods.


Conclusion: Abstractions like visual programming are poised to seize new ground


Look around you and you're going to see the writing on the wall. You're going to see how much more powerful Scratch 2 is, how intuitive the NoFlow project looks to make software crafting, and how games like 

LittleBigPlanet have created whole communities of people who are building software and don't even realize it.

Our walls are arbitrary. We look down on choices of text editor, on the choice between text editor and IDE. The very fact that we define a difference as if Emacs and Eclipse are so much different speaks volumes for our ability to segment ourselves needlessly. We've done the same with visual programming tools, and I think to their detriment, restraining the passion of developers who would improve them, and cutting off what could be a powerful avenue for whole new classes of developers to join our ranks.

I don't think we've learned to create software, but we've been prototyping the concept. There are fantastic possibilities when we look at the tools we hold sacred in our craft as ephemeral as the things we produce with them.

Comments

John M. Camara said…
Narrative 1 can be resolved by using pyinstaller - http://www.pyinstaller.org/
Anonymous said…
Extension to Narrative 1: Learning how to program also includes learning how to distribute.

Some free tools which can be used to create a Windows installer for Python + Pygame programs:
- py2exe: http://www.py2exe.org/
- Nullsoft NSIS: http://nsis.sourceforge.net/Main_Page
- HM NIS Edit: http://hmne.sourceforge.net/

Tutorial: http://www.cs.iupui.edu/~aharris/pygame/Appendix_C.pdf
Anonymous said…
Unfortunately that doesn't work for the millions of kids with iPads where as web programming does
dr dre said…
It's called Simulink, son. It is used in cars errday.
Anonymous said…
To expound, these narratives have been around for a few decades and are rather well understood until a new young whippersnapper comes along. Basically, a GUI complicates about as much as it simplifies, simple task that don't require speed or control could be done with scratch or the lego mindstorm software, but then the people writing those programs discover macro/script languages and realize it's not worth the hassle of of the GUI. I just went through this last year with a lego robotics team I coached. The kids made a line following algorithm in the GUI and it worked. I made one in C and it worked a factor or two faster. Several of those kids still program this year and want the speed and control. Not that a visual language couldn't do that but the intent of the programmer becomes lost in the module, icon, componen, or whatever the object is called.

Notice the web is run with text based source many times written by hand, not the output from a GUI.

I've got to go take a nap, so GET OFF MY LAWN.
Anonymous said…
IDLE? That's your example of an IDE?

It's a terminal window wrapped in some GUI chrome. It doesn't even have any toolbars.

C'mon mate. What about something like PyCharm or Pytools for Visual Studio?
Mario said…
Not to be overly negative but your arguments have serious flaws.

First, to add to John M. Camara's comment: Python, pygame and PyInstaller are all multi-platform which actually makes it fairly easy to distribute to your friends who are on different platforms. Additionally you mention switching to "web-based coding" ... clearly you lack experience in this field and are not familiar with the unholy nightmare that is cross-browser compatibility.

Second, onto Narrative 2; "UNIX vs IDE culture" is just plain wrong as there are many popular full featured IDEs that work on UNIX-like operating systems (Eclipse is probably the most popular). I develop cross platform application and regularly use both Windows & Linux. I personally prefer to use a powerful text editor instead of a full blown IDE. And that's all it is; a personal preference. I hear arguments from the other side (the IDE guys)all the time, saying that I should just use notepad and that I can't possibly be productive, but you really have to understand UNIX culture and history to get our workflow. We use small tools that do specific jobs very well. Using one large tool for everything goes against the way we have been working for decades, and for us is ultimately unproductive.

As per IDLE, it's more a proof of concept than anything else. It is not a robust editor that receives frequent updates. It is quite outdated and has many known bugs and limitations which is why the vast majority of Python developers don't recommend it.

Lastly, Narrative 3. The "real developers" are the people making real-world applications that are used on a daily basis, that much should be obvious. You ask who gets to make that decision. WE DO! Developers build communities, we know each other, and we know who the key contributors are.

The problem that we are having with "Visual Programming" is that we currently have out tried and true traditional method for building software that clearly works. Along comes non-programmers and less savvy programmers who are saying that our methods are broken/too complex/incomplete and that programming should be easy and visual. Visual programming is an interesting concept and has its uses, but until it has demonstrated clear value or advantages over our current methods, there's no reason for us to want to switch.

LittleBigPlanet: Good point, its a really a great example and more people who want to advocate Visual Development should reference it.

Your last comment is truly out of line; both insulting and incredibly ignorant. As you sit at your computer making this blog post, that will be sent as packets through many computers, to get to a server cluster which will then share the information with people all around the world you have audacity to imply that the art of creating software is still in the prototyping stage? Did you even think before you made that comment? You have just downplayed decades of work by millions of people with out whom you wouldn't even be able to make this blog post. That sir, is truly disgusting.
Anonymous said…
I think the reason behind visual programming being considered not for "real programming" is because of its limitations. You don't give a blacksmith a wooden hammer just cause someone found it was easier to use than a metal one. I've used visual programming tools in the past, mostly blocks and such. My biggest concern with visual programming such as that is the mouse-keyboard rotation. Every time i'd need to add a variable, i would have to go to my mouse to do so, then start typing the name. If i wanted to choose a type i would have to click a combo list, etc etc.. It is a lot easier to define a variable name and such then simply hit enter, no need to mouse your hand off the keyboard, onto the mouse then reorient the mouse to the needed position. Taking that into consideration there is only one answer for me, text based all the way. That is to say visualizing an algorithm isn't needed, simply the two should remain separate. Using diagrams and such to interpret the idea and using a programming language to implement it.
Anonymous said…
You write better than you think.

The TL;DR crowd wants everything to be on YouTube.

But who built YouTube?

What sort of documentation supports the operation of YouTube?

How much information can be conveyed effectively by colors, shades, and shapes?

Food for thought.
Anonymous said…
" We can't start developers on a path with these kinds of walls."

I find this to be a specious argument. Many kids of my generation, going to middle school in the early 90s, started out writing BASIC programs on the outdated but ubiquitous Apple IIe. We didn't have the tools to write software for the newer Macs or PCs in the computer lab, but that didn't stop us from experimenting and having fun. We didn't even have the manual to the BASIC interpreter, and the Internet hadn't been invented yet. We had to learn the BASIC command syntax by word of mouth, and peeked and poked our way to interesting results. We took strange, complex machines, learned their secrets, and gained control of them. We were no longer users, we were programmers. The wall is what makes you climb, and when you learn to love climbing then no wall can stop you.
Unknown said…
What about biztalk orchestration/pipeline/mapping creators. Mostly graphical. I would say they're useless..

Popular posts from this blog

CARDIAC: The Cardboard Computer

I am just so excited about this. CARDIAC. The Cardboard Computer. How cool is that? This piece of history is amazing and better than that: it is extremely accessible. This fantastic design was built in 1969 by David Hagelbarger at Bell Labs to explain what computers were to those who would otherwise have no exposure to them. Miraculously, the CARDIAC (CARDboard Interactive Aid to Computation) was able to actually function as a slow and rudimentary computer.  One of the most fascinating aspects of this gem is that at the time of its publication the scope it was able to demonstrate was actually useful in explaining what a computer was. Could you imagine trying to explain computers today with anything close to the CARDIAC? It had 100 memory locations and only ten instructions. The memory held signed 3-digit numbers (-999 through 999) and instructions could be encoded such that the first digit was the instruction and the second two digits were the address of memory to operate on

Statement Functions

At a small suggestion in #python, I wrote up a simple module that allows the use of many python statements in places requiring statements. This post serves as the announcement and documentation. You can find the release here . The pattern is the statement's keyword appended with a single underscore, so the first, of course, is print_. The example writes 'some+text' to an IOString for a URL query string. This mostly follows what it seems the print function will be in py3k. print_("some", "text", outfile=query_iostring, sep="+", end="") An obvious second choice was to wrap if statements. They take a condition value, and expect a truth value or callback an an optional else value or callback. Values and callbacks are named if_true, cb_true, if_false, and cb_false. if_(raw_input("Continue?")=="Y", cb_true=play_game, cb_false=quit) Of course, often your else might be an error case, so raising an exception could be useful

How To Teach Software Development

How To Teach Software Development Introduction Developers Quality Control Motivation Execution Businesses Students Schools Education is broken. Education about software development is even more broken. It is a sad observation of the industry from my eyes. I come to see good developers from what should be great educations as survivors, more than anything. Do they get a headstart from their education or do they overcome it? This is the first part in a series on software education. I want to open a discussion here. Please comment if you have thoughts. Blog about it, yourself. Write about how you disagree with me. Write more if you don't. We have a troubled industry. We care enough to do something about it. We hark on the bad developers the way people used to point at freak shows, but we only hurt ourselves but not improving the situation. We have to deal with their bad code. We are the twenty percent and we can't talk to the eighty percent, by definition, so we need to impro