4 ms·

I think that's a problem of still using text and the filesystem as our codebase storage format. Databases have transactions, query languages, backup capabilitie

I think that's a problem of still using text and the filesystem as our codebase storage format. Databases have transactions, query languages, backup capabilities, and a number of other extraneous features which can be removed or replaced with generally simpler versions (clustering with version control for example). If code is data, why arn't our codebases databases?

btown 13y ago
Of course, the flippant answer to this is that our codebases are already databases - the filesystem is our storage engine, commits are our transactions, etc. But is this the optimal way to store information? It would be very interesting to look at code as a graph database (of the https://github.com/tinkerpop/blueprints/wiki https://github.com/tinkerpop/blueprints/wiki family, for instance). In a way, one could see how a functional programming language defines entities and their relationships, and how a function is just a composition of other functions to which it could be linked. But do we want to write a graph operation every time we want to make an edit or add a feature to our code? Perhaps the textual codebases we have are the most easily editable visualization of the underlying "graph."
- SolarNet 13y ago
  If the database is the model, then add a controller (IDE) and view (textual representation) and you may start to see how that could work. Also I should have said, "why aren’t are codebases like modern databases".