Re-editable code

Once in a while when I have an idea I look around to see if others have the same idea. Sometimes they do and sometimes they don’t. Most of the time the majority opinion is almost the exact opposite. But every so often I’m vindicated

I also must confess to a strong bias against the fashion for reusable code. To me, “re-editable code” is much, much better than an untouchable black box or toolkit. I could go on and on about this. If you’re totally convinced that reusable code is wonderful, I probably won’t be able to sway you anyway, but you’ll never convince me that reusable code isn’t mostly a menace.

That’s an excerpt from an interview with Don Knuth.

We now have several incompatible syntactical forms and contexts for expressing the same idea and have to resort to all sorts of hacks for “re-using” an expression of an idea from one context in another. Programmers attribute great meaning to these contexts and even get tribal about it going as far as defining in-group contexts and out-group contexts all the while forgetting that the whole thing was made up to begin with. The context I’m talking about is the programming language and language ecosystem.

So what exactly does this all have to do with re-usable vs re-editable code? Well, re-usable code has proven in practice to be a myth. Treating something like a black box turns out to be a terrible idea, at least as far as software is concerned. There is always a slight semantic mismatch between the black box and whatever domain I’m trying to use the black box in which leads to all sorts of hacks and workarounds. If the emphasis from the beginning had been on re-editable code then I suspect we’d have much better cultural practices for incorporating 3rd part software in our own and we’d have fewer unmaintainable systems.