Wow. Seeing your open source project while scrolling through hacker news is something that really brightens your day. I’m happy to answer any questions people have.
This project is AMAZING. Earlier this week I had the exact same idea of a project while disentangling a bowl of spagetthi code. I'm glad I've seen it here today so I didn't have to reinvent the wheel. Also, I'm impressed by the quality of the documentation. It's pure eyecandy. Kudos!
Under the "Known limitations" section, the author mentions that anonymous functions get skipped. That might be a dealbreaker for some.
Since this program just walks the statically apparent callgraph, you'll get an under-approximation of the behavior of your program. If you'd like an over-approximation, something like control-flow analysis can handle cases with anonymous functions. [^1] [^2] [^3] There are still some limitations, but CFA is really powerful.
(Anyone curious can contact me (see my blog) if you want more information on CFA.)
I could have used something like this numerous times whenearning a new codebase (or a new part of a big codebase). I wonder why this tooling isn't more popular.
The next thing that would be great is hyperlinks to the source code from each node in the graph
Very cool! It always makes me happy to see people develop tools that are useful without tying themselves in knots over the general case (total callgraph generation).
It's worth noting that it's impossible in the general case to generate a perfect callgraph for static languages as well. Function pointers in C are the obvious example, but more generally anything that converts control-flow into data-flow (like a dispatch table) causes the same problem.
Not really... I built a block-based IDE like that which compiled to TypeScript/React (you could switch to writing code and back to blocks at any time)... And I just never used it, writing code was much faster, even though it supported custom "macro" blocks and other new ways of making programs.
It depends on what kind of problems you're solving. System integrations and ETL-type stuff where it's mostly data transformation and not too much logic are great for visual dataflow programming. It's a lot easier if you can have code-within-blocks and blocks-within-code, too.
Also, I suspect there's going to be a correlation between a preference for spatial vs. lexical reasoning and a preference for visual vs. textual development.
Yeah I agree, I originally built that block-code tool for data transformations and in that domain it is used in practice and very useful. But it's just configuration/queries, no unrestricted coding (the users were shooting their feet too much).
That sounds perfect. If you have a strongly-typed language to develop new blocks in, then surely simple "configuration" for the blocks is enough for visual programming.
I'm curious what graphical Rust would look like. The type/trait system seems powerful enough to prevent weird errors at Runtime, while still enabling wide usecases for example with `AsRef<str>` where any type implementing conversion to string can be used.
In my case, it took much longer to convert the program from what I am seeing into a in-head representation. Perhaps I am just too used to textual code, but I really tried to do it another way... Or perhaps it's simply not for me, but others might be happy.
The two are very similar. I wrote the first version of this almost 10 years ago and only became aware of the existence of Sourcetrail while doing the rewrite a few months back.
On the surface - there is a difference in languages. Sourcetrail explicitly supports C/C++/Java/Python while Code2flow supports Python/JS/PHP/Ruby.
I would love to give code2flow the capability of Sourcetrail but would need to feel very good about it making money before I devoted that time to it.
