- #1
elcaro
- 128
- 28
- TL;DR Summary
- Some years ago I posted a message about the idea of storing source code ino a (relational) database in its semantic form (AST-Abstract Synta Tree), instead of text-files. I can't find that post anymore. But here is a new post about this topic, and about a recent implementation about this idea in the form of the Unison programming language and development environment.
Most progrmming languages and programming environments work at the basis of a textual representation of the code, and all tools to built the executables or libraries are based on acessing text files, including the built tools, version control systems and compilers and such. There are not much noteworthy exceptions to this, except perhaps SmallTalk, which nowadays is not used very often.
To change from text-based storing and processing of source code to a storage format that stores the semantic form of the code (in the form of the Abstract Syntax Tree) is therefore a major paradigm shift.
There are both advantages and disadvantages to this:
pro:
The tools for compiling/generating code have already knowledge about all the dependencies of the code. After submitting code to the editor (UCM - Unison Codebase Manager) the AST of the code block is produced and from that a hashvalue (SHA512) is computed and stored. Different code will generate different hashes and hash collisions is almost impossible. All kind of code management, like refactoring, renaming, are much easier to perform, and don't have the disadvantage that regular text-base tools have of leaving the code in an invalid intermediate state. Actions like renaming variables or functions are in fact a no-op, which doesn't break the code nor involves recompiling or rebuilding the code. Distributing the code to other systems is also very easy, if the system already runs Unison, it would just involve sending the hashvalue. If the hashvalue already exists on that platform, it can handle (execute) the code, if not, it can ask for the code to be handed over in byteformat, and all dependencies will automatically be handled.
con:
This new format for storing and developing code is a huge break with existing (text-based) code development, and will require time before it becomes adapated widespread. Existing code bases can (as of yet) not be transformed to Unison, but maybe in the future tools will be developed to migrate from existing platforms to Unison. Existing tools for building/compiling software will not work with Unison (but Unison provides a rich set of tools for that kind of work, which potentially are even more capable as existing tools for program development).
As an introduction to Unison, here are some links to video conversations about Unison, and links to the main website.
Rethinking Distributed Programming with Unison Lang (with Rúnar Bjarnason)
Rúnar Bjarnason - Unison
"Unison: a new distributed programming language" by Paul Chiusano
Rúnar Bjarnason, "Unison: A Friendly Programming Language from the Future"
Official website of Unison lang:
Unison-lang website
To change from text-based storing and processing of source code to a storage format that stores the semantic form of the code (in the form of the Abstract Syntax Tree) is therefore a major paradigm shift.
There are both advantages and disadvantages to this:
pro:
The tools for compiling/generating code have already knowledge about all the dependencies of the code. After submitting code to the editor (UCM - Unison Codebase Manager) the AST of the code block is produced and from that a hashvalue (SHA512) is computed and stored. Different code will generate different hashes and hash collisions is almost impossible. All kind of code management, like refactoring, renaming, are much easier to perform, and don't have the disadvantage that regular text-base tools have of leaving the code in an invalid intermediate state. Actions like renaming variables or functions are in fact a no-op, which doesn't break the code nor involves recompiling or rebuilding the code. Distributing the code to other systems is also very easy, if the system already runs Unison, it would just involve sending the hashvalue. If the hashvalue already exists on that platform, it can handle (execute) the code, if not, it can ask for the code to be handed over in byteformat, and all dependencies will automatically be handled.
con:
This new format for storing and developing code is a huge break with existing (text-based) code development, and will require time before it becomes adapated widespread. Existing code bases can (as of yet) not be transformed to Unison, but maybe in the future tools will be developed to migrate from existing platforms to Unison. Existing tools for building/compiling software will not work with Unison (but Unison provides a rich set of tools for that kind of work, which potentially are even more capable as existing tools for program development).
As an introduction to Unison, here are some links to video conversations about Unison, and links to the main website.
Rethinking Distributed Programming with Unison Lang (with Rúnar Bjarnason)
Rúnar Bjarnason - Unison
"Unison: a new distributed programming language" by Paul Chiusano
Rúnar Bjarnason, "Unison: A Friendly Programming Language from the Future"
Official website of Unison lang:
Unison-lang website
