Visual Programming Is Unbelievable (2015)(outsystems.com)
outsystems.com
Visual Programming Is Unbelievable (2015)
http://www.outsystems.com/blog/2015/03/visual-programming-is-unbelievable.html
106 comments
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.
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.
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
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
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.
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/
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
[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...
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.
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.
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'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.
...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 :-)
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.
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_...
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...
[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.
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
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?
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 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!
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.
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.
[deleted]
'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 elements, I visually see the data in my head (the gui elements), then I run the algorithm and see the elements 'move' into position dependent upon their dock/anchor/margin properties (also taking into account previously docked elements positions, parent element resize delta, etc). This is the visual I need to see on screen! I need to see my real data being manipulated by my algorithms and moving from A to B. I expect with this kind of animation I could easily see when things go wrong naturally, seeing as visual processing happens with no conscious effort.
Instead visual programming thinks I want to see the textual properties of my objects in memory in fancy coloured boxes, which is not the case at all.
When I write code, for example a layout algorithm for a set of gui elements, I visually see the data in my head (the gui elements), then I run the algorithm and see the elements 'move' into position dependent upon their dock/anchor/margin properties (also taking into account previously docked elements positions, parent element resize delta, etc). This is the visual I need to see on screen! I need to see my real data being manipulated by my algorithms and moving from A to B. I expect with this kind of animation I could easily see when things go wrong naturally, seeing as visual processing happens with no conscious effort.
Instead visual programming thinks I want to see the textual properties of my objects in memory in fancy coloured boxes, which is not the case at all.
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.
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.
For fairly simple configuration tasks IMO visual programming is a powerful tool for non-programmer end users to actually create programs which are not prone to syntax errors, misguided loop conditions or such. It also means one does not need to learn yet another syntax. True, the application domains are limited, but for example the common node based computational graph generation done for example in Blender and other visual software works quite well.
It's not meant for professional programming, it's about empowering the end user with programmable tools.
It's not meant for professional programming, it's about empowering the end user with programmable tools.
But at what point does simple become complex? It's all well and good saying only use it for simple tasks, but when real life complexity comes knocking, you end up with this sort of magic [1] that is far worse than any C++ I've seen in the wild.
[1] http://scriptsofanotherdimension.tumblr.com
[1] http://scriptsofanotherdimension.tumblr.com
People interested in VP really, really should learn about DRAKON[1], the Russian style guide for structured dataflows.
I've used it for real projects and it actually solves the spaghetti problem. Compare this:[2] with this:[3].
[1] https://en.wikipedia.org/wiki/DRAKON
[2] http://scriptsofanotherdimension.tumblr.com/image/1386972466...
[3] https://upload.wikimedia.org/wikipedia/commons/0/0f/Dutch_cr...
I've used it for real projects and it actually solves the spaghetti problem. Compare this:[2] with this:[3].
[1] https://en.wikipedia.org/wiki/DRAKON
[2] http://scriptsofanotherdimension.tumblr.com/image/1386972466...
[3] https://upload.wikimedia.org/wikipedia/commons/0/0f/Dutch_cr...
A drakon node does not seem to support multiple input values? That's why these visual graphs get convoluted. Compute nodes deal with multiple input and output connections.
Good call. Drakon is for control flow specification, not data flow specification. However having a standard for splitting subsystems in separate modules and laying out components using regular rules would benefit any kind of visual graph.
Visual programming excels at data wrangling (parsing structured data in an input/output pipeline that spits the same filtered data in a new format and structure).
You're right that until now its usage has been limited to domain-specific languages for automating applications. But with the emergence of functional programming in the mainstream and visual tools that follow that paradigm, I predict that soon there will be visual tools that allow quite general programming. (I've already seen working prototypes, and they deliver on most of the promises).
You're right that until now its usage has been limited to domain-specific languages for automating applications. But with the emergence of functional programming in the mainstream and visual tools that follow that paradigm, I predict that soon there will be visual tools that allow quite general programming. (I've already seen working prototypes, and they deliver on most of the promises).
Watch Bret Victor's videos about Learnable Programming[1], in particular Stop Drawing Dead Fish. [2] Only because visual tools in the past were limited to putting properties in boxes doesn't mean that all visual tools have to be that way.
[1] http://worrydream.com/LearnableProgramming/
[2] https://vimeo.com/64895205
[1] http://worrydream.com/LearnableProgramming/
[2] https://vimeo.com/64895205
I have seen it, and while Bret Victors 'research' is interesting, none of it actually scales to a practical level.
Because it is not engineered to industrial levels. It lacks encapsulation and packaging, but those can be added.
Have you seen the tools by Chris Granger (Light Table, Eve)? Although they are not as spectacular as Victor's, those show a lot of promise to become practical tools.
Have you seen the tools by Chris Granger (Light Table, Eve)? Although they are not as spectacular as Victor's, those show a lot of promise to become practical tools.
Bret Victor's ideas lack a lot more than that. Complex systems contain hundreds of sub systems which in turn can contain hundreds of algorithms, which then contain many many variables. All interacting in some way. His ideas simply don't scale to this level (he works with < 10 variables, enough for a nicely packaged demo).
Chris Granger himself stopped working on LightTable because he didn't believe in the project, and if you use it, the live editing gives minimal gains in productivity. As well as being buggy, slow, distracting and potential dangerous when blindly running half complete IO operations.
As for Eve, well.. his first release was a visual programming tool that inflated 3 line sql statements to take up a whole page with, you guessed it, boxes and arrows. Now he is working on a 'card wiki' idea which effectively tries to hide all the program logic behind pictures and hyperlinks. Neither are good ideas, or once again, scale in any meaningful way.
Chris Granger himself stopped working on LightTable because he didn't believe in the project, and if you use it, the live editing gives minimal gains in productivity. As well as being buggy, slow, distracting and potential dangerous when blindly running half complete IO operations.
As for Eve, well.. his first release was a visual programming tool that inflated 3 line sql statements to take up a whole page with, you guessed it, boxes and arrows. Now he is working on a 'card wiki' idea which effectively tries to hide all the program logic behind pictures and hyperlinks. Neither are good ideas, or once again, scale in any meaningful way.
Why do you think that doesn't scale? Hiding information is the basis for progressive disclosure, which is essential to handling the limitations of short-term human memory. Wikipedia is card-based,* and it is one of the five largest sites in the web. See Cognitive Dimensions[1] for ways to make visual systems scale.
As soon as you add encapsulation and abstraction, the system can scale; it's no different than hiding code logic behind function declarations and object schemas. If you add easy composition, like modern functional languages have, such systems could be more scalable than traditional imperative languages; code outliners like Leo follow the same structural principle, and they're great for programming.
[1] https://en.wikipedia.org/wiki/Cognitive_dimensions_of_notati...
* Ok, Wikipedia contains articles and not code, but my point is that the structure can handle lots of hierarchical content in multiple categories.
As soon as you add encapsulation and abstraction, the system can scale; it's no different than hiding code logic behind function declarations and object schemas. If you add easy composition, like modern functional languages have, such systems could be more scalable than traditional imperative languages; code outliners like Leo follow the same structural principle, and they're great for programming.
[1] https://en.wikipedia.org/wiki/Cognitive_dimensions_of_notati...
* Ok, Wikipedia contains articles and not code, but my point is that the structure can handle lots of hierarchical content in multiple categories.
Wikipedia is also written in English, and made for human consumption. English is infinitely more scalable than any programming language, and the brain is far more capable of understanding than a computer. So comparing the two is unfair to say the least.
Additionally simply adding 'encapsulation and abstraction' does not equal scale. Live programming for instance requires context and re-running of code on every edit (and we could be talking millions of lines of code that need to execute), re-reading of data files, re-running of prior user input and so on. There's a reason it is only implemented for small systems (read, useless practically).
Additionally simply adding 'encapsulation and abstraction' does not equal scale. Live programming for instance requires context and re-running of code on every edit (and we could be talking millions of lines of code that need to execute), re-reading of data files, re-running of prior user input and so on. There's a reason it is only implemented for small systems (read, useless practically).
> English is infinitely more scalable than any programming language, and the brain is far more capable of understanding than a computer. So comparing the two is unfair to say the least.
IMHO programming a large system shouldn't be all that different from writing an encyclopedia, or rather a math textbook; the same combination of informal explanation and formal demonstrations could be the shape that "visual" programs could take. Literate programming is written in English, and it provides much of the same advantages of the encyclopedia or technical book. Systems like IPython / Jupyter work in that direction, and they belong in the family of visual programming (although they use "classic" languages for the formal part, nothing stops them from also including graphical models as part of the code specification).
Programming languages should be made for human consumption, and one of the promises of visual languages is that they use secondary notation to convey the meaning of the program, so that parts that are not visible to the compiler are still relevant.
I believe that programming environments should converge towards a hybrid of programming, using the best representation for each concept - like text (to represent abstract concepts), diagrams (to represent more physical properties - time, data flows, and dependencies between modules), and raw text for the human-readable comments that explain how everything is tied together. If you build a programming environment like that, my comparison is not unfair at all.
>Live programming for instance requires context and re-running of code on every edit (and we could be talking millions of lines of code that need to execute), re-reading of data files, re-running of prior user input and so on. There's a reason it is only implemented for small systems (read, useless practically).
Modern IDEs are capable of doing a lot of that when in debug mode, I see no reason why having a language with a graphical syntax should make any difference - it just places a little more weight on the parser and graphic card.
IMHO programming a large system shouldn't be all that different from writing an encyclopedia, or rather a math textbook; the same combination of informal explanation and formal demonstrations could be the shape that "visual" programs could take. Literate programming is written in English, and it provides much of the same advantages of the encyclopedia or technical book. Systems like IPython / Jupyter work in that direction, and they belong in the family of visual programming (although they use "classic" languages for the formal part, nothing stops them from also including graphical models as part of the code specification).
Programming languages should be made for human consumption, and one of the promises of visual languages is that they use secondary notation to convey the meaning of the program, so that parts that are not visible to the compiler are still relevant.
I believe that programming environments should converge towards a hybrid of programming, using the best representation for each concept - like text (to represent abstract concepts), diagrams (to represent more physical properties - time, data flows, and dependencies between modules), and raw text for the human-readable comments that explain how everything is tied together. If you build a programming environment like that, my comparison is not unfair at all.
>Live programming for instance requires context and re-running of code on every edit (and we could be talking millions of lines of code that need to execute), re-reading of data files, re-running of prior user input and so on. There's a reason it is only implemented for small systems (read, useless practically).
Modern IDEs are capable of doing a lot of that when in debug mode, I see no reason why having a language with a graphical syntax should make any difference - it just places a little more weight on the parser and graphic card.
> Programming languages should be made for human consumption
The problem here is the "impedance mistmach" between humans and computers. Wikipedia is not a good example: it is exclusively for humans. If there is a "program" for the computer, it's minimal: "search this", "when I click here, take me to this page" (you'll notice everything more complex than that, even in Wikipedia, requires its own mini-language). This is the kind of trivial systems which are easily encoded by "visual" programming.
The problem is that real computer systems need to be understood by the computer as well as by humans. In order for something to be understood by a computer, it must be specified in formal terms; English -- natural language, actually -- is terrible for this. Once you're working in a complex system with a formal language, the limitations of these "visual" tools become evident.
The problem here is the "impedance mistmach" between humans and computers. Wikipedia is not a good example: it is exclusively for humans. If there is a "program" for the computer, it's minimal: "search this", "when I click here, take me to this page" (you'll notice everything more complex than that, even in Wikipedia, requires its own mini-language). This is the kind of trivial systems which are easily encoded by "visual" programming.
The problem is that real computer systems need to be understood by the computer as well as by humans. In order for something to be understood by a computer, it must be specified in formal terms; English -- natural language, actually -- is terrible for this. Once you're working in a complex system with a formal language, the limitations of these "visual" tools become evident.
> Wikipedia is not a good example: it is exclusively for humans.
Not exclusively. Bots and Wikidata have shown themselves pretty capable of doing complex automated tasks on top of the structured data contained in the encyclopedia. And the wiki platform plus templates is a very general and flexible data structure that makes it easy for humans and software to collaborate.
> In order for something to be understood by a computer, it must be specified in formal terms
This doesn't need to be that way, at least not for 100% of the system. End-user development tools like spreadsheets and Programming By Example can be used to ease the impedance mismatch without requiring the human to specify by hand every single step in a formal language, so that partially ambiguous inputs can be used to specify valid programs.
Only the task of building system software should require the full technical approach; most business applications can benefit from looser approaches - in fact being less strict can be a benefit in the requirements specification phase, just like User-centered design has shown us.
Combine that with logic solvers and deep learning, and in the future we could get some systems that can use very high-level commands to build fairly complex automated behaviors.
Not exclusively. Bots and Wikidata have shown themselves pretty capable of doing complex automated tasks on top of the structured data contained in the encyclopedia. And the wiki platform plus templates is a very general and flexible data structure that makes it easy for humans and software to collaborate.
> In order for something to be understood by a computer, it must be specified in formal terms
This doesn't need to be that way, at least not for 100% of the system. End-user development tools like spreadsheets and Programming By Example can be used to ease the impedance mismatch without requiring the human to specify by hand every single step in a formal language, so that partially ambiguous inputs can be used to specify valid programs.
Only the task of building system software should require the full technical approach; most business applications can benefit from looser approaches - in fact being less strict can be a benefit in the requirements specification phase, just like User-centered design has shown us.
Combine that with logic solvers and deep learning, and in the future we could get some systems that can use very high-level commands to build fairly complex automated behaviors.
You have a point about wiki bots, I hadn't thought of that. But isn't the "Wiki platform plus templates" an example of a textual programming language with a precise syntax and rules?
As for the rest, I think it's a pipe dream except for the most basic, "build this out of predetermined blocks" apps.
As for the rest, I think it's a pipe dream except for the most basic, "build this out of predetermined blocks" apps.
Does the Visual Editor in Wikipedia count as a visual tool? :-P
My point is that the structure of a wiki, where each unit of content is a separate building block, can be used to build a visual system in the same way that you can build a textual one; the basic components of storage and APIs are the same, only the thin syntax layer is different. You are no longer dependent on the single stream of raw text following a strict syntax, which is the basis from which compilers generate binary code in traditional languages; you'd be able to build programs by arranging code and data in a network within a semi-structured platform, which is one of the characteristics of visual tools.
You're right that stuff like this has been a pipe dream for at least half a century, since the Mother of All Demos; but in the very recent years I've seen a lot of the required pieces falling into place, so I believe it to be possible.
If we apply the same amount of engineering work and refinements that went form Engelbart's demo to modern desktop systems, we could have a functioning system with this paradigm; the basis are in place for it, and many of us have the vision of the benefits it shall provide.
Of course, part of building a program may require describing some components using a textual representation, where it makes the most sense; but with a wiki-like "outliner" platform, parts of the working system could be programmed using visual code, and be integrated with those other components programmed in traditional languages. Heck, GUI builders and visual tools for database schemas already work that way; the only thing they lack is the capability to be expanded with new components, which this new family of visual tools have.
My point is that the structure of a wiki, where each unit of content is a separate building block, can be used to build a visual system in the same way that you can build a textual one; the basic components of storage and APIs are the same, only the thin syntax layer is different. You are no longer dependent on the single stream of raw text following a strict syntax, which is the basis from which compilers generate binary code in traditional languages; you'd be able to build programs by arranging code and data in a network within a semi-structured platform, which is one of the characteristics of visual tools.
You're right that stuff like this has been a pipe dream for at least half a century, since the Mother of All Demos; but in the very recent years I've seen a lot of the required pieces falling into place, so I believe it to be possible.
If we apply the same amount of engineering work and refinements that went form Engelbart's demo to modern desktop systems, we could have a functioning system with this paradigm; the basis are in place for it, and many of us have the vision of the benefits it shall provide.
Of course, part of building a program may require describing some components using a textual representation, where it makes the most sense; but with a wiki-like "outliner" platform, parts of the working system could be programmed using visual code, and be integrated with those other components programmed in traditional languages. Heck, GUI builders and visual tools for database schemas already work that way; the only thing they lack is the capability to be expanded with new components, which this new family of visual tools have.
> Why do you think that doesn't scale?
Because it doesn't. Watch Bret Victor's last talk about Eve. All those ideas fail when you give them to novices and try to do anything more complex than describing a few static relationships.
Maybe there's a way, but I'm skepitcal.
Because it doesn't. Watch Bret Victor's last talk about Eve. All those ideas fail when you give them to novices and try to do anything more complex than describing a few static relationships.
Maybe there's a way, but I'm skepitcal.
Yet end users are able to build fairly complex data structures and conditional processing using spreadsheets, so we know for sure that it can be done.
Of course experimental tools will be severely limited compared with industrial IDE systems that have been polished literally for decades; it will take years before we get these new tools into shape and learn what their best use cases are. But I'm not skeptical, because I've seen it happen before, and the conditions for it are now better than ever.
Of course experimental tools will be severely limited compared with industrial IDE systems that have been polished literally for decades; it will take years before we get these new tools into shape and learn what their best use cases are. But I'm not skeptical, because I've seen it happen before, and the conditions for it are now better than ever.
Spreadsheets IMHO are a solution space that hasn't been sufficiently explored. However they are not particularly visual (especially if you try to do complex things with them), they are very much domain specific they are extremely computationally inefficient, they're very hard to version and they become intractably complex much quicker than equivalent imperative or functional programs.
I've thought about what could be done to improve on their weaknesses (like strong typing, bridging the gap to databases, better table naming), even wrote some code in this direction, but anything I can think of involves either making them less visual, less user friendly or both and doesn't even begin to address the lack of generality
Finally I have to point out that some spreadsheets have been around for longer than many programming languages in current use so they don't actually lack maturity, yet they have seen little improvement in over a decade.
I've thought about what could be done to improve on their weaknesses (like strong typing, bridging the gap to databases, better table naming), even wrote some code in this direction, but anything I can think of involves either making them less visual, less user friendly or both and doesn't even begin to address the lack of generality
Finally I have to point out that some spreadsheets have been around for longer than many programming languages in current use so they don't actually lack maturity, yet they have seen little improvement in over a decade.
Just because they haven't replaced coding in a text editors for all use cases doesn't mean they "failed". In my industry (PLC, building automation), visual programming languages are the norm and are extremely successful.
They significantly drop the barrier to entry and allow basic controlling of systems for non-programmers.
They significantly drop the barrier to entry and allow basic controlling of systems for non-programmers.
"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.
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.
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.)
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.)
To add to this, I present to you screenshots of visual programming spaghetti code in all of it's glory [1].
[1] http://scriptsofanotherdimension.tumblr.com
[1] http://scriptsofanotherdimension.tumblr.com
So one advantage of visual programming languages, spaghetti code literally looks like a plate of spaghetti!
> screenshots of visual programming spagetti code in all of it's glory
While that serves as a reminder that visual programming isn't a cure for spaghetti code, (a) it was never claimed to be, and (b) terrible spaghetti code exists in all sufficiently powerful programming environments. I don't know that I'd enjoy tracing through that any more than untangling a mess of objects and functions that call each other—but then, I don't know that I'd "enjoy" it any less, either.
While that serves as a reminder that visual programming isn't a cure for spaghetti code, (a) it was never claimed to be, and (b) terrible spaghetti code exists in all sufficiently powerful programming environments. I don't know that I'd enjoy tracing through that any more than untangling a mess of objects and functions that call each other—but then, I don't know that I'd "enjoy" it any less, either.
[deleted]
Takes me back to my Max/MSP days.
That post has no clue about the shortcomings, which were true in the past but needn't be any longer. Programmers have been doing visual programming since the advent of the visual debugger that shows updated values during program execution, and they are requesting more and more of it with tools for Live Programming like jsfiddle or LightTable (for VP in classic languages) or new languages like Apparatus[1] or Eve[2].
We are in the middle of the Visual Programming renaissance, now that the hurdles that limited composability of visual programs have been theoretically solved in the last decade by Programming Languages researchers, and computers are finally powerful enough to move visual languages without slowing to a crawl.
Unfortunately, Visual Programming suffers the same curse as Artificial Intelligence: for every breakthrough that produces revolutionary new tools, it is no longer considered Visual Programming but merely "how the tools should work".
[1] http://aprt.us/
[2] http://eve-lang.com/
We are in the middle of the Visual Programming renaissance, now that the hurdles that limited composability of visual programs have been theoretically solved in the last decade by Programming Languages researchers, and computers are finally powerful enough to move visual languages without slowing to a crawl.
Unfortunately, Visual Programming suffers the same curse as Artificial Intelligence: for every breakthrough that produces revolutionary new tools, it is no longer considered Visual Programming but merely "how the tools should work".
[1] http://aprt.us/
[2] http://eve-lang.com/
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.
Selecting text from lists is not visual, neither is relative 2D offsets.
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
[1] https://bz.apache.org/ooo/show_bug.cgi?id=117508
Not only that, they're functionally-evaluated!
And they have all the same problems; beyond a certain problem size they're unwieldy and confusing.
At work we use a blend of C++ with Unreal Engine's visual programming language Blueprints. I am going to be honest with you guys here: I love blueprints.
They are very limited compared, lacking even maps. When it comes to connecting existing behavior together they are king. Consider the parts of game development which cannot be made generic. By sticking those in Blueprints we get nice high level code.
They are very limited compared, lacking even maps. When it comes to connecting existing behavior together they are king. Consider the parts of game development which cannot be made generic. By sticking those in Blueprints we get nice high level code.
I found it odd there is no mention to Scratch or Scheme Bricks.
https://vimeo.com/62615513
https://vimeo.com/62615513
This. Scratch is the killer application of visual programming. It's educational, yes, but it's excellent at that (from experiences from my two kids).
Is there a production system or game for sale that's written in Scratch?
Visual programming does not work well mostly due to a physical problem: typing characters into a computer is much faster and flexible at generating imperative code than using a mouse. There are declarative domains, such as simple UI building, where that is less true, but even then, when you kick out to the event handler, text is much faster.
IntelliJ has done more for visual programming, by integrating visual/wizard aspects seamlessly into a text-dominant environment, than almost all the visual programming advocates of the last fifty years.
Visual environments do demo well, and sometimes convince businessmen that they won't need to pay those annoying and expensive programmers so much money. Hence its enduring appeal to the business world.
IntelliJ has done more for visual programming, by integrating visual/wizard aspects seamlessly into a text-dominant environment, than almost all the visual programming advocates of the last fifty years.
Visual environments do demo well, and sometimes convince businessmen that they won't need to pay those annoying and expensive programmers so much money. Hence its enduring appeal to the business world.
I think visual programming would match some problem domains very well, such as games (Unreal Blueprints), music (Reason, Max, PD), Neural Nets (???), UI (Quartz Composer), robotics (???), as well as the already mentioned spreadsheets. Most of these domains focus on flow and transition of scalars. The problem that I've had in the past with PD and MAX is in coordinating of multiple inputs that flow into a node. Sometimes I'd have to create a special node to properly sequence inputs. But, that is a limitation of the tool, not the idiom.
Another problem is how to explore and manipulate a flow graph? I like the idea of using a force directed graph. Here is one, where I mapped a visual music synthesizer to Jeffry Heer's Prefuse toolkit: https://www.youtube.com/watch?v=a703TTbxghc
Would love to explore authoring flow, using force directed graphs on an iPad pro + pencil (and its ilk), where one could not only draw arc between nodes, but also between convex hulls of a collection of nodes.
Another problem is how to explore and manipulate a flow graph? I like the idea of using a force directed graph. Here is one, where I mapped a visual music synthesizer to Jeffry Heer's Prefuse toolkit: https://www.youtube.com/watch?v=a703TTbxghc
Would love to explore authoring flow, using force directed graphs on an iPad pro + pencil (and its ilk), where one could not only draw arc between nodes, but also between convex hulls of a collection of nodes.
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/
https://www.coati.io/
So it would be like a souped-up Visual Assist (as used in VS C++)?
Here is a comprehensive list of different visual programming languages.
http://blog.interfacevision.com/design/design-visual-progarm...
The issue isn't visual programming but rather that we haven't found many good cases to use it still.
I do think visual programming is going to have a bigger and bigger impact in things like robotics, space exploration etc where you need more tactile access to computation power.
It's kind of like with the idea of a 3d interface. It only make sense when the holistic whole rather than the details are important.
It makes no sense to create a 3d warehouse I can walk around when I could just do a search and a list.
But you wouldn't necessarily want to control a robot doing repairs on your spaceship by having to program it every time you wanted it to do something new.
http://blog.interfacevision.com/design/design-visual-progarm...
The issue isn't visual programming but rather that we haven't found many good cases to use it still.
I do think visual programming is going to have a bigger and bigger impact in things like robotics, space exploration etc where you need more tactile access to computation power.
It's kind of like with the idea of a 3d interface. It only make sense when the holistic whole rather than the details are important.
It makes no sense to create a 3d warehouse I can walk around when I could just do a search and a list.
But you wouldn't necessarily want to control a robot doing repairs on your spaceship by having to program it every time you wanted it to do something new.
Similar discussion here: https://news.ycombinator.com/item?id=11204017
(From my submission just 6 days ago.)
(From my submission just 6 days ago.)
The problem with visual programming is the same as those UML tools where you designed classes with boxes then filled in the code later. First of all it's quicker and easier to define with text than drawing. And second of all the detail is the important bit. You can't design the high level code in isolation and then fill in how it works. You need to build up the components from the details and see how the abstractions emerge. And that's not very visual/.
Visual programming is exploding in Unreal Engine with Blueprints to define in-game behaviours.
https://docs.unrealengine.com/latest/INT/Engine/Blueprints/i...
I for myself think visual programming is not really programming, since by following that train of thought any GUI like Photoshop Actions could be considered programming.
https://docs.unrealengine.com/latest/INT/Engine/Blueprints/i...
I for myself think visual programming is not really programming, since by following that train of thought any GUI like Photoshop Actions could be considered programming.
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".
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".
Except we can perfectly communicate visually, and we do it all the time.
It is common to draw diagrams when you are trying to understand or explain a problem. If you want to give somebody a rough idea of how your program works, it is infinitely more likely that you use some kind of drawing than music, touch or smell.
I don't agree neither with visual programming inviting people to lose time in details. The same you do not lose time thinking about how to structure a sentence to write a program, you would not lose it changing colors and fonts in a visual programming environment with an enforced "syntax".
I do not like visual programming (I have had very bad experiences with LabView), but I think it may be as good (or as bad) as text if the field had evolved differently.
It is common to draw diagrams when you are trying to understand or explain a problem. If you want to give somebody a rough idea of how your program works, it is infinitely more likely that you use some kind of drawing than music, touch or smell.
I don't agree neither with visual programming inviting people to lose time in details. The same you do not lose time thinking about how to structure a sentence to write a program, you would not lose it changing colors and fonts in a visual programming environment with an enforced "syntax".
I do not like visual programming (I have had very bad experiences with LabView), but I think it may be as good (or as bad) as text if the field had evolved differently.
Visual communication without language is always much simpler and more abstract than other forms of visual communication. Without invoking a language with syntax, you simply cannot get enough information density to make it useful.
The only time we generally communicate visually is when we want to express something with less detail (e.g. charts, diagrams, graphs, emoji, etc).
The only time we generally communicate visually is when we want to express something with less detail (e.g. charts, diagrams, graphs, emoji, etc).
"Except we can perfectly communicate visually, and we do it all the time."
Hmmm, someone should create a visual programming language using Dilbert characters & iconography. :)
Hmmm, someone should create a visual programming language using Dilbert characters & iconography. :)
The title sounds like it comes from BuzzFeed.
...otherwise you might just end up in the wrong side of history.
And I don't believe it worked within the US Army [0][1][2] - unless I'm not correctly remembering the history of Outsystem's Visual Programming there...
[0] https://www.outsystems.com/company/news/2012/outsystems-us-a... [1] http://www.army.mil/article/96352/SEC_s_Cloud_Mil_solution_f... [2] http://www.afcea.org/content/?q=us-army-innovates-cloud-comp...
And I don't believe it worked within the US Army [0][1][2] - unless I'm not correctly remembering the history of Outsystem's Visual Programming there...
[0] https://www.outsystems.com/company/news/2012/outsystems-us-a... [1] http://www.army.mil/article/96352/SEC_s_Cloud_Mil_solution_f... [2] http://www.afcea.org/content/?q=us-army-innovates-cloud-comp...
I interned at VPL Research[1] in 1992 and they had a Mac-based VPL for controlling objects in VR called Body Electric[2] that was really fun to use - especially since I'd never seen anything like it. I implemented gravity for objects and a virtual arm using it. If I remember correctly, debugging could be a challenge. It was later interfaced with Macromedia Director[3] to control desktop apps.
[1] https://en.wikipedia.org/wiki/VPL_Research
[2] http://www.jaronlanier.com/vpl.html
[3] http://www.art.net/~hopkins/Don/lang/bounce/bounce.html
[1] https://en.wikipedia.org/wiki/VPL_Research
[2] http://www.jaronlanier.com/vpl.html
[3] http://www.art.net/~hopkins/Don/lang/bounce/bounce.html
Software developed using visual programming languages often has the potential/necessity to include content which constitutes a 'visual/non-visual hybrid' as the application becomes more complex: the boxes to which arrows are connected usually contain things which are lines of text/symbols/formulae, i.e. are not 'diagrammatic'. Visual programming languages tend to use diagrams for structure and 'notationally rich text' for content and are therefore addressing requirements for simplifying the representation of and increasing the intelligibility of the structure of application development as their highest priority. The reason why this rationale can seem to be problematic is because justifying/achieving the job of meaningfully 'separating structure from content' in software brings it's own highly contingent/subjective challenges (as any detractor of object-oriented design will be aware). For instance, how far could/should you go in trying to 'diagrammatise' the notational content of boxes in a boxes and arrows language. Is the fact that you are diagrammatising the app at all enough of a benefit in terms of reducing the learning curve/programming aptitude requirement, such that 'further/total diagrammatisation' is nothing more than a 'diminishing returns' consideration? What criteria do you use to decide the 'diagramtic benefit limit'? The biggest growing business in software development today is 'triple A games development' and visual programming languages are used as a way of giving designers the means to create content and gameplay without requiring the designer to have programming skill levels that match those of developers (developers can then optimise the designer's work by converting it into C++ to get the frame rate up and integrating it with the rest of their native codebase). Here's an example of an impressive case in point done in UE4 Blueprints without a single line of C++: https://www.youtube.com/watch?v=EjCandEgtHo
I don't get it - isn't the Outsystems Platform (following the link from the blog) a visual programming environment? This article seems very odd coming from Outsystems itself. What am I missing here?
They are probably dissatisfied with developer stance toward their RAD framework.
I'm sure various business apps can be built successfully on top of their Visual programming IDE, but even Microsoft has mostly abandoned that route.
But I dislike that even they propagate the lie that systems are slow when built on top of "High level language". That is mostly an optimization problem and you can often optimize well beyond what people would be willing to do in lower level language.
I'm sure various business apps can be built successfully on top of their Visual programming IDE, but even Microsoft has mostly abandoned that route.
But I dislike that even they propagate the lie that systems are slow when built on top of "High level language". That is mostly an optimization problem and you can often optimize well beyond what people would be willing to do in lower level language.
Showing that you're aware of all the drawbacks may give customers more confidence that they've been addressing them.
I've used outsystems, and it was straightforward. Although I prefer C#.
I've used outsystems, and it was straightforward. Although I prefer C#.
I worked quite a bit with Outsystems and like with all the tools that use boxes(/balls) with lines between them as 'visual programming', it depends largely on how you organise things if / when it becomes a big mess. After a while of working with it we usually just wrote what we needed in C# and when we had very abstract things hooked them up. It looks/works well but needs a lot of discipline (and thus training) and it's crazy expensive (for what it does) imho.
No mention of the Deutsch limit:
https://en.wikipedia.org/wiki/Deutsch_limit
https://en.wikipedia.org/wiki/Deutsch_limit
Smalltalk is pretty close. I use the GNU one (yeah, I know about Pharo) and is awesome you can switch between a Smalltalk scripting and the VisualGST browser.
Is there any visual programming language well-suited to implementing complex data structures like red-black trees? What about a recursive descent parser? File system?
I have not used visual languages extensively, but it seems like they are better suited to simple control flows with flat data structures and limited state mutation. This would explain their success for graphics shaders, audio, industrial control, etc.
I have not used visual languages extensively, but it seems like they are better suited to simple control flows with flat data structures and limited state mutation. This would explain their success for graphics shaders, audio, industrial control, etc.
Quartz Composer is a pretty effective visual programming environment. At least as far as a particular problem domain is concerned.
To illustrate of what is possible with Quartz Composer: https://youtu.be/eUEr4P_RWDA
[deleted]
We use a visual programming system in our startup's game development tool Construct 2 [1].
We may not be Visual Basic big (yet!) but we're running a successful business on a visual programming IDE with lots of users who love it!
[1] https://www.scirra.com
We may not be Visual Basic big (yet!) but we're running a successful business on a visual programming IDE with lots of users who love it!
[1] https://www.scirra.com
I have many time mused at having visual elements integrated into your code, to better explain or schematize some concepts (which many times cannot be easily explained by mere comments). The future is not visual programming, it's augmented textual programming (ATP). You heard it here first folks.
I used RAPTOR in a generic programming class at community college when trying to get into grad school 3.5 years ago. I was somewhat impressed with it, despite the bugs.
http://raptor.martincarlisle.com/
http://raptor.martincarlisle.com/
Visual programming is doing quite well in editing computational graphs in software such as Maya or Blender.
IMO, Visual programming does not have a proper definition yet. Coding frontend and coding backend are altogether two different things and sometimes users confuse the application of visual authoring (programming) in one area with the other.
But I believe it is the future. I bet you won't be carrying your laptop, enslaved by the physical keyboard, which is necessary for traditional 'coding' with you in 2030. You would be dragging and dropping stuff, perhaps in Virtual reality headset or through voice or gesture to build what you want, just like you would author in a visual platform like Adobe illustrator or in a 3d authoring tool.
Visual programming have it's own strength and weaknesses. For e.g. Creating algorithms from scratch in a Visual programming is not very productive (yet), but authoring business logic is highly effective in Visual programming. How many times, as a regular programmer you have had to write an algorithm? Most often it's just business logic that we tag under the category of an algorithm, which is not right. Algorithms are very generic piece of logic and business logic applies to your own problem/data specifically. If you have a closer look you realize that we are simply reusing algorithms or modules (created by a smaller group of people comparatively) to build the rules/business logic. What we do is mostly write glue code. we don't really need to code for that.
There are tons of examples for highly successful application of visual programming. But as an average web developer you never get to see that. Reason - Visual authoring tools are highly expensive and hence are confined to fortune 500 companies. That along with lack of quality open source implementations are the reason for visual programming to never take off among general web programming community. Even the newer generation ones like Treeline (for backend) and Bubble.is (frontend) are also closed source. NoFlo is open source and it almost started to create some buzz, but the team got sidetracked apparently, and they are using dataflow method for authoring frontend which is a highly inefficient.
You want to see successful application of Visual programming in real life? Ever heard of Enterprise Application Integration (EAI) ? Business Process Automation (BPMN/BPEL) ? Extract Transform and Load (ETL)? They all employ Visual programming to a great extend and are multi-billion dollar businesses. Do a google image search of following, in no particular order.
Dell bhoomi (EAI)
Tibco Business Works (EAI)
Snaplogic (Founded by Informatica ex. CEO) (EAI)
MuleESB/Anypoint studio (EAI)
Oracle BPEL (Business process automation)
Tibco iProcess (Business process automation)
Mendix (Web app development)
Webratio (Web app development)
(+lots of others if you dig out)
But I believe it is the future. I bet you won't be carrying your laptop, enslaved by the physical keyboard, which is necessary for traditional 'coding' with you in 2030. You would be dragging and dropping stuff, perhaps in Virtual reality headset or through voice or gesture to build what you want, just like you would author in a visual platform like Adobe illustrator or in a 3d authoring tool.
Visual programming have it's own strength and weaknesses. For e.g. Creating algorithms from scratch in a Visual programming is not very productive (yet), but authoring business logic is highly effective in Visual programming. How many times, as a regular programmer you have had to write an algorithm? Most often it's just business logic that we tag under the category of an algorithm, which is not right. Algorithms are very generic piece of logic and business logic applies to your own problem/data specifically. If you have a closer look you realize that we are simply reusing algorithms or modules (created by a smaller group of people comparatively) to build the rules/business logic. What we do is mostly write glue code. we don't really need to code for that.
There are tons of examples for highly successful application of visual programming. But as an average web developer you never get to see that. Reason - Visual authoring tools are highly expensive and hence are confined to fortune 500 companies. That along with lack of quality open source implementations are the reason for visual programming to never take off among general web programming community. Even the newer generation ones like Treeline (for backend) and Bubble.is (frontend) are also closed source. NoFlo is open source and it almost started to create some buzz, but the team got sidetracked apparently, and they are using dataflow method for authoring frontend which is a highly inefficient.
You want to see successful application of Visual programming in real life? Ever heard of Enterprise Application Integration (EAI) ? Business Process Automation (BPMN/BPEL) ? Extract Transform and Load (ETL)? They all employ Visual programming to a great extend and are multi-billion dollar businesses. Do a google image search of following, in no particular order.
Dell bhoomi (EAI)
Tibco Business Works (EAI)
Snaplogic (Founded by Informatica ex. CEO) (EAI)
MuleESB/Anypoint studio (EAI)
Oracle BPEL (Business process automation)
Tibco iProcess (Business process automation)
Mendix (Web app development)
Webratio (Web app development)
(+lots of others if you dig out)
> I bet you won't be carrying your laptop, enslaved by the physical keyboard, which is necessary for traditional 'coding' with you in 2030.
I disagree. I wouldn't have thought that Microsoft, author of Visual Basic, would be basically forced in 2015 to add improvements to their console system -- but here we are. If anything text-based programming is more prominent now than in the last 10 years.
> You would be dragging and dropping stuff, perhaps in Virtual reality headset or through voice or gesture to build what you want, just like you would author in a visual platform like Adobe illustrator or in a 3d authoring tool.
Your arms will get very tired.
> but authoring business logic is highly effective in Visual programming.
I disagree. We have one giant visual-programmed workflow solution and it's a very modern and powerful system but it's also insane to work with. You can describe the problem in text with much clearer than trying to follow a diagram that won't fit on a dozen screens in either direction.
> Reason - Visual authoring tools are highly expensive and hence are confined to fortune 500 companies.
They are snake-oil; nearly something you can only sell for millions of dollars to people who make billions of dollars. You need a team of highly paid expert consultants to make changes because nobody else knows these systems or wants to know them. It's like going back 30 years in terms of expressive power.
I disagree. I wouldn't have thought that Microsoft, author of Visual Basic, would be basically forced in 2015 to add improvements to their console system -- but here we are. If anything text-based programming is more prominent now than in the last 10 years.
> You would be dragging and dropping stuff, perhaps in Virtual reality headset or through voice or gesture to build what you want, just like you would author in a visual platform like Adobe illustrator or in a 3d authoring tool.
Your arms will get very tired.
> but authoring business logic is highly effective in Visual programming.
I disagree. We have one giant visual-programmed workflow solution and it's a very modern and powerful system but it's also insane to work with. You can describe the problem in text with much clearer than trying to follow a diagram that won't fit on a dozen screens in either direction.
> Reason - Visual authoring tools are highly expensive and hence are confined to fortune 500 companies.
They are snake-oil; nearly something you can only sell for millions of dollars to people who make billions of dollars. You need a team of highly paid expert consultants to make changes because nobody else knows these systems or wants to know them. It's like going back 30 years in terms of expressive power.
>Your arms will get very tired.
Ha ha, What about voice? Even without fancy stuff like gesture or voice, actually it wont be tiring. In fact if you prefer to use keyboard, you can solely work using pure keyboard to perform all of the visual wiring using configured shortcuts. It would be then much less effort (in terms of typing) that in traditional coding, as you don't need to do any boilerplate coding.
> I disagree. We have one giant visual-programmed workflow solution.
Why couldn't you break it up into multiple sub-workflows?
> They are snake-oil
Agreed. we need great open source solutions to move the needle from where it's been stuck for over several decades.
> I disagree. We have one giant visual-programmed workflow solution.
Why couldn't you break it up into multiple sub-workflows?
> They are snake-oil
Agreed. we need great open source solutions to move the needle from where it's been stuck for over several decades.
> Why couldn't you break it up into multiple sub-workflows?
Oh it is broken up into multiple sub-workflows. There is even a way to call workflows like functions and there is a workflow that decodes XML.
Oh it is broken up into multiple sub-workflows. There is even a way to call workflows like functions and there is a workflow that decodes XML.
Second. I am a competent programmer who degrades himself in the drudgery of business rules and visual ETL (DataStage, Informatica, etc.) and I do it only for the money.
So many of the problems are trivially solved with small programs, or even gasp just plain SQL. I concede there are features delivered by these fancy ETL tools beyond the quick (but not dirty) of custom solutions, but the overheads are higher too and I believe a cost-benefit analysis would invalidate the supposed business cases for using these tools.
This is not not-invented-here syndrome. This is simpler and cheaper. The problem for my case often is previous attempts to do it ourselves are shit. That's not a problem with the technology. :P
Behind the scenes I've solved hundreds of problems - one-off or on-going, small and large - by writing custom applications. This is the real increase in productivity that justifies my fee.
So many of the problems are trivially solved with small programs, or even gasp just plain SQL. I concede there are features delivered by these fancy ETL tools beyond the quick (but not dirty) of custom solutions, but the overheads are higher too and I believe a cost-benefit analysis would invalidate the supposed business cases for using these tools.
This is not not-invented-here syndrome. This is simpler and cheaper. The problem for my case often is previous attempts to do it ourselves are shit. That's not a problem with the technology. :P
Behind the scenes I've solved hundreds of problems - one-off or on-going, small and large - by writing custom applications. This is the real increase in productivity that justifies my fee.
I loved using labview when I was in test automation
Gnu Radio Control is a perfectly fine visual language for its problem domain: http://www.joshknows.com/grc
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