TensorFlow, Von Neumann and the future of DevOps

It’s like what God did to the mankind for the Tower of Babel — creating different languages and cultures so human beings cannot be as united as before.Photo by Billy Huynh on UnsplashAlternate Universe: Graph Layer & Meta-ProgrammingCircle back to the AutoGraph article — after reading about it, I have this idea that maybe in the future we can unite all the different program languages again so we can end this knowledge segregation.We created programming languages because we don’t want to touch the bare-metal assembly code that has too much CPU-specific information..But we also suffer from different languages because each of them requires a different way of thinking and it’s hard to context-switch..The solution is to add something in between.Intermediary Graph LayerJust like how TensorFlow works on a computation graph, what if in an alternate universe, we create an intermediary graph layer between programming languages and assembly instructions?.This layer basically contains purely computational and platform-agnostic graphs that can get interpreted and optimized into platform-specific CPU instructions..We then introduce an AutoGraph-like tool that compiles regular code into computational graphs.The changes to the original programming flow happen under the hood — a normal piece of C or Go (or anything else) code gets compiled into a computational graph, and later a graph-interpreter runs it..Therefore the developer-facing programming experience will not change much.What changes the most is how tech companies store large software projects..Now every tech company probably has their own repository somewhere storing the source code of their software product..In this alternate universe, tech companies will store annotated computational graphs into the repository instead..One complete graph is an isomorphic representation of a working software system and can be directly executed by a TensorFlow-like runtime.When a developer finishes writing a new feature in their most comfortable language, we run a first-order compiler that compiles the code into a graph and append the graph to the existing graph repository..The compiler can also save developer-specific annotations such as variable and function names into the repository so later we can reconstruct the graph back to human-readable code.When the developer wants to modify an existing sub-graph, the system extracts the sub-graph and its annotations and uses its best-effort to generate human-readable code in any programming languages from the annotations..Developers can then modify the code and compile a new graph to replace the original one.Imagine the workflow of building a new backend service that takes in information from one database and updates an entry in another database..On the graph level, this can be modeled as one input data node, one processing node, and one output data node.. More details

Leave a Reply