
Ask HN: Why have graphical programming languages never taken off? - gitgud
There&#x27;s been many efforts, but why are all developers still writing code using <i>characters</i>?<p>I come from an engineering background and naively imagined plugging software components together like Lego. But in reality, you can never seem to get away from writing code...
======
facorreia
In my experience, because they don't solve the real, hard problems, slow down
work, and make it harder to view a good chunk of code at a time.

Typing is not what makes coding hard, it is coming up with the proper
algorithms, data structures, architecture (e.g. coupling), tests, etc.

Typing is faster than dragging icons and filling in properties.

Text is denser, so you can view more of your program at once, and in an
expressive language can be quite descriptive.

------
brogrammer2019
See: Visual Programming - Why it’s a Bad Idea
[http://mikehadlow.blogspot.com/2018/10/visual-programming-
wh...](http://mikehadlow.blogspot.com/2018/10/visual-programming-why-its-bad-
idea.html)

~~~
gitgud
What a great article, that explains the feelings I've had perfectly.

------
airbreather
A graphical linking of function blocks is commonly used to configure process
control systems, historically DCS style systems but now with IEC 61131 one of
the five languages used by PLC's is function block diagram.

Some of these systems can be reasonably complicated, we are talking oil
refineries, LNG processing plants, large mineral processing facilities,
chemical plants etc.

The reasons they are programmed this way are many and varied, many
historical/legacy, but essentially much of it boils down to limiting
variability of the language and creating a "bridge" language that the
specialist engineers focusing on the chemistry of the process can more easily
discuss and work with.

This probably isn't changing in a hurry as the industry is also very slow to
adapt. The sort of facilities are plant worth tens of billions of dollars and
multi-millions of dollars lost per trip or hour of downtime. Owners are
understandably risk adverse to experimenting with a new paradigm that may work
a little better, but may also create problems.

Additionally, plant owners factor in availability and decades of experience in
the existing pool of labor that has the specialist skills related to
optimisation and real time control of the process as the primary value add.

------
dagw
There are lots of successful domain specific graphical "programming
languages". FME, Dynamo, UE Blueprint, Pure Data, LabView, various shader
constructing tools etc.

The problem is that general purpose programming is too abstract to fit nicely
into a visual metaphor, but as long as you can narrow your scope enough there
is plenty of room graphical programming.

------
anotheryou
My personal guess coming from my experience with pd/maxMSP:

this is what I'm talking about:
[https://www.youtube.com/watch?v=X2kQ8ETzdyw](https://www.youtube.com/watch?v=X2kQ8ETzdyw)

In generative music these are actually very popular.

\- it's great for simple small things, here it takes out the complexity of the
flow of information because it shows it with lines

\- input is more work. you still have syntax and everything you can't type you
have to click together or even search in a library of elements

\- nesting and object orient programing is difficult to depict, you loose more
than you gain. You can use a lot of containers and that's what people who are
good at it do, but I think it's still not as elegant as reusable functions.

\- i personally don't like to have to do screen estate management

~~~
anotheryou
big pro i forgot: these have real-time input for free, e.g. a slider for some
ranged number you can quickly fiddle around with.

------
JDDunn9
There's too many possibilities. You need a narrow field of options for
graphical programming to work. Blueprints works for Unreal because it is
focused only on video games. [https://docs.unrealengine.com/en-
us/Engine/Blueprints](https://docs.unrealengine.com/en-us/Engine/Blueprints)

------
marssaxman
I spend far more time reading code and thinking about code than I ever do
writing code. Writing code using characters is no more an issue than writing
email using characters. Language is a powerful, appropriate technology.

Problems simple enough to be solved by plugging software components together
are also simple enough to be solved with a few lines of code, but that's not
where the actual work lies. Writing code is effortless compared to the work of
thinking out the design of the code that needs to be written, and that work
would need to happen regardless of the interface.

------
sgillen
There are a few successful examples of graphical programming languages used by
engineers and scientists everyday. Simulink and Labview are what I'm thinking
of, there may be a few other similar ones I don't know about.

I actually don't like using these tools too much personally, and yes I suppose
they are relatively niche. But there are some people that swear by them, and
they really are powerful and useful in their problem domains.

------
veddox
It isn't for nothing that we often describe programming as "talking" to a
computer. Programming is a language, and as the alphabet replaced pictograms
in human languages, so characters and words continue to be a useful and above
all compact way of representing computer languages.

------
fulafel
There is no common symbol system that would facilitate tooling, interchange
formats, common idioms and other ways of exploiting network effects. So the
text based world has built a far away lead in inertia and value from network
effects over the last 70 years or so.

------
Cypher
speed > ui

programming with a graphic interfaces is good for visual feedback but slow at
developing as it requires a mouse and then some laying out which is more of a
designer tool.

