One of the many neat uses of Observable is quickly prototyping these kinds of graphics - often by starting with a notebook someone has already created and iterating on it.<p>I have a notebook here which can visualize the table structure of any Datasette-hosted database: <a href="https://observablehq.com/@simonw/datasette-table-diagram" rel="nofollow">https://observablehq.com/@simonw/datasette-table-diagram</a><p>My first version used a force-directed graph for this, but then Thomas Ballinger from the Observable team showed me how to use a DOT diagram, which is a much better visualization for relational tables.
Seas of nodes are also used as IR in Java Hotspot and the V8 engine (<a href="https://doar-e.github.io/blog/2019/01/28/introduction-to-turbofan/" rel="nofollow">https://doar-e.github.io/blog/2019/01/28/introduction-to-tur...</a>)
I started learning Blueprints in Unreal Engine recently, I swear it has helped my problem solving ability in other general areas of programming. Watching the links light up as nodes are executed is pretty great for debugging.
This was a nice article, and I thank you for providing those references at the end.<p>The article makes it seem as if TruffleRuby is a Shopify project, where this GitHub repo seems to differ on that point: <a href="https://github.com/oracle/truffleruby" rel="nofollow">https://github.com/oracle/truffleruby</a>. What's the deal?<p>I'm also very curious about how much TruffleRuby helps you save in infrastructure costs. It looks like Shopify is starting to put together serious systems around optimization of Ruby code.
Aren't we coming full circle back round to UML? UML is very good at designing and documenting complex code and it's interactions at many different levels, and having a common graphing notation helps ensure everyone is on the same page by looking at the same diagram.<p>The problem comes when the design and the code get out of step, but there are tools available to round-trip the code and model to keep everything in sync. Executable UML used to be a thing too, but I was never very convinced by it.
not _directly_ related, but one interesting thing my coworker has been working on is visualizing ML models using graphs, which has made them much more interpretable for business stakeholders. Being able to break the model down into steps, feed the graph individual observations to see how the model flow would work, etc. I was surprised how receptive non-technical people were to the concept
I enjoyed the article, but am maybe too dense to understand the repercussions. My understanding of the summary is that a goal is to be able to develop these graphs and then convert them back to ruby so that developers who know ruby can see how the compiler is optimizing. My honest question is, why does this matter? If the developers then start writing code more in line with what a compiler would do, then it seems compilation would be faster - is it significant, and is this a reason why? What else could it be? Thanks for the article and any thoughts!
The big value of the visual representation is if it is dynamic. That is, it gets updated while you are running the code and can use it during debugging. Otherwise, the novelty wears off quickly.<p>Static graphs are still useful to understand a new piece of code, see Source Trail[1]
[1]: <a href="https://www.sourcetrail.com/" rel="nofollow">https://www.sourcetrail.com/</a>
Interesting topic. I feel like the representation of the Ruby fib misses the mark though because of how many language implementation details are caught up in it. The lack of abstraction here takes away from the usefulness of using a graph for understanding control/data flow in a program.
Interesting article and good question about whether we should program using graphs. In a different domain, languages like halide, tvm and tiramisu or in a way letting programmers create graphs for high performance.