Interesting thread in the sense that it represents how most programmers think about VPL. L Ritter holds the fort though. I'm curious what people here think about some of the comments and the general temperature of the thread https://twitter.com/tom_forsyth/status/1355404333135798272?s=19

I wonder if he includes statechart FSMs in the term "visual programming". I'd really like to know how well they work in the wild.

I think it's a waste of time to try to convince people that already have for formed opinion like that. Use the energy saved by not arguing with them to build something good and useful for a group that is more open to new tools/ideas or that could/would not participate in programming without a visual tool. If you are successful, even for a niche you may be closer to convert them eventually.

I think because it's mostly game programmers in the thread, the discussion is about node based tools, some mention of structured editors and block based editors as well

I like such provocations that get a lot of responses, as I end up learning a lot quickly. (Didn't know about vvvv - there are actually jobs for that tech, that's a great sign.) One word I didn't see in the threads is "refactor". Someone hit the nail on the head when they said "beginner code is tangled too". I liked these 2 comments about layers https://twitter.com/mikkomononen/status/1355456413598937094?s=21

I agree with @Mariano Guerra in that people like this have their mind already made up, and they're just looking for intrinsically biased responses to validate their own biased position. I have spent my professional career working in LabVIEW, although I know other languages like F#, Racket, Python, et. al., and LabVIEW is, in my opinion, the current most general purpose visual programming language. So I have dealt with these biases a lot, often in person and unfortunately in interviews. It's honestly a pretty rough ride being a professional visual programmer when 98% of your industry colleagues think your tool is a joke and not "real" programming. If I respond here to the person's tweet, I believe they are asking the wrong questions. I don't think I would make an argument about visual programming necessarily being more "concise and readable", nor do I have a particular example that stands out as being one that would be readable in a visual programming environment and unreadable in a text-based one (for one, which language?). For one, I don't even know how you compare conciseness and readability. Those comparisons are ill-formed when comparing two text-based languages. The context in which to discuss visual programming is that it is just as valid (no more valid or less valid) than text-based programming. The real cornerstones are of representation and paradigms, again, just like how one compares text-based programming. When I think of what language to use (beyond technicalities), I like to think in paradigms and which one is best suited to represent the problems I have. Additionally, visual languages more readily provide live feedback, and so this is also where the argument gets lost, because visual programming tends to blur the line between program, the program running, and viewing the program in either of these states. When I program LabVIEW, I do not even have a compile step. It's compiling all the time, running type propagation to let me know what's broken, allows me to (by default) debug a running program by touching the data, etc. Yes, you can do this in a text-based environment, but I think the visual environment invites this more and makes it easier. So when I think of visual programming, I personally think of concurrency, dataflow, visual feedback, touching my program, etc.

Hmm... The thread contains the usual arguments and positions that seem to be set in stone. In my opinion, there are good arguments on both sides of the VPL vs. textual PL argument when you filter the irrelevant nonsense out (e.g. "I can type faster than I can drag nodes"). Generally, the discussion is about whether relations between parts of the system should be displayed visually (e.g. by lines connecting blocks) or implicitly by having the same name in two places (e.g. function declaration and function usage). The latter approach requires the programmer to imagine the structure in their head, which requires talent and experience to do well. Humans are great at understanding spacial structure, so explicitly showing that structure does make sense. If you don't want to take my word for it, look at all the UML stuff or programmers drawing pictures to communicate their ideas. On the other hand, showing ALL relations doesn't scale, just as stated in the twitter post that started the discussion. Take a

utils

lib in your project as an example. It is used almost everywhere and disturbs the relevant project structure when shown visually. In my opinion, the crucial point is focus and abstraction. I believe that visually showing "the bigger picture" can really help understand a project, especially when it's large. It's just that you can't plot all relationships between all parts on a 2D canvas and expect people to understand it. That's also not what programmers using textual PLs have in mind when they think about the system. It's ok to hide some details in order communicate the higher-level dependencies. Another important part is perspective. For code I've written, I have a pretty good mental model and probably don't need to actually see the structure on screen. If I need to understand someone else's project (or my projects from 3 years ago), it's really beneficial to have that overview available. This social issue is probably more important than the technical ones. Experienced programmers and people who mostly work on the projects they created don't benefit from VPL as much as beginners and people trying to understand existing stuff. I believe that the optimum is somewhere between textual PLs and current VPLs. Being able to choose between different views (see Projectional Editing) seems to make a lot of sense. Additionally, I'd like to see a system where users can specify which parts should be shown visually and which ones shouldn't be. Think of this like a street map where as you zoom out, only the most important streets are shown.

I would like to reiterate the points made here that discusses the reasons textual or visual languages are better for different domains: https://futureofcoding.slack.com/archives/C5T9GPWFL/p1599034947086700?thread_ts=1598907017.049900&cid=C5T9GPWFL Within this analytically framework, it seems obvious that LabVIEW takes the better approach for the task toward which it is oriented, but would feel awkward for some differently shaped problem domains.

The premise is wrong, and from there you just know the tweet isn't made to widen one's perspective. Being in the gaming industry, there's just no substitute for softwares like Houdini, Substance Designer or Unreal Engine's material editor. You could create all of those things with textual programming, but there's zero benefit for 99% of the userbase to do that. Once there's a textual programming language where my grandma can type "sort all my pictures by year and put each year into a subfolder, then send them to my grandkids on whatsapp" I think textual programmers will have a case for being against VPLs, but until then it's just gatekeeping with zero input on how to solve the problem of democratizing programming.

Yeah, all I can think is that old school game programmers like Tom have forgotten how much of a barrier syntax can be, and also are thinking mostly in a professional context. This might also delve a little into him actually not classifying "art tools" that use node based workflows as VPLs

I have asked before, "Where do you get the idea that you can sit down with MATLAB and do anything useful by just typing in some equations roughly the same as you would write them on a piece of paper?"