3 ms·

Ask HN: Why have graphical programming languages never taken off?

• JDDunn9 8y ago
  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
• Cypher 8y ago
  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.
• facorreia 8y ago
  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.
• fulafel 8y ago
  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.
• brogrammer2019 8y ago
  See: Visual Programming - Why it’s a Bad Idea http://mikehadlow.blogspot.com/2018/10/visual-programming-why-its-bad-idea.html http://mikehadlow.blogspot.com/2018/10/visual-programming-wh...
  • gitgud 8y ago
    What a great article, that explains the feelings I've had perfectly.
• sgillen 8y ago
  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.
• dagw 8y ago
  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.
• airbreather 8y ago
  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.
• anotheryou 8y ago
  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 8y ago
    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.
• veddox 8y ago
  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.
• marssaxman 8y ago
  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.