Ask HN: Why does visual programming suck?
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.<p>For my master&#x27;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 &quot;Hello world&quot; complexity (anything more complex literally became hairy to look at). Since then I&#x27;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 &quot;eject&quot; button until we were catapulted away from the monster. All in all I consider myself vaccinated at this point.<p>As for my reply to the question of the OP, I&#x27;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&#x27;s easy to search for stuff, and it&#x27;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&#x27;t matter (such as aligning boxes and arrows), and views very quickly become cluttered when you start connecting things.<p>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&#x27;n&#x27;drop to compose the UI, but the code is still written in a text editor. This can work reasonably well.