ATowerOfSimpleSystems

Context: ProgrammingStuff

A speculation I made over on Quora in the FutureProgramming Space: https://www.quora.com/q/qqylyzqgpwisoecc/A-Tower-of-Simple-Systems

Re-reading the answer I reposted here a couple of days ago about the “Holy Grail” of programming language design : modification.

https://www.quora.com/q/qqylyzqgpwisoecc/What-is-the-Holy-Grail-of-programming-language-design

So here’s a question for you all.

A dumb solution ...

But what if we created a system as a tower of “snapshots” of solutions?

Git and other source control systems already store our development history as a series of snapshots.

Containers already give us the way to snapshot full systems.

Things like Amazon Lambda give us the ability to spin-up functions quickly and cheaply on demand.

So …

… what if, when I build a system, I just make a system that handles the first use-case or user story.

That’s now “frozen” at the base of my tower.

Then a new use-case or user story comes in. Instead of trying to slot handling this use-case into my existing program, I just create a new, trivially simple, solution to handle it. That gets added as the next “floor” of the tower.

Now the system is up and running. A user interaction happens. The system first tries to see if the current top-floor of the tower can handle the behaviour. If it can, fine. If not then we simply drop down to the layer of the tower below it to see if that can handle the story.

And so on …

Effectively our tower of old versions of the system is acting rather like an immutable database, “story-handlers”. For any user-story we can keep adding new handlers for it to the top of the tower (where it supersedes older versions). Other user stories which haven’t changed, we just fall down the tower until we find a handler for them. Would this simplify trying to compose complex systems?

Obviously this will work best when each user-story handler is a purely functional program (easy and cheap to spin up) and state is kept in an external database.

What does everyone think? Is this just crazy or a viable way of approaching the problem of growing a system? Ie. embrace the fact that you’re going to get cruft (or layers of archaeology) building up anyway, so just handle that explicitly?

Can we call it “Cruft-oriented programming” :-) ?

Compare:

• Languages that hash versions of functions like UnisonWeb