Many software and hardware manufacturers are proud of exponential technological change, but for users and consumers of their products and services, rapid technological obsolescence often means increased costs, frustrations and promises unfulfilled. Corporate America expects to make capital investments in goods and facilities that should last five, ten or twenty years, but only a life of eighteen months for software and hardware investment is not uncommon. Lowering the costs to develop new software solutions or extending the lifetime of software applications are two complementary approaches to addressing technological change. These goals can often be achieved by adopting a declarative strategy when designing software systems independent of the programming methodology used. Problems with the imperative programming Most programming projects today use the imperative style of programming. Developers write sequences of operations in a language such as C + +, Java, Visual Basic, etc., that implement an algorithm, or recipe, for performing tasks. The algorithm for the task mixes logical, or relational, statements about the task to solve and control instructions on how to calculate the solution. The logical statements describe “what to” calculate while the control statements describe “how to” calculate. Debugging the algorithm consists of verifying the correctness of logical statements and fixing the control statements, if necessary. There are many problems with the imperative approach. The sequence of operations critically determines the correctness of the algorithm. Unexpected execution sequences through an algorithm caused by user input actions or real-time events in a multitasking environment may result in subtle or catastrophic algorithm failure. Write control logic is the programmer’s responsibility and, therefore, prone to errors in implementation. Understanding the algorithm of a program is often difficult for other developers without extensive metadata, or comments on the code and empirical tracing of program execution with sample data. Check the accuracy of the program consumes a significant amount of development effort, but also usually fails to discover a large number of defects. To solve the problems associated with imperative programming, the computer industry has developed, and advocated many approaches. Structured programming and campaigns against “go-to” statements address some of the problems discovered with ad hoc control structures and declarations. Modularization initiatives stress decomposition techniques on the premise that man can understand, reason on, and maintain small pieces of code. Object-oriented programming constructs program encourages the use of reusable components, libraries and frameworks. The school emphasizes programming model analogies with other areas, such as architecture, by constructing programs using well-designed and built solutions or models, which are repeated in programming contexts. What is declarative programming? Declarative programming separates the logic, or what, a control algorithm, or how an algorithm. The programmer still specifies the logic or equations specifying relations problem, but the programming system is responsible for monitoring, or how the logic is evaluated. The best known examples are spreadsheets and query languages for relational databases. The user or programmer, specifies a mathematical relation as a query, such as SQL, for what to retrieve, while the database engine determines how to execute the query against the database. There are many advantages to declarative programming over the imperative style. In declarative languages, programmers do not specify sequences of operations, but only definitions or equations specifying relations. Unlike imperative programming, the logic relations in declarative programming are execution order independent, free of side effects of evaluation, and semantically clear to visual inspection. The family of declarative programming languages has a long history in the academic computing community and specialized areas of commercial demand, such as construction of the compiler, expert systems and databases. Declarative languages have two main family trees. The logic declarative languages like Prolog are based on first order predicate calculus, which generalizes the notions of Aristotelian true or false values to statements or predicates, involving relations between entities. The family branch consists of functional declarative languages, such as Miranda, Haskell, and SML. The functional declarative languages are based on the calculus developed by the mathematician, Alonzo Church in the 1930s. l-calculus formalizes the notions of recursive application of pure functions to computable problems. Although not widely recognized as such, the latest programming fashion, XSLT, a stylesheet language for transforming XML extensible, is also a functional declarative language. Despite the theoretical advantages of declarative programming languages, they do not have widespread use in commercial programming practice despite an attempt in the 1980′s by Borland to mass-market a PC version of Prolog with the highly popular Turbo Pascal. There are many factors contributing to low use of declarative languages. A major contributor is the lack of college training in declarative languages, but difficult syntax for some languages, inefficient compilers and run-time, and restricted domains of applicability of generalized “how-to” mechanisms are all contributors. Using Declarative Strategies in Commercial Software While declarative programming languages have not received widespread commercial use, the strategy of separating logic, or what, control, or how, in an algorithm is a powerful technique generalized to the increasing ease of use and extension of the longevity of software. Declarative techniques are particularly powerful in user interfaces and application programming interfaces (APIs) that have a rich complex set of inputs over a relatively small number of behavioral performance. Two examples of commercial software that illustrate the application of declarative techniques are DriverLINX ExceLINX and in the areas of data acquisition and control of test instruments. The use of data acquisition reports DriverLINX is an API for controlling data acquisition hardware used to measure and generate analog and digital signals interfaced to all types of external sensors. data entry applications include laboratory research, medical instrumentation, and control industrial processes. Traditionally, APIs for data-acquisition devices modeled the characteristics of the hardware design and had a large number of functions of one or more parameters to configure the hardware and control data flow in the system. The order of sequences of operations is often critical to correctly programming and controlling equipment. Upgrade data acquisition hardware was often costly as new equipment necessary changes in the order of operation sequences to program the hardware required costly software changes. To overcome these problems, DriverLINX adopt an abstract approach to declarative programming and data acquisition. Instead of modeling on specific models, summaries DriverLINX the functional subsystems of data acquisition hardware into generalized attributes and capabilities. application programs to measure the task they want to accomplish by setting a service request “declaration. DriverLINX The runtime determines how to satisfy the service request using the available hardware and returns measures as a stream of packets to the program. Data Acquisition programmer is relieved of any responsibility for the control algorithms of data acquisition. Besides relieving the programmer of control responsibility, the DriverLINX abstract, declarative approach gives the program syntactic and semantic interchangeability when migrating to equivalent hardware products. The abstract, declarative approach also helps isolate the software vendor of rapid technological obsolescence of change in the computer industry by focusing on the immutable logic of data-acquisition relations while the mechanisms control vary depending on software development. DriverLINX was a viable approach to programming data acquisition for more than 12 years despite the market evolution from Windows 16-bit. NET today. From the statements of verification instruments test instruments, such as digital voltmeters and electrometers, have evolved from simple devices with a button on the front panel and display screen to sophisticated measurement processors from the scene of dozens of measurement functions and control . As data acquisition devices, typically developers send a carefully ordered sequence of commands to an instrument to implement the measure, then send additional command sequences to control the flow of measurement data of the instrument. The above problems for developers using imperative approaches to instrument control significantly limit ease of use and prohibit instrumentation solutions for rapidly measuring needs in the short term. ExceLINX is an add-in for Microsoft Excel lets you specify the configurations of the rapid test instrument using worksheet forms. Users specify, or declare, the channels, configurations, sampling rates, triggering, and location data for the measures they wish to participate by completing an Excel spreadsheet. When the user selects the “start” button on the toolbar, ExceLINX translates the specification into the correct command sequence to the instrument target launch position and the flow of data to the worksheet requested. Users can configure and collect measurements by themselves in minutes using logic specifications compared to days or weeks using programmer’s time for imperative specifications. Internally, ExceLINX also uses a declarative approach to address the complex problem of field validation for the worksheet forms. Instruments have hundreds of parameters with complex overlaps among parameters. To validate whether the instrument supports the parameter set selected by the user, ExceLINX maintains a dependency tree of allowed, disallowed, and the parameters for every input cell on the worksheet. Each node of the tree also maintains logical relations among the selected set of parameters that ExceLINX evaluates the performance of cross validate user input selections. Each model of the instrument has taken over the semantics of different parameters, but ExceLINX can easily handle this complexity by adopting the model trees because the logic of the specific model in the validation tree is separate from the implementation of shared control in the code ExceLINX. Declarative programming strategies that separate logic from control in algorithms are powerful techniques that can be used with currents of today, imperative languages. These techniques can make software more interchangeable, maintainable, usable, and endurable Roy E. Copyright Furman, M. D., Ph. D 2005