Code2flow: Pretty good call graphs for dynamic languages(github.com)
github.com
Code2flow: Pretty good call graphs for dynamic languages
https://github.com/scottrogowski/code2flow
18 comments
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.)
[^1]: https://lambdaland.org/posts/2021-05-20_cfa/
[^2]: https://en.wikipedia.org/wiki/Control_flow_analysis
[^3]: https://www.ccs.neu.edu/home/shivers/papers/pldi88.pdf
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.)
[^1]: https://lambdaland.org/posts/2021-05-20_cfa/
[^2]: https://en.wikipedia.org/wiki/Control_flow_analysis
[^3]: https://www.ccs.neu.edu/home/shivers/papers/pldi88.pdf
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
The next thing that would be great is hyperlinks to the source code from each node in the graph
Well, there is
Understand
https://www.scitools.com/
Source Insight
https://www.sourceinsight.com/
Imagix 4D
https://www.imagix.com/
But it is not open source
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.
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.
[deleted]
This actually should be the way codes are written. This is how we reason about codes in our minds.
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.
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.
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.
How about writing code and then looking at it through blocks?
That might be superior, if done right.
That might be superior, if done right.
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.
Isn't this something already accomplished by Sourcetrail (a FOSS tool!) with much better UX? It's unfortunate that it is now dying.
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.
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.
Can't get it to work well with flask route annotations but the basics are really great!