The article clearly explains how self-healing code works. However, what I don't understand is why this is a good idea in the first place. If you can't correctly write a function that meets a given specification, what makes you think that some random recombination of code you've previously written will meet the specification?
> If you can't correctly write a function that meets a given specification, what makes you think that some random recombination of code you've previously written will meet the specification?
Absolutely. There are three additional issues I see with it.
Most code in our codebase deal with business objects, not with mucking about with integers. Very little of that code would have similar signatures. This would make, in many cases, for an empty pool of candidates.
Secondly, the fact that function X crashes does not always mean that function X is wrong, it may just be a case of an upstream function W sending the wrong input. If you happen to have a "no-check" version of X, the "self-heal" will happily let invalid data get into your system.
But the worse is that, while I don't know clojure.spec, I doubt that it's able to describe side effects. Who wants a program that invokes arbitrary side effects looking for a good candidate because writeData(data: string) -> void crashed with an error?
It's possibly an interesting research topic, but practically, it seems either useless or plain nasty.
Machine learning algorithms do exactly that--they "write" a function that humans couldn't write by hand. What makes you think we couldn't eventually do the same here?
There's a qualitative difference between tuning parameters that are real numbers (exploring a continuous space with a meaningful notion of “marginally better”) and coming up with code on the fly (exploring a discrete space of syntax trees, which can only be done by enumerating them). Topological considerations can give you an idea of what kinds of things are worth trying.
