7 ms·

I think visual programming is one of those ideas that intuitively seems like a good idea but never is. Thus, it never really dies, it just gets picked up as a k

I think visual programming is one of those ideas that intuitively seems like a good idea but never is. Thus, it never really dies, it just gets picked up as a kind of rite-of-passage by new generations of developers. Managers also tend to like the concept as it would allow them to bypass the pesky code monkeys and just feed their drawings to the computer. For my master's thesis, some 15 years ago, I programmed a system for visually composing and executing Java programs. The UI looked a bit like UML, and it worked nicely for anything resembling "Hello world" complexity (anything more complex literally became hairy to look at). Since then I've twice found myself on projects where we had to work with visual programming tools (caused by skilled salesmen and inept managers). In both cases the only sensible action was to pound the "eject" button until we were catapulted away from the monster. All in all I consider myself vaccinated at this point. As for my reply to the question of the OP, I'm not sure that it differs much from everyone else. The main reason that it will never catch on, IMHO, is that the text editor is far better for managing complexity. It's easy to search for stuff, and it's easy to move or copy it. Also, every serious text based programming languages offers plenty of ways to hide complexity away, allowing you to focus your thinking at the desired level of abstraction. Visual programming tools -- or at least those that I have met -- instead force you to deal with stuff that doesn't matter (such as aligning boxes and arrows), and views very quickly become cluttered when you start connecting things. That being said, I think visual tools can be a good fit for tasks whose output is UI. There are applications and frameworks that allow you to drag'n'drop to compose the UI, but the code is still written in a text editor. This can work reasonably well.

nzonbi 9y ago
My horse carriage is very useful. The horse just feeds itself, if you leave him in a grass field. It rarely gets sick and last many years. The wheels are easily replaced from the store. The other day I saw a crazy guy with a mechanical contraption that, according to the guy, moved by burning wood! The guy was demoing it at the town. He filled it with wood, and then had to start the fire. The crazy machine got so hot that nobody could get near it. The thing barely moved a few meters and then Kabooooom!! it exploded in a black cloud. What sane person may ever believe that one of these contraptions could be useful? Am I right? Are you right? we don't know. Research is the only way to know.
- wpietri 9y ago
  Except that there has been a lot of research. The first visual programming language I can find is from 1966. They have always been tiny, niche things over a period where we've had waves of text-based languages rise and fall. One of the striking things for me when I talk with visual programming enthusiasts is that they very rarely have looked at the decades of research. And if you try to talk with them about the history, they seem actively averse. There's a joke that some people have ten years of experience, and some people just have one year of experience ten times over. My experience has been that visual programming is more like the latter, but for 50 years.
- olau 9y ago
  There are decades of research. It's not unreasonable to adjust expectations based on that. Honestly, I feel part of the problem is that this seems to attract people who think that text is bad and more visual = better, while the truth probably is that you need to be really, really careful to arrive at something that doesn't explode in complexity when confronted with all the little details of ordinary programs.
djedr 9y ago
Some good points. But I think your view has become too negative, perhaps due to your experiences. Or at least I see more hope for visual programming. :) > I think visual programming is one of those ideas that intuitively seems like a good idea but never is. Thus, it never really dies, it just gets picked up as a kind of rite-of-passage by new generations of developers. Perhaps the intutition is right, but the problem is too general and thus very hard to solve. And I think that, looking at the general trend, it does seem to evolve towards something better with every new generation. Not the first and not the last idea like that. We're just not there yet. > For my master's thesis, some 15 years ago, I programmed a system for visually composing and executing Java programs. Similar experience here [0]. :) But for me it was a year ago, so I guess I represent a newer generation. > Since then I've twice found myself on projects where we had to work with visual programming tools I worked with some too, mostly Unreal Engine 4. Fortunately all for education, not for work. ;) And your experience is probably a good picture of the state of the art in this area, if it comes to complex and more general-purpose application development. > The main reason that it will never catch on, IMHO I'm still a believer. But probably not in my generation either. ;) > the text editor is far better for managing complexity. It's easy to search for stuff, and it's easy to move or copy it. True. Compared to a visual editor of today. For this and other reasons, text coding can't and will not be replaced with visual coding. Visual programming, I think, should be thought of as an extension of text programming. So I think that visual editors will only start becoming successful and more wide-spread among regular developers when they stop being visual-only. Or, in other words, when they stop eschewing all the good parts of text-based environments. Visual programming should complement text-based programming. Not replace it. > Visual programming tools -- or at least those that I have met -- instead force you to deal with stuff that doesn't matter (such as aligning boxes and arrows), and views very quickly become cluttered when you start connecting things. It's almost like coding in text without the editor helping you with indentation and structuring of text. You have to arrange boxes and connections yourself. This is one thing that illustrates that some visual languages are really a few steps back in evolution compared to text languages. But there are visual environments (e.g. Scratch and the like), which do help you with structure. Anyway, I'm tired and it's very late, so I'll end here. Cheers! [0] (copy-pasted from my previous comment): (a screenshot from my project) http://djedr.github.io/gfx/masters-thesis/ide-prototype.png http://djedr.github.io/gfx/masters-thesis/ide-prototype.png (link to my thesis) http://djedr.github.io/masters_thesis.pdf http://djedr.github.io/masters_thesis.pdf
revelation 9y ago
Except there is a successful visual programming tool and it probably runs a large chunk of software in your car. It's called Matlab Simulink: https://mathworks.com/help/simulink/examples/anti-windup-control-using-a-pid-controller.html?prodcode=SL https://mathworks.com/help/simulink/examples/anti-windup-con... Obvious lectures from this: 1) Don't be silly and copy a text based language into visual blocks. Nobody wants to drag&drop the components of a while loop or click a box to enter a variable name. If you have variable names, you probably failed this one already. 2) It's about the data, stupid. There is very very little explicit control flow in Simulink diagrams. Instead it's all about the flow of data. 3) Seriously, nobody wants to click together while loops. Simulink works because it has a very large and very powerful library of blocks that you need just a few of at a time to build very complex functionality.
- mvindahl 9y ago
  That's actually very interesting. Never heard of that before. A few remarks off the the top off my head: 1) Visually, it reminds me of electrical diagrams, perhaps taking it one or two steps up the ladder of abstraction. I can see how it might be an appealing notation for someone trained in electrical engineering, which may explain its usage in cars. It's really interesting how different "cultures" find different solutions to similar problems. 2) Still, and this may be unfair since I only glanced over it for a few minutes, it strikes me as more of a niche thing than as something that I'd describe as a general purpose language. It seems fixed at a certain level of abstraction. Probably just the right level of abstraction for configuring your car firmware, but impractical for authoring a complex piece of desktop software. Maybe the future will prove me wrong :)
  - bzalasky 9y ago
    Perhaps creating niche visual DSLs is a more viable approach to developing visual programming environments than to focus on creating a general purpose programming environment. It'd be interesting to see if there are any existing solutions in other domains.
- hsjoberg 9y ago
  I have a background as a programmer and recently started using Matlab/simulink. It is good for some things like controllers etc. Can't really say I like it for things I would usually use when programming, like loops and if statements(I know simulink has these but they make no sense). I also believe simulink has been used mostly for simulation therefore it's name and not programming. However now you can generate code from your model.
heisenbit 9y ago
> That being said, I think visual tools can be a good fit for tasks whose output is UI. There are applications and frameworks that allow you to drag'n'drop to compose the UI, but the code is still written in a text editor. This can work reasonably well. Even there some people claim it works better for micro scale: widgets are ok but larger scale composition (storyboards, composing dynamic views from re-usable sub-views) are better done in code.
seanmcdirmid 9y ago
There is a huge difference between direct manipulation of concrete concepts, and graphical manipulation of abstract code. Visual programming works much better with the former than the latter.

nzonbi 9y ago

My horse carriage is very useful. The horse just feeds itself, if you leave him in a grass field. It rarely gets sick and last many years. The wheels are easily replaced from the store. The other day I saw a crazy guy with a mechanical contraption that, according to the guy, moved by burning wood! The guy was demoing it at the town. He filled it with wood, and then had to start the fire. The crazy machine got so hot that nobody could get near it. The thing barely moved a few meters and then Kabooooom!! it exploded in a black cloud. What sane person may ever believe that one of these contraptions could be useful? Am I right? Are you right? we don't know. Research is the only way to know.

wpietri 9y ago
Except that there has been a lot of research. The first visual programming language I can find is from 1966. They have always been tiny, niche things over a period where we've had waves of text-based languages rise and fall. One of the striking things for me when I talk with visual programming enthusiasts is that they very rarely have looked at the decades of research. And if you try to talk with them about the history, they seem actively averse. There's a joke that some people have ten years of experience, and some people just have one year of experience ten times over. My experience has been that visual programming is more like the latter, but for 50 years.
olau 9y ago
There are decades of research. It's not unreasonable to adjust expectations based on that. Honestly, I feel part of the problem is that this seems to attract people who think that text is bad and more visual = better, while the truth probably is that you need to be really, really careful to arrive at something that doesn't explode in complexity when confronted with all the little details of ordinary programs.

djedr 9y ago

Some good points. But I think your view has become too negative, perhaps due to your experiences. Or at least I see more hope for visual programming. :) > I think visual programming is one of those ideas that intuitively seems like a good idea but never is. Thus, it never really dies, it just gets picked up as a kind of rite-of-passage by new generations of developers. Perhaps the intutition is right, but the problem is too general and thus very hard to solve. And I think that, looking at the general trend, it does seem to evolve towards something better with every new generation. Not the first and not the last idea like that. We're just not there yet. > For my master's thesis, some 15 years ago, I programmed a system for visually composing and executing Java programs. Similar experience here [0]. :) But for me it was a year ago, so I guess I represent a newer generation. > Since then I've twice found myself on projects where we had to work with visual programming tools I worked with some too, mostly Unreal Engine 4. Fortunately all for education, not for work. ;) And your experience is probably a good picture of the state of the art in this area, if it comes to complex and more general-purpose application development. > The main reason that it will never catch on, IMHO I'm still a believer. But probably not in my generation either. ;) > the text editor is far better for managing complexity. It's easy to search for stuff, and it's easy to move or copy it. True. Compared to a visual editor of today. For this and other reasons, text coding can't and will not be replaced with visual coding. Visual programming, I think, should be thought of as an extension of text programming. So I think that visual editors will only start becoming successful and more wide-spread among regular developers when they stop being visual-only. Or, in other words, when they stop eschewing all the good parts of text-based environments. Visual programming should complement text-based programming. Not replace it. > Visual programming tools -- or at least those that I have met -- instead force you to deal with stuff that doesn't matter (such as aligning boxes and arrows), and views very quickly become cluttered when you start connecting things. It's almost like coding in text without the editor helping you with indentation and structuring of text. You have to arrange boxes and connections yourself. This is one thing that illustrates that some visual languages are really a few steps back in evolution compared to text languages. But there are visual environments (e.g. Scratch and the like), which do help you with structure. Anyway, I'm tired and it's very late, so I'll end here. Cheers! [0] (copy-pasted from my previous comment): (a screenshot from my project) http://djedr.github.io/gfx/masters-thesis/ide-prototype.png http://djedr.github.io/gfx/masters-thesis/ide-prototype.png (link to my thesis) http://djedr.github.io/masters_thesis.pdf http://djedr.github.io/masters_thesis.pdf

revelation 9y ago

Except there is a successful visual programming tool and it probably runs a large chunk of software in your car. It's called Matlab Simulink: https://mathworks.com/help/simulink/examples/anti-windup-control-using-a-pid-controller.html?prodcode=SL https://mathworks.com/help/simulink/examples/anti-windup-con... Obvious lectures from this: 1) Don't be silly and copy a text based language into visual blocks. Nobody wants to drag&drop the components of a while loop or click a box to enter a variable name. If you have variable names, you probably failed this one already. 2) It's about the data, stupid. There is very very little explicit control flow in Simulink diagrams. Instead it's all about the flow of data. 3) Seriously, nobody wants to click together while loops. Simulink works because it has a very large and very powerful library of blocks that you need just a few of at a time to build very complex functionality.

mvindahl 9y ago
That's actually very interesting. Never heard of that before. A few remarks off the the top off my head: 1) Visually, it reminds me of electrical diagrams, perhaps taking it one or two steps up the ladder of abstraction. I can see how it might be an appealing notation for someone trained in electrical engineering, which may explain its usage in cars. It's really interesting how different "cultures" find different solutions to similar problems. 2) Still, and this may be unfair since I only glanced over it for a few minutes, it strikes me as more of a niche thing than as something that I'd describe as a general purpose language. It seems fixed at a certain level of abstraction. Probably just the right level of abstraction for configuring your car firmware, but impractical for authoring a complex piece of desktop software. Maybe the future will prove me wrong :)
- bzalasky 9y ago
  Perhaps creating niche visual DSLs is a more viable approach to developing visual programming environments than to focus on creating a general purpose programming environment. It'd be interesting to see if there are any existing solutions in other domains.
hsjoberg 9y ago
I have a background as a programmer and recently started using Matlab/simulink. It is good for some things like controllers etc. Can't really say I like it for things I would usually use when programming, like loops and if statements(I know simulink has these but they make no sense). I also believe simulink has been used mostly for simulation therefore it's name and not programming. However now you can generate code from your model.

heisenbit 9y ago

> That being said, I think visual tools can be a good fit for tasks whose output is UI. There are applications and frameworks that allow you to drag'n'drop to compose the UI, but the code is still written in a text editor. This can work reasonably well. Even there some people claim it works better for micro scale: widgets are ok but larger scale composition (storyboards, composing dynamic views from re-usable sub-views) are better done in code.

seanmcdirmid 9y ago

There is a huge difference between direct manipulation of concrete concepts, and graphical manipulation of abstract code. Visual programming works much better with the former than the latter.