Hacker News Reader

I'm skeptical because I don't see how visual programming models are even possible for the type of development I routinely perform (my day job is writing a high-performance distributed, parallel implementation of the well-known 'make' tool). Even if it is theoretically possible, for some parts of my project, I imagine it would take nearly as long to create the visual programming environment, and I'm not sure it would be particularly reusable.

I loved Bret Victor's talk. And this recursive drawing thing is neat too. But both of those are dealing with programs that are primarily visual in their own output. I can't help but think, "That's neat, but not broadly applicable." Honestly, how many people are there out there dying to write programs to make fractal-like pictures?

Perhaps I'm just not visionary enough to see the potential, but I don't believe these techniques will really "democratize programming." Whether or not doing so is desirable in the first place is another debate altogether.

I'm skeptical because I remember the RAD tools of the early 00s that were going to let businessmen program.

Oh, and who can forget the wonderful workflow systems that were all the rage soon after? There seemed to be a new one released every week.

I invite you to go try MS's WWF, that's 'visual'. What a nightmare that is.

They don't work. You need a programmer involved because edge cases rapidly become complicated and that's the hard bit, not visualizing a workflow. And these tools deprive you the programmer of the fine grained control you sorely need or worse generate code that's so hard to read and work with that it's faster coding from scratch even for amateurs.

I love Bret Victor's vision, but because of what it means for programmers, not the fuzzy 'creatives' in the article. I know some animation guys and yes, you can visually automate things like animation now, but logic flow? No.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.