There is more to visual programming than simple wire diagrams and "code-blocks-as-visual-blocks":
https://www.youtube.com/watch?v=6orsmFndx_o
https://www.youtube.com/watch?v=I9LZ6TnSP40
https://alumni.media.mit.edu/~mt/thesis/mt-thesis-Contents.h...
And yes, this: http://www.fantasticcontraption.com/ This is not 100% real programming, because it does not include sensors, but you do create constructs that interact with the environment and accomplish goals. It's close enough to show what's possible with certain interfaces.
Long-term: https://dynamicland.org/
There have been much fewer resources allocated to the development of these concepts. Mostly for historic reasons.
The sad reality is that both critics and proponents of visual programming are often uninformed about prior work, user studies and related research rooted in cognitive and developmental psychology.
Various links related to this have come up in the past few days, and I think they mostly betray a lack of understanding of the weaknesses of text-based programming, and a lack of imagination as to how visual programming could actually work.
One person who's done a lot of thinking about this is Bret Victor, and I encourage anyone interested to watch his videos: http://worrydream.com/
Here's a project that's trying to split the difference between visual programming and text-based programming: https://luna-lang.org/
Tools for visual programming have seen massively less effort spent on them than text-based tools. This is why text-based tools have much more conveniences, and better integration, than visual-oriented tools.
Another important aspect is that humans use words to communicate, so some amount of text is inevitable (and welcome) in visual programming tools.
Also, text-based tools use the most common and open format of all, a stream of ASCII (UTF-8) characters. This allows to mix and match text-based tools (editors, compilers, formatters, linters, etc). Visual languages were (and are) dominated by proprietary formats. This keeps visual programming tools in silos, profitable for the vendor but preventing the wild expansion that text-based programming languages periodically enjoy.
I'm not a visual programming proponent, but I don't think this article does a very good job of supporting its thesis. It exclusively makes claims about current VP implementations and tries to extrapolate them to VP in the abstract, but I think these are all non-sequiturs. I specifically think the article fails to distinguish between the dual problems of _modeling a program_ (hard) and representing that model visually vs textually.
For example, the article claims that the idea behind scratch is that programming is fundamentally easy but text makes it hard. I don't think that's the idea at all, but rather that programming (i.e., modeling a program) is fundamentally hard, but the difficulty is compounded because text is not a natural way for the current crop of humans to think about a program.
Another example is his criticism of the failure of enterprise UML tools--presumably the problem with these is that UML is just not a very good way of _modeling a computer program_, regardless of whether the interface to UML is visual or textual.
Another example is the criticism that the current crop of VP tools are procedural. Why can't a visual programming language be functional?
Another is the claim that VP is bad because the current crop of tools combines visual and textual programming (I'm not sure this is even true; I don't recall LabVIEW requiring text, for example). Is there any fundamental reason a programming model can't be purely visual? Why can't you represent a whole programming model (all the way down to primitives) visually?
I think most of these would be solved with more trial and error and more investment; none of these support the thesis that VP is fundamentally a bad idea.
To be clear, I think this article has a lot to offer people who are trying to solve visual programming issues, but it doesn't make the case that it sets out to do--that visual programming is fundamentally a waste of time.
Years ago I developed a visual interface to an existing non-visual language, the multi threaded object oriented dialect of PostScript in the NeWS window system. Since PostScript is homoiconic, the data viewers and editors could also be applied to code!
It didn't try to replace text based PostScript programming, just augment it: there was an interactive shell window you could type expressions to, which had a stack "spike" sticking out of it representing the PostScript stack, which would update in response to the commands you typed, or you could drag and drop objects to manipulate the stack and the state of the system.
You could perform "direct stack manipulation" by dragging objects up and down or on and off the stack, open up nested objects and functions in an outliner, adjust the point size and formatting style, open up special editors on data and code, drag and drop objects and code around, etc. It was like a live Smalltalk system, in that you could explore (and vandalize) the entire state of the window system, and use it as a debugger to inspect and modify and debug processes of other NeWS clients (including itself).
https://medium.com/@donhopkins/the-shape-of-psiber-space-oct...
In order to make a serious comparison of textual and visual programming, you'd be better off using a serious system such as Labview for the comparison, not a... toy for children.
Hi! I'm Wojciech Danilo, one of the founders behind Luna language ( http://luna-lang.org ). I'd love to share with you our blog post about why actually visual programming languages could be very useful: https://medium.com/@luna_language/luna-the-visual-way-to-cre...
We've been building visual languages in the past for people in different industries, including Visual Effects one. Watching people with limited programming skills to create outstanding things on their own is truly amazing.
Pros
The author well formulates the limitations of VPLs (Visual programming languages).
Cons
The rant seems to jumble in VPLs for general purpose programming with VPLs for domain-specific usecases. So although VPLs may be "a bad idea" for general purpose computing and does a good job of explaining its downsides, it is a little reckless in saying VPLs are a bad idea overall.
The author also offers two straw man arguments to make their point, though I don't believe that these things are common misconceptions at all:
1) Abstraction and decoupling play a small and peripheral part in programming.
2) The tools that have been developed to support programming are unimportant.
Lastly, the author uses Scratch as its representative VPL example, even though it is probably the most far removed from "Visual Programming" and more in line with something I'd call "Block-Based Programming". These are far from equivalent and a poor choice to use for talking about general purpose VPLs (though the author does admit that it may have been a poor choice later).
> The lack of good source control is another major disadvantage of most visual programming tools.
I think this is underselling the point.
Lack of good source control is a non-starter for any programming paradigm. If you want to do visual programming or any other kind of programming that doesn't dovetail with directory tree of text files, you are not going to get anybody serious to work with you until you fix that problem.
The first problem you should solve is not how to compile the code, nor how to debug the code, but how to store it.
Matrix/EA used a visual language for Spore. http://puredata.info/exhibition
Pure Data (Pd) is a visual programming language developed by Miller Puckette in the 1990s for creating interactive computer music and multimedia works
https://en.wikipedia.org/wiki/Pure_Data
This is the one shinning example where a visual language actually accomplishes something that a general language can't not. Make programming accessible to creative people.
This is the only visual language that I felt was worth learning.
I personally think node based programming is suitable for DSL, high level plumbing, data visualization (imagine Jupyter cells but having branches). The best visual programming language is UE4 Blueprint: prototype quickly, great debugging experience (great tooling in general), communicate with C++ easily, intellisense... It's really productive to glue stuff together but not that helpful for "drawing" all the core logic. VSP is good but not for every use-cases.
> The final misconception is that visual programmers can do without all the tools that have been developed over the decades to support programming. Consider the long evolution of code editors and IDEs. Visual Studio, for example, supports efficient intellisense allowing the look-up of thousands of APIs available in the base class library alone.
I think this point the author makes is an interesting one because I see it form a different perspective. I think the biggest issue is that we mix presentation with representation.
> The lack of good source control is another major disadvantage of most visual programming tools. Even if they persist their layout to a textual format, the diffs make little or no sense.
At the same time tabs vs spaces is still a thing. In languages which aren't whitespace sensitive, the diffs similarly don't make any real sense in my opinion.
I believe (and have no idea how to implement) that the representation of a programming language should be modified more directly and the rendered presentation (textual, visual, interpretive dance) should be irrelevant to the tooling.
seems from the bottom of the post, since he posted a picture of scratch (which is a fantastic tool!) that the author really just has an opinion about this and actually hasn't done really solid research and measured anything by actual outcomes.
The block based visual programming embraced by scratch and things like the BBS micro:bit are really good, my 7 year old son can do really cool things with these systems (also check out the new beta https://beta.scratch.mit.edu/ which is done with React for anyone interested )
You can even add this kind of visual block based coding into your own systems using something like https://developers.google.com/blockly/
I think it's a little shortsighted to think just because there's been tools that didn't really work out too well that the idea is bad
https://www.mendix.com/ Seems to be cleaning up on the concept. I've seen two start-ups now using it and the turn-around times for features were definitely impressive. The problems with such solutions are always long term maintenance, scalability and lock-in.
Going from text to visual programming only takes you from (sort of) one dimension up to two dimensions. That isn't much of an advantage for complex code where the "dimensionality" (for lack of a better term) is much higher than 2D.
Perhaps the growth of VR and other 3D interfaces will breathe new life into visual programming?
What does visual mean? A text file is a 2D set of characters, so if you consider it that way everything is visual. What are brackets, if not visual markers of blocks that start and end? What is code coloring if not visual aid to help with typing?
Programming is visual, full-stop. The main reason why “visual programming didn’t catch on” is because there can’t be a semantic equivalent to placing programming elements on a 2D grid. A program executed things On sequence, so it’s convenient to program top to bottom. That’s why text is better suited to represent it.
Dataflow programming is not generally executing in sequence. And that’s where visual programming shines.
Spreadsheets are visual programming languages, and they seem pretty popular.
The economy would collapse if you took them away, so I think that's a pretty good measure of how important and widely used they are.
A preface before you read this- it's just a long joke :)
I wonder if instead of new programming languages or VPLs aren't the problem, but lack of meta data structures (going beyond a class or interface) that tie together data with expected structure and their implicit validations (including relateable data) to code that performs business rules (booking airplane tickets) and code that draws a UI (ticketing screen).
I know about 10-15 years back this was called "4GL" (fourth generation languages) but instead of that taking off, a sludge of just new procedural programming languages took hold (rust go ts etc..). I think VPL tries to fill that same niche space where the goal is to think meta-like, not procedurally about each input box. If the system understands and records data in similar ways, we can eventually get to a place where data is ubiquitously stored in the structure the system defines, not the programmer defined way.
So while right now we may not have the correct primitives for 4GL or VPL, maybe one day and that's why these ideas won't die - because it is likely going to be the way that software is designed in the far (or near?) future. Especially in the wake of AI where we might have a chance to let the system write the UI/business logic.
In other words, instead of thinking of AI as writing code in C/C++/Rust, etc.. AI will be in charge of moving data - at first in human defined chunks (likely spec'd out in VPL or 4GL structures), but eventually for AI to define its own objects of related structures. Eventually getting to the point where us mere humans ask AI to build things that fit human process.
The last step is that humans would no longer define the process, and AI be able to incrementally add processes with the data it has, by defining the most optimal path for humanity whether it be tax rates or human production or smoothing out effects of electricity futures based on incoming solar mass ejection predictions. Eventually in the final stages of humanity, defining the work output each human needs to make during a day. By this point enough people will have opted out and the giant war between the owners of AI and the people will start. Killing off most people, but at the same time many of the oligarchs will have been assassinated by members of the public that were willing to rip out their tracking chips in the left eye.
Enough of the planetary population will be gone and totally untrusting of anyone, but we'll have finally visioned our AI future. Won't it be grand!
Oh sorry off topic again yeah we probably should stay away from Visual Programming.
The auther of this poor article, is extremely blinkered and lacking in imagination. Just 5 minutes watching a demo of the incredible power of modern games engine, such as Unreal, blows to smithereens, the whole premise of this article. Has he never wondered into an accounting department? Not seen an Excel workbook running a business? Or seen designers and their viusal tools. A shame though, that Microsoft can’t be bothered to update the ancient appalling VB editor that ships with Excel.
This sounds analogous to the argument that mathematicians used to have: whether abstraction trumps intuition, especially in geometry.
For instance, you can't really plot a 25-dimensional object, but the same object is trivial to manipulate with equations.
It's clear to most people that both approaches have their place. In geometry, the visual component is very important to develop important intuitions about how objects behave in low dimensional space. On the other hand, if one were to insist on the visual, one would be stuck with purely intuitionist ideas and never be able to move into more complicated realms where you cannot visualize objects graphically (e.g. high-dimensional space).
The Bourbaki group was a group of mathematician who aimed to put mathematics on a rigorous foundation by developing the abstractions that shaped modern math, and by moving mathematics past its intuitionist foundations. Some argue that this caused modern "geometers" to lose their feel for geometry because everything became about symbols. But without this development, a lot of modern discoveries might not have been possible.
Our company develops a software for alarm receiving centers. In our software our customers can use a visual code editor http://pfau.de/images/beispiel002.gif to program their own processes for alarm reactions. That is actually our main selling point. They can control the user interaction (what to do, who to call, etc) in reaction to an alarm, access all the data to change process outcomes in response to data or user interaction and automate a lot of processes (filling forms, mailing reports and even automated invoices). They can even call external programs (on other computers) and fill and read databases to interact with other systems. That generally works well as long as people use simple flows and standardise a lot. But as soon as people start to program complex flows you can really see who is a “programmer in disguise“ and who is “just a user thrown in way over his head”.
source control is the biggest problem with visual programming. i remember doing something we eclipse modelling tools which actually supported merging of models but you just lose so much going from languages that are supported by the existing text based eco-system to languages that are not.
I remember the first programming languages I used (when I was very young) were visual. I think Flowol at primary (elementary) school was the first. They gave me a pretty much instant understanding of how imperative programming worked. Admittedly, I never created anything practically useful in it, but what's important is that I could imagine, from early in my life, what programming could do / was for, and put it on my cognitive radar.
As a child I was more inspired by seeing the inner workings of something than being told X was possible if you learn to code. Visual languages can better expose the guts of the working automaton.
That said, I agree that [current] visual programming languages have shortcomings that limit them to simple / educational scenarios.
To this day, I'm amazed at the things that were done with Access, and horrified by the things I've seen in Lotus Notes.
It really just depends. What visual systems provide is accessibility for novices to create value. That sometimes means planning to replace them, or enhance them with skilled developers. In my mind, it creates jobs. Not always great jobs, but at least security in that Software Development will always be a viable career, with lots of opportunities.
There's no one-size-fits-all for programming. FWIW, I can recall a project where one piece was built visually (SSIS) and I enjoyed working with it.
For me personally, I can see a theoretical benefit to visual programming languages - because I already think of code mostly in terms of shapes created be the flow of data. I've just never seen one that really matches my mental model, and trying to see myself using one of them seems like it would end more as a fight with the language than any actual benefit.
Well I always liked Authorware [1]. Maybe it was very media (CD/DVD) orientated but I really liked how you could see the flow of the program.
This article is poorly researched (the only "visual" tool it mentions is scratch???) and pretty lazy in considering the merits of extratextual programming. It's worrying that something of this quality resonates with people.
In the early days of KloudTrader, we attempted to use Visual Programming too.
https://web.archive.org/web/20171006072839/http://www.kloudt...
The main difficulty was scale and tradeoffs between power vs ease-of-use. We spent a lot of time creating "subroutine blocks" for the most commonly used functions and optimizing for UI/ease of use that we weren't doing much else. Furthermore, pretty much every integration, library etc. had to be converted into its visual equivalents for the language to be of any use and all the linear algebra/candlestick libraries were taking up so much time that the rest of the product was suffering. Stuff that often makes sense to a professional programmer had to be "simplified" so the UX is more optimal. E.g. data structures.
If you look at VPLs in production, there's a reason most of them tend to be "imperative commands only" i.e. a glue language that mainly strings together other subroutines. The concept of objects, or even structs is completely eliminated in the VPL.
http://www.ni.com/getting-started/labview-basics/data-struct...
There are exceptions to this however, the Unreal Engine's Blueprints is a lot more flexible than most.
If you want to get started building your own version of Google's Blockly, here's a good guide:
http://www.aosabook.org/en/500L/blockcode-a-visual-programmi...
Throw in an immediate-mode UI library like React and you might even scale up indefinitely with plain HTML (most browser VPLs stick with SVG/Canvas).
For prettier node-based types of languages, try these libraries:
https://github.com/retejs/rete
https://github.com/slothking-online/diagram
https://github.com/jagenjo/litegraph.js
Bonus tip for anyone looking to implement any: use code generators. AST -> Visual programming component conversion may save you lots of time (assuming that the language has mature enough tooling and labour is extremely expensive)
once again, someone has a strong opinion on something they have never used or don't know much about.
in my personal opinion, scratch and blockly have very little to do with visual programming. they are nice little experiments but just repeat what's bad about text-based programming into visual blocks, which just compounds the issue. i honestly am surprised mit and the media lab have dumped so much time into scratch.
i have said this before, but the most productive visual programming language and environment is labview. it certainly has its problems, and i am a big critic of it, but its visual programming style and dataflow paradigm are more powerful than people realize. it has some seriously good ideas that aren't found in many other languages, and it had many innovative features well before other languages. for example, doing concurrent programming in labview is a breeze.
on the other side, you see that modern IDEs are starting to add a lot of visual content to help the programmer out. the languages remain text-based, but the environments are adding visual features. i think that there is a lot of untouched ground regarding hybrid environments and languages that merge the ideas of text-based programming with visual-based programming. in addition, the dataflow paradigm is also underused.
there's also other computation targets other than CPUs such as FPGAs. it's silly in verilog and vhdl how you often have to manually label up wires where in labview, the tool and language do that for you. you simply draw your circuit out as you would in a diagram.
common complaints against visual programming have almost no weight. for example, "oh, you can't diff visual programs like text programs". yes you can. it's not like computers were gifted by god text-based diff programs. these things were developed and iterated on. labview has a diff mechanism. it isn't great, but my point is that people view text as some sort of innate trait of programming and all the tools are "natural" and already exist as if they just poofed into being once programs started being written. but if we put some thought and work into the tools for visual programming, similarly to how it has been done with text programming, it's possible to create really powerful environments and languages.
where visual programming languages often have a ceiling is abstraction. for example, labview has object-oriented features, but it doesn't go far. i program on the side in f# and racket, which have an amazingly high ceiling for abstraction, but interacting with these languages is often frustrating coming from labview. there are many things that are simply easier in labview. some of that is tooling. some of that is the visual language and dataflow paradigm.
There are a lot of things to respond to in this.
The purpose of Scratch is not to have all programming done in an environment like Scratch. It's to ease students into precisely what the author wants (textual programming environments).
Scratch eliminates several categories of errors for students.
Students in younger grades often lack an understanding of grammar and its utility or applicability. Consequently, the novel (to the student) syntax of programming languages can be vexing: Why is "while if x > 3" not allowed? The rules of the languages proscribe it. So now they're learning language rules and the concepts of programmatic/computational thinking.
They can no longer make typos when writing out keywords and variables. Keywords are typically available as draggable icons that they can then "fill-in-the-blanks" for. Variables become draggable icons or can be filled in with a simple drop down or text field that filters a drop down. Try explaining to an 8-year-old who still Writes Like this and SomeTimes tHis that there's an actual meaningful difference between "name" and "Name".
Scope is made explicit. Variables and logic exist within certain scopes so scoping errors (trying to use a variable outside the appropriate scope) becomes impossible as well.
Are all these constraints great for pedagogy? I don't know. But after teaching a number of high schoolers (now years ago), I'll say it would have been awesome to have had Scratch. They got along well enough with Dr. Scheme (now Racket), but a lot of time was spent fighting with the language that could have been abbreviated or eliminated with a different environment.
In the case of block-based editors, you can actually get version control. Usually, they're just a constraint-based, visual editor over a textual representation. So the underlying source files can be version controlled and compared quite easily (if the implementors considered this in their implementation).
================================
Other thoughts:
This reminds me of an ex-girlfriend who legitimately thought it would be better if all math were written as:
To calculate the average of the population sum up
each of the members and divide by the count.
Ʃ pop
average(pop) = -------
|pop|
Graphical representations of processes can, similarly, be more useful than their textual counterparts (though not in all cases, I wouldn't argue that).
================================
But here's a fun one:
Problem: Identify binary strings (read left-to-right, last digit read is the least significant) that are multiples of 3. So 11 = 3, 1010 = 10, etc.
Do this with just regular expressions. No tables, no diagrams, nothing.
Ok, now do the same thing but with a standard DFA diagram or state transition table.
Much easier, right? Now, once you have those last two you can write out the textual regular expression and embed it in your program with relative ease. And maybe that's how you want to store it in your code. Or if you don't want to use a regex engine you could encode the table form into your program easily enough, and still retain its visual characteristics.
Are visual programming environments going to replace most of our programming languages and work? Probably not. But it's foolish to discard them based on the complaints in this blog post without considering the reasons why they have value.
text-based representation is visual.
Last I heard text is visual... so then what is text but a form of visual programming?
In essence text is visual programming limited to set of symbols and tokens parsed in left to right order.
Who said that this arbitrary set of rules is the best way to represent programming logic? The number of concepts for abstraction encompass many things in the visual realm. Graphs, procedures, arrows and even 3D space can be used to represent logic... Obviously with a space this big, text is unlikely to be the best way.
Text based programming is simply a local minima that is seemingly the optimal minimum. The problem is we're so deep in this minimum that it's hard to climb out.
Flow-based programming is visual - http://www.jpaulmorrison.com/fbp/
Visual programming languages will only take you so far, but often that is far enough. What the author misses is that we as professional programmers miss the success stories, because we only get called in when the boundaries have been reached.
In my career I’ve often been asked to rewrite Access DBs, InfoPath forms, or SharePoint sites developed by amateurs into something more usable. My early reactions where along the lines of “what insane person tried to do this in Access.” I realized at some point that was the wrong approach in my thinking. These systems are working software delivering value. I now say “wow, congrats on doing so much on your own. Let me help you take this further.”