'''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.