This is Holon, handling its own source:
Acknowledgements: Holon is built on Wikit. It started by adding a book-structure (HolonWikit), then the wikit pages turned into program containers for source and comments. The hardwired links are replaced by dynamic links to page titles=names. Comments are edited and saved in Tk format; source is saved unformatted. Some Wikit features remain.
Storing source in a database makes sense, particularly if a program consists of a large number of units. (The number of units depends on the size of your definitions. If you don't mind writing procedures that span a printed page or more, you are probably better off with text files and a fancy editor.) I prefer many short definitions. Small procedures are simple to write, simple to read and understand, simple to test, simple to change. And: if I store the units in a database, it is a simple matter to keep track of the multitude and to implement useful features for efficient program development.
Handling source in a database is not new, of course. It is common in OO systems (Smalltalk and others). It is used in the powerful Tcl introspection tools and development systems, which work on the internal database in Tcl. Isn't this general: Every modular program is turned into a database as soon as it is converted to code (interpreted/compiled). I keep wondering: Why is source still handled on text files? Are there any real advantages, or is it a matter of software folklore?
Lars H, 2007-07-15: Community inertia is probably a major factor in this, but I can think of at least three reasons why text files are good:
wej - 2007/07/28 (revised comment): Sorry, but I still don't see why text files are good. But thanks anyway for the additional points of view.
If you are used to text files; if you don't mind the inherent complexity and create beautiful programs anyway, why change? I certainly don't mind, just wanted so present an alternative.
NEM 4Aug07: If you store your routines individually in a database you can also always regain a linear narrative sequence by creating some top-level "contents" routine that links to the others. Typically your main routine will probably do this anyway.
wej: You have several options to make the program readable. You can present and handle the database records in any editing structure that you like. So, why not try and write the program in a 'narrative sequence' per se. Tcl doesn't enforce it, but In Forth, say, you have to follow the sequence because every element of the story=program must be defined before you can use it in the program. The Model/View/Controller structure also implies a narrative sequence, I think. First the actors and places are described, then the action unfolds.
wdb For programming, a database can provide a better GUI than a text editor. For long-term storing, a text file is better than an application-dependant db. But, I do not see any conflict, if the application can store the db 1:1 as text file -- and can read it back to db.
HZe 2007-Aug-04: One benefit of text files could be a source code management system (like CVS, Subversion) that allows to work on those files by many people and handle multiple changes on the same file. Is it possible to work on a Holon database simultaneously by several developers? The description seems to indicate that this isn't possible, the source management seems to be limited to the one working with the database.
DKF: FWIW, subversion can work with binary files too, but in that case it's entirely up to you to figure out how to do the merge...
wej: Holon is not meant for team work in its present form, I have developed Holon as one programmer's personal tool. But I see no principal reason why the concept can't be expanded to a multiprogrammer environment. The simplest solution is to break down your great project into a set of weakly dependent one programmer jobs... Sometimes it is possible.