Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Folk wisdom on visual programming

drossbucket.com

Post reply on HN
Print view View original

21–30 of 168 posts

Re: Folk wisdom on visual programming

#21

Post by jimsmart »

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…

> But you can only go so far with Scratch vs other programming languages.

A friend has built some pretty amazing stuff in Scratch, including a BBC Micro emulator (runs 60+ games), a few arcade game ports, and lots more [1].

As a developer myself, I find it quite surprising how far one can go with Scratch. (FWIW I've never coded with it myself)

[1] https://scratch.mit.edu/users/RokCoder/

Re: Folk wisdom on visual programming

#23

Post by lliamander »

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…

In my experience, there are three things that visual programming tools make difficult:

* abstraction

* version control

* test automation

Those are also (in my opinion) the three techniques which separate proper "software engineering" from coding/scripting, which is why visual programming tools are pretty much universally unsuited for complicated projects.

The one asterisk I would put on that is tools in which the visualization is based upon an actual, human readable, programming language. I did some work with XSLT back in the day using a visual programming tool, and it worked reasonably well.

Re: Folk wisdom on visual programming

#24

Post by namuorg »

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…

Yup, I've been working on a visual browser automation tool (https://browserflow.app/) for the past year, and it's been quite the fun design problem to balance simplicity (so that it can be used by non-technical users) with flexibility (so that it can handle more than the simplest cases).

An approach that worked for me was to provide an escape hatch (in my case, giving the user a way to run arbitrary Javascript on the page being automated) so that the built-in commands could be designed for the most common scenarios and users would still have a way to handle gnarly edge cases.

Re: Folk wisdom on visual programming

#26

Post by protomyth »

lliamander wrote: post #23
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…

In my experience, there are three things that visual programming tools make difficult: * abstraction * version control * test automation Those are also (in my opinion) the three techniques which separate proper "software engineering" from coding/scripting, which is why visual programming tools are pretty much universally unsuited for complicated projects. The one asterisk I would put on that is tools in which the vis…

abstraction

I do wonder why some concept likes building chips doesn't make it into visual environments? I should be able to pass a chip with inputs and outputs to others.

Re: Folk wisdom on visual programming

#28

Post by koolhaas »

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.

Re: Folk wisdom on visual programming

#29

Post by taeric »

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.

To further your point. Copy/paste. Email. Templating. Highlighting. Rendering that is not a part of the visual, such that accessibility tools work with it.

There is an impressive list of things your enter a race to parity with.

Re: Folk wisdom on visual programming

#30

Post by taeric »

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.

That falls on is face at scale. There is a reason not every bullet in a gun is a tracer bullet.
Post reply on HN