Adaptability is the keyword to
understanding the MultiValue approach

As has been commented elsewhere, the majority of MultiValue programmers have only limited formal education in using the MultiValue environment. The reason for this is simply because the core elements of MultiValue are comparatively easy to master, and can often be learned ad hoc, when needed. All this derives from several core principals inherent to all MultiValue environment.

All data is text

The first of these is that all data is, fundamentally, text. Names and addresses are clearly text. But just as clearly, numbers are text, whether we express the same as digital numbers, or as exponents. Finally, even things such as photos are "text" in the sense that they are expressed by a series of ascii characters. And this all makes sense, if you think about problems such as encryption or compression. It is not possible, for instance, to encrypt a unity that "number" represents, but it is possible to encrypt the text "expression" of that number.

The core advantage of thinking in terms of text is that there is no need for keeping track of data types. The second is that it permits full association of information that would not be possible otherwise. For instance, in context, "0.25" ".25" '1/4 inch" and '1/4"' are all pieces of text describing the same thing. The third is that thinking of all storage as "text" permits simplification of expression, conversion, and analysis of internal information.

Even null -- the absence of data -- can have meaning as text, and is so permitted in the MultiValue environment. As pure text, null merely means absence of information, but analogously, in Math it can mean zero or the absence of completion events.

All data should be directly viewable

About the only thing you need to learn from scratch in a MultiValue environment is ED [filename] [recordname]. As long as you can use this command, you can inspect any data stored in or accessible by a MultiValue system. From the perspective of someone writing a program, this is far more powerful than you might think at first glance. In many systems, atomic data is not stored by itself, but is rather stored as part of a "file." Often, the data stored in these files (as with, for instance, ISAM files) will consist of many parallel records, each with a fixed length, and with a fixed character length for each element within the datum. Human-reading such files is just about impossible. But MultiValue treats each atomic datum as a separate "record" directly accessible by an "itemid." Similarly, rather than binding data elements to specific field lengths, each is expressed as an "attribute" viewable as a separate line when edited. The best way to think of this as a single sheet of paper, or perhaps as an individual rolodex card in a rolodex file.

The power of this approach should not be neglected. Not only does it conform to the principal of data as text, but it allows for real-time viewing of data or results as a system goes through its paces, rather than an abstracted prayer that everything is as it should be.

The principals of data viewability apply to the debugger process as well as to the file system itself.

Data should be expressible in an array,
rather than scattered in many places

Most database environments force you to write tables of data -- 2-dimensional structures. As the layers of interaction increase, so do the number of discrete data elements which must be inspected and maintained as separate elements. Similarly, tables intrinsically presume limits to data size, and the use of white-space to preserve order.

In complex systems, this can become extremely cumbersome, with data in 40 or 50 different places, rather than just one. For instance, if you are writing an order entry system, you have to have header information about the name and address. Then you have to have separate table elements for the parallel order lines. Finally, if you permit or need split shipments, you need to have a further sub-construct to indicate what quantities, serial numbers and such were shipped on given days by what shipping methods.

MultiValue methodology allows storage of data in up to 3 dimensions within a data record. To this end, it reserves 3 high-order characters (ascii 252-254) that can be used as delimiters. The first of these are viewable as separate lines while the subsequent levels have indefinitely parallel sparse structures. Reading data with embedded delimiters is a skill that has to be acquired, but it is far easier and more verifiable than having to view data from a large number of places.

Code should be orderable any way you like

Many programming environments compel individuals to adapt to their own rules and methods for writing programs by, for instance, forcing code to be structured, or preventing the nesting of code within other code. Thus, many programs may fail, or practically fail, because people cannot express the solution to the problem as they then understand it.

MultiValue does not require that code be structured, ordered or organized in any particular way in order to work. And as a result, there exists a lot of bad code in the industry ... code that is inelegant, unstructured, spaghetti-like or redundant, and thus inefficient. On the other hand, this "bad code" also "works" while such code in other environments is likely to fail. Elegance and cleanness are skills mastered over many years, and are further always relative. The most important requirement of the reliability of any environment is that you be able to write code that "works" at 6 in the morning after 22 hours on the job, and not just when your mind is fresh and clear at 8am. Code can always be made more efficient or clear once it is working, but even here that constraint only applies when there is an external requirement such as maintainability, efficiency, absence of computing resources, or frequency of use. By volume, 80% or 90% of all programs do not need to be "elegant;" they only need to work.

A system that adapts to much broader modes of thought

Most computer environments require that the practitioners have a profound capacity to abstract -- to think in theoretical terms rather than concrete terms that they can "see." These areas of abstraction generally include data mapping, data management and the styles and methods used to get from point A to point B. MultiValue does not have all these hidden rules. As a result, whether you are a novice, or lacking professional training, or an unclear thinker, or someone attempting to work in spite of exhaustion, you are more likely to succeed in your work, and complete it sooner, than you would in other environments. This is demonstrated in the completion rate of projects. In the MultiValue environment, typically 90% of projects will be completed and be used. In the general computer industry, the completion rate is generally below 60%.