Self Healing Code with clojure.spec

Because you can divide your runtime in to multiple stages: if program A runs and outputs program B, then from B's point of view A was able to perform a static analysis of B's behavior.

You can always view the term and type levels of a programming language as two separate but intertwined languages. In this case, both the term and type level would be identical instead of the type level being specialized with logic programming-esque constructs as usual.

You are arguing for and against the same logic, but defending one level of abstraction as good and another as poor.

Functions that you define take parametrized input and use predefined logical constructs and produce some output. Self-healing (diction demands a more appropriate word, perhaps rectifying as code isn't defined ontologically as holistic, though a reordering of ethics might serve that purpose one day), so: self-rectifying code does so by working in the boundary conditions set by the logician who defines its instruction, and merely iterates through code chunks and tests against user defined output until it is successful. The big O to achieve fairly complex goals makes implementation very manageable, I presented a paper on this at my alma mater a few years ago and was a bit surprised it had yet to receive much traction. Every parameter can be included in the logic to ensure space and time complexity restraints are met, as well as code style.

Would you argue against a medical procedure that heals your cells instead of healing your organ at the tissue level?

Yes. You can get pretty fancy with decorators, and there's always eval/exec if you need it. The stdlib has plenty of power tools for introspection.

The leg up that lisps have over Python is that Python's eval/exec operates on strings whereas lisps can easily manipulate the AST. (I'm not sure if I should call it abstract for a lisp.) Directly manipulating Python's AST can be done with the aptly named ast module, but personally I find it easier to do string templating and eval.

"system died from autoimmune disease" - this is gold!

I can't imagine why would anyone want to have an untested set of semibuggy functions just to replace them at will. However, I can imagine the tinkering code approach, not "self-healing", when we are expecting ALL functions to be good, it is just we don't know which one fits better to the situation. People actually do this all the time since the beginning of the history, but perhaps the discussed approach can introduce more abstract framework for that.

Yep, read it and its flaw is the assumption of "correct" code transfer from another application to the error region, resulting in "correct" code. In other words, it ignores the context. And such self healing systems have been around. I worked with "syntax-healing" compilers and code that linear interpolates upon error to a approximate solution of nearby earlier results. So dividing by zero is basically- nearby is 1 - the identity operator, with a minus in front if you divide a neg number. And that is just a solution for flawed code that returns numerical results.

You can not switch context that easily, without erecting a whole system of Meta-Information for every function. So instead of debugging, we start to fill out forms again, hoping- not knowing for certain that the result will be self repairing. And then the idea dies, to be reborn again, one generation into the future. Because self-repair system even in nature are often flawed and kill the repaired organisms.

If time and resources wouldn't matter- you would stand a better chance of solving this, by having a result fitness function (aka unit test) and a genetic algorithm, modifying the code.