Folk wisdom on visual programming • Hacker News Board

Re: Folk wisdom on visual programming

#101

Post by hermitcrab » Fri, Jul 02, 2021, 7:54 AM UTC

ping_pong wrote: post #4

I worked on a visual programming tool from the late 90s to the early 2000s. The same problems apply then as they do now. There's an unwinnable war between keeping things simple and being complex-enough to do useful things. Visual stuff is great for simple things, but simple things aren't very useful. When you really need to do more complex things, you reach a limit very quickly. It becomes pretty unmaintainable very…

I think visual programming tools are great when they are aimed at a specific domain. but not when they try to do too much. While Scratch is great for teaching kids to code, trying to come up with a visual replacement for C++ is almost certainly a bad idea.

Also it is possible to blend the two approaches. For example by allowing users to script some of the boxes in a text based language. This is the approach I have taken with my own visual-based data wrangling tool. The standard transforms cover 95% of cases people need (re-order columns, pivot, filter etc) and you can script a Javascript transform for anything else.

Re: Folk wisdom on visual programming

#102

Post by hermitcrab » Fri, Jul 02, 2021, 8:38 AM UTC

JPKab wrote: post #62

ping_pong wrote: post #4

I worked on a visual programming tool from the late 90s to the early 2000s. The same problems apply then as they do now. There's an unwinnable war between keeping things simple and being complex-enough to do useful things. Visual stuff is great for simple things, but simple things aren't very useful. When you really need to do more complex things, you reach a limit very quickly. It becomes pretty unmaintainable very…

There is most definitely an unwinnable war between simplicity/ease-of-use and more power/customizability. That being said, Alteryx is an example of a company that has made a ton of money via a data munging tool that is a visual programming language. The users are fanatical as well.

It is not really a war though is it? Some people prefer visual tools like Alteryx, Knime or Easy Data Transform. Other people prefer R or Python. And some people will alternate approaches, depending on the problem at hand. Also, many 'visual' tools include the option of text based programming, for flexibility.

Re: Folk wisdom on visual programming

#103

Post by hermitcrab » Fri, Jul 02, 2021, 8:41 AM UTC

galaxyLogic wrote: post #69

What I find interesting is that the human society and economy at large is able to function without there being any genius programmer who designed it all. If you look at roads, there is a road everywhere and still people don't get lost. But in a big chunk of source-code I do feel I get lost. I believe that may be because there are too few constraints when programming textually. Whereas when designing roads and bridges…

Habe you seen an aerial view of Birmingham's "spaghetti junction"? ;0)

Re: Folk wisdom on visual programming

#104

Post by sideshowb » Fri, Jul 02, 2021, 8:41 AM UTC

bmitc wrote: post #73

analog31 wrote: post #17

The author alludes to problems related to complexity, modularity, and formatting, of visual code. I think a hard problem for visual languages is the sheer physical labor of creating code using drawing tools. I used LabVIEW extensively for a few months, and ended up with crippling wrist fatigue and eyestrain headaches from all of the fine mouse work and menu selections needed to write even small programs. This is an e…

> I used LabVIEW extensively for a few months I’m not sure that a few months is enough to understand the true pros and cons of a language. I’m using Elixir in my day job now and have used F# for side projects, and it’s not clear to me any one is faster to program in, especially for GUIs. LabVIEW actually shines, contrary to popular but inexperienced opinion, for large projects. I have used LabVIEW rather extensively,…

> As an aside, it is curious to me that many programmers are heavy PC gamers as the one true way to game and don’t complain about the mouse use there but will throw out all sorts of complaints when using it to program

Are those definitely the same people? Mouse use is certainly one of the reasons I gave up gaming. (The other being that an X hour working day is quite enough time to spend in front of a computer already).

Re: Folk wisdom on visual programming

#105

Post by hermitcrab » Fri, Jul 02, 2021, 8:48 AM UTC

koolhaas wrote: post #28

shadowgovt wrote: post #12

The biggest challenge with visual programming is you have to reinvent every text-based tool. And there are a lot of them. Diff, interactive debugging, keyboard-accelerated inputs and shortcuts, search, version control... The list goes on.

Side note: interactive debugging is kinda inherent with the flow based programming paradigm. The program is continuously executing with every new action and immediately reflecting the current state. To program with it is to debug. If there’s an error with a component, it turns red and everything down stream breaks as well.

Yes, I think that sort of instant feedback is very helpful and is probably one of the reasons Excel is so popular.

Re: Folk wisdom on visual programming

#106

Post by hutzlibu » Fri, Jul 02, 2021, 8:59 AM UTC

analog31 wrote: post #17

The author alludes to problems related to complexity, modularity, and formatting, of visual code. I think a hard problem for visual languages is the sheer physical labor of creating code using drawing tools. I used LabVIEW extensively for a few months, and ended up with crippling wrist fatigue and eyestrain headaches from all of the fine mouse work and menu selections needed to write even small programs. This is an e…

"I think a hard problem for visual languages is the sheer physical labor of creating code using drawing tools."

Has anyone tried yet, to build a compiler, that compiles code into visual programming structures - and back?

I know scratch does this in a very limited way(code to scratch), but are there other tools around?

I am not aware of any, except for mine (which is unpublished as of yet, but if I get the website right, that might change by this weekend).

Re: Folk wisdom on visual programming

#107

Post by gridspy » Fri, Jul 02, 2021, 9:14 AM UTC

dharmab wrote: post #3

markus_zhang wrote: post #2

I guess this is turning into another "visual programming" post. On my side I'd like to ask your opinion about Blueprint. It really turned me off back in the day and I always wonder why they couldn't optimize UnrealScript further instead of getting something totally new. Yeah for sure eventually everyone get used to it and it becomes the new standard ("How can I NOT do Blueprint? It's so splendid" type of posts will s…

This presentation might enlighten why visual programming is in demand for gamedev. It's about a similar system developed in-house for The Division series: https://www.gdcvault.com/play/1023382/AI-Behavior-Editing-an... In short: There are many game designers and artists who prefer visual scripting tools over traditional code.

If you cannot access the vault, here is a YT link to the same talk:

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

Re: Folk wisdom on visual programming

#108

Post by slx26 » Fri, Jul 02, 2021, 9:19 AM UTC

w_t_payne wrote: post #36

I believe that diagrams are at their most useful when they are deployed as a communications tool. When discussing our software, we commonly draw a diagram to help illustrate how functionality is divided up among components, and to show which components are impacted by particular functional chains. They are a powerful tool for communicating and coordinating the work of multiple people or multiple teams. If our softwar…

Yeah, to make sense of complex systems they need to be well structured and modularized, and visuals have a lot to contribute here. If you can't fit your structure comfortably in a diagram, your structure is too complex for most people to manage.

Further down the line you stop needing to know where you are (global view, understanding), and you only need to deal with implementation: actually doing what you need to do. Implementation can be often very complex on its own too, that's why algorithms are so scary at the beginning... and text is a better tool here. There's not much more structure to distill, and some parts are tricky, and you have edge cases and you often need to get your hands dirty. You need to keep all this complexity in mind at the same time anyway, and after you are done you can treat the implementation as a black box. So text is superior here.

That's how we manage complexity. Now we only need tools that can represent it better. But maybe it's not even visual programming languages, but rather visual system "structurers"? There are other parts of programming that could use better visual cues, and visual editors for visual stuff (colors, shapes, borders, etc.) will always be relevant, but those are all very different concerns.

Re: Folk wisdom on visual programming

#109

Post by gridspy » Fri, Jul 02, 2021, 9:23 AM UTC

Zababa wrote: post #67

gridspy wrote: post #63

Earlier quoted context omitted.

Personally I think programming language is about a compromise between performance and convenience. For instance, I program in Python if speed is irrelevant. Rust if it is very relevant. C# if I want a large project where performance is somewhat important. I think there are a wide range of languages for each "category" where I put Python, C# and Rust above, but those 3 are my current favorites. Certain languages are v…

> Personally I think programming language is about a compromise between performance and convenience. That's one dimension, but what about popularity, maintainability, being able to hire, productivity, being able to tackle precise problems, etc.

I concur, though most of the traits you mention are not problem-specific.

When putting a language into "your toolbox" you indeed SHOULD focus on "popularity, maintainability, being able to hire."

However, when picking which of the languages you have learnt to apply to a given problem you need to know their relative strengths.

Most of the strengths you mention help you pick the "best in class" language. But only the problem can tell you which subset of langauges you are picking from. Sometimes the best possible tool for your problem is going to be unpopular.

Re: Folk wisdom on visual programming

#110

Post by knolan » Fri, Jul 02, 2021, 9:40 AM UTC

I really like the node based workflow used by Blender for creating materials, compositing and now for generating geometry. This is where I think visual programming works best, realtime interactive tweaking of something actually visual.

It's also generally kept simple and is powerful enough to get the job done.

I've always hated LabView however, it grows too unwieldy quickly and the limited nature of its visual display doesn't help. I remember once going to a NI training session around 2008 that was actually a sales session and their guy tried to convince us that LabView was easily parallelisable by drawing two empty while loops and showing them maxing out both CPUs on his laptop. The mind boggles.