Packaging Compiler + Source + Binary for greater LTS

[adrianduke]

Reframing "Long Lifetime Without Maintenance" to include User Empowerment may be another notch in the quest for LTS software, to include such empowerment and taking some mangled inspiration from the Smalltalk world (particularly Moldable Development), what would it take to package a compiler, source and its compiled binary together?

There are variations on this like file(compiler, editor, source code, binary, documentation), but this really is just a matter of 'can you generate docs from the source? No... then embed the docs' and 'does the users environment support editing blocks of a file? No... then embed an editor'.

The concept here is the compiler can only compile the source code included in itself and the compilation target is the very file itself, which would recreate a file(compiler, source, binary). It's a sort of quine on steroids and really brings out the stand-alone. I'd assume normal operation is to execute the binary, but switching to the other modes /could/ be much like busybox, the filename you call me as is the behaviour I exhibit, call me a compiler and I re-compile. Call me editor and I edit my source... etc.

Now there is no reason the compiler couldn't be one of these triples either f(c,s,b)...

I understand the increase in size bloat, but really I feel the standard in a non-interpreted environment should be the aforementioned triple if what we care about is LTS. Optimisations can be made, but the choice to live in an environment composed of f(c,s,b) || f(c) || f(s) || f(b) files should be down to the user.

It would seem to me there is not much more you can do for a user than provide them everything in one place to modify, understand and play around with. We lose a lot of time in setup and environment configuration.