Decide On The Primitives

Pattern Name: DecideOnThePrimitives

Aliases: Atomic functions, Base capabilities

Context: Many capabilities can be added to a system at any time. The strength and consistency of these functions vary. Random requirements may arise at any time as well, so the need for specific functions to work well changes constantly.

Problem: New functions are needed to perform key operations.

Forces: No universal set of functions can perform all the required operations at any given time. Energy and materials to support a given function are limited, so only so many functions can coexist.

Solution: Decide what basic operations are need to be in order to support all the necessary operations. After making a preliminary decision, put each primitive operation under a microscope (so to speak) by isolating it from its environment. Perform metrics on the known set of operations, seeking to improve its overall efficiency and flexibility in isolation. Allow all operations to interact as usual, checking for new operations that are needed and monitoring emergent behavior between existing operations.

Resulting Context: All operations necessary to provide normal operation are optimized. This frees up critical resources that are necessary to support research and experimentation. New operations are added as their suitability and efficiency become sufficient.

Design Rationale: When the primitive operations required by a system are ill-defined, the ability to use resources to their maximum potential is minimal. Deciding on the basic set of operations that will be 'supported' and refined reduces frivolous effort and reduces waste. Emergent behavior still exists, but it does not rely on elements that are the product of subtle interactions that may be lost due to subtle environmental reasons.

Examples: Any scripting language, microprocessors, programming languages.

Related Patterns: AlternateHardAndSoftLayers, CreateFlexibleMessaging

-- DavidCymbala

Most the C/POSIX primitives were glommed together from various vendors' APIs which in turn were created by necessity, customer request and marketing concerns. Totally the opposite of what's stated here. In practice, I have found that deciding what the primitives are is equivalent to solving the problem... unless you implementing something based on theory, like a TuringMachine/programming language environment. Then, you can prove what the primitives are. Even then, after the initial spike, your set of primitives may change for optimization purposes or because of failure to understand the problem. -- SunirShah

The primitives act very much like words in a natural language, and (in accordance with the SapirWhorfHypothesis), the choice of primitives will influence the way you think about the higher-level operations built from them.