3 ms·

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,

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.

JunkDNA 14y ago
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.
- sbmassey 14y ago
  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.

JunkDNA 14y ago

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.

sbmassey 14y ago
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.