Ask HN: Why does visual programming suck?

Totally agree. I think the major reason visual programming sucks is exactly because some things which are simple to do using text-based programming become way harder when all you can do is drag graphs around.

On the other hand, some things are easier and more intuitive when represented and manipulated visually using graphs or trees.

I think that a visual programming environment which would be an extension of a text-based programming environment, in that you could do everything that you can do in IDEs everybody is already used to PLUS the cool stuff you can do with visual programming, would have high chances of not sucking.

> Imagine GUI editor where the user can type the code on the left side and also can move and edit widgets with cursor on the right side. And editing of both sides is working in live mode. My point is that we need to have the best of both worlds to be really productive.

I made a hybrid visual and text programming language and prototype development environment for it as a project for my master's thesis [0].

The main idea was very similar to what you are imagining. Textual code on the left side and visual representation on the right [1]. You can edit one and have the changes reflected dynamically in the other.

Actually my idea was even more general and could be extended to parallel-editing multiple representation of the same syntax tree.

I would love have the time to explore this stuff some more.

[0] http://djedr.github.io/masters_thesis.pdf

[1] http://djedr.github.io/gfx/masters-thesis/ide-prototype.png

i have worked in labview very seriously over the past 4-5 years. at this point, i am essentially an expert in the language. i have done object-oriented programming (OOP), functional programming, and also programmed using an actor framework. all of that is in addition to obviously adopting the dataflow-first paradigm. my projects have not been simple applications. they have been large applications, with many different components and non-trivial user interfaces.

it's amazing how such a simple and small base language can be so powerful due to the dataflow nature. my programs are almost always essentially bug free when i am done. this is due to how labview works, which is rather advanced. as i program labview, i work on VIs. these are small blocks of code that perform a certain task. oftentimes, these are purely dataflow functions. in other words, they take in information and pass information out without modifying things via references. since every VI has dynamic type propogation and compilation as you work on it, you get immediate feedback on wehther or not your types match up and whether your VI runs. once your VI successfully compiles (by the way, you never kick off the compile process as it's automatic), you can run it. so i build up systems out of basic dataflow processors, almost all of which i am able to run freely with inputs to see how they interact. out of those that i can't, mainly due to needing a "mock object" to test, it still makes it easy to reason about to due simply having to understand how the data flows through your code. if something's not available, it's pretty easy to trace it back to where it should have come from. all of this also makes labview easy to debug. data is just flowing through your program. just navigate to where you want to view your data and place a probe on a wire to see what's happening at that point in your program.

all of this is quite advanced. this type of interactive writing of code, running, and debugging doesn't really exist in other languages. then you have the ability to easily create modern looking user interfaces (my interfaces are almost untraceable back to labview based upon their look) and program desktop, real-time OS, and FPGA applications all with the same language.

and i haven't even talked about how labview is concurrent by default. want two while loops running concurrently? just draw two while loops on the screen, and you're done. multithreading is so easy in labview that you don't even have to think about it. it's inherent to the language, and labview takes advantage of multiple cores by default.

many of these features are discussed ad nauseum in reference to other languages: type propagation, REPLs, dataflow, concurrent/multithreaded programming, etc. these are things people throw out in praise of a language, and yet labview has all of them.

finally, i will mention that labview does struggle with some things, but it is not due to the visual programming environment being inadequate in most cases. most of the time it is because the language is manufactured by a company, which has finite resources in what they can do to the language. there are plenty of problems with labview, but they are all solvable. they just need attention from national instruments and the research community at large.

it's just that visual programming is different and necessitates different approaches. people somehow forget that it took them years to understand how to program computers using text. it isn't that text is THE way to program computers, but people certainly seem to think that. i am convinced a hybrid approach is appropriate. i myself am slowly designing a language and environment along these lines.

The downside is perhaps that this very same instant gratification makes you very prone to add business logic in the UI, and it the application sticks around, you eventually want to refactor the whole thing.

- Programming errors most of the time break everything. You probably know how bitchy Word can be. Errors will be frequent und finding them when you don't really know what happens under the hood will be very difficult.

- WYSIWYG does not abstract very well. The big power of programming however is, that you can build your own tools from a minimal set of building blocks. Visual representation for self-build tools and routines will not be pretty out of the box.

---

Those visual languages that do have a big userbase do the following:

- no WYSIWYG, just "nodes". The visual parts of the nodes:

- - inputs and outputs are often connected with "wires"

- - simple control UI like a knob or a button can be shown directly

- they allow wrapping a bunch of wired mess in to a box with simple in- and outputs again

- some allow to jump back in to code where necessary

- in general nice for small art-projects

- difficult or at least in-flexible for complex stuff

- often a lot more copy+pasting

---