Task Major

A matrix can be stored in memory in "row-major" or "column-major" format. The difference lies in how you interpret the meanings of adjacent bytes in memory. A row-major storage format implies that adjacent bytes are (usually) other values in the same row. Likewise, a column-major storage format implies that adjacent bytes belong to the same column.

By way of analogy, we may think of software architecture as consisting of two views: a ModuleMajor view, where fragments of code are collated by their relationship to each other (e.g., all functions that manipulate lists go into the Lists unit), and a TaskMajor view, where fragments of code are collated by their relationship to the job at hand (e.g., all functions that maintains the USS Enterprise's life support systems go into the LifeSupport? unit).

The ForthLanguage philosophy states, in general, that you always write what you need, when you need it, and to make it maintainable, where you need it as well. For example, we can illustrate this by defining a simple stack in memory:

 create someStackSpace
   16 cells allot

 variable stackPointer

 : reset
   someStackSpace stackPointer ! ;

 : advance
   [ 1 cells ] literal stackPointer +! ;

 : push
   stackPointer @ ! advance ;

 : regress
   [ -1 cells ] literal stackPointer +! ;

 : pop
   regress stackPointer @ @ ;

However, perhaps you're using this stack to hold a collection of values that, under some circumstances, you want to print to the screen in the order they were pushed onto the stack. If this were a true stack, you'd have to play towers of Hanoi by popping the items off the stack, re-arranging the items, and printing them. Or, you'll need to use deep recursion (which effectively does the same thing) in your print code.

It'd be better, in the grand OO tradition, to just "tell" the stack what to do. The problem is, however, writing the implementation inside the "stack module" will complete lose the context of why the method was even needed in the first place. Since Forth is a HyperStaticGlobalEnvironment, it is all too easy to write code that does what we want, exactly how we want it, where we need it most:

 : print'em
   ( this should be in the stack "module," but we define it here instead... )
   someStackSpace  begin dup stackPointer @ < while  dup @ . cell+  repeat drop ;

 : someOtherCode
   blah blah print'em blah blah ;

This is perfectly structured code, but it is not "modular" as we tend to think of it. If we continue to disperse stack-related functionality with task-related code, stack methods are scattered throughout the entire codebase, which makes trivial re-use of the code much more difficult. Nonetheless, this code is extremely modular in the task major sense, because print'em is directly relevant to what someOtherCode is doing.

Note that nothing prevents other code from depending on print'em either!! It's just that it's defined when and where we need it.

Therefore...

A program is expressed in a TaskMajor form if adjacent fragments of code are directly relevant to a specific task.

Examples

SmalltalkLanguage persists source code as "difference files", which contains differences to existing classes (as well as new classes of course). The ability for Smalltalk's source importer to dynamically create methods on already-existing classes can be (and has been) exploited in literature that uses Smalltalk as the programming language of choice for examples. Examples will tend to bundle related pieces of code, even if dispersed across several classes, together on a page or a single program listing.

LispLanguage also permits this style of coding, particularly exploited with CommonLispObjectSystem software to expand upon pre-defined classes on an as-needed basis.

LiterateProgramming will exploit a glorified macro preprocessor to allow the author of the software to bundle related (and named) chunks of code together, amidst rhetoric which explains in greater detail their relationships.

Benefits

• Context. A program may define a function relevant to a concept, but may do so where it makes logical (rather than structural) sense to. This significantly aids comprehension of the code.
• Due to greater locality of logically related code fragments, IDEs don't have to work quite so hard when performing common tasks, like refactoring. IDEs that are designed to support TaskMajor coding should be faster than current generation IDEs.

Drawbacks

• To support code re-use, specialized tools are required which are designed expressly to support TaskMajor program representation. (In contrast, today's IDEs are always optional "dang nice to have" tools. They're not strictly necessary.)
• In support of code re-use again, it's best to store individual fragments of code in a database of some kind, which runs the risk of undermining the PowerOfPlainText. OTOH, we're moving into the province of IntentionalProgramming when we do, so maybe this isn't quite the drawback it might seem.

---

See also ModuleMajor, StepwiseRefinement