Visual programming languages are commonly used for the creation of chatbots in frameworks such as IBM Watson Assistant. They end up being an absolute complete mess. The reliance on global variables and go-to statements for control flow makes them extremely bug prone and unintelligible.

What does that have to do with visual programming? Any program written with a "reliance on global variables and go-to statements" is going to be "extremely bug prone and unintelligible" -- visual or otherwise. There are certainly VPLs with scope and flow control constructs.

But who’s using them? From the symptoms you describe I would guess it’s people very far removed from software development.

The Sims uses a visual programming language called "SimAntics" for scripting behaviors and "AI" of people and objects.

The Sims, Pie Menus, Edith Editing, and SimAntics Visual Programming Demo. This is a demonstration of the pie menus, architectural editing tools, and Edith visual programming tools that I developed for The Sims with Will Wright at Maxis and Electronic Arts.

https://www.youtube.com/watch?v=-exdu4ETscs

https://medium.com/@donhopkins/the-sims-pie-menus-49ca02a74d...

The Sims Steering Committee - June 4 1998. A demo of an early pre-release version of The Sims for The Sims Steering Committee at EA, developed June 4 1998.

https://www.youtube.com/watch?v=zC52jE60KjY

https://medium.com/@donhopkins/the-sims-pie-menus-49ca02a74d...

Mod The Sims Wiki: SimAntics:

https://modthesims.info/wiki.php?title=SimAntics

Simantics Wiki:

http://simantics.wikidot.com/

SimsTek Wiki: SimAntics

https://simstek.fandom.com/wiki/SimAntics

From Ken Forbus's game design course:

Under the hood of The Sims:

http://www.cs.northwestern.edu/~forbus/c95-gd/lectures/

Programming Objects in The Sims:

http://www.qrg.northwestern.edu/papers/Files/Programming_Obj...

Thanks for taking the time to write this up!

A bunch of disgruntled computer science grads questioning their life choices, at the large telecommunications provider for which I was working.

The Watson language just doesn't provide any other way to do anything. It's a common problem amongst visual programming languages as mentioned in the article.

Here's another paper about visual programming that Brad Myers wrote a couple years after his 1989 paper.

C32: CMU's Clever and Compelling Contribution to Computer Science in CommonLisp which is Customizable and Characterized by a Complete Coverage of Code and Contains a Cornucopia of Creative Constructs, because it Can Create Complex, Correct Constraints that are Constructed Clearly and Concretely, and Communicated using Columns of Cells, that are Constantly Calculated so they Change Continuously, and Cancel Confusion

Spreadsheet-like system that allows constraints on objects to be specified by demonstration. Intelligent cut and paste. Implemented using Garnet. 1991

Brad A. Myers. "Graphical Techniques in a Spreadsheet for Specifying User Interfaces," Proceedings SIGCHI'91: Human Factors in Computing Systems. New Orleans, LA. April 28-May 2, 1991. pp. 243-249.

https://www.researchgate.net/publication/221518856_Graphical...

C 32 Spreadsheet 1991: https://www.youtube.com/watch?v=IsINJ8mlD5A

If you enjoyed the full audacious name of C32, then you may also enjoy some of the other acronym names of projects by Brad and his students:

http://www.cs.cmu.edu/~bam/acronyms.html

(My meager contribution was "GLASS: Graphical Layer And Server Simplifier".)

One more general-purpose thing I miss very much is filesystem. Really what is a good option for a usb disk filesystem which you would like to use on Mac, Win and Linux? Seems to me that without using Paragon/Tuxera/etc. you're screwed.

Agreed. For sharing a filesystem, I assume the best you can do today is probably FAT32 (or whatever the latest of that family is), which is not great.

Why can't we get people from major tech companies together and have them develop a good on-disk format which supports the features we all need, and then everybody can go back and write their own implementations? Like we do with Unicode, or IP. And like we should do for many other features.

For all the talk about the importance of separation of interface and implementation, operating system designers really suck at it.

The modern answer is exFAT. August last year Microsoft opened up the specifications, and pledged that it won't be patent encumbered[].

How well an operating systems has a separation of concerns between interface and implementation really has very little (unfortunately) to do with business incentives. Even if the Linux kernel had perfect separation of concerns, there's no way to force Microsoft or Apple to support it in their products.

Not to mention the problem with standards: https://xkcd.com/927/

[1] https://cloudblogs.microsoft.com/opensource/2019/08/28/exfat...

Amazingly, the web folks seem to be doing OK on this front. They often manage to miss the xkcd#927 trap. What I see (admittedly the simplified public version) is more like:

- Here's a standard that kind of works and everybody is using it.

- Hey, we invented this cool new thing that isn't part of that standard but people seem to like it! (XHR, Canvas, ...)

- OK everybody let's put that into the standard as well so we can all agree on how it works. Thanks!

There was no way to "force Microsoft or Apple" to make a web browser, either, and yet they both did, and made it part of their operating systems.

FAT32 is too modern in some cases. I had to fall back to that recently to use with a fairly recent commercial photocopying machine (of the kind that can do full color, A3 paper, staple and fold outputs, etc, so not bottom line).

And I think that, “For sharing a filesystem” nowadays your best option is ”the cloud” for most people.

UDF is secretly well-supported for read/write across devices. That said, exFAT or NTFS seems to be the right option nowadays; NTFS-3g works well on Linux, there’s various options for macOS (not perfect but oh well.)

Agreed! Many of those claims completely disregard the research in visual programming that has happened in the past 30 years. Specifically the idea that it is about visual vs. textual seems utterly outdated now that more and more modern development environments find ways to combine the best of both worlds.

If anyone finds the time to update these claims, please consider our vvvv in your research: - A visual programming environment for the .NET ecosystem - Compiles to C# using Roslyn - Can use code from any .NET library as visual code blocks - Its language VL augments dataflow with features from OOP and functional programming, supports generics and easy multithreading - Useful since 2002: https://vimeo.com/371511910

Free for non-commercial use without restrictions (Windows only): http://visualprogramming.net

vvvv definitely doesn't solve all known issues but we hope it raises the bar for visual programming and such discussions.

I'll preface by saying that vvvv looks impressive and certainly seems like one of the more polished options in this space. We have a type of visual programming as part of an internal configuration tool, and I will definitely look into vvvv for how things can be done differently.

That said, this screenshot from one of your tutorial videos highlights the type of thing I think people are worried about: https://i.xkqr.org/screenshot_2020-04-27T09:47:46.png

I'm not saying it's bad – it might just be a question of habit whether or not graph edges are better than named identifiers in text, but it is hard to build away, even with best in class tooling.

It has it's advantages and disadvantages, same goes for text-programming though: Sometimes in text you store results in badly named variables because it is hard to make up a meaningful term for each step of a computation. In those cases visual code shines because instead of forcing you to come up with a name it allows you to directly connect things with the added benefit of visualizing dataflow, thus structuring your code. If you have an algorithm though where each interim result can be clearly named, then text code shines. So roughly we argue that the more high-level your code is, the better it works visually, the more low-level it is, the better it is expressed in text. And it is therefore about a combination of both worlds. We don't have this yet in vvvv gamma (but have it in vvvv beta) that you can at any point write text-code if you prefer and wrap this in a node for further use in your visual graph.

> Lack of evidence? Again, they're holding VPLs to a higher standard. When a language like Ruby appeared, nobody asked for proof. Simply creating something that some programmers liked was sufficient.

If there was a visual programming language with anywhere near the popularity of Ruby, I'd be willing to consider that maybe the idea has some merit.

I don’t know how many people use Ruby, its certainly not as popular as it was during the Rails hype, so its hard to day, and I don’t have numbers for the visual languages either, but Unreal Engine’s Blueprints has a lot of users. Max/MSP does too, and apparently a lot of artists use tools like Substance Designer to create visual materials and those tools have visual programming too.

EDIT: Media Molecules’ Dreams has a lot of users using its visual language to implement game logic! It sold about 8.5 million copies. Obviously not all people who bought it are using its visual language, but I imagine a very large percentage have at least tinkered a bit. I doubt Dreams would be as popular if it required textual programming.

Excel.

I could turn your argument around: If Ruby were anywhere near as popular, widely used, and successful as Excel, I'd be willing to consider that maybe the idea that Ruby is a viable programming language has some merit.

But I won't, because whether or not something is a visual programming language isn't up to a popularity contest.

Can you come up with a plausible definition of visual programming languages that excludes Excel, without being so hopelessly contrived and gerrymandered that it also arbitrarily excludes other visual programming languages?

> I could turn your argument around: If Ruby were anywhere near as popular, widely used, and successful as Excel, I'd be willing to consider that maybe the idea that Ruby is a viable programming language has some merit.

How is Excel, as widely used, a programming language? Excel sheets in their widely used form are not instructions or behaviour; you can't run them, only manually edit them. Perhaps there is a way to turn Excel sheets into programs, but I highly doubt such a way of using Excel would be more popular than Ruby.

> Can you come up with a plausible definition of visual programming languages that excludes Excel, without being so hopelessly contrived and gerrymandered that it also arbitrarily excludes other visual programming languages?

I'd say a visual programming language is a programming language for which the primary way of making changes to the program is visual. Even if we were to consider Excel a programming language, the primary way in which people make changes to Excel sheets - especially advanced users who are doing more programming-like things - is by editing textual formulae, IME.

Are we talking about the same "Excel"? I mean Microsoft Excel, in case there's something else called Excel that I haven't heard of.

Microsoft Excel spreadsheets certainly do contain instructions and behavior. That's the whole point of spreadsheets, that distinguish them from plain CSV files! They continuously run every time you make any change to them. And Excel is several orders of magnitude more popular and successful than Ruby: there is no comparison.

Excel even supports "Programming by Demonstration" through its macro recorder. Programming by Demonstration happens to be one of Brad Myer's favorite areas of research!

Brad wrote the 1989 paper about visual programming that we're discussing, and Visual Programming, Programming by Demonstration, and Programming by Example are closely interrelated topics that he has done a lot of work with and written a lot about.

I think it's important to consider some of his and other people's more recent work, before extrapolating on the technological limitations that he wrote about in 1989, without taking into account 31 years of progress, research, and development.

https://en.wikipedia.org/wiki/Brad_A._Myers

"Myers is a leading researcher in the field of programming by demonstration and created the Garnet and Amulet toolkits."

https://en.wikipedia.org/wiki/Programming_by_demonstration

"In computer science, programming by demonstration (PbD) is an end-user development technique for teaching a computer or a robot new behaviors by demonstrating the task to transfer directly instead of programming it through machine commands."

Watch What I Do: Programming by Demonstration. Edited by Allen Cypher, Daniel Conrad Halbert, David Kurlander, Henry Lieberman, David Maulsby, Brad A. Myers, and Alan Turransky.

https://archive.org/details/watchwhatido00alle

http://acypher.com/wwid

Watch What I Do: Foreword by Alan Kay

http://acypher.com/wwid/FrontMatter/

>I don't know who first made the parallel between programming a computer and using a tool, but it was certainly implicit in Jack Licklider's thoughts about "man-machine symbiosis" as he set up the ARPA IPTO research projects in the early sixties. In 1962, Ivan Sutherland's Sketchpad became the exemplar to this day for what interactive computing should be like--including having the end-user be able to reshape the tool. [...]

Microsoft Excel Macro Programming History

https://en.wikipedia.org/wiki/Microsoft_Excel#Macro_programm...

"History: From its first version Excel supported end-user programming of macros (automation of repetitive tasks) and user-defined functions (extension of Excel's built-in function library). In early versions of Excel, these programs were written in a macro language whose statements had formula syntax and resided in the cells of special-purpose macro sheets (stored with file extension .XLM in Windows.) XLM was the default macro language for Excel through Excel 4.0. Beginning with version 5.0 Excel recorded macros in VBA by default but with version 5.0 XLM recording was still allowed as an option. After version 5.0 that option was discontinued. All versions of Excel, including Excel 2010 are capable of running an XLM macro, though Microsoft discourages their use."

>I'd say a visual programming language is a programming language for which the primary way of making changes to the program is visual.

Your arbitrarily gerrymandered definition turns C++ into a visual programming language, which it clearly is not.

So how is making changes to a C++ program in VI or Emacs not visual, then? People use visual editors to make changes to textual C++ programs all the time.

The "V" in "VI" STANDS FOR "Visual", because it is the "visual mode" of the line editor called ex.

But the actual structure and syntax of a C++ program that you edit in VI is simply a one-dimensional stream of characters, not a two-dimensional grid of interconnected objects, values, graphical attributes, and formulas, with relative and absolute two-dimensional references, like a spreadsheet.

https://en.wikipedia.org/wiki/Vi

>The original code for vi was written by Bill Joy in 1976, as the visual mode for a line editor called ex that Joy had written with Chuck Haley.[3] Bill Joy's ex 1.1 was released as part of the first Berkeley Software Distribution (BSD) Unix release in March 1978. It was not until version 2.0 of ex, released as part of Second BSD in May 1979 that the editor was installed under the name "vi" (which took users straight into ex's visual mode),[4] and the name by which it is known today. Some current implementations of vi can trace their source code ancestry to Bill Joy; others are completely new, largely compatible reimplementations.

>The name "vi" is derived from the shortest unambiguous abbreviation for the ex command visual, which switches the ex line editor to visual mode. The name is pronounced /ˈviːˈaɪ/ (the English letters v and i).[5][6]

There was also Fabrik in Smalltalk, which began as a spreadsheet.

http://web.archive.org/web/20080511202219/http://users.ipa.n...

https://dl.acm.org/doi/abs/10.1145/62083.62100

https://wiki.squeak.org/squeak/1175

> They continuously run every time you make any change to them.

Which is very much unlike what a program does.

> FYI, the "V" in "VI" STANDS FOR "Visual", because it is the "visual mode" of the line editor called ex. Your arbitrarily gerrymandered definition turns C++ into a visual programming language, which it clearly is not.

I appreciate your condescension, but I'm well aware of the history of vi and in any case quite capable of using wikipedia myself.

How is taking the plain meanings of the words in the definition "arbitrarily gerrymandered"? You tell me what visual means to you and how C++ is not a visual programming language, if that's somehow clear in a way that does not apply to Excel.

>> They continuously run every time you make any change to them.

>Which is very much unlike what a program does.

You're saying "Program that run continuously every time you make any change are very much unlike what a program does?" That doesn't make any sense to me at all, can you please try to rephrase it?

Speaking of program that run continuously, have you ever seen Bret Victor's talks "The Future of Programming" and "Inventing on Principle", or heard of Doug Engelbart's work?

The Future of Programming

https://www.youtube.com/watch?v=8pTEmbeENF4

Inventing on Principle

https://www.youtube.com/watch?v=8QiPFmIMxFc

HN discussion:

https://news.ycombinator.com/item?id=16315328

"I'm totally confident that in 40 years we won't be writing code in text files. We've been shown the way [by Doug Engelbart NLS, Grail, Smalltalk, and Plato]." -Bret Victor

Do you still maintain that "Excel sheets in their widely used form are not instructions or behaviour", despite the examples and citation I gave you? If so, I'm pretty sure we're not talking about the same Microsoft Excel, or even using the same Wikipedia.

Your definition is arbitrarily gerrymandered because you're trying to drag the editor into the definition of the language, while I'm talking about the representation and structure of the language itself, which defines the language, not the tools you use to edit it, which don't define the language.

I'll repeat what I already wrote, defining how you can distinguish a non-visual text programming language like C++ from a visual programming language like a spreadsheet or Max/MSP by the number of dimensions and structure of its syntax:

>But the actual structure and syntax of a C++ program that you edit in VI is simply a one-dimensional stream of characters, not a two-dimensional grid of interconnected objects, values, graphical attributes, and formulas, with relative and absolute two-dimensional references, like a spreadsheet.

Text programming languages are one-dimensional streams of characters.

Visual programming languages are two-dimensional and graph structured instead of sequential (or possibly 3d, but that makes them much harder to use and visualize).

The fact that you can serialize the graph representation of a visual programming language into a one-dimensional array of bytes to save it to a file does not make it a text programming language.

The fact that you can edit the one-dimensional stream of characters that represents a textual programming language in a visual editor does not make it a visual programming language.

Microsoft Visual Studio doesn't magically transform C++ into a visual programming language.

PSIBER is an interactive visual user interface to a graphical PostScript programming environment that I wrote years after the textual PostScript language was designed at Adobe and defined in the Red Book, but it didn't magically retroactively transform PostScript into a visual language, it just implemented a visual graphical user interface to the textual PostScript programming language, much like Visual Studio implements a visual interface to C++, which remains a one-dimensional textual language. And the fact that PostScript is a graphical language that can draw on the screen or paper doesn't necessarily make it a visual programming language.

https://medium.com/@donhopkins/the-shape-of-psiber-space-oct...

It's all about the representation and syntax of the language itself, not what you use it for, or how you edit it.

Do you have a better definition, that doesn't misclassify C++ or PostScript or Excel or Max/MSP?

> You're saying "Program that run continuously every time you make any change are very much unlike what a program does?" That doesn't make any sense to me at all, can you please try to rephrase it?

Running continuously every time you make any change is very much unlike what a program does. Programming is characteristically about controlling the sequencing of instructions/behaviour, and someone editing a spreadsheet in the conventional (non-macro) way is not doing that.

> Do you still maintain that "Excel sheets in their widely used form are not instructions or behaviour", despite the examples and citation I gave you? If so, I'm pretty sure we're not talking about the same Microsoft Excel, or even using the same Wikipedia.

This is thoroughly dishonest of you. You edited those points and examples into your comment, there was no mention of macros or "programming by demonstration" at the point when I hit reply.

To respond to those added arguments now: I suspect those features are substantially less popular than Ruby. Your own source states that Microsoft themselves discourage the use of the things you're talking about. Excel is popular and it may be possible to write programs in it, but writing programs in it is not popular and the popular uses of Excel are not programs. Magic: The Gathering is extremely popular and famously Turing-complete, but it would be a mistake to see that as evidence for the viability of a card-based programming paradigm.

> Your definition is arbitrarily gerrymandered because you're trying to drag the editor into the definition of the language, while I'm talking about the representation and structure of the language itself, which defines the language, not the tools you use to edit it, which don't define the language.

Anything "visual" is necessarily going to be about how the human interacts with the language, because vision is something that humans have and computers don't (unless you're talking about a language for implementing computer vision or something).

> I'll repeat what I already wrote, defining how you can distinguish a non-visual text programming language like C++ from a visual programming language like a spreadsheet or Max/MSP by the number of dimensions and structure of its syntax:

But you can't objectively define whether a given syntactic construct is higher-dimensional or not. Plenty of languages have constructs that describe two- or more-dimensional spaces - e.g. object inheritance graphs, effect systems. Whether we consider these languages to be visual or not always comes down to how programmers typically interact with them.

> PSIBER is an interactive visual user interface to a graphical PostScript programming environment that I wrote years after the textual PostScript language was designed at Adobe and defined in the Red Book, but it didn't magically retroactively transform PostScript into a visual language

There's nothing magical about new tools changing what kind of language a given language is. Lisp was a theoretical language for reasoning about computation until someone implemented an interpreter for it and turned it into a programming language.

> Lisp was a theoretical language for reasoning about computation until someone implemented an interpreter for it and turned it into a programming language.

Lisp was designed and developed as a real programming language. That it was a theoretical language first is wrong.

color tree seems to embody a lot of the things you’ve mentioned. it uses a zui to edit lisp code. i hope the author finishes it soon! http://colortree.app