Version 15 of Holon - a simple programming system

Wolf Wejgaard: Yet another programming system? Holon is new in Tcl but is based on over 15 years experience with Holonforth 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:

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. -- (QED - wej ;-)
Tcl philosophy: Everything is a string, so what format could possibly be more suitable for a Tcl program than a text file?

wej - Another good reason: Compilers and interpreters love text files (**). I agree that text files are useful, and nothing precludes the database from writing the contents to a file if needed.

Holon implements four text-file-related features: 1. If you print a module, the listing looks like a text file (*). 2. You can export and import modules as text files, which have a little structure markup added. 3. Holon offers a text file view in addition to its list and tree views, if you want to see your definitions in a familiary context. 4. Holon maintains a source file for every module, as an interface to your code generator/Tcl.

(*) Good for the next 30 years, a paper listing is probably the only medium then still readable -- how do you read your 30 years old text files? My files at the time were stored on DECtapes, and later on 8" floppies, then 5.25" floppies. All gone with the wind.

The database gives me more options. I can structure the program the way I want; like a book, for example, taking Literate Programming literally. And do a lot more, which is probably best experienced in the Holon system itself. You will probably be able to do some of this as well with text files and your elaborate editor. However, I start growing fond of the latest feature of Holon, which is intimately tied to the database: Atomic version control. Forget CVS. You can look up previous versions of any definition in Holon with one simple click. And with a right-click on a version number you get a list of the definitions that have changed in that revision.

(**) Compilers and interpreters load the source in the form of text files, thus a database must provide the source as files. You could instead integrate the code generator with the database, but that is a major project. It is done in Smalltalk, and I have done it in the previous HolonForth systems. Having the code in the database together with the source gives you new options for development. E.g. in HolonForth (which is mainly used to program embedded systems) it provided a method for selective loading of code. A simple recursive routine loads only the Forth words that are actually used in the target. Moreover, since the database keeps track of the code pieces, you are able to replace code in the running system. Fortunately, Tcl provides this feature as well thanks to its built-in database and the foresight of its developers. Tcl is an excellent companion to a source database. Source files aren't really necessary, you could interface the database and Tcl with some channel, 'send' source to Tcl. Holon includes such an interface in the form of a monitor in Tcl, which reads a shared file. However, I don't use this to replace the source files, but rather to work on the running application, to change procedures and see the results immediately; I develop on Holon itself in this way.

Category Application | Category Dev. Tools