We need visual programming. No, not like that
Visual programming struggles to gain traction as it attempts to replace code syntax instead of focusing on developers' actual visualizations, such as state transitions and memory layouts, requiring better integration and usability.
Read original article
Visual programming environments often struggle to gain traction among developers because they attempt to replace traditional code syntax and business logic, which developers do not visualize. Instead, developers typically visualize aspects such as state transitions, memory layouts, and network requests. The article argues that visual programming would be more effective if it focused on these areas rather than trying to simplify code syntax. Many existing visual programming tools are designed with the assumption that users will be experienced developers, which may not align with the needs of the broader programming community. Developers often visualize complex aspects of their code, such as codebase structures, memory layouts, and network diagrams, but these visualizations are often created ad-hoc and lack integration into standard workflows. Some tools, like Sourcetrail and treemaps, provide useful visualizations but still face challenges in usability and integration. The article emphasizes the need for better visualization tools that align with how developers think and work, suggesting that effective visual programming should focus on enhancing understanding of complex systems rather than merely replacing code syntax.
- Visual programming fails because it tries to replace code syntax rather than focusing on what developers actually visualize.
- Developers prefer visualizations of state transitions, memory layouts, and network requests over simplified code representations.
- Existing visual programming tools often lack integration into standard workflows and are not widely adopted.
- Effective visual programming should enhance understanding of complex systems rather than just simplifying code syntax.
- Tools like Sourcetrail and treemaps show potential but need better usability and integration into development environments.
Related
We need visual programming. No, not like that
Visual programming environments struggle due to mismatched focus on syntax. Developers prefer visualizing state transitions and code aspects. Tools like Sourcetrail aid in understanding code complexity, suggesting more visualizations for improved software comprehension and optimization.
Visual programming should start in the debugger
Visual programming leverages visual-spatial reasoning, proposing enhanced debuggers to visualize data structures over time. Efforts prioritize debugger improvements over text editors to create a new visual programming approach.
Where should visual programming go?
Visual programming enhances software development by integrating graphics with traditional code syntax. Advocates suggest using diagrams alongside code to improve understanding and maintain cleaner code, aiming for a harmonious coexistence of text and visuals. Luna explores a dual representation system where diagrams complement textual coding, similar to game engine scene management.
Defense of Lisp Macros
The article highlights challenges in automotive software development, emphasizing reliance on C, fragmentation from specialized tools, and advocates for powerful languages like Lisp to improve efficiency and integration.
Where should visual programming go?
The article discusses the future of visual programming, advocating for its role in enhancing traditional coding through useful visual elements, while outlining four integration levels for diagrams and code.
4 commentsI like how markdown has allowed us to render a purely textual definition of a document without majorly muddying the concerns of layout with content. I also like how mermaid has made diagraming through text more approachable too. So if a programming language's comment syntax could make way for standardized embeddable mermaid, maybe more editors/IDEs/tools could present the visualizations as context while editing the code? Possibly such tooling could look for discrepancies between the diagrams and the code to flag when they might be diverging?
Many interesting discussion there.
Because real programming languages are free.
That's it. That's the main reason. Sure, there are hobby projects, yes, but almost every visual "programming language" in use in the industry, is a proprietary product, being licensed or sold. It's a way to make money, and a pretty smart one to be honest: Once people invest time, resources, training, and build actual stuff in my proprietary system, they either invest a lot more money to get rid of it, or keep using it. And inertia in businesses being what it is, they usually chose the latter. What better vendor lock-in than a programming language?
---
IMHO, no, we don't need "visual programming". I have worked with several such systems in professional settings. There is one thing they all have in common: They suck. No exceptions. It doesn't matter what level they abstract at. They are all sold on the simplest of use cases, and to be fair: They can manage them very well. And some even look pretty and are a pleasure to work with.
At the start, that is.
Then the honeymoon is over, and you hit the first snag. The first thing the devs of it didn't anticipate, or anticipated but implemented badly. And you build around that. And then the next thing happens. And the next. And the next.
And very soon, you keep running for the escape-hatch constantly, like calling into library code, or making HTTP requests to some server to do things that would have been a breeze in a real programming language. Congratulations, we are right back to "non-visual-programming", only now our real code is tangled up in this mess, having to waste precious clock cycles pandering to the ideosyncracies of a less capable system, for no better reason that to not get rid of said system. And god help you if you have more than one of these things and they have to talk to each other. Now you can write glue-code between two pseudo-programming systems! FUN!
And, of course, these things are usually not accessible to any established tooling: There either is no version control at all or some vendors pet project idea of what a cool (read: bad) git alternative should look like. There usually is no way to unit- or integration-test anything. The only "IDE" that can deal with them, is the one the vendor provides. Also, `grep`, what's that? Never heard of it.
To be fair, there are some legitimate use cases, for example a limited flow-engine within a larger system that never has to leave that systems confines. But quite often, even these systems would be easier to setup and administer, if the devs had just put in a LUA interpreter and called it a day.
---
So, coming back to the question
"But why do people keep coming back to visual programming?"
allow me to ask an alternative question: Why do people stick with textual programming, despite decades spent on trying to make visual programming happen?
Related
We need visual programming. No, not like that
Visual programming environments struggle due to mismatched focus on syntax. Developers prefer visualizing state transitions and code aspects. Tools like Sourcetrail aid in understanding code complexity, suggesting more visualizations for improved software comprehension and optimization.
Visual programming should start in the debugger
Visual programming leverages visual-spatial reasoning, proposing enhanced debuggers to visualize data structures over time. Efforts prioritize debugger improvements over text editors to create a new visual programming approach.
Where should visual programming go?
Visual programming enhances software development by integrating graphics with traditional code syntax. Advocates suggest using diagrams alongside code to improve understanding and maintain cleaner code, aiming for a harmonious coexistence of text and visuals. Luna explores a dual representation system where diagrams complement textual coding, similar to game engine scene management.
Defense of Lisp Macros
The article highlights challenges in automotive software development, emphasizing reliance on C, fragmentation from specialized tools, and advocates for powerful languages like Lisp to improve efficiency and integration.
Where should visual programming go?
The article discusses the future of visual programming, advocating for its role in enhancing traditional coding through useful visual elements, while outlining four integration levels for diagrams and code.