[raindev]

Why should we break compatibility with plain text based tools to achieve what Lamdu is set to achieve? AST could be an intermediate representation but source should be text. Parsing/generating source to and from AST is some work but doesn't look like an unsolvable problem. We would got all the benefits without actually throwing away all the existing tools. Am I missing something?

[Peaker]

There are numerous benefits that would be lost.

In Lamdu, each subexpression has its identity that survives as it is edited, moved, etc. This helps merge changes with far fewer conflicts.

Lamdu also allows attaching English names to identifiers, in addition to Chinese names, Hebrew names, etc. This approach can hopefully rid the world of duplicated libraries where the code is nearly the same but the names are Chinese. This kind of rich metadata doesn't survive well when serializing to text.

Lamdu will also maintain(and distribute) code indexing alongside the code such that the algorithmic complexity of refactoring large projects is not O(project size). Text is not a good data structure to perform these operations.

Lamdu also maintains many invariants about the code (e.g all type errors are localized and marked as such), what would Lamdu do if you try to load text that doesn't maintain the invariant?

We also believe the entire textual tool chain could be so much better if it were rewritten to work with asts.

So for us the only value in textual integration is the "old world" of programming, and we're creating Lamdu much because of our dissatisfaction with that world.

[raindev]

Thank you for detailed explanations.

Some of this issues could be resolved while staying within plain text, well to some extent at least. There're various attempts to encode metadata into plain text source code. Loading partially incorrect code should be possible, that's what many IDEs do successfully.

Plain text is the most portable data format ever invented, any incentive to replace it should have very convincing benefits.

[Peaker]

Loading partially incorrect would mean that the invariants are not, in fact, invariants.

Encoding the metadata in the text would lose the benefit of using text. At that point you may as well store the code as XML or indeed as we do, in a key value store.

We could layer our data on top of text but this would lose the algorithmic benefits of a good data structure, and wouldn't actually be editable reasonably with a simple text editor.