From the article: I'm in the middle of a couple of grinding projects where I'm yet again picking apart uncommented code. I'm manually diagramming how it's put together, what has to happen for...
From the article:
Most visual programming environments fail to get any usage. Why? They try to replace code syntax and business logic but developers never try to visualize that. Instead, developers visualize state transitions, memory layouts, or network requests.
In my opinion, those working on visual programming would be more likely to succeed if they started with aspects of software that developers already visualize.
...
Developers do spend the time to visualize aspects of their code but rarely the logic itself. They visualize other aspects of their software that are important, implicit, and hard to understand.
Here are some visualizations that I encounter often in serious contexts of use:
Various ways to visualize the codebase overall.
Diagrams that show how computers are connected in a network
Diagrams that show how data is laid out in memory
Transition diagrams for state machines.
Swimlane diagrams for request / response protocols.
This is the visual programming developers are asking for. Developers need help with those problems and they resort to visuals to tackle them.
If you are skeptical about needing these, let me ask you: do you know exactly how your data is laid out in memory? Bad memory layouts are one of the biggest contributors to poor performance. Yet it is very hard to "see" how a given piece of data is laid out and contrast it with the access patterns present in the codebase.
Alternatively, do you know all the external dependencies your code hits when responding to a given HTTP request? Are you sure? Didn't you notice that Bob just added a call to a rate limiter service in the middleware? Don't worry, you'll learn about it in the next outage.
For both of these questions, the answer is usually "I think I know the answer?" with a creeping fear that maybe you missed something you couldn't see.
I'm in the middle of a couple of grinding projects where I'm yet again picking apart uncommented code. I'm manually diagramming how it's put together, what has to happen for database interactions and external API calls, and trying to figure out how to rewrite/insert new functions...
It's too proprietary for any existing tooling; just me and Excel, Visio, and scrap paper. But I really feel this article.
I got started on programming on Labview through Lego Mindstorms, and that makes any sort of textual language requires more brain time than text for me. It would be nice if there was more of an...
I got started on programming on Labview through Lego Mindstorms, and that makes any sort of textual language requires more brain time than text for me. It would be nice if there was more of an open standard for visual coding, but I understand that it would be yet another standard that would have less access than other languages in order to make more sense to a niche audience.
I totally get where the author is coming from. Visual representations of architecture and call patterns are super useful for understanding systems. The trouble is, particularly with micro...
I totally get where the author is coming from. Visual representations of architecture and call patterns are super useful for understanding systems. The trouble is, particularly with micro services, there's rarely a universal protocol that could be programmatically crawled to generate these diagrams.
The exceptions are things like AWS Step Functions and other workflow executors. They help organise things, but they also encourage unnecessary micro service proliferation. (Monoliths have their own issues. I just deeply hate micro services at multi-national scale.)
From the article:
I'm in the middle of a couple of grinding projects where I'm yet again picking apart uncommented code. I'm manually diagramming how it's put together, what has to happen for database interactions and external API calls, and trying to figure out how to rewrite/insert new functions...
It's too proprietary for any existing tooling; just me and Excel, Visio, and scrap paper. But I really feel this article.
I got started on programming on Labview through Lego Mindstorms, and that makes any sort of textual language requires more brain time than text for me. It would be nice if there was more of an open standard for visual coding, but I understand that it would be yet another standard that would have less access than other languages in order to make more sense to a niche audience.
I totally get where the author is coming from. Visual representations of architecture and call patterns are super useful for understanding systems. The trouble is, particularly with micro services, there's rarely a universal protocol that could be programmatically crawled to generate these diagrams.
The exceptions are things like AWS Step Functions and other workflow executors. They help organise things, but they also encourage unnecessary micro service proliferation. (Monoliths have their own issues. I just deeply hate micro services at multi-national scale.)