Live data from Hacker News

Folk wisdom on visual programming

drossbucket.com

111–120 of 168 posts

Re: Folk wisdom on visual programming

#111
"A picture paints a thousand words, sure, but here's a thousand word essay. Try painting me a picture of it."

I don't remember where I hard that, or close to it, but there's a lot of truth to it. There do seem to be some very useful visual logic and work flow tools, I hope that continues, but there's something magical about the ability of language to explain, describe and precisely define things.

Maybe eventually we'll arrive at a state where really good programming environments incorporate the advantages of both textual and visual tools in a powerful and dynamic way. I love films and picture books, I also love novels, but even the best novels are enhanced by really good illustrations and sometimes even maps. Some authors find visual tools like relationship maps and even geographic maps help them in the actual authoring process too.

Re: Folk wisdom on visual programming

#112
post #95
post #67

Earlier quoted context omitted.

> 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.

Those are layman’s concerns. Programmers love to learn new things and are typically good at it. If a given tech has merit and some unique advantages. Edit: I didn’t read the comment right. Productivity and being able to solve precise problems are essentially why you’re choosing a technology in the first place?

> Those are layman’s concerns. Programmers love to learn new things and are typically good at it. If a given tech has merit and some unique advantages.

I don't think that's true, I believe most programmers are either dark matter developers [1] or people doing Java (or equivalent) all their life for a software service company. There is nothing wrong with that, but that would explain why less popular languages and ecosystem still have lots of stuff. For example, Rust has ~60k crates on crates.io, while Maven Central has ~400k packages. I believe Java is used by more than 10 times the number of people that use Rust. But the people writing the libraries in the first place are usually the people that are open to trying out new languages.

[1]: https://www.hanselman.com/blog/dark-matter-developers-the-un...

Re: Folk wisdom on visual programming

#113

Something I'd like: a modern maintained DRAKON version: https://en.wikipedia.org/wiki/DRAKON . Tried it once, generates reasonably good C code. It would be great to have a modern FLOSS version.

Not for C, but someone shares your motivation enough to build a version for JS: https://drakon.tech/ & https://github.com/stepan-mitkin/drakon.tech

Re: Folk wisdom on visual programming

#114

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…

For a beginner Labview can be a great step up.

Back in 1991 I worked on Labview at a university lab. It seemed amazing for the time.

For a teenager migrating from Basic - Labview seemed a fantastic improvement.

It felt incredibly powerful to draw boxes and wires to make multiple scientific instruments gather data.

I do remember spending a lot of time on alignment, plus there was no code revision at the time...

However, the lab moved to custom C based workflow. It was great on a personal level - writing low level drivers etc.

Part of the reasoning was that at some point the scientists needed a custom UI and it was actually easier to create one with C than with Labview.

Re: Folk wisdom on visual programming

#115
It think, VP shines in specialized fields and not general programming.

Visual domains are an obvious example.

If your domain is constrained by something that maps good to spatial dimensions than you're good to go. A few extra dimensions can also put into styling. But after that it becomes too restricting.

That's why interface builders work fabulous until you have to implement actual business logic and modularize your application. This always leads to adding things that aren't directly represented in the current visual model and get lost, because of indirections.

Re: Folk wisdom on visual programming

#116
post #108

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.…

It's always a good sign when a debate moves beyond 'x' is better than 'y' to a more nuanced discussions of the circumstances and conditions when 'x' provides more value, and the circumstances and conditions when the converse is true.

Re: Folk wisdom on visual programming

#117
post #9

Great job on summarizing and categorizing tons of opinions in one post! Shameless plug of my take on rethinking visual programming couple of years ago: https://divan.dev/posts/visual_programming_go/

Oh, this is great. I especially like the fire torch analogy and the animation you came up with (https://divan.dev/images/torch.gif).

That's exactly how I feel when reading code. Recently, I explained the problem to a dear colleague when working on a code base (with about 600K lines of code). I compared the situation to working in a large office building with all lights turned off and you have to skim through thousands of documents with a flashlight.

It's comforting to know that other people feel the same way.

Re: Folk wisdom on visual programming

#118
Mandatory fanboi mention, and IMO a gross omission of the article:

https://enso.org/ (née Luna)

- an open-source language & IDE which aims to insta-kill all the "vs. textual programming" arguments by keeping a strict 1:1 visualtextual representation translation as a core feature of the language. A 2.0 alpha was recently released, go check it out!

Re: Folk wisdom on visual programming

#119
post #110

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 displa…

Arguably he's not wrong?

I don't love LabVIEW but I make it work because their hardware is not bad compared with alternatives.

Dragging two loops is pretty easy compared to figuring out threads and thread-safe communications in C++.

Re: Folk wisdom on visual programming

#120
post #111

"A picture paints a thousand words, sure, but here's a thousand word essay. Try painting me a picture of it." I don't remember where I hard that, or close to it, but there's a lot of truth to it. There do seem to be some very useful visual logic and work flow tools, I hope that continues, but there's something magical about the ability of language to explain, describe and precisely define things. Maybe eventually we'…

"Maybe eventually we'll arrive at a state where really good programming environments incorporate the advantages of both textual and visual tools in a powerful and dynamic way. "

Yes, I agree. But not surprisingly, this is not easy to solve. You need a visual language as a consistent concept and then you need a actual visual framework, rendering it all, and enabling user input. You need a compiler compiling forth and back, between text and visu.

And then it needs to scale. And be performant enough to actually work with it and not just have a visual demo.

Sounds hard? Trust me, it is.

Post reply on HN