[Wolf Wejgaard]: 
Yet another programming system? Holon is new in [Tcl] but is based on over 15 years experience with Holon[forth] under DOS.

Main features:

   * The source is stored in a database. 
   * The program is presented in a book-like structure of modules (chapters), sections and units. The units are the actual program (procedures, functions, variables, objects, methods, ...); the modules and sections bring order to the collection of units.
   * Holon keeps track of changes.

See http://holonforth.com/new/holon.html for details. Holon is presently available as a free [starpack] for
[Microsoft Windows] (MIT license).

This is Holon, handling its own source:

[http://holonforth.com/new/images/listview.gif]

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. 
----
'''Remarks'''

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:
   Long-term readability:   Source as a text file remains readable, even after a long time has passed -- programs written 30 years ago can still be read, even if modifications may be necessary to make them run again. How old is the oldest database you can read? How many other programmers do you know that can read it?
   Programs as literature:   The central thesis of [literate programming] is that programs are not just written for computers to run, they are also written for programmers to read. The program as a collection of text files can provide a narrative structure (even if that is in practice often just a random jumble) that by default would be absent from a database. On the other hand, [Knuth]'s WEB system for literate programming is to some extent an in-text-file database of program fragments. 
   Tcl philosophy:   [Everything is a string], so what format could possibly be more suitable for a Tcl program than a text file?

[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 want to handle 30 year old programs you better store the source on paper, probably the only medium that you can still read. We can print database records as well as text files.
   * [Literate Programming] is more likely an argument for source in a database, as you hint to yourself. E.g. [Knuth]'s METAFONT program consists of numbered program pieces, each with a description (comment) and the actual source code. Exactly the format used in Holon. And, as in Holon, you can easily order and present the program fragments in the 'narrative structure' of a book. 
   * Tcl strings have identitifiers/names, otherwise they are probably not very useful. Thus your Tcl program consists of a collection of similar items, and a database looks like a good place to store collections, at least as suited as text files, I think.
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.  
----
[Category Application] |  [Category Dev. Tools]