Ask HN: Why does visual programming suck?

Every time a VPL (Visual Programming Language) has gone against a TPL (text programming language) , VPL not only has come out a winner it has massacred its opponent.

There are 3 areas that I am aware of that VPLs have appeared a) modular audio synthesis b) 3d graphics c) game programming

(a) has been the first with origins back to 1995 , there are like a ton of programming apis for building modular synthesizers , there even programming languages that specialize in this that have existed for decades now like CSOUND and Supercolider but Reaktor and Max/MSP have literally mopolised the market. Reaktor itself has been such a massive success that made Native Instrument as the dominant company on audio software.

(b) 3d graphics is no secret that is probably the richest software industry with the generation of the well knows CGI for films and games its a goldmine for developers and has been dominated by VPLs. You are not aware of this most likely because we never refer to them as VPL but rather as procedural material, textures, animation etc. Not using a VPL for todays standards is considered insane even if you try to do it via a very lovable language like Python. Text languages like POV RAY that specialize in 3d graphics have died a miserable death. 3d is where TPLs go to die and are used strictly for generating the software alone and thats about it.

(c) computer games there VPLs are something new but Unreal has definitely changed that with Blueprints. Probably the best and most powerful VPL. If you have played any kind of AAA game chances are that the game you played uses Unreal which in turn makes heavy usage of Blueprints and C++ code. The rule of thumb among Unreal developers is "Do it with Blueprint and if you cannot avoid it do it with C++". Unity has smelled the roses and has implement its own VPL as well very similar to Blueprints.

So if VPLs are so amazing why we do not see more of them ? They are actually very hard to make. If an implementation of lisp , a basic one, needs a few hundreds lines of code a VPL needs thousands and that imposes a high barrier for language designers. Hence why we have thousands of TPL and only a handful of VPLs.

The majority of them are crappy obviously because that is how quality works , you have to have high quantity for high quality.

But a high quality VPL will kick high quality TPL ass any day and this is why VPLs are massively more popular than TPLs for the same task.

One that does not work as well as it looks and it depends on drag and drop is a crappy VPL . Yes a crappy VPL will suck, not as much as a crappy TPL (see C++ , Javascript etc) but it will suck none the less.

you can also read my quora answer here for more details why VPLs dominate so easily and why they will replace TPLs in the not so distant future to a very large extend

https://www.quora.com/Why-did-graphical-programming-language...

I've been working on a project that does exactly what you described for the last few years. IMHO vue.js/react really changed the game here, especially for CRUD apps.

For example what I did was to code a server part in golang and use vue.js on the frontend and for the app builder. Using the web-based app builder (also 100% vue) the user can design forms. The forms are stored as serialized JSON in the database and the server renders dynamically vue.js components. It's super fast. And there's a complete freedom to design any form with a 16-column responsive grids and a lot of widgets and styling options. Forms are also nestable (thanks vue!) and completely extendable with custom JS code so it's possible to create a custom widget and then simply import it in other parts of the app.

As I said I think the shadow DOM and frameworks like vue really made the difference. I started without using such frameworks and it was not only tedious, but the resulting app wasn't very interactive and felt like a customized Excel spreadsheet attached on top of a PostgreSQL database. Now it's a completely different story - it's easy to build fully reactive apps that feel like a "normal" cloud app and are actually pleasant to use. Of course instead of spending few months designing and building it, it was created in a few hours.

So yeah... I think that drag-n-drop builders are definitely coming and will probably eliminate the need to write such apps in coming years.

It doesn't. The electrical world has been using contactor diagrams for complex logic for decades, and with the inclusion of more advanced computer components ladder logic (still the same concepts, symbols and logic)

https://www.allaboutcircuits.com/worksheets/ac-motor-control... is the link I quickly found.

It's typical to see a handful of symbols handle what would take a hundred of lines of code for the level of user interface usability, validation, and core functionality.

I guess it depends on what one considers to be programming. For certain DSLs (audio, control systems, UIs), it seems to be doing OK. For general-purpose work, I think they will always be less desirable than text. Even after thousands of years, words are still our most powerful tool for recording and sharing new ideas.

Alan Kay's mistake is that a lot of his original work was with Papert on educating children. For early learning, having a visual/physical analog adds value. For professional work, when you already have the concepts down, it just gets in the way.

Is it something you are doing as open source - pls share link if so (above comment downvoted, why ?)