I worked using an object oriented database, where all code was stored as the AST as versioned objects in the database. Problems that I remember that might be relevant:
1. To “install” code into another instance, you usually exported your code as a massive text file from your dev server as source code, then import the source code as text into your production server. You could do individual functions, but that had a high risk of ending up with a pet with different code than your dev server. Version control was a mess.
2. We just ended up putting source code (without comments) directly onto production servers. That happened to turn out well for the client, and turn out badly for the development company (who owned the code).
3. Syntax or semantic changes to the language were a bitch when the database version needed an upgrade. Any existing code was migrated, from the old objects to the new objects, which sometimes caused problems.
4. Limited IDE. You had to use the IDE that came with the database, and various code transforms, global refactors, or normal development actions were unavailable. The primary other option was to export a complete syntax tree as text, make changes, then re-import (uggggh).
5. Debugging was hell.
Obviously Unison is a very different beast, but some of the above problems were a result of having the AST be the source of truth: problems which have the potential to apply to Unison too.
1. A Unison codebase is a persistent shared data structure, which should be easy to integrate deeply with something like git or borrow ideas from it. Conceptually, it's just like a git repository.
2. It's possible to add an additional compilation step to generate (potentially obfuscated) machine code for a Unison AST. The same point applies to Javascript/Python or JVM bytecode.
3. Data migrations are an open question, yes. Still, Unison is a pure functional programming language and might do this much better than an imperative OOP language. Especially if you model your data as a shared persistent data structure too (like Clojure).
4. This is true, all the textual tools go out of the window without some kind of a translation layer. There are possible workaround like exposing a codebase as a FUSE filesystem. On the other hand, the codebase-as-AST makes it trivial to do code transforms, global refactors, etc, in a Lisp-style macro way, with its pros and cons.
5. I agree that debugging and execution observability is a must. The idea here seems to be "let's have a Haskell-like language that does not need much debugging in the first place". I am a bit skeptical of this approach in general, but it does make a lot of debugging go away.
Thanks for sharing your experience, many of the points are valid for Unison.
1. To “install” code into another instance, you usually exported your code as a massive text file from your dev server as source code, then import the source code as text into your production server. You could do individual functions, but that had a high risk of ending up with a pet with different code than your dev server. Version control was a mess.
2. We just ended up putting source code (without comments) directly onto production servers. That happened to turn out well for the client, and turn out badly for the development company (who owned the code).
3. Syntax or semantic changes to the language were a bitch when the database version needed an upgrade. Any existing code was migrated, from the old objects to the new objects, which sometimes caused problems.
4. Limited IDE. You had to use the IDE that came with the database, and various code transforms, global refactors, or normal development actions were unavailable. The primary other option was to export a complete syntax tree as text, make changes, then re-import (uggggh).
5. Debugging was hell.
Obviously Unison is a very different beast, but some of the above problems were a result of having the AST be the source of truth: problems which have the potential to apply to Unison too.