I apologize in advance for the ManifestoMode tone of this page. Feel free to edit it into normal DocumentMode.

Source code doesn't have to be flat ASCII any more. A compiler which can take a richly formatted (and annotated) source and strip the appropriate code information could be a great productivity tool. All of the UserInterface portion of a program could be built into the source as well, eliminating the need for a separate set of files.

If you give up the flat ASCII restriction for source code, a whole new set of tools becomes available. True markup becomes possible, adding metadata in layers to the source document. It becomes almost trivial to consider tracking the authorship of every character of code, comment, and even the GraphicalUserInterface bits. Comments could become yet another layer. You could, if you really wanted to, store all of the versions of source in the same document.

I think this is the way things will go, if the idea is given enough attention and support. I think it will increase our productivity by a huge chunk, if done right. (Need to avoid the 15 fonts in one page silliness of early Mac documents, for example).

-- MikeWarot

I've thought about that some... and then realized what will happen is PlainText ascii files with xml-style tags. What we really need is cross-language way to say, "Don't show this data in the text display, just make a little icon that says it is there."

Actually, I've always wanted "collapsible functions/methods" - where you click the icon and the text display toggles between showing the function and its prototype. I think such a tag would work well for documentation and graphics as well.

-- LayneThomas

''NetBeans has collapsible functions.  In fact, many text editors can do this; at least, Vim and Scite can.''

----

Given a choice between a) an application (like MicrosoftWord) with extensive change-tracking features built into the file format, and b) a "dumb" file format coupled with a good VersionControlSystem, I'll take b) any day. (Of course, if b) isn't available, often times we're stuck with a).

''That *is* the debate of the millennium. Is power and control better centralized or distributed? I'm going to go on a limb here and say "both" - i.e., build revisioning into the file format - and then stick it into CVS and double check just to make sure somebody with a hex editor didn't start a war^H^H^H^H^H^H^H^H^Haccidentally edit the wrong bit.''

Hmmm... it occurs to me that a chief argument against a "smart" file format is that generic tools don't support it.  However, the solution for that is to make a standard-ish file format for rich source code.  This won't make it (much) easier to process mechanically, but will at least ensure that you won't need seven different text editors to handle seven different languages or platforms.  In other words, you need to make it as ubiquitous as plain-text.
----
See also IntentionalProgramming, PowerOfPlainText