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

We need visual programming. No, not like that

blog.sbensu.com

Post reply on HN
Print view View original

91–100 of 505 posts

Re: We need visual programming. No, not like that

#91

Post by andrewflnr »

lolinder wrote: post #28
andrewflnr wrote: post #19

Earlier quoted context omitted.

Specifically, textual programs use symbols to build a graph of references between computations, where the average visual language tries to use explicit lines between blocks. But the reference graphs of non-trivial programs are often decidedly non-planar, which only becomes a problem when you try to lay them out on a plane.

Why does laying out code on a line not cause a problem with spatial reasoning but a plane would? Are we somehow incapable of applying spatial abstractions when we move up into a higher dimension than 1?

As jampekka put it, text isn't trying to use spatial abstractions, it's using the (arguably more powerful) abstraction of named values/computations. Hard to think about? Yes, there's a learning curve to say the least. But it seems to be worth it for a lot of cases.

Re: We need visual programming. No, not like that

#92

Post by learn_more »

sbensu wrote: post #75
twelvechairs wrote: post #20

Most of this isn't visual "programming" just good explanatory diagrams. I think it gets to a core issue which is a dichotomy between: - trying to understand existing programs - for which visuals are wanted by most but they usually need concious input to be their best - programming (creating new code) itself - where the efficiency of the keyboard (with its 1d input that goes straight to spaghetti code) has never been…

You are right. The diagrams are used as explanations not as the source of the program. But wouldn't it be neat if when you sketch out the state transition in a diagram (how I think about the state transitions), _that diagram_ was the source of truth for the program? That is the implied point: let's go to places where we already draw diagrams and check if we can elevate them into the program

You might be interested in:

https://schematix.com/video/depmap

I'm the founder. It's a tool for interacting with deployment diagrams like you mentioned in your article.

We have customers who also model state machines and generate code from the diagrams.

Re: We need visual programming. No, not like that

#93

Post by charleslmunger »

sbensu wrote: post #75
twelvechairs wrote: post #20

Most of this isn't visual "programming" just good explanatory diagrams. I think it gets to a core issue which is a dichotomy between: - trying to understand existing programs - for which visuals are wanted by most but they usually need concious input to be their best - programming (creating new code) itself - where the efficiency of the keyboard (with its 1d input that goes straight to spaghetti code) has never been…

You are right. The diagrams are used as explanations not as the source of the program. But wouldn't it be neat if when you sketch out the state transition in a diagram (how I think about the state transitions), _that diagram_ was the source of truth for the program? That is the implied point: let's go to places where we already draw diagrams and check if we can elevate them into the program

This can be really tricky to do. I reached the limit of my brain's working capacity designing a priority inheritance system, and sketched the state machine out in a dot file, visualized with graphviz - this worked really well for reasoning through the correctness of the algorithm and explaining it to others. I tried to structure the implementation code to match it and I was able to get pretty close; but the actual states were a bunch of bit-packing and duplicated control flow to get optimal assembly output for the hottest paths. Each one of those changes was easy to reason about as an isolated correct transformation of the original structure in code, but would have been a mess visually.

Re: We need visual programming. No, not like that

#96

Post by KingOfCoders »

Twenty years ago I was a researcher (Fraunhofer) on executable UML, especially on aspect oriented programming (AOP which was a thing back then, but never caught on). You could draw a boundary around some UML process flow, and attach an aspect to it. For example a security boundry, and then the code generated would automatically add a security check aspect for all flows going inside.

What we did find out, text is just better to read and understand. It's easier to refactor and much denser. We experimented with different levels to zoom in and zoom out for bigger programs but Visual programming does not scale (or didn't at least back then).

Re: We need visual programming. No, not like that

#97

Post by dralley »

Harmohit wrote: post #59

I am surprised I have not seen LabView mentioned in this thread. It is arguably one of the most popular visual programming languages after Excel and I absolutely hate it. It has all the downsides of visual programming that the author mentions. The visual aspect of it makes it so hard to understand the flow of control. There is no clear left to right or top to bottom way of chronologically reading a program.

Most industrial automation programming happens in an environment similar to LabView, if not LabView itself. DeltaV, Siemens, Allen-Bradley, etc. Most industrial facilities are absolutely full of them with text-based code being likely a small minority for anything higher level than the firmware of individual PLCs and such.

Re: We need visual programming. No, not like that

#99

Post by tomrod »

rockemsockem wrote: post #95

You say several times that developers say they want visual programming, but I've never heard any developer ever say this. Is there some particular context where you've heard people say this in particular?

I develop, and I'd like at least a visual of my codebase as it interfaces with other systems as part of automatic documentation. So n=1, I reckon.

Re: We need visual programming. No, not like that

#100

Post by seanmcdirmid »

Visual programming with connections often just becomes literal spaghetti code, we really lean a lot on linguistic abstractions to manage complexity. I played around with lots of ideas, the latest one being direct manipulation of visually represented abstractions. Fun and somewhat promising (works really well for expressing bubble and quick sort, less well for rebalancing a red black tree after a delete), but I don’t see anything panning out before AI writes all the code for us.
Post reply on HN