<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Sun, Jun 25, 2017 at 11:00 PM Joe Armstrong <<a href="mailto:erlang@gmail.com">erlang@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Welcome to the world of broken software.<br>
<br>
In my opinion this (making sure software evolution does not break<br>
existing functioning software)  is one of the biggest remaining<br>
software problems - my guess is that this problem is getting worse<br>
(due to the explosion in the numbers of programming languages,<br>
libraries and frameworks and build systems) and will be even worse in<br>
the IoT world.<br>
<br>
Lots for you guys to work on :-)<br>
<br></blockquote><div><br></div><div>I think a viable source of inspiration is biology. A cell will have situations in which it will have to adapt to the "new interface." (whatever that is). Obviously, cells manage to do this, partly because the "API" is simple enough you can apply fixes.<br><br></div><div>Currently, code needs continuous maintenance to survive. If you don't, then the code will eventually rot and become unusable. As Richard and you observe, the more dependencies, the less your adaptability. This is a darwinistic approach, but the fitness function is obviously wrong. Effort applied as half a billion Javascript programmers make code survive, but that doesn't mean the code is good, elegant or adaptable.<br><br></div><div>The hard part is that we'd like some code to be ephemeral. Perry Metzger observes that hardware is ephemeral: it naturally breaks down, and so does the errors in the hardware as a result. Software has the ability to survive hardware generations which means that it is far more persistent. This is dangerous from a security perspective. It is dangerous from a correctness perspective as well. We need to kill the right kind of code by making it not work anymore.<br><br>I'm a big fan of something like Golang's `fix` tool. Before 1.0, you 
could run `go fix` and have your code rewritten to match the new spec 
automatically. Wrangler in the Erlang world by Simon Thompson can do the
 same for when things are altered. In the C world, semantic patches as 
in Coccinelle is highly useful for the same thing since you can apply a fix all over a code base easily.<br><br></div><div>I'd really like a set of "fixups" which applies globally to code. If we look at the ezwebframe problems 7stud encountered, they are all fairly trivial rewrites. We even have a coherent hivemind (e.g., Tristan :) who knows what the problems are and how to fix them. With a bit of luck, we can take fixes in one project and apply them to other projects. Projects where the fixups are not easy are probably fit for a black hole.<br><br></div><div>I'd also like a repository of formally proven algorithms which can be extracted from e.g. Coq into different programming languages. This would allow us to reuse components which have a high level of assurance all over the place. To get this to work, however, we would need political support. You have to outright demand that level of assurance, or companies will gravitate toward the simplest solution which works.<br><br></div></div></div>