Code Ordering

Standard programming languages like C, C++, Java, SmallTalk, etc. exhibit CodeOrdering: conceptually, each statement is executed one at a time, possibly modifying state, and then the next statement is executed, possibly using state modified by the previous statement.

Several programming systems have been created that relax this code ordering.

DonKnuth's LiterateProgramming, which interleaved documentation and code. It is written in an order conducive to telling a story or documenting the code; the code is extracted and resorted into the order that a conventional programming language would expect.
EdwardKiser's BuildSyntax
AspectOrientedProgramming
Hardware design languages like VHDL, Verilog, or iHDL (Intel HDL). See CodeOrderingInHardwareDescriptionLanguages.
pure ActorsLanguages, in which statements are executed in parallel by default
OccamLanguage
HandelCeeLanguage (C with 'par' construct)
The PrologLanguage is, in theory, non-ordered: You declare a set of facts, and the system determines what values satisfy the facts. (In practice, I found that sequental logic and conventional recursion sneak back in. But you could argue that I wasn't using the language properly. I would certainly argue that. ;-)
- Disagree; it is essentially impossible to avoid such introductions of sequentiality in most large complex Prolog applications. That's a different question than whether they are avoided as much as possible by most people (they're not).

In all of these, the order in which the code may be written does not correspond to the order in which it would need to be written for a sequential programming language - but there is a single order.

I am particularly interested by the possibility of dynamic code reordering: allowing the program to be sorted into any form convenient for the programming task at hand, and then edited in that form. In DataBase language, this is called an EditableView?.

For example, one might create a view by grepping all usages of a variable. One could then edit in this view, and automatically have the change reflected in other views, including the canonical sequential order.

In a pipeline, one could create a view that followed a variable all along the pipeline; or, one could create a view that examined all variables in a pipestage, or just the protocol across a pipestage boundary.

There might be a way to write a practical implementation of this in a very short time. Call it a prototype:

First, my recommendation is to define a "programming language" DTD (DocumentTypeDefinition) for XML (ExtensibleMarkupLanguage). XML is easy to parse. XML parsers are rapidly becoming standard components. You can save yourself the trouble of writing your own parser.
Second, you can write a bunch of tools that "extract" various views from these XML programs, and write them in separate XML files. You could write a "view description" DTD, and then write view descriptions, and you would run the program on a view description and on your main source file, and the program would produce a "view" which adhered to yet another DTD.
Third, you can write a bunch of tools that can "merge" those extracted views back into the main source file.
So, you could write a source file, extract a view, edit that view, merge the view back in. Extract another view, edit that view, merge the view back in. (Of course, if you do not change a view, you don't have to merge it back in.)
Of course, it might be a good idea to figure out some way to run your verbose little XML programs -- and make it possible for them to do something useful, so that you will want to use them. One possibility is to make them compile to C. You could even have them compile to C and HTML and produce a LiterateProgramming tool.

This way, you'd be able to test your hypothesis. You'd have a tool that could produce various editable views of a piece of code. You'd be able to see for yourself if programming is made any easier by those tools. (To be scientific, you'd have to compare whether it's easier than programming in your XML programming language without such tools. Comparing XML to C is no fair.)

What do you think? Easy, hard, or impossible prototype? -- EdwardKiser

Edward - it's a good idea, and I don't think it would take much work to do. Basically you are leveraging existing C compilers for code generation and existing HTML/XML browser technology for display. What is needed now is a better pinning down of what the useful 'views' are. --JamesCrook

The merge functionality is difficult to impossible. Deletion isn't much of a problem, in-place editing isn't much of a problem, but spatial relocation or insertion are a problem unless you make the relevant spatial transformations two-way. I'm assuming you want some higher granularity than simple module level. --RichardHenderson .

Split and merge is refactoring. It need not be that difficult if there is fine granularity of functionality and we are just talking about moving the 'atoms' about into different aggregates. We need examples to make this discussion more concrete.

Some very similar ideas are expressed in a project of an XML-based transforming text editor by DmitryKirsanov? at http://www.kirsanov.com/te/te.html .