We need to see the code paths that were executed for a certain request/feature/transaction.
I created Call Stacking for this visualization.
We need visual programming. No, not like that
101–110 of 505 posts
Re: We need visual programming. No, not like that
#102People have mentioned a bunch of successful visual programming applications, but one that I've been thinking a lot about lately is Figma.
Figma has managed to bridge the gap between designers, UXR, and engineers in ways that I've never seen done before. I know teams that are incredibly passionate about Figma and use it for as much as they can (which is clearly a reflection of Figma themselves being passionate about delivering a great product) but what impressed me was how much they focus on removing friction from the process of shipping a working application starting from a UI mockup.
I think Figma holds a lot of lessons for anyone serious about both visual programming and cross-functional collaboration in organizations.
Re: We need visual programming. No, not like that
#103The Big Tech monolith (`bingo`, `papaya`, etc.) is a fantastic callback to this video: https://www.youtube.com/watch?v=y8OnoxKotPQ. Although that video is perhaps ironically about microservices.
Re: We need visual programming. No, not like that
#104[deleted]
Re: We need visual programming. No, not like that
#105Most of these solutions are based on a cognitive trap, which I don’t know a name for, so I’ll call it the “maker vs. taker” fallacy. Person A (the maker) has a problem, and works to solve it by creating a tool. The tool is effective and person A applies it to many similar problems to good effect. Person B (“taker”) has just such a problem and applies the tool. Unfortunately it doesn’t help nearly as much as person A…
[deleted]
Re: We need visual programming. No, not like that
#106Most of these solutions are based on a cognitive trap, which I don’t know a name for, so I’ll call it the “maker vs. taker” fallacy. Person A (the maker) has a problem, and works to solve it by creating a tool. The tool is effective and person A applies it to many similar problems to good effect. Person B (“taker”) has just such a problem and applies the tool. Unfortunately it doesn’t help nearly as much as person A…
[deleted]
Re: We need visual programming. No, not like that
#107I 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.
I think the whole flow concept is really only good for media pipelines and such.
In mathematics, everything exists at once just like real life.
In most programming languages, things happen in explicit discrete steps which makes things a lot easier, and most node based systems don't have that property.
I greatly prefer block based programming where you're dragging rules and command blocks that work like traditional programming, but with higher level functions, ease of use on mobile, and no need to memorize all the API call names just for a one off tasks.
Re: We need visual programming. No, not like that
#108Visual 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…
I just don't think quicksort is a good fit for visual programming, (not that I've ever actually implemented quicksort....).
Visual is excellent for things like "At 7PM if the enable switch is on, turn on the sprinkler".
Stuff that's very simple, but you want no chance of it going wrong, and you might want to edit it from a phone.
When you want the least powerful programming model possible, that isn't even turing complete, that's arguably not even programming and just configuration, it's great.
Re: We need visual programming. No, not like that
#109Great article. To circle back to the point, some of these visualisations also contain hints to how they could be used for actual programming.
E.g. changing arrow type in the ownership diagram is a good example of a change that is very annoying to do manually in Rust but it's trivial in the diagram.
The challenge is to connect this action to the whole programming workflow, which is currently optimized for text, I'd even say overfitted. Rust especially is famously difficult to process by tools. I think we might need to use a language that is specifically designed to be processed by visual tools to make it all work.
Re: We need visual programming. No, not like that
#110You 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.
Yeah, in fact, most interfaces - video editing, Airbnb, 3D modeling - are some sort of visual interface. I understand code isn’t resembling a physical object.
But books and paintings were our best approximation of reality, then technology allowed us to make movies and photos. I feel like code being lines of text isn’t the best abstraction. But finding a better one won’t be easy.