Live data from Hacker News

Where should visual programming go?

tonsky.me

31–40 of 77 posts

Re: Where should visual programming go?

#31
post #3

When this last round of discussion of visual programming happened I had a minor epiphany. For a little background, I’ve maintained that visual programming goes absolutely nowhere until we have visual diffs that work (work as in workflow). I’ve been saying that since before the UML Trough of Disillusionment kicked into high gear. Without diffs, without analysis, we are going nowhere fast. Almost every other link of th…

> Without diffs, without analysis, we are going nowhere fast.

The victory of plaintext coding over visual programming is another example of worse is better. Semantic, language-aware diffs exist, but I see them much less frequently than dumb plaintext diffs. Intelligent code search exists, but in many cases grep is just as good. IDEs come with very advanced refactoring tools, but I still prefer to refactor using vim macros.

When we write code in plaintext, we're expressing our code in a lower level of abstraction with really great tooling. Doesn't matter if it's java or yaml or something custom—plaintext tools work on all of them. Visual programming languages can't do this. There's no language-agnostic vim or git for visual programming. Even if we wanted to invent sort of unified language-agnostic visual programming abstraction, the ecosystem isn't there, and there's no guarantee it'd get adopted.

So I think plaintext will remain king for the foreseeable future. Visual tools have to use human-readable, human-editable plaintext as their source of truth, if they want to succeed.

Re: Where should visual programming go?

#32
Visual Programming is fine for very specific cases: Graph-based connection of inputs and outputs. It was used for DirectShow GraphEdit and ComfyUI, and works find there. Just please provide a way to also type things in manually as well.

Re: Where should visual programming go?

#35

It's interesting to see how different programming languages approach building software. Languages like Lisp are all about planning out the whole program structure (the "Abstract Syntax Tree") upfront, kind of like a blueprint. But modern tools and visual programming often take a more piece-by-piece approach. You build smaller parts first and then connect them together, gradually building up the whole thing. This bott…

> Languages like Lisp are all about planning out the whole program structure (the "Abstract Syntax Tree") upfront, kind of like a blueprint.

Lisp seems like a poor example because the emphasis there is building incrementally in an interactive REPL session. I think this style of programming would be very amenable to visual programming.

Re: Where should visual programming go?

#36
post #15

Recent and related: We need visual programming. No, not like that - https://news.ycombinator.com/item?id=40937119 - July 2024 (494 comments)

Further posts related to visual programming in the last month:

Visual programming should start in the debugger - https://news.ycombinator.com/item?id=40968215 - July 2024 (56 comments)

* Unit is a general purpose visual programming system* - https://news.ycombinator.com/item?id=40900029 - July 2024 (80 comments)

Re: Where should visual programming go?

#37

not a well thought out take, but i think visual programming should stop trying to encode application logic and focus on: - building good UIs rapidly (e.g. improving & simplifying layout options, look & feel, etc.) - make debugging trivial & powerful - make deployment trivial Visual Basic was on the right track in almost every way except as a language. Hypercard maybe had the language thing figured out: use english as…

Yeah, I feel like this blog post misunderstood the original post it was responding to. The argument wasn't simply "add visualization where it makes sense". It was "diagrams are more effective for dynamic analysis, as opposed to representing static structure, which code already represents effectively." Debugging being the #1 candidate, as you pointed out.

Re: Where should visual programming go?

#38
post #3

When this last round of discussion of visual programming happened I had a minor epiphany. For a little background, I’ve maintained that visual programming goes absolutely nowhere until we have visual diffs that work (work as in workflow). I’ve been saying that since before the UML Trough of Disillusionment kicked into high gear. Without diffs, without analysis, we are going nowhere fast. Almost every other link of th…

If functions are represented as directed graphs, it would be better and simpler to compare their graphs instead of how they look on a computer screen.

Re: Where should visual programming go?

#39

Non-programmer here. I’ve long desired to program Arduino microcontrollers but haven’t had the ability and/or the patience to learn programming. I’m a very visual person and get confused if I have to keep more than a few lines of code in my head. Even if I understand how I want a signal to be processed into an action, when the flow chart in my head needs to be translated into text I get overwhelmed. A solution arrive…

Interesting. Looks like the Flprog website is largely in Russian and Outseal seems to be Indonesian. Is there a good introduction to ladder logic in English?

Re: Where should visual programming go?

#40

Earlier quoted context omitted.

Curious, what's your profession? To me you do sound like a programmer.

Former machine technician. I used to repair machines in factories. I’ve been lurking on hacker news for over a decade because I find the work of programmers fascinating, but my brain just doesn’t cope well with code. I do however, understand machines and control logic, so for me visual programming is a sweet spot.

have you tried Simulink? it gets hated on and it's proprietary but I bet you'd really like it. there's also Drakon if you're down with flow charts.
Post reply on HN