3 ms·

I've always wanted a runtime visualizer, and/or a static analysis visualizer. With a couple of exceptions I was unable to find a suitable library and it seems f

by proc0 7y ago

I've always wanted a runtime visualizer, and/or a static analysis visualizer. With a couple of exceptions I was unable to find a suitable library and it seems for some reason this hasn't been built yet. So I also decided to take a stab at this, and hopefully will share if I get anything useful. I'm using Haskell + Diagrams to construct a JS parser (to begin with) that will do static analysis and render a graph of whatever you need. The simple use case I've always wanted was just a slice of the graph of the function calls, perhaps with some information on context variables. Seeing this visually would help me get up to speed with any codebase and would allow extremely fast contributions.

westoncb 7y ago
I do wonder why more work hasn't been done in this area—especially on the run time side. I actually think a big part of it is something like a fixed perspective on what the process of computer programming has to be like that comes from an era before it was possible to do such a thing well. One of the skills a programmer always implicitly learns is to imagine the data their code is operating on—and only to occasionally peek into it with e.g. printlns and debuggers. There's something about the seeming necessity of that that keeps people away from tackling the problem directly. It may be a fish not being able to see the water kinda thing. (At least that's my read on it :)
- fungicide 7y ago
  What the hell is water?
- shalabhc 7y ago
  Perhaps a combination of cultural and technical feedback loops? Technology selects folks that like 'playing computer in your head' as Victor said [1]. This grows a culture where tools that help you avoid mentally simulating the computer are devalued. This selects more people even better at playing computer in their heads, etc. [1] https://www.theatlantic.com/technology/archive/2017/09/saving-the-world-from-code/540393/ https://www.theatlantic.com/technology/archive/2017/09/savin...

by proc0 7y ago

westoncb 7y ago

I do wonder why more work hasn't been done in this area—especially on the run time side. I actually think a big part of it is something like a fixed perspective on what the process of computer programming has to be like that comes from an era before it was possible to do such a thing well. One of the skills a programmer always implicitly learns is to imagine the data their code is operating on—and only to occasionally peek into it with e.g. printlns and debuggers. There's something about the seeming necessity of that that keeps people away from tackling the problem directly. It may be a fish not being able to see the water kinda thing. (At least that's my read on it :)

fungicide 7y ago
What the hell is water?
shalabhc 7y ago
Perhaps a combination of cultural and technical feedback loops? Technology selects folks that like 'playing computer in your head' as Victor said [1]. This grows a culture where tools that help you avoid mentally simulating the computer are devalued. This selects more people even better at playing computer in their heads, etc. [1] https://www.theatlantic.com/technology/archive/2017/09/saving-the-world-from-code/540393/ https://www.theatlantic.com/technology/archive/2017/09/savin...