Live data from Hacker News

Visual Programming Is Unbelievable (2015)

outsystems.com

11–20 of 107 posts

Re: Visual Programming Is Unbelievable (2015)

#11
"That evolution, which seems so inevitable today, brought us better graphic cards – which lead to better games, brought us the world wide web,"

It should be remembered that in the early days of the web, some people argued that it should remain text-only. Basically, if you couldn't read it on the command line with Lynx, they weren't interested. Of course, the web seemed different at 9600 baud (or even slower).

Being color-blind, I am not enthusiastic about the idea of visual programming, just because a lot of visual tools are color-coded in ways that are hard for me to work with, esp. if the default settings are not easily modified. Even syntax-coloring in a text editor is a chore to deal with.

Re: Visual Programming Is Unbelievable (2015)

#12
post #8

Spreadsheets are visual programming languages, and they seem pretty popular, and have been for a while.

Low barrier of entry for high yield, thus their popularity. Though they really don't scale well, and you can end up with the stuff of nightmares.

It's sad how fuzzy the CSV file format is for such an important commonly used kind of file. Like how the name of the first column can't be "ID" or Office will give you an inexplicable error about some "SYLK" filter you don't care about. [1] Who would ever want to name their first column "ID", huh?

[1] https://bz.apache.org/ooo/show_bug.cgi?id=117508

Re: Visual Programming Is Unbelievable (2015)

#13
Can't communicate visually. The translation between written and spoken words, even made up technical words, is fast, accurate, unambiguous. Visual means slow, inaccurate, ambiguous, which is sometimes cool for art, but not for communication.

It would be like trying to program musically, or by touch, or by (oh no) smell.

There is also the productivity danger of futzing, or whatever the modern term is. In the early desktop publishing era, we were promised that instead of taking ten minutes writing a memo, we'd type one in five minutes, but reality was we'd spend an hour using a minimum of seven fonts and three text colors and pictures. So much for productivity improvement! Likewise a visual programming language would invite people with authority but no ability to endlessly rearrange "put that box over there, looks nicer" "Make that text red" "that needs a larger font".

Re: Visual Programming Is Unbelievable (2015)

#14
post #10

Spreadsheets are visual programming languages, and they seem pretty popular, and have been for a while.

Not really. You still need to write formulas using a textual language.

Or selecting formulas from menus and parameters by pointing and clicking and dragging, directly manipulating rows, columns and cells, and addressing parameters by relative two-dimensional offsets.

Re: Visual Programming Is Unbelievable (2015)

#15
I'm currently working on a developer tool that leverages the advantages of visualization not for writing source code, but for navigation and understanding. Coati, a source explorer for C/C++, combines graph visualization and source code interactively. The graph makes it easy to see what relationships a class or a function has, while the code still provides all the details of the implementation.

https://www.coati.io/

Re: Visual Programming Is Unbelievable (2015)

#16
post #4

'Visual Programming' failed (and continues to fail) simply because it is a lie; just because you surround my textual code with boxes and draw arrows showing the 'flow of execution' does not make it visual! This core misunderstanding is why all these 'visual' tools suck and don't help anyone do anything practical (read: practical = complex systems). When I write code, for example a layout algorithm for a set of gui el…

This seems pretty close to my experience. I remember thinking when I first encountered SQL Server Integration Services that this is 'visual programming'.

It didn't take very long to realise that as a solution SSIS was well suited to some simple tasks where the logical actions on screen matched those taking place on the database.

But as soon as those tasks became even slightly more complex, and this mirror was broken, the whole thing sort of fell apart. Then I was struggling to find ways to defeat the system to make it do what I wanted. It was with this realisation, i.e. that the solution was the problem, that I stopped using it.

But it's not just SSIS that suffered this way, ActiveBatch is another example and I'm sure there are plenty more.

Re: Visual Programming Is Unbelievable (2015)

#17
post #9

There is one place where visual programming is alive and well and has been for a long time. That's programming PLC (Programmable Logic Controllers). It's easy to forget about PLCs[1], but it's an old and large niche in large corporations that do a lot of industrial automation like assembly lines, (automobile) manufacturing, oil & gas... Most PLC programming is done using Ladder Logic [2] and various visual tools tool…

Visual programming is also alive and well in device, instrument and robotic control, where accuracy and reliability is important.

At the high end of the mission critical benevolent guardian mega robot spectrum, the Maeslantkering [1] is programmed in LabView [2]. I sure hope it's accurately programmed and well debugged!

[1] https://en.wikipedia.org/wiki/Maeslantkering

[2] http://www.ni.com/labview/?cid=Advertising-LabVIEW-Northern_...

Re: Visual Programming Is Unbelievable (2015)

#19
It is a very strange essay form to give multiple reasons why a thing has not worked very well, then end it with the conclusion that people just irrationally don't like it because your brain is just biased against it.

I don't believe in it in the general case simply because I've never seen a general-purpose visual programming language work. Show me one and show me lots of people choosing it freely and I'll believe just fine. I'm not holding my breath, though. (There are certainly specialized ones that meet this bar.)

Most analyses of this problem fall prey to the "anything can be made to look good if you only consider the positives of one side and the negatives of the other" effect. Visual advocates generally make wild promises about the positives of visual programming, which turn out to much harder to manifest than imagine in your head, and then make silly criticisms of textual languages, mistaking accidental issues of complexity for fundamental issues in the language. (Visual languages, just as one example, have no special protection against spaghetti code, any more than anything else does. Spaghetti code is not caused by textual languages, it's caused by developers creating spaghetti code from the spaghetti concepts in their heads.)

So not only are the analyses incomplete, examining only the positives of visual languages and the negatives of textual languages, most of the ones I see are even pretty terrible on those terms.

If you want do this, you need to look at both the pros and the cons of both sides, fairly. And if you haven't got a solid set of positives on the textual side and negatives on the visual side, go back and do it again.

(I'm not saying you must conclude that the net benefit is to text. You may have things that outweigh what I mentioned and your sum may come out in favor of visual programming. I'm simply saying if you can't explain in a sensible manner why text has been successful and why existing visual languages have failed, you do not have an analysis. You have a wish.)

Re: Visual Programming Is Unbelievable (2015)

#20
post #9

There is one place where visual programming is alive and well and has been for a long time. That's programming PLC (Programmable Logic Controllers). It's easy to forget about PLCs[1], but it's an old and large niche in large corporations that do a lot of industrial automation like assembly lines, (automobile) manufacturing, oil & gas... Most PLC programming is done using Ladder Logic [2] and various visual tools tool…

Except the programming is shit. My first job was building DCS software for coal power plants. We had such a graphical programming language. I can assure you, it was a pain in the butt to work with. Oh, you want to build many similar logic systems? Go ahead, do the SAME thing 200 times, click spamming is your job. The technology is used not because it's good, but because the industry is stuck in the 80's.

I understand the appeal of having visual flow and feedback for your code but I see no reason why the building of code should be exclusively visual. I see great improvements that can be made by programatically generating control structures. But, well, the clients pay for it, the companies get wads of cash for sending engineers in the field so I guess it all works out in the end.

As a side note, I suspects that if someone good puts his mind to it they could generate the code out of the layout of the plant and the different control mechanisms involved. With proper constraints, I suspects the system would be sufficiently defined without laying one stupid line (like, an actual line, from point A to point B) of code.

Post reply on HN