[piinbinary]

I wish I had tools that were just a little smarter at working with code. There are some things that I find I have to manually track down in a large codebase, but the things I do could be automated. I'm thinking of operations like the following:

* Tell me where in package (or module) X it calls functions that can eventually reach function Y in package Z (that is, there is a possible stack trace starting in X that leads to Y.

* Recursively expand the tree of callers of this function.

* Show me where the value passed to this function are created.

* List what packages have functions that can get called when I call function X.

* Given two functions A and B, what functions can result in calls to both? (This is sort-of the greatest common denominator of possible stacks leading to A and B)

(It seems like this must surely exist, but I have yet to find it)

I also want better tools for tracing what a system does when running. For example:

* Say I have a test over some deterministic code, and I make a small change to that code. I'd like to be able to run that test before and after, and get a diff of where the computation was the same vs. where it was different.

* When debugging, I'd like to be able to ask questions about the history, like what set this field on this model to the current value? (With debuggers I've used, you have to know these questions in advance and set up things to watch - you can't ask those questions after the fact)

* List all packages that had a line of code run while running this test.

edit: formatting

[afiori]

> * Say I have a test over some deterministic code, and I make a small change to that code. I'd like to be able to run that test before and after, and get a diff of where the computation was the same vs. where it was different.

There are many things I do not like about ocaml build ecosystem but the last time I looked into it this was the default structure of test; is was possible to assert stuff in unit test, but you were "forced" to output something and then promote it to valid output; the next time the unit test are run the build tool check for diffs and you can choose whether the new output is wrong of whether it should be promoted to correct output.

I found it extremely flexible, expecially if you make an API change that would require to update dozens/hundreds of tests

[nscalf]

The stack trace comment is 100% what I wish I had built into my IDE, and from my time mentoring more junior devs, I can tell you this is one of the hardest things for them. All of these are great suggestions, but the first one really has been a pain point for me.