Offload Mental Simulation

Which allows you to build up the kind of what if scenarios, and also has the primary purpose of allowing you to build the sorts of “simulation space” primitives that they are talking about. “I want to test this code with the first argument as odd integers divisible by 7 and the second argument is random days of the week” and Hypothesis will generate dozens to hundreds (how exhaustive it runs is configurable) of scenarios and run them through the code, which basically does offload the kind of mental simulation debugging the author is talking about.

I’ve driven complex Django installable apps to better than 100% test coverage this way. I had already hit 100% test coverage but the property based testing discovered so many more un-handled behaviour branches that it really elevated the overall code quality to another level. I try to use it for all my Python testing whenever I can. Once you learn (and it’s not super hard to learn how to use it for the basics) it it really isn’t hard to use at all for basic testing.

When running abstract mental simulations, do you assume that I/O operations succeed or fail for knowable reasons? It seems likely. If the code were expressed to match your mental simulation, for example by not performing I/O within the function, but by merely receiving I/O messages from a foreign actor, it seems like you're not far away from offloading the full mental simulation to something like quickcheck and writing down explicit invariants!

It seems to me right off the bat that the nature of the visualisation required is very much an application dependent thing, making it hard to design a general-purpose solution for any but the most trivial of use cases. Secondly, moving to a new programming language (or even a new development environment) is not something that most of us have the freedom to do in our daily work, and overcoming that inertia is a real challenge.

The vision is, however, compelling enough for us to persist. Besides, giving up is never something that I like to countenance. Perhaps there's an easier and quicker way?

Dynamic languages like Python (and anything else with an 'eval') certainly offer the ability to reload program logic on the fly, and it's not terribly difficult to monitor the file-system and trigger re-loading functionality when it changes. Couple this with a data flow framework that guarantees determinism (e.g. a Kahn Process Network), and you've got the beginnings of something that can run and re-run chunks of program logic and compare the outputs. Couple this with some nice building blocks for program-state introspection and visualisation ... and I think you get a significant distance of the way towards the vision of interactive, dynamic, graphically rich (and distributed!) programming.

I.e. rather than looking for a panacea or a magic bullet, we can just try to use the tools that we have today to get as close as we can to the vision that so many of us share.

There is already some amount of both practical (Swift/IDEs) as well as theoretical (Bret Victor) ways that do simulation of a specific function.

What's often missing is the visualization or simulation of how code blocks, classes, modules, libraries fit together. Modern frameworks and programming languages hide a lot of detail behind layers which compound this problem.

Certainly a great but missing assist to current IDEs.

See the "fork" statement which is close to the "what if" branching logic referenced in OP's article. I've been trying to revisit some of these concepts for chatbots or game AI. Reach out to me if you want to discuss via voice/video, since this topic is what my PhD was on.

[1] https://w3c.github.io/dmpl/

The biggest limitation still in place is that it can't reason very well about value ranges (e.g. numbers between 20 and 30) without you enumerating every single possibility (i.e. 20 | 21 | 22 | 23 | ... | 30) which isn't really feasible or desirable for larger ranges.

We're probably very close to this level of generality, though, with the recent string template types being a major step forward in expressiveness.

Is this a real issue? Don’t you just need 2 copies of the code base, and terminate your 2nd copy to make it “transient”?

Unfortunately it looks like it's no longer under development.

But I think there are two arguments that might be worth more from a practical perspective: first, there are certainly programs with sections that could be optimized if you knew of some restriction on inputs. However, you could do that with tools available today (turn a variable parameter to a function into a constant, then compile and decompile the program). But by extension there must be programs whose representation is already the simplest form of expressing the computation they do (eg. hailstone sequence).

Second, there are real world influences that reduce a program from theoretical computation to the practice of it (I/O considerations are just one example).

The language that could be fully analyzed would have to strip some of that complexity and in process become sub-Turing-complete.

Since my team at work maintains something like a data flow language, I always find a different question that interests me: what if we selectively gave up Turing completeness? What if we embraced pure functional languages for more of our work? What could that buy us in terms of maintainability/quality of software?

That's not necessarily how I would approach a simulation, and not how I would speak to myself if that's what I saw myself do.

let x = a number that is < 7

That way we won't need to test with lots of random numbers.

There's nothing wrong with having a loose cached copy of a program in your head. The real problem is getting distracted and having to rebuild that cache! This is why open plan offices don't really work for coding. You need as few distractions as possible, and have to be able to dial in and have laser focus and have everything else tuned out. One thing I can't forgo is music however, as it makes all your coding seem epic, and activates creative parts of the brain.

In most programming languages, the pain points they describe are real - how do we know that a program will give back exactly what we put in?

The answer is to provide it with an appropriately restrictive type such that any output is necessarily of the right shape. Types allow us to do this exact kind of "offloading", so that we simply trust the compiler to know when we are plumbing things together correctly.

Language purity is really helpful with trusting that a piece of code does what it says it does, and nothing else. If our language is impure then the scope of any given function is essentially unbounded. With purity, it can only perform computations based on the things that are locally available to it, and that severely bounds the amount of leeway a programmer has in its implementation - and hence the number of ways things can go wrong.

In short, an effective, ergonomic, statically-typed programming language can solve most or all of the author's woes. I hope they find one that fits their needs.