4 ms·
Most of the tools for visualizing code lack the practical part. Dependencies graphs are often so huge, that generated graphiz output doesn't even open on Macboo
by divan 5y ago
Most of the tools for visualizing code lack the practical part. Dependencies graphs are often so huge, that generated graphiz output doesn't even open on Macbook M1. Codeflow graphs kinda helpful sometimes, but nothing game changing.
I explored the topic of visual programming a couple of years ago and presented the first attempt to make the code visualization tool useful and practical in this long-read - "Rethinking visual programming with Go" [1]
The key point is that we build mental maps of the code whiel reading it. Simplicity of Go allows for rules' formalization of how I build 3D mental map myself, so I can outsorce it to the code. I.e. the static code analysis tool that reads any Go codebase and visuzlies a 3D structure similar to how I would do it in my head anyways. By clearly separating spatial and temporal aspects of code, it's possible to blend this code visualization approach with editor and make it practical and helpful rather than just visualization excercies.
I paused the development, as I see the future of this project only in VR/AR environment, and I'm not sure this ecosystem is ready yet (it's a side project still). But honestly I dream about this tool almost daily, while coding with usual text code representation.
[1] https://divan.dev/posts/visual_programming_go/ https://divan.dev/posts/visual_programming_go/
- devmunchies 5y agoAmazing write up. Spent 25 minutes on it. I’m about to start learning Go now. I tried it a few times before but I never got that ah-ha moment. I wanted to build a visual tool in the devops space, and go is prevalent so I need to learn it sooner or later. But with your explanation, I see similarities to OCaml (which I love), where most of the work is modeling the domain by composing types.
- azth 5y ago> Simplicity of Go allows for rules' formalization of how I build 3D mental map myself, so I can outsorce it to the code. I don't see how that's any different from reading Java/C#/Kotlin code honestly.
- bmitc 5y agoVery interesting article. I'm gonna read it in more detail tomorrow. Thanks for sharing it. However, I did note that you lumped LabVIEW in with other visual "tools" and scripting tools. LabVIEW is a fully featured, general purpose language. You can do anything in it you can do in other languages, and there's plenty you can do in it that other languages can't. I don't know of any language that allows you to program desktop PCs, embedded high-level programs, real-time programs, and FPGAs with the same language. Maybe C/C++ with Vivado HSL. But...C/C++. LabVIEW compiles to DFIR, an intermediate dataflow language, and then that compiles down to LLVM IR, which is handed off to LLVM. You can call .NET assemblies and C/C++ DLLs. It has value-based OOP, various (rather unique) implementations of polymorphism, built-in multithreading across cores, immutable data, a nice event structure for building GUIs, is highly performant, and a ton of other features. It has built-in support for basically any protocol (HTTP, TCP/IP, UDP, etc.), so it can talk to basically anything. If it doesn't have something built-in, you can obviously build your own or pull in some .NET or C/C++ dependency. So yes, you could rather easily write a raytracing engine or a GraphQL library in it. In fact, LabVIEW is damn fast, so it is great at things needing to be performant, especially if they can be parallelized. LabVIEW is "specialized" to certain industries for three main reasons. (1) How well it ties in to NI's hardware and other test and measurement and scientific hardware. (2) It is expensive, but now there is a free Community version. (3) Non-acceptance amongst "mainstream" programmers of visual programming languages. So it actually has little to do with the language and more to do with factors external to the language.