There are also many more mundane problems than visual explanations involved in team development. Developers often step on each other's toes in various ways, since it is difficult for them to know how their work is affecting the work of others. This, too, is a problem that Eidola can help solve.

This problem is inherent to anything as intricately intraconnected as a program, but the problem is exacerbated by the way we design languages. It's fairly awkward to have multiple people editing the same text file at once. The current preferred method seems to be having somebody do a lot of diffs as the changes come in, and merge them by hand. If you don't want somebody integrating all edits manually, the smallest practical unit of dividing labor is a source file. Unfortunately, a particular programming task is likely to touch many source files in small ways, creating frequent contention between developers for files.

Another problem is that it's hard for one developer to know how their changes will impact another's work. It's very common to have your code suddenly break because of somebody else's update to another part of the program. This makes programmers hesitant to update their source code with other people's changes, which is bad -- the less tight the collaboration, the coarser it becomes, and the fewer developers can be effective simultaneously.

A representation-independent language could address these problems with a structure-savvy version control system. Such a system could check out, lock, and update code with a much finer grain than entire source files, allowing a developer to stake out a relevant cross-section of a program. The version control system could then use its fine-grained knowledge of what each developer is working on to communicate to other developers potential conflicts and change impacts: "Hey, you should probably warn Jill that you're editing that, because her code references it", or "The interface of a class you used has changed; do you want update to the new version now? Do you first want to see what parts of your code would break if you updated?"

Having such a version system would be like turning on the lights in a crowded room where people are grouping and standing far apart to avoid bumping into each other in the darkness. Suddenly, people know they're going to crash into each other before it happens, and the room can have a lot more people before it feels crowded.

A few pages back, I talked about a kernel having objects and events, giving the impression that a kernel has to be written in an object-oriented language. And certainly, it can -- the Eidola reference implementation is written in Java -- but oh, it's possible to get so much more creative with a kernel. It would be quite sensible to implement a kernel backed by a database, or perhaps even entirely inside a relational database, in which every class, function, assignment, and floating point constant in a program is a row.

The words "flat file" have taken on quite a derogatory connotation, as in, "Oh, they're so primitive...they do every thing on a mainframe with flat files (gasp)!" Source code is, by the way, a flat file format. Think of the world of possibilities that opened up when people started putting stuff in relational databases, and imagine what would happen if programming languages went through a similar transformation.

Having a program stored in a database would make it almost trivially easy to ask questions like "show me every piece of code that modifies this member variable", or "show me everyone who has modified this class in the last week". Ponder that, and you'll see that although it would certainly be an enormous task, it's not unreasonable to imagine building a collaborative development system like the one I described. (I leave the details as a quick exercise for the reader.)

A structural diff (as opposed to a textual diff) could be much smarter about knowing what changes are important, and how different revision forks relate to one another. Although human care would be necessary in merging forks, having good information to work with would allow the merge-master to focus more on impacts to the code and its intradependencies, and less on the messiness of the diff itself.