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

51–60 of 168 posts

Re: Folk wisdom on visual programming

#51

Post by koolhaas »

taeric wrote: post #46
koolhaas wrote: post #39

Earlier quoted context omitted.

Flow paradigm doesn’t claim scale though. It’s about being a DSL for specific environments, often visually-oriented software like CAD or interactive art, which doesn’t have heavy 10K person team requirements.

Fair. And I think there is more here. If you are programming a singular thing, this probably has good legs. As soon as you are programming many things, though? This is why cad systems can be seen as visual programming of parts, but are never considered for this debate.

I’d be curious to hear you elaborate on the singular/many things point. Trying to understand which deficiency you are pointing out.

Re: Folk wisdom on visual programming

#52

Post by mikewarot »

For completeness, I feel compelled to mention GNU Radio. It is a node based visual programming tool. It has its quirks, but you can do fairly complex digital signal processing with it, and it will do I/O from your sound card, as well as RF stuff.

Re: Folk wisdom on visual programming

#53

Post by mikewarot »

dannywarner wrote: post #41

I like the line "There’s a comforting familiarity in reading the same internet argument over and over again." The problem I think with visual programming tools is people get stuck. I watched my dad's career die stuck in Visual Basic. It's because people get stuck in thinking the way those tools force you to think. Code in text has a magnificent universality.

I'm curious what you mean by how Visual Basic makes you think.

Re: Folk wisdom on visual programming

#54

Post by taeric »

koolhaas wrote: post #51
taeric wrote: post #46

Earlier quoted context omitted.

Fair. And I think there is more here. If you are programming a singular thing, this probably has good legs. As soon as you are programming many things, though? This is why cad systems can be seen as visual programming of parts, but are never considered for this debate.

I’d be curious to hear you elaborate on the singular/many things point. Trying to understand which deficiency you are pointing out.

For example, Programming a security system for my house would be great visually. Programming all of the houses on my block? Not so much. Even though the textual rules would be roughly equivalent.

Re: Folk wisdom on visual programming

#55

Post by MetaWhirledPeas »

Years ago I bounced around from one visual tool to another, never mastering any of them but getting deep enough to see the flaws. Hypercard, Authorware, Director, Flash. They were all very approachable, but they were all incredibly flawed in the end. You'd spend most of your time jumping from one limitation to the next, trying to hack your way out of the spaghetti jungle.

I think the better approach is to use conventional languages with UI tools layered on top that at worst generate readable code. (Like I assume is often done in game development.) Source control and diffing are indispensable.

The lure of these tools is that they are approachable, which sometimes is exactly what you need to get started. It's just very rarely what you need to finish. So let these tools be used to get people interested in programming, or to give people an idea of how to accomplish a project. But more importantly let's make sure to continue taking steps to demystify coding. Not because we want everyone to be programmers, but because when people do choose to program we want them to be able to collaborate with the rest of the world, and when they leave we don't want to inherit some visual pasta dish.

Re: Folk wisdom on visual programming

#56

Post by whatusername »

protomyth wrote: post #26
lliamander wrote: post #23

Earlier quoted context omitted.

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.

Node Red "Nodes" perhaps?

Re: Folk wisdom on visual programming

#57

Post by IdiocyInAction »

jimsmart wrote: post #21
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/

People have also made neural networks using Redstone in Minecraft. You can make anything you want in Scratch; the question is whether it is wise to do so.

Re: Folk wisdom on visual programming

#58

Post by ziml77 »

epage wrote: post #44

My feedback, based on my both long but limited LabVIEW experience > IDEs for text-based languages normally have features like code folding and call hierarchies for moving between levels, but these conventions are less developed in node-based tools. This may be just because these tools are more niche and have had less development time, or it may genuinely be a more difficult problem for a 2D layout — I don’t know enou…

I had to suffer through a semester of LabVIEW. It seems like it might be okay if you have high enough level blocks of functionality available that you're never hooking many together, but for what I was trying to do it was a massive pain (doable, but tedious and hard to organize and follow)

Re: Folk wisdom on visual programming

#59

Post by Sophistifunk »

We need both. And more. Visual projection and editing is valuable when looking at a zoomed-out "components and wires" sort of architectural view. It's also good for showing high-level overviews of a process, like various UML diagrams should have been. It can sometimes be used well for the nitty-gritty implementation details of a single unit, although this seems to be where a lot of it breaks down.

But it's terrible for doing all of these things at once. And also, if you can control your level of detail/zoom well enough to do it right, you'd get similar benefits projecting to simpler text formats as well.

What's most important is that all this stuff needs to be declarative. Not in the sense that you hide the order of operations within a block of code, in a way that final performance characteristics can become a surprise, but that the more complex structures of your project that organises the blocks into modules, classes, functions, records, etc need to be declarative, rather than an imperative set of instructions that build a structure at run-time (usually difficult or impossible to explore and instrument) which is later executed to achieve your actual goals.

Re: Folk wisdom on visual programming

#60

Post by raphlinus »

> Is ‘folk wisdom from internet forums’ worth exploring as a genre of blog post?

Yes. I found this very well done and useful.

One other (not entirely unrelated) potential area that immediately comes to mind for me is the architecture of UI toolkits. This is an area where there is very little serious (ie academic) writing, and even less good writing. The vast majority of what's set to paper is marketing material for a particular toolkit. There are some potentially interesting blog posts, but these tend to be highly opinionated.

Adding to this, while most of the discussion today is around shiny new stuff like SwiftUI and React, there's actually a pretty significant "literature" of older systems. It's hard to know what's worth digging into.

And, as with visual programming, there's not much in the way of synthesized understanding about the best way to do things. Game programmers like imgui, but it hasn't caught on outside that domain. Why? React is massively popular, but there is criticism of its performance (and of web-based technology stacks). There are other debates about the value of being "native," which perhaps used to be a clear distinction but is fuzzier today when you look at it closely.

So I think something along these lines for that topic could be pretty valuable.

Post reply on HN