@Laaauurrraaa I’ve done some work towards this sort of thing in Clojure. What you’re essentially describing is a combination of static analysis (for the “show me all things that contribute to this result” part) and tracing (for replay of values that flowed through)

Ah I'll just continue here

you may find this relevant: https://en.wikipedia.org/wiki/Provenance#Computer_science

Ooohhh cool thx ❤️

Another related term is 'program slicing'. https://en.m.wikipedia.org/wiki/Program_slicing

If I had to do this, I think a pragmatic middle ground would be (in javascript) to set up a code coverage tool, an run a test that generates the output I'm interested in, then inspect the coverage report.

I don’t see how code coverage intersects with data lineage/program slicing…

In some cases you can take shortcuts by using optimization to see which parameter affects what output: http://omrelli.ug/g9/gallery/ Or, if you are only interested in the final line that drew an element, you could inject info about the code explicitly into the metadata of components that are drawn. “Use-define chain” seems like a related concept based on the Wikipedia page, but I don’t know anything more about that: https://en.wikipedia.org/wiki/Use-define_chain I asked a possibly related question on Stackoverflow a year ago related to instrumenting JS, but didn’t get any useful replies there: https://stackoverflow.com/questions/47871319/how-to-inspect-variable-data-flow-in-javascript Somehow I get the feel that maybe LISP-like languages, where code and data are more similar, would be easier to debug and reason about. Then, instrumenting code wouldn’t be anything special or cause so much perf overhead. Probably also any architectures with mainly pure functions.

profilers, code coverage, anything that instruments your code probably has some way to get the call graph and parameters. from that data you can analyze it how you wish. For javascript, doing it at runtime seems better than with however far you could get with static analysis and via a test runner is just a convenient way to control the code paths under scrutiny.

In Microsoft Assembler programming, the debugger had the ability to watch a piece of memory and pause the execution at the instruction that was modifying that object, thus allowing you to back-trace from the effect to the cause. This has been around since early days of computers. I think the technical term is WatchPoints, but different language has been used over this long span of time. Unfortunately with object oriented programming, it is very difficult to set a watchpoint on an object's properties when the object doesn't exist yet. This is therefore one of my main objections to the entire OOP paradigm, that it precludes triggering a stop to examine things on a data transition. Languages which have no allocation (no new, no dispose) and are static in structure are so much easier to debug. If you look at the RAM map of a typical object oriented program, its like a bucket of vomit.