The article gives an example that most programmers would be familiar with; canonicalization so that version control and code reviews go smoothly. Version control also becomes somewhat simpler as it can compare the structure of code rather than the structure of a sequence of characters that still must be lexed, parsed, etc. There are lots of other areas where storing code in a structured database of some sort would benefit tooling as well. One example is the use of language servers to index, perform continuous recompilation, perform cross-reference lookups, and offer code completion. With a structured database a lot of this becomes relatively trivial.
I'll definitely have to look into this language further as I'm curious about how their database is designed.
> Code is stored as a structured, type-checked tree in a database, not as text in files
What does everyone think a filesystem is?
The file system is in an entirely different and irrelevant layer of abstraction.
I'm sure this analogy is technically incorrect but: This reminds me of Smalltalk and old Lisps on mainframes shared by many researchers where the main thing was the VM image, not an object file. Though the probably kept the source code around? At a gut level getting rid of source code makes me uncomfortable but I'm ready to learn more.
PS sorry for the ugly raw links I'm on my phone
I think you may be misunderstanding what is being stored here. Now as a caveat I'm not familiar with this language, but I am familiar with the concept as described. They are not removing source code, rather source code is stored after some processing; in this case it appears to be after lexing, parsing, and type checking. I'm not sure exactly what is being stored, i.e. an AST, but it sounds like they're basically moving this stage of compilation/interpretation to be much earlier in the process.
I'm assuming this database can be queried and the result can be rendered back to a textual presentation as well. Presumably this opens the door for syntax being divorced from language semantics since how the syntax is parsed into the database and how the database is rendered into text can be a client side decision rather than set in stone inside the compiler/interpreter. What is set in stone is the semantics of the database that everyone must agree to.
Again, there's the caveat that I'm not familiar with how this language in particular is implementing this concept.