Hacker News Reader

Comment by mtanski | Hacker News Reader

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 tools for creating and editing Ladder Logic. Here's a screenshot of one such environment, RSLogix: https://i.ytimg.com/vi/4yEj065J1q4/maxresdefault.jpg

It's an interesting data point because A) it's a highly technical field where accuracy (and verification) matters B) almost everybody who does PLC programming spends all their time in a visual programming environment.

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

[2] https://en.wikipedia.org/wiki/Ladder_logic

View on HN

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.

Never said it a great experience, just that they used visual programing to express logic flow.

And I agree, the "language" forces you to repeat yourself. I believe that over the years there's been attempts at alternatives but none of them caught on. The only new things you see if faster hardware (PLC), new buses (took forever for ethernet to catch on) and new classes of IO / devices to control.

The controls / industrial automation industry has different set of constraints & values. It's a very conservative industry. Double so if what you're programming is safety and error proofing.

So the industry values tools that consistent, maintainable (by current / future staff). There's many cases where you might be supporting an installation with a mixture of both new and 20 year old hardware.

It is just a different world.

Both of the major platforms Allen Bradley RSLogix 5000 and Schneider Electric Unity allow the programmer to create objects of user defined data types and functions that can operate on elementary (eg float, INT) or user defined data types. They also support arrays, and arrays of objects. They also both support structured text so you can type if statements and for loops and call functions. So for at least those PLC platforms it is not exclusively visual and you can write a function once and use it many times.

Another place where visual programming is popular is among music producers, with systems like Max/MSP[1] and PureData[2].

I dabbled in PureData a little, and while it seemed to be ok for simple things, I imagine that for anything even moderately complex, it would quickly become a nightmare.

While visual programming paradigms seem like a nice thing at first glance, they are missing out on whole ecosystems of tools developed over many decades for text-based programming. Things like debugging, version control, grep, search/replace, all the features of advanced text editors like vim or emacs, etc.

[1] - https://en.wikipedia.org/wiki/Max/MSP

[2] - https://en.wikipedia.org/wiki/Pure_Data

Also node-based visual compositing (eg. Nuke / Natron / Blender's compositor). It works very well there, although it does rely on people doing proper programming to create the nodes.

I don't know what your definition of a "moderately complex" program looks like, but I have to say that from my own dabbling with PureData I really enjoyed the way it handled the concepts of abstraction and encapsulation.

It's been long enough that I've forgotten the terminology, but I remember thoroughly enjoying the process of first building a widget, then meticulously arranging all of the little boxes, color-coding, and labeling various sections until it looked visually attractive. Then when I was satisfied, I could take that entire widget and abstract it away as a small box with only the relevant input/output connectors.

I guess it's always just stuck out in my mind as the one time I really dug into a visual language, and the aesthetic aspect of organizing my "code" was very appealing. It's been a decade since I last opened any of those old project files, but I can still picture many of the components I built with my mind's eye. In and of itself, that's got to be worth something.

I imagine that someday we'll see the rise of a programming metaphor that works as a hybrid of code and visual. Even though working with PureData was inspirational, I don't see text-based languages losing relevancy any time soon. However, I think that while text code is great for representing the flow of logic, higher-order organizational constructs (such as class hierarchies) might be better represented by visual relationships. If I give you a paper and pencil and ask you to map out interconnected relationships between a bunch of entities, you're probably going to start drawing boxes and lines-- and end up with something that looks a lot like PureData.

Especially if you consider the potential of future iterations on today's VR/AR concepts, I wouldn't be too surprised if programming languages eventually looked like color-coded interconnected boxes of text code that can be rearranged in space. It wouldn't even be that far-fetched to imagine animations being included to enhance a programmer's ability to visualize the flow of logic. And I don't think that such concepts should be particularly offensive to those who consider themselves to be serious programmers.

I imagine that someday we'll see the rise of a programming metaphor that works as a hybrid of code and visual.

You're going to enjoy the Eve language...[1][2] :-)

[1] http://eve-lang.com/

[2] http://incidentalcomplexity.com/

Pd and Max/MSP are indeed great languages, at least with respect to being able to visualize audio signal flows. But I beg to differ with this idea that they can't be fast or efficient. Such languages can be compiled just like any other, though Pd doesn't do this in order to retain the flexibility of dynamic patching.

[1] I helped write a system called Heavy which can translate Pure Data patches into fast C code. https://enzienaudio.com/

[2] Here's a simple example video. https://www.youtube.com/watch?v=_zwI5g3NNYw

Jeremy Bernstein's discussion of NATO+3d modular has some interesting screen dumps of Max/MSP programs. [1]

Depending on the temperament of the "NATO.0+55 pilots" [2], the code could get pretty ahem "artistic" looking. [3]

[1] http://www.bootsquad.com/old_site/nato/nato00.html

[2] https://en.wikipedia.org/wiki/Nato.0%2B55%2B3d#NATO.0.2B55_p...

[3] https://en.wikipedia.org/wiki/Nato.0%2B55%2B3d#/media/File:N...

The nice thing about VPLs is that they are more intuitive to people with non-programming experience. I imagine many Max/MSP / PD artists have never written a line of C in their life. And even if you have programming experience, VPLs can be a lot quicker to set up for certain tasks versus writing a full fledged plugin. So VPLs can be great as a prototyping / experimentation tool.

But yes, absolutely, for more complex tasks (and my examples would be: DSP routines such as filtering, anti-alias oscillators, etc.), it would be better to use a text language. Both PureData and Max/MSP have external objects (that you write and compile in a text based language) for this purpose... although, even these objects will never be as fully optimized as a plugin that is completely text-language based.

I'm actually reading this article while in a two-day introduction to PLC programming. It's been pretty fascinating, and is an interesting view into earlier days of programming...

...From here, I definitely feel like there's something "we" missed in how these systems work, and the situations they describe. But there's also a great deal that they've missed - and are stuck in the 80s.

I think the big one is that these systems (PLC visual programming environments) don't let me make my own domain-specific languages, and that's maybe the killer app of modern code.

But there's also some interesting bits - there's something that looks like agent-based programming: There's a series of environments, and you have a function (agent) that modifies an environment. You point it at each the environments, just like a loop, and it does it's thing, like a weird cross between functional and state-based, that works because it's all a form of stigmergy.

> stigmergy

This is a new word for me—thanks :-)

It's a word that dictionary.com doesn't know. Anybody got a (ELI5-ish) definition?

Wikipedia: Stigmergy is a mechanism of indirect coordination between agents or actions. The principle is that the trace left in the environment by an action stimulates the performance of a next action, by the same or a different agent.

I usually think of it as "communication through modification of the environment".

And agent observes their environment, makes a decision about how to modify it, modifies it. The same or a different agent then does the same. Instead of a central authority dictating tasks, each agent knows the complete plan, and compares the current state to the plan to find the next step, then does it.

https://en.wikipedia.org/wiki/Ant_colony_optimization_algori... is how I first learned about the idea, and remains a good introduction.

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_...

Yet user's of LabView describe it as a horror to actually use practically [1].

[1] https://jshoer.wordpress.com/2007/08/03/why-i-hate-despise-d...

This person is very inexperienced with LabVIEW. The first two points are not true, and there are lots of hidden shortcuts for removing mouse use. (Ctrl-Space)

I was similarly furious with LabVIEW before I started working with people who had been using it for decades.

It's the easiest language I've used for making graphical user interfaces.

There are so many vastly different approaches to visual programming out there, that anecdotes about one person's bad experience with one particular decades-old system or application doesn't invalidate the whole idea of visual programming.

I'm very impressed by the usability of Grasshopper [1], the visual programming language in the Rhinoceros3D [2] nurbs modeling tool.

It feels like the people who designed it use it themselves regularly, which can't be said for many other visual programming languages. Plus the user interface and component libraries are built on top of and integrated with the wonderfully powerful set of graphics capabilities that Rhino supports.

Grasshopper is very popular for architecture design [2], and even jewelry [4] and 3d printing.

[1] http://www.grasshopper3d.com/

[2] https://www.rhino3d.com/

[3] http://www.grasshopper3d.com/video/video/search?q=architectu...

[4] http://www.grasshopper3d.com/video/video/search?q=jewelry

The Wikipedia page links to a credible article which mentions that "the software that drives it is written in C++ and consists of 200,000 lines of code for the operational system and 250,000 lines of code for the simulation systems.[2]"

What am I missing?

I assume that like any mission critical benevolent guardian mega robot software, it has parts written in many different languages. It's kind of hard to count the number of lines of code written in a visual programming language. My guess is that LabView was probably used in data collection and device control, and possibly for the gui, which is what it's designed to do.

I worked with someone at TomTom who worked on it in his previous job, and whose name is mentioned in the acknowledgements of that paper. I could ask him for more information about the parts he wrote in LabView, if you like. Here's a presentation about the Maeslantkering's fault tolerant software architecture. [1]

[1] http://www.sasg.nl/sasg_30_BOS_Fault-tolerance.pdf

> I assume that like any mission critical benevolent guardian mega robot software, it has parts written in many different languages.

Oh -- mine too, I'm just surprised NI's mega marketing army isn't mentioning that everywhere :-).

Also, no need to bother you colleague for me, but whoa, thanks for the presentation!

Also 3D graphics.

Both in real-time and pre-rendered graphics, node graph-style programming languages are very much a thing. Unreal Engine's Blueprints system, Motionbuilder's nodes system, Maya's graph systems...

And they can get pretty huge and complex.

Reply on news.ycombinator.com