1 Taxonomies, Paradigms, and the Untangling of Terminology
Joyce Farrell, our textbook author, raises a number of interrelated issues on p. 92. I have
tried to analyze her terminology in comparison to a dozen or so other print and web authors. I have tried to summarize or quote a number of these other authors below in outline
form. I would propose to distinguish between the following aspects of computer programming:
1. Program Logic Levels, Styles, and Classes
a. Low-level program logic
b. Intermediate-level program logic
c. High-level program logic
1) Class 0
2) Class 1
3) Class 2
d. System-level logic
2. Processing Mode
a. Batch
b. Interactive
3. (User) Interface Design
4. Implementing High-Level Program Logic Alternatives
a. Operating System Features
b. Event-Driven Programming
5. Programming Language Paradigms
a. Procedure-Oriented/Procedural Programming Languages
1) Low-Level Programming Languages
a) Machine Languages (First Generation Programming Languages)
b) Assembly/Assembler Languages (Second Generation Programming Languages)
2) High-Level Programming Languages (Third Generation Programming Languages)
b. Nonprocedural Programming Languages
1) Functional (“broad sense”)/Applicative Languages
a) Definitional
b) Single Assignment
2) Declarative Languages
a) Logic Programming Languages
b) Expert System Languages
1 of 45
c) Knowledge-based Systems (Knowledge Representation)
d) Theorem Proving Systems
e) Grammars for formal and natural languages (Metalanguages)
3) Constraint Languages
a) Query and Update Languages
4) Multi-paradigm
a) Constraint Logic
b) Functional Logic
5) Non-procedural Systems (Fourth Generation, Very High Level)
a) Report Program Generators
b) Sort Generators
c) Spreadsheets
6. Programming Methodologies
a. Modular Programming
b. Structured Programming
c. Object-Oriented (& related) Programming
1) Refactoring
2) Patterns & Anti-Patterns
3) Prototype Based
4) Aspect-Oriented
a) Reflective (related to Functional Programming Language
Paradigm)
d. Literate Programming
e. Modeling Languages
f. Unified Process
g. Genetic
7. Problem Analysis and Program Design Methodologies
a. Structured Program Design (Top-Down)
b. Object-Oriented Program Design (Bottom-Up)
8. Programming Language Domains of Application
a. Machine-oriented (i.e., Machine and Assembly/Assembler Languages)
b. Problem-oriented/Application-oriented
1) General Purpose
2) Application areas sufficiently wide and important to justify particular consideration:
a) numerical and non-numerical (i.e. formal algebraic) scientific applications
b) business data processing
2 of 45
c) special data structures
i) string processing
ii) (linked) list processing
3) Special-Application-Oriented
4) Special-purpose
1.1 Taxonomies and Paradigms
The term “taxonomy” generally means “an orderly classification”. Until recently, it was
used mostly by biologists to indicate an orderly classification of plants and animals according to their presumed natural relationships. Computer technology authors have
adopted the term to indicate their various efforts to bring order to a complex and constantly evolving discipline. Unfortunately, “taxonomy” is beginning to achieve
“buzzword” status.
“Paradigm” is another term which is definitely in buzzword status. Nevertheless, it can
still be useful if treated carefully. Its basic meaning is “a model, example, or pattern, especially an outstandingly clear or typical pattern or archetype”. More recently, it has
come to mean some pattern or method used to interpret, understand, express, or (over?)
simplify something more complex, such as “reality”—a kind of “world view” sort of
thing. Computer technology authors seem to have adopted the term to classify various
major types of programming languages.
1.2 Untangling Terminology, Part 1—the Use of Alternatives and
Criteria in Program Logic
What I haven’t found so far is a good characterization of the underlying design decisions
that software designers and programmers need to make in order to realize their analysis
and design. Toward this end, it may be helpful to consider the role of logical alternatives
and their related criteria in a program. As near as I can tell, all programming languages,
properly so called, provide some means of specifying alternative evaluations or courses
of action, and some means of specifying the criteria to select between those alternatives.
In our course discussions so far, that would encompass the “decision” step and its use in
selection and repetition structures.
It is possible for alternatives criteria to be based entirely on processing which is completely internal to the program, for example alternatives criteria based on a pseudorandom number generator. However, such programs would be self-deterministic, not very
flexible, and probably of limited usefulness. It is much more common to base alternatives
criteria on input to the program, or, indirectly, on calculations based on input. This allows
the programmer to provide the program with various degrees of responsiveness to that
input. Most programs, then, are programmer-specified combinations of basic evaluations
or courses of action, and criteria-determined alternatives.
1.2.1 Levels of Program Logic
These alternatives and their criteria can be applied at any or all of several different levels
in the overall program logic.
3 of 45
1.2.1.1 Low-Level Program Logic
At a relatively “low” level, alternatives and their criteria can be applied to particular data
values. Chapter 5 of Farrell deals primarily with this level of programming. Major sections of chapters 6, 8, 9, and 10 also pertain.
1.2.1.2 Intermediate-Level Program Logic
At an “intermediate” level, alternatives and their criteria can be used to direct the processing of blocks of data. Examples include selecting, sorting, and organizing data, merging of multiple files, and the use of “transaction action codes” (“add”, “change”, or “delete”)—on a record by record basis. Chapters 7 and 11 illustrate these examples, along
with major sections of chapters 6, 8, and 9.
1.2.1.3 High- (or Top-) Level Program Logic
The application of alternatives and criteria at a “high” level of program logic, i.e., in the
mainline logic or “main loop” of a program, has the greatest effect on a program’s “personality”, that is, how the program is perceived by its users. For example, the popular distinction between “batch” and “interactive” processing, as well as the various approaches
to batch and interactive processing, is most commonly manifested at this level of program
design. Chapter 10 includes a discussion of batch processing and interactive processing.
Likewise, while user interface issues pertain at all program logic levels, they are particularly relevant at the high level for interactive programs.
At this point, I would like to employ some terminology to describe the various types of
high level program logic, independent of considerations of processing mode or user interface. If such a terminology is out there discipline wide, so far I haven’t been able to find
it. It appears that Farrell is also struggling with this issue. Unfortunately, she has chosen
some terminology that is easily confused with other common usages. So, for the purposes
of this discussion at least, I would propose the following classes of high level program
logic.
1.2.1.3.1 Class 0 High-Level Program Logic
This is the simplest possible form of high-level program logic. There are no alternatives
and criteria, hence no looping or selection. It just executes straight through, step by step,
from start to end. It has very limited application.
1.2.1.3.2 Class 1 High-Level Program Logic
This class is the simplest that results in truly useful programs. It includes a “main loop”
with but a single criterion to determine whether the end of the input data has been encountered, along with alternatives to loop back and continue processing additional input
data if the end has not yet been encountered or to conclude processing if the end has been
encountered. Chapters 4 though 9, 11, and parts of 10 and 12 illustrate this approach.
1.2.1.3.3 Class 2 High-Level Program Logic
For now, this is a catchall class that encompasses all high-level program logic more complex than Class 0 or Class 1. It will typically include a main loop with program termination as just one of several or even many alternatives and criteria.
4 of 45
1.2.1.4 Logic Levels beyond the Program (“System”-level logic)
For the sake of completeness, I would note that most modern operating systems provide
various facilities such as a (job) control language, “batch command files”, scripting, macros, or “record/playback”. At their most basic, these facilities provide a way to sequence
a series of requests to the operating system to perform various system functions or to initiate specified utility or application programs. Once the sequence is initiated, it can be
carried out automatically. User or system operator interaction may be provided for, but is
not necessary. Many of these facilities also allow for selection and repetition logic
through the use of some form of alternative sequences and related criteria. The most advanced forms of scripting even allow alternatives to be applied to standard program input
using criteria based on standard program output.
1.2.2 Processing Mode and Program Logic Design
1.2.2.1 Batch Processing Mode
Most everyone seems to agree that batch-oriented programs are those that take relatively
large collections of data, such as data files, and process these large collections forthwith.
The only user intervention consists of gathering the data into the collection, initiating the
execution of the program or submitting the program for later execution, and receiving,
distributing, and acting on the output produced by the program. The mainline logic of
batch-oriented programs is typically “Class 1”. There are examples of “Class 2” batchoriented programs, such as “command-driven” batch-oriented programs.
1.2.2.2 Interactive Processing Mode
There is less agreement about the precise meaning of “interactive”. The most general definition of “interactive processing” is roughly this: a mode of processing where the program receives input, processes the input, and returns output that is “immediately” available to help determine further input. The program then awaits further input.
This definition has several significant implications. For one thing, because the computer
will be awaiting further input, there must be some “correspondent” (other than a data file)
that can provide the further input, based on the previous output. A human user is the most
familiar correspondent; but other types of correspondents are possible, including (computer numeric or process control of) machinery, and (interaction with) external physical
phenomena or other computer systems.
Note that batch processing may also involve interaction, but that this must take place between the time when the program terminates and the time when its execution is next initiated. With the interactive processing mode, interaction takes place between the time
when the program is initiated and the time when it terminates, in other words, while the
program is still “running”.
A second implication is “response time”. The timing requirements of the program’s external correspondent must be taken into consideration. Both hardware and software design features may need to be brought to bear to meet these response time requirements.
Systems which are able to meet the response time requirements of external correspondents are commonly called “real time” systems. For the human user, response time requirements may be largely psychological but nonetheless real.
5 of 45
A third implication is what to do with a computer system that is awaiting further interactive input. For a mechanical or phenomenal correspondent, the wait time may be from
relatively short to practically non-existent. The wait for input from a human user will, on
the other hand, be fairly significant from the computer system’s point of view. For a relatively inexpensive single user system, an idle computer system may be acceptable, and no
special handling may be needed. For a multi-user or multi-tasking system, there are a
number of strategies available to redeem the wait time for use by other users or tasks.
A fourth implication is “on-line” connection. “On-line” refers to the state of (equipment)
being directly controlled by or in direct communication with a computer. (Active networking is included.) On the other hand, “off-line” refers to (equipment) not being directly controlled by or connected to a computer. (Applications designed for batch processing
mode can theoretically tolerate the delays involved with input-output via off-line equipment. Typically, off-line equipment records data into files or outputs data from files independently of the computer that processes the data. Of course, software designed for
batch processing mode can just as well use on-line input-output equipment.) The relatively short response time required by interactive processing generally requires on-line inputoutput equipment, however.
Programmers can design very limited interactive programs using only “Class 1” highlevel program logic. “Class 2” is usually more difficult to program, but gives the programmer many more options to satisfy human factor requirements in the user interface.
1.2.2.3 Interchangeability between Batch and Interactive Processing Modes
I would hasten to add that, from the programmer’s perspective, the distinction between
“batch” and “interactive” is not absolute. For one thing, most modern operating systems
allow the file input and output of batch-oriented programs to be redirected to the user’s
console or terminal (keyboard, display, etc.). This provides for an admittedly crude form
of interaction with the user.
In addition, most modern operating systems provide various facilities such as “batch
command files”, scripting, macros, or “record/playback”, and the ability to redirect keyboard input from and console output to data files. With some effort, the programmer can
embed interactive-oriented programs in a “batch” environment.
Also, there are forms of high-level program logic that can function in either a batch or an
interactive mode, although with perhaps varying degrees of effectiveness. One example
would be “command-driven” program logic.
1.2.3 Interface and Program Logic Design
In the broadest sense, (user) interface design encompasses both batch and interactive processing modes; and human factors should be taken into consideration for all types of programming. Most discussions, however, focus on the more contemporary issues of designing a viable user interface for an interactive processing mode. If interaction with a mechanical or phenomenal correspondent is part of the program design, technical knowledge
of the interface protocols will be required. If interaction with a human user is part of the
program design, human factors must be given central consideration in designing and implementing the user interface. Chapters 10 and 13 include discussions of various user interfaces and their features.
6 of 45
1.2.3.1 User Interface Design at Low- and Intermediate-Levels of Program
Logic
1.2.3.1.1 Prompting
1.2.3.1.2 Form Fill-in (Screen/Window-based)
1.2.3.2 Interface Design at the High-Level of Program Logic
1.2.3.2.1 Command-Driven
Chapter 13 includes a discussion of command-driven program logic.
1.2.3.2.2 Function-key Driven
1.2.3.2.3 Menu-Driven
Chapter 10 includes a discussion of menu-driven program logic.
1.2.3.2.4 Direct Manipulation
1.2.4 Implementing High-Level Alternatives and Criteria
The more high-level alternatives and criteria that a program design calls for, the more
complex the mainline logic or main loop becomes. It is certainly possible for the application programmer to directly code all the logic involved with these features. However,
several facilities are commonly available to assist the programmer in this regard.
1.2.4.1 Operating Systems
Operating system designers and programmers must provide batch and interactive user
interfaces for the operating system in order to provide for user control over the system,
for example to allow the user to call for the initiation of execution of a particular program. Many aspects of these existing interfaces may be available for use by application
programs as well.
1.2.4.2 Event-Driven Program Logic
Event-driven program logic is useful for designing and implementing both human user
and nonhuman interfaces. Chapter 13 includes a discussion of event-driven program logic.
In order to allow the run-time environment or operating system to redeem wait time for
other users and tasks, and/or in order to free the application programmer from the complexities of managing events generated by GUIs, many event-based programming environments provide the programmer with a main loop or mainline logic which will wait for
events to occur. The application programmer does not have to code the main loop or
mainline logic.
There are many different ways this can be implemented. In some programming environments, the programmer must code, as part of the program, the criteria that identify the
various types of events which may occur and then invoke the appropriate alternative
7 of 45
modules. In others, the programmer uses some mechanism external to the program to
specify which modules go with which types of events. A third approach is to require the
programmer to include executable code, typically part of initial housekeeping, which will
inform the run-time environment about which modules are to be associated with which
types of events. A fourth approach, which can be used with object-oriented programming
languages, is to allow the programmer to provide a new definition for an “event handler”
method that will “override” the standard default method of the same name defined for the
object class of the object to which the event is related.
1.3 Untangling Terminology, Part 2—“Procedural”, “ObjectOriented”, or “Event-Driven”?
1.3.1 “Procedural”
On pp. 92 and 343, Farrell seems to define “procedural” to mean something akin to what
I have called “Class 1 high-level program logic”. The problem with the term “procedural”
is that it is widely used to distinguish a particular class or paradigm of programming languages, rather than a particular form of program logic. You can sample some of the range
of usage for “procedural” and related terms under “Taxonomies of Programming Language Paradigms”, below. I have tried to gather together some of Farrell’s usages under
“Taxonomies of Program Logic Styles”, below. It should be noted that languages in the
procedural paradigm may include nonprocedural features, such as declarations, expressions, and functions. Similarly, many nonprocedural languages may have some features
more typical of the procedural paradigm. There is also interest in mixed- or multipleparadigm programming languages.
1.3.1.1 A brief summary of the procedural (or procedure-oriented) programming language paradigm:
1.3.1.1.1 explicit flow of control:
1.3.1.1.1.1 The problem or its solution is expressed in terms of sequential steps.
1.3.1.1.1.2 Repetition may be expressed in terms of the iteration or looping of steps.
1.3.1.1.2 explicit interaction with values in memory:
1.3.1.1.2.1 In third generation procedural languages (COBOL, BASIC, C, etc.), this
is accomplished by using
1.3.1.1.2.1.1 programmer-named variables to designate single values or aggregations of
values (arrays, records, etc.) in memory, and
1.3.1.1.2.1.2 assignment or input steps to update the values of variables.
1.3.1.1.2.2 “Preservation of State”
Values in memory are retained unchanged (“preservation of state”) until an update step is
executed or the memory is released. When a variable (or memory location) is referred to,
8 of 45
other than when receiving an update, its most recent value, or values, in the case of aggregates, are made available for further processing or output. (In a multitasking environment, the update might be performed by an independently executing module.)
1.3.1.1.2.2.1 Modules might be allowed to preserve private state between invocations.
1.3.1.1.2.3 “Side effects”
Modules might not be restricted to returning values through the standard parameter and
return value mechanisms, and might be allowed to update (global) memory values that
will be available to other modules after the module exits.
1.3.1.2 Nonprocedural programming language paradigms minimize or eliminate the above features.
1.3.2 “Object-Oriented”
In the Tip on the bottom of p. 92, Farrell seems to distinguish between “procedural” (i.e.,
Class 1 high-level program logic) and “object-oriented” programs. She further defines
“object-oriented programming” on pp. 356-7. In the latter case, she emphasizes the similarities between object-oriented and “modular procedural programming”.
There is considerable, although not complete, agreement throughout the computer science
discipline about the major characteristics that distinguish object-oriented programming
and programming languages. However, there is a notable degree of variability in the
ways various authors place object-orientation in programming and programming language taxonomies.
This may be in part due to the various ways object features have been implemented. In
some cases, object features have been added to an existing procedural language. Examples of this include Simula, the first object-oriented language (based on ALGOL), and
C++ (based on C). In other cases, new languages have been created from the ground up
based entirely on object concepts—Smalltalk, for example. Another example is Java,
which is based entirely on object concepts, but adopts those parts of the C and C++ languages which can be made entirely safe and consistent with its object concepts. There are
also efforts to bring object concepts to nonprocedural programming language paradigms.
The power of object-oriented programming and programming languages has commonly
been applied to help manage complex programming tasks, especially graphic user interfaces. However, it can just as well be applied to other processing modes (such as “batch”)
and other forms of program logic (such as “Class 1”, what Farrell calls “procedural”).
For the above reasons, I would strongly caution against the inference from Farrell’s
statements that “object-oriented” programs form a separate class from “procedural” programs, either in her sense as a class of program logic or in the sense of a programming
language paradigm. I would suggest that object-oriented programming be classified as a
programming method or “methodology” that can be applied to a programming language
paradigm, processing mode, or class of program logic. See below.
9 of 45
1.3.2.1 A brief summary of object-oriented features (Farrell, p. 356):
1.3.2.1.1 Attributes and Methods
You analyze the objects you are working with [What are their “attributes”?] and the tasks
[“methods”] that need to be performed with, and on those objects.
1.3.2.1.2 Messages
You pass messages to objects, requesting the objects to take action [using their methods].
1.3.2.1.3 Polymorphism
The same message works differently (and appropriately) when applied to different [classes of] objects. [In some languages, the programmer will need to provide separate logic
for each of the different object classes. Some languages may provide mechanisms, such
as “templates”, that help generate the logic for multiple object classes.]
1.3.2.1.4 Method Overloading
A module or procedure can work appropriately with different types of data it receives,
without the need to write separate modules. [As with polymorphism, in some languages
the programmer will need to provide separate logic for the various combinations of data
types, or use features such as templates. Overloading may be available in non-objectoriented languages, such as C.]
1.3.2.1.5 Inheritance
Objects [or object classes] can share or inherit traits of [classes of] objects that have already been created, reducing the time it takes to create new [classes of] objects. [Attributes or messages/methods defined for a “child” class may “override” an identically
named attribute or identical message/method defined for a “parent” class.]
1.3.2.1.6 Encapsulation
Encapsulation and information hiding are more complete [i.e., more powerful and flexible] than with the modules used in procedural [i.e., non-object-oriented] languages. [Encapsulation can be applied to both attributes (data) and methods (functions).]
1.3.3 “Event-Driven”
While Farrell gives pretty clear, standard, un-entangled definitions for “object-oriented”
programs and programming in chapter 12, and of “event-driven” programs and programming in chapter 13, the Tip at the bottom of p. 92 is a rather different story. She states
that “A distinguishing feature of many object-oriented programs is that the user determines the timing of events in the main loop by using an input device such as a mouse”;
but that distinguishing feature is, in fact, a definition of event-driven programs (see below). So, she is saying that many object-oriented programs are also event-driven programs, which is technically correct. Just don’t take that distinguishing feature of eventdriven programs as a definition of object-oriented programs.
See also Jo-Mae B. Maris at Northern Arizona University
(http://www.cba.nau.edu/facstaff/maris-j/CIS220/220Notes/L8Program.Ppt#17).
10 of 45
Here follows a recap of some source materials. [My comments and clarifications (hopefully) are enclosed in square brackets.]
2 Taxonomies of Processing Modes
2.1 David N. Freeman Taxonomy (Encyclopedia of Computer
Science, 3rd ed, 1993, “Processing Modes”, pp. 1104ff)
2.1.1 Batch processing modes
differ from [on line & real time] in that substantial queues of unprocessed transactions
(jobs) are held in the computer throughout normal operation.
After all input records have been read into the computer [see below], the job (processing
task defined by these records) is enqueued for execution. If small and short, it may be selected for execution a few seconds later; if large and low-priority, it may remain
enqueued for hours.
When the control program selects a job for execution, its control statements are scanned
for consistency and completeness. If valid, source data and programs are processed on a
nonstop minimal-intervention basis. Output records are generated at this time, typically
accumulated on tape or disk, rather than flowing directly to a line printer or display device.
use programs and data stored at all levels of a memory hierarchy:
1. Main memory
2. Auxiliary memory
3. Card decks, floppy disks, cassettes, etc.
Each batch installation maintains a library of systems and applications programs on
fast auxiliary memory, typically drums or disks.
2.1.1.1 Card-oriented batch processing [off-line preparation]
included here for historical completeness, but is now virtually obsolete
Typical response time: 102 to 104 sec.
Applications based on punched cards (or their images) required input unit records prepared on keypunches, key/disk key/tape systems, teletypes, or other off-line devices not
connected to a computer. Input data (and specialized programs associated with the data)
were submitted to the computer all at once in a high-speed stream. Little validation of
data was performed during this input phase.
Likewise [to job queues], substantial queues of output reports are printed/punched continuously for card-oriented batch processing
2.1.1.2 Keyboard-oriented batch processing [on-line preparation]
Typical response time: 100 to 102 sec.
Users of keyboard-oriented batch processing prepare input data and programs much the
same way as for card-oriented processing. Some validation and syntax checking are performed as statements are typed directly into the computer. When accepted, images of
11 of 45
these statements are retained temporarily/permanently on disk storage. A broad repertoire
of commands is available for inserting new statements, updating existing statements, and
other editing of partially developed programs.
These [output] queues are presented on request during keyboard-oriented batch processing.
2.1.2 Performed on line & in real time
responses to input stimuli (or input transactions) are almost instantaneous.
2.1.2.1 Interactive computing
Typical response time: 100 to 101 sec.
appropriate for those who wish to develop and operate programs in real time, correcting
errors as soon as the latter are detected by the computer. (This contrasts with debugging
in batch-processing mode, where most errors cause immediate termination of jobs, accompanied by diagnostic printouts.) Also, programs and data may be validated as entered, syntax checked, consistency with prior program statements established, and range
tests on variable values performed.
2.1.2.2 On-line inquiry & transaction processing
Typical response time: 100 to 101 sec.
use the computer to access rapidly a repository of data and to update the database or to
insert new data in it. Processing time per query or transaction (e.g. making an airline reservation) is typically trivial compared with times required to enter and display information. This mode has been made feasible by development and widespread usage of
large disk drives whose capacities range from 50 million to 1 billion characters per drive.
Complete and up-to-date master files can be accessed by authorized clerks, management
personnel, etc. using typewriter terminals or CRT (cathode ray tube) displays.
2.1.2.3 Message switching
Typical response time: 10-1 to 100 sec.
resembles on-line inquiry in that processing per input stimulus (message, query) is trivial.
Whereas the inquiry mode permits retrieval and display of disk-stored records, the message-switching mode receives streams of characters (messages) from one site and routes
them to other sites automatically, according to destination headers describing (for each
message) where it is to be sent. Message switching is almost invariably used in conjunction with the public telephone network; large commercial, manufacturing, and governmental enterprises use message switching for high-speed communications among offices
and for efficient usage of their telephone networks. Such systems are the forerunners of
more general electronic mail systems.
2.1.2.4 Data acquisition & control (DAX)
Typical response time: 10-2 to 100 sec.
has many operational similarities to message switching—modest requirements for computational power and main memory, fast processing of incoming cassette tapes and
punched paper tapes. As data are received from such instruments as voltmeters, gas
12 of 45
chromatographs, and thermocouples, they are scaled and tested for conformance to normal operating ranges for these instruments (and associated physical processes). When the
computer detects an out-of-range condition, it notifies appropriate personnel such as a
plant guard, fireman, or operating engineer. Typically, the DAX-oriented computer types
out a warning message, rings an alarm bell, or flashes an alarm light continuously until
the out-of-range condition is corrected.
2.2 Janossy/Samuels Programming Taxonomy (CICS/ESA Primer, 1995, pp. 3-10)
[/I have placed the author’s comments about the specific hardware and software platforms used to implement these processing modes in smaller type and often enclosed them with slashes/]
2.2.1 Batch
Batch programs accept information from processing in groups called batches and produce output grouped in sets, such as report pages or records in new files. … Batch programs are useful for tasks such as producing reports from whole files or databases, applying a file of transactions to a master file, or scanning a file to purge it of outdated information. Batch programs do not communicate with anyone as they execute. Once started,
their execution is supervised by the computer’s operating system. Unless a batch program
experiences a problem, it continues to execute “on its own” until its work is finished. …
Batch processing is the older of the two forms of processing. [?] The first business activities automated in the 1960s were accounting functions, which operate on regular daily,
weekly, monthly, quarterly, and annual cycles. Batch processing was (and continues to
be) ideally suited to much of this work. For example, a payroll system runs on a regular
cycle, and by its very nature processes grouped sets of data (time sheets) into a grouped
output (a set of paychecks).
/IBM mainframes were designed [originally] to support the automation of the 1960s, and as such have [or
had?] a “batch” personality. These machines and their operating systems were not designed to communicate with end user terminals. In fact, computer terminals were not even a part of the computing environment when major mainframe design decisions were made in 1962-1963. [This may be somewhat of an
overstatement, but does reflect the most common approaches to computing at that time.] Even [many of]
today’s mainframe architectures date from this era! [One should, however, recognize the continuing efforts
of mainframe vendors to keep their technologies up-to-date while still backwards compatible with existing
applications and approaches.]/
usually support some form of “scripting” language that resembles
the job control language /of mainframes/, so that batch processes, like repetitive file backups, can be arranged and processed on them.
/Mini- and microcomputers/
1. Primitive batch machine: The earliest vacuum tube computers, which had an operating system so primitive that only one program could be run at a time. An example was the IBM 705 of 1953.
2.2.2 Interactive
Interactive programs are designed to communicate with people as they run, usually using computer terminal screens. Interactive programs issue messages, called prompts, to
an end user for the entry of information, such as customer id, and retrieve and present related information on the screen.
… Interactive programs allow the end user to communicate new information or change
existing information, and then put this information into external (disk) storage. You
13 of 45
might think about interactive program processing as similar to the way a desk calculator
works. You enter information, the calculator processes your inputs and immediately provides you with computed results. You do not pool or “stack up” hundreds or thousands of
calculations for your calculator, then run it in batch mode to do all of your computations
overnight and produce a report! …
Interactive processing is the newer form of processing /and is typical of minicomputers and microcomputers. Mini- and microcomputers are inherently interactive, since they (and their operating systems) were designed with this form of processing in mind. Word processing, spreadsheet analysis, and database information retrieval are all typical mini- and microcomputer applications. These are highly interactive and cannot be handled adequately in a batch mode./
2.2.2.1 Traditional
Traditional interactive programming consists of two different approaches to the way the
person at a terminal is “talked to” by the software in a shared computer.
… Interactive program logic is housed on a /mainframe or minicomputer/ host that accesses
indexed files or a database on disk. End users work at terminals /or microcomputers emulating
terminals/. The number of terminals the host can support is affected by the interactive programming technique used—pseudoconversational techniques let the host support many
more terminals than conversational techniques. But ultimately, the arrangement is constrained by the power of the host computer, where all processing actions must be accomplished. Under traditional interactive programming, the workload is not split between the
host computer and the desktop device. The desktop device is treated as being entirely
dumb.
2.2.2.1.1 [Platform Architectures]
2.2.2.1.1.1
2. Traditional multiprogrammed architecture: / Traditional Interactive Application
Architecture
A mainframe or minicomputer running a capable multiprogrammed operating system with dumb terminals attached. An example was the IBM System/360 or a VAX/780. Dumb terminals are simply communications devices with no programmable logic of their own—[some types of these terminals are] also known
as ASCII terminals.
In the traditional interactive system architecture, dumb terminals are connected to a processor such as a
mainframe or a minicomputer, …. In this arrangement, all processing tasks associated with database access
and the user interface (such as formatting the terminal screen or accepting and validating user input) are
handled by the mainframe or minicomputer.
Traditional architecture is expensive in more ways than its requirements for software development. [See
Language Paradigms, below] Processor costs range from millions of dollars for a mainframe to hundreds of
thousands of dollars for a minicomputer. With the price of microcomputers, workstations, and Reduced
Instruction Set Computer (RISC)-based machine platforms declining while their processing power increases, the difference in cost between mainframe/mini’s and these newer levels of equipment is easy to appreciate. Programming in a modern nonprocedural language and sharing processing tasks between a host computer and powerful but inexpensive desktop equipment is a natural direction to explore.
Note that the essential characteristics and expense of traditional interactive system architecture are maintained, even if dumb terminals are replaced with microcomputers emulating terminals. Having a microcomputer emulate a terminal often gains an economy of equipment, as well as slight additional flexibility in
capturing, saving, or printing screen images. But terminal emulation does not allocate to the microcomputer
any of the processing tasks associated with database access or interaction. The mainframe or minicomputer
host is still the workhorse and, for the most part, the bottleneck. You don’t necessarily have client/server
just because you access a host computer with a PC or Mac!
14 of 45
2.2.2.1.1.2
3. Freestanding microcomputer or workstation:
Only a competitor to a mainframe or minicomputer for the smallest single-user interactive processing tasks.
An example is a single PC running a database such as Microsoft Access, FoxPro, Dbase IV, Paradox, Revelation, Dataease, or a spreadsheet.
2.2.2.1.1.3
4. Networked microcomputers or workstations with print or file server: / Networked
Microcomputers (Local Area Networks)
Multiple freestanding workstations, each of which can route print to a shared printer and download software or files from a PC or workstation acting as a file server. A Novell network is an example.
… In this arrangement, PCs might communicate with a “main” PC acting as a file server, in order to share
software located on the server and access an expensive peripheral device such as a laser printer. The network server may provide terminal emulation software and a connection to a host system, so that individual
PCs can act as terminals and log on. The file server may be nothing more than a capable PC with a large
hard disk.
A network of microcomputers, a PC, Mac, or workstation acting as a print or file server is not a client/server arrangement. [Some authors would classify this as device or file client/server, but not as application client/server.] Networks not only provide conveniences in software licensing and access control, but
also greater security than individual microcomputers acting as terminals to a host. In a network, a microcomputer or workstation may receive the software to run an application over the network instead of having
the software loaded on its hard disk. But the critical point is that each microcomputer executes software
entirely on its own. In other words, the server in the network is simply a central storage location for programs and files. The server performs no real [application] processing on behalf of any application.
2.2.2.1.2 Conversational
Conversational programming carries on a “conversation” with the end user at a terminal using a program that is active all of the time. /This form of interactive programming is typical
of minicomputers and microcomputers./ It is relatively easy to program and provides acceptable
support for small numbers of terminals.
2.2.2.1.3 Pseudoconversational
Pseudoconversational programming gives the appearance of carrying on a conversation with a terminal user, but gains an efficiency advantage by deactivating the program
that the terminal user thinks is communicating with him or her while he or she makes entries on the screen. Pseudoconversational programming logic is much more complicated
than conversational logic, but it makes it possible /for even a small mainframe or minicomputer/
to support thousands of computer terminals rather than hundreds.
2.2.2.2 Client/Server / How Client/Server Architecture Works
Client/server interactive programming is a newer form of programming usually involving communication between microcomputers using a local area network (LAN) and different types of software running on different participants in the network. Client/server
computing /has become a topic of much interest to the industry, because it/ holds the potential to
make interactive programming easier, more accessible, and less expensive. /In the remainder
of this chapter, we’ll focus on client/server computing, to complete your perspective of interactive programming./
5. Client/server architecture: Intelligent devices such as PCs or workstations communicating with a database server and sharing processing tasks with the server. This could also be called “cooperative computing”, because the processing load is split between two similar or dissimilar machines (the PC/workstation
client and the database server).
15 of 45
Programming in a modern nonprocedural language [see below] and sharing processing
tasks between a host computer and powerful but inexpensive desktop equipment is a natural direction to explore.
You don’t necessarily have client/server just because you access a host computer with a
PC or Mac! [This is due to the option of terminal emulation to access a traditional interactive application architecture. See above.]
Client/server architecture is a departure from the traditional way in which processing
tasks are divided between devices such as computer terminals (or microcomputers acting
as terminals) and a host computer. Client/server is also different from a plain local area
network. In the client/server arrangement, the server is often a powerful mini- or microcomputer [or, now, even a mainframe] that manages a relational database. The server is
capable of processing SQL statements, that is, statements in a standard relational database
manipulation language. The server might perform all of the tasks of an ordinary local area network server in addition to acting as an SQL “engine”. …
In client/server architecture, application software resides on the hard disk of every client
(microcomputer or workstation), or on the server much as in an ordinary file server network. This software manages the client’s user interface, which is often graphic in nature.
The end user selects functions via a mouse, pull-down menu selections, fill-in lines, or a
combination of these. From these inputs, the application software forms SQL statements
unseen by the user and sends these to the database server via the local area network. The
server processes the SQL statements and creates a relation (table) containing the results.
The server then sends these results back to the client over the network, which stores the
data in memory or on its hard disk. The client manipulates the data in any way that the
client’s user desires, applying the processing horsepower of the client, not the server.
2.2.2.3 Event-driven Realtime
Event-driven realtime programming encompasses the internals of graphical user interfaces (GUIs), as well as software that controls machinery.
2.2.2.3.1 Windows GUI
Some aspects of modern business programming are beginning to involve GUIs as an adjunct to ordinary information acquisition and management. GUI programming is complex; business applications are often confined to making use of GUI features and access
provided by modern support software. /Tools such as Microsoft Visual Basic and PowerSoft PowerBuilder provide access to the GUI interface of Microsoft Windows, while XWindows provides the same
form of access under UNIX./ Most client/server tools provide high-level support for the GUI
interface, so applications can be simplified and standardized. This means that while GUI
is complicated, it internal complexity is hidden.
2.2.2.3.2 Process Control
Process control programming, on the other hand, often involves an intimate knowledge of
real-time events and software interfaces to transducers that sense pressure, temperature,
location, and speed. Languages such as C and Ada are often used to translate the analog
signals generated by transducers in industrial piping, storage tanks, engines, turbines,
16 of 45
pumps, lifts, aircraft, and missiles into digital form for interpretation by software and the
generation of control signals for related machinery.
2.3 Free Online Dictionary of Computing
(http://foldoc.doc.ic.ac.uk/)
2.3.1 batch
All input is prepared before the program is run and so cannot depend on the program’s
output.
2.3.2 interactive
Input/output is interleaved, like a conversation, allowing user’s input to depend on earlier
output from the same run.
2.3.2.1 real-time
An application which requires a program to respond to stimuli [i.e., input] within some
small upper limit of response time.
2.3.2.2 event-driven
A program, such as a GUI, with a main loop which just waits for events to occur. Each
event [type] has an associated handler [software module].
2.3.2.3 main loop
The top-level control flow construct in an input- or event-driven program; the one that
receives and acts or dispatches on the program’s input.
2.4 Tom Ellman on Batch vs. Continuous Transformation Systems (http://www.cs.vassar.edu/~ellman/old-courses/235spring-2000/cs235-lecture23.pdf)
2.5 Joyce Farrell Taxonomy (Programming Logic and Design,
2nd ed., 2002, Ch. 10, p. 279ff)
You can divide computer programs into two broad categories based on how they get their
data.
2.5.1 Batch processing
Programs for which all the data are gathered prior to running use batch processing.
Many computer programs use batch processing with sequential files of data records that
have been collected for processing. All standard billing, inventory, payroll, and similar
programs work this way, and all the program logic you have developed while working
through this text also works like this. Records used for batch processing are gathered over
a period of time—hours, days, or even months. Programs that use batch processing typically read an input record, process it according to coded instructions, output the result,
and then read another record. Batch processing gets its name because the data records are
17 of 45
not processed at the time they are created; instead, they are “saved” and processed in a
batch. For example, you do not receive a credit-card bill immediately after every purchase, when the record is created. All purchases during a one-month period are gathered
and processed at the end of that billing period. …
A batch processing system can be off-line; that is, you can collect data such as time cards
or purchase information well ahead of the actual computer processing of the paychecks or
bills.
2.5.2 Interactive processing
Programs that depend on user input while they are running use interactive processing.
Many computer programs cannot be run in batches. They must run interactively—that is,
they must interact with a user while they are running. Ticket reservation programs for
airlines and theaters must select tickets while you are interacting with them, not at the end
of the month. A computerized library catalog system must respond to library patrons’ requests immediately, not at the end of every week. Interactive computer programs are often called real-time applications, because they run while a transaction is taking place,
not at some later time. You also can refer to interactive processing as online processing,
because the user’s data or requests are gathered during the execution of the program.
2.5.2.1 Menu programs
A menu program is a common type of interactive program in which the user sees a number of options on the screen and can select any one of them. … The final option, Quit the
Program, is very important; without it, there would be no elegant way for the program to
terminate. A menu without a Quit option is very frustrating to the user.
Some menu programs require the user to enter a number to choose a menu option. …
Other menu programs require the user to enter a letter of the alphabet [commonly based
on a keyword in the displayed description of the menu option]. Still other programs allow
the user to use a pointing device such as a mouse to point to a choice on the screen. The
most sophisticated programs allow users to employ the selection method that is most
convenient at the time.
Tip: Many organizations provide a [voice response] menu to callers to handle routing of
telephone calls.
2.5.2.2 Command line (Ch. 13, p. 371)
From the 1950s, when people began to use computers to help them perform many jobs,
right through the 1960s and 1970s, almost all interaction between humans and computers
was based on the command line. The command line is the location on your computer
screen at which you type entries to communicate with the computer’s operating system.
An operating system is the software that you use to run a computer and manage its resources. Interacting with a computer operating system was difficult because the user had
to know the exact syntax (that is, the correct sequence of words and symbols that form
the operating system’s command set) to use when typing commands, and had to spell and
type those commands accurately.
18 of 45
2.5.2.3 Graphical user interface (Ch. 13, pp. 371ff)
Fortunately for today’s computer users, operating system software is available that allows
them to use a mouse or other pointing device to select pictures or icons on the screen.
This type of environment is a graphical user interface, or GUI. Computer users can expect to see a standard interface in the GUI programs they use. Rather than memorizing
difficult commands that must be typed at a command line, GUI users can select objects
that look like their real-world counterparts and get the expected results. For example, users may select an icon that looks like a pencil when they want to write a memo, or they
may drag an icon shaped like a folder[?] to another icon that resembles a recycling bin
when they want to delete a file[?].
3 Taxonomies of Program Logic Styles
3.1 Loren K. Rhodes on “Procedural Control Model” vs. “User
Interface Control Model”
(http://faculty.juniata.edu/rhodes/smui/syllabus.htm)
3.2 Tom Ellman on Modes of Interacting with Input Objects
(http://www.cs.vassar.edu/~ellman/old-courses/235-spring2000/cs235-lecture17.pdf)
3.3 Julia Case Bradley & Anita C. Millspaugh (Programming in
Visual Basic 6.0, 1999, Ch. 1, “Programming Languages—
Procedural, Object Oriented, and Event Driven”, pp. 3ff)
3.3.1 [Event Driven]
The newer programming languages, such as C++ and Visual BASIC, us a different approach [from the “procedural” languages]: object-oriented programming (OOP) and
event-driven programming. Microsoft refers to Visual BASIC as an event-driven programming language, which has many (but not all) elements of an object-oriented language such as Java.
In the event driven-model, programs are no longer procedural; they do not follow a sequential logic. You, as the programmer, do not take control and determine the sequence
of execution. Instead, the user can press keys and click on various buttons and boxes in a
window. Each user action can cause an event to occur, which triggers a BASIC procedure
that you have written. For example, the user clicks on a command button labeled Calculate. The clicking causes the button’s Click event to occur, and the program automatically
jumps to a procedure you have written to do the calculation.
3.4 Art Gittleman (Computing with Java™: Programs, Objects,
Graphics: Alternate Second Edition, 2002, “1.4 ProgramDriven vs. Event-Driven Applications”, pp. 15 ff.)
Older programming languages support the program-driven style of programming in
which our program executes from beginning to end following the steps of our code much
19 of 45
like a cook follows a recipe. Java permits program-driven code, and further supports
event-driven programming in which our program, like the firemen in the station, wait for
an event to spur them into action. [Note that his definition of program-driven seems very
similar to what I would call Class 1 high level program logic. Below you will see he ties
this to batch processing mode. But as I try to show above, this is not a strictly one-to-one
relationship.]
3.4.1 The Character Mode [Batch Processing Mode/Program-Driven]
… During these [early] years, computers executed programs in batch mode. The computer operator put together a batch of programs, using the card reader to feed then to the
computer that executed the programs one after another, printing a listing of each program
and the results. When the operating system started a program, that program had control of
the processor until it finished executing. We call such execution program-driven because
the program [rather, computer?] continues executing the program, one statement after the
other until the program ends or a fatal error occurs.
Executing such a program is like preparing a dish from a recipe. The cook is in charge,
executing the steps of the recipe until the dish is complete. …
Program-driven applications are still a very important part of computing. Preparing the
payroll does not require user intervention. The payroll program takes input regarding
hours worked and rate of pay and prepares the paychecks and other payroll records. As
another example, the Java compiler takes the source program as its input and produces
the byte code for the JVM [Java Virtual Machine] with no need for a graphical user interface, operating in character mode in which input and output consists of characters.
The Big Picture: The program-driven approach suits applications such as compilers that
require no user interaction. …
3.4.1.1 Execute code in a step-by-step fashion like a recipe.
3.4.1.2 Transform input into output, without user intervention.
3.4.1.3 Typically use character mode.
3.4.2 The Graphical User Interface [and Interactive/Event-Driven]
With monitors and operating systems capable of displaying graphics, we can develop
programs that interact with the user via a graphical user interface (GUI). The operating
system responds to the user’s input, conveying it to the program that passively waits for
user input to request it to provide some service. We represent these user requests as
events. An event-driven program includes code to respond to messages informing it about
events involving its windows, such as button presses or data entry.
The Big Picture: … Event-driven programs suit user interfaces whose components respond to user interactions such as pressing a button or making a selection. With the advent of more powerful computers with graphics capabilities, event-driven applications
have taken a more important place in computing.
20 of 45
3.4.2.1 Wait for the user to generate an event.
3.4.2.2 Include code to respond to that event.
3.4.2.3 Respond to user actions.
3.4.2.4 Typically have a graphical user interface.
3.5 Joyce Farrell Taxonomy (Programming Logic and Design,
2nd ed., 2002, Ch. 4, p. 92ff; Ch. 12, p. 343ff)
3.5.1 Procedural Programs
You can write a program that reads records from an input file and produces a printed report as a procedural program—that is, a program in which one procedure follows another from beginning until the end. You write the entire set of instructions for a procedural program, and when the program executes, each instruction takes place one at a time
following your program’s logic. The overall or mainline logic of almost every procedural
computer program can follow a general structure that consists of three distinct parts:
1. Performing housekeeping, or initialization tasks. Housekeeping includes steps
you must perform at the beginning of a program to get ready for the rest of the
program.
2. Performing the main loop within the program. The main loop contains the steps
that are repeated for every record.
3. Performing the end-of-job routine. The end-of-job routine holds the steps you
take at the end of the program to finish the application.
You can write any procedural program as one long series of program language statements, but most programmers prefer to break their programs into at least three parts.
The main program can call the three major modules [that embody the three distinct
parts, above].
Throughout most of computer programming history, which now totals about 50 years, the
majority of programs were written procedurally. A procedural program consists of a
series of steps or procedures that take place one after the other. The programmer determines the exact conditions under which a procedure takes place, how often it takes place,
and when the program stops. The logic for every program you have developed so far using this book has been procedural.
Tip: You first learned the term procedural program in Chapter 4.
It is possible to write procedural programs as one long series of steps. However, by now
you should appreciate the benefits of modularization, or breaking programs into reasonable units called modules, subroutines, functions, or methods. …
Tip: You first learned the term modular in Chapter 2; you learned about abstraction in
Chapter 3.
21 of 45
3.5.2 Event-based = Event-Driven Programs (Ch. 4, p. 92; Ch. 13, pp.
371ff)
Tip: Not all programs are procedural; some are object-oriented. A distinguishing feature
of object-oriented programs is that the user determines the timing of events in the main
loop of the program by using an input device such as a mouse. As you advance in your
knowledge of programming, you will learn more about object-oriented techniques. [I believe the author is here describing a style of programming she later defines more extensively as event-driven, rather than “object oriented”, which she defines more extensively
elsewhere (see below) as a different but related programming concept. In fact, some programming environments, such as Microsoft Visual BASIC or Borland C++ Builder, use
the power of object-oriented programming to help manage the complexities of eventdriven programming.]
GUI programs are called event-based or event-driven because actions occur based on
user-initiated events such as clicking a mouse button. When you program with eventdriven languages, the emphasis is on the objects that the user can manipulate, such as buttons and menus, and on the events the user can initiate with those objects, such as clicking or double-clicking. The programmer writes instructions that correspond to each type
of event.
Event-driven programs require unique considerations for the programmer. The program
logic you have developed so far for most of this book is procedural; each step occurs in
the order the programmer determines. In a procedural program, if you issue a prompt and
a statement to read the user’s response, you have no control over how much time the user
takes to enter a response, but you do control the sequence of events—the processing goes
no further until the input is completed. In contrast, with event-driven programs, the user
might initiate any number of events in any order. For example, if you use a word processing program, you have dozens of choices at your disposal at any moment. You can
type words, select text with the mouse, click a button to change text to bold or to italics,
choose a menu item, and so on. With each word processing document you create, you
choose options in any order that seems appropriate at the time. The word processing program must be ready to respond to any event you initiate.
With an event-driven program, a component from which an event is generated is the
source of the event. A button that a user can click is an example of a source; a text field
that one can use to enter text is another source. An object that is “interested in” an event
you want to respond to is a listener. It “listens for” events so it knows when to respond.
Not all objects can receive all events—you probably have used programs in which clicking on many areas of the screen has no effect at all. If you want an object, such as a button, to be a listener for an event such as a mouse click, you must write the appropriate
program statements.
Although event-based programming is relatively new, the instructions that programmers
write to correspond to events are still simply sequences, selections, and loops. Eventdriven programs still declare variables, use arrays, and contain all the attributes of their
procedural-program ancestors. An event-based program may contain components with
labels like “Sort Records”, “Merge Files”, or “Total Transactions”. The programming
logic you use when writing code for each of these processes is the same logic you have
22 of 45
learned throughout this book. Writing event-driven programs simply involves thinking of
possible events as the modules that constitute the program.
Tip: In object-oriented languages, the procedural modules that depend on user-initiated
events are often called scripts.
4 Taxonomies of Programming Language Paradigms
4.1 Jean E. Sammet Taxonomy (Encyclopedia of Computer Science, 3rd ed, 1993, “Programming Languages”, pp. 1123ff)
4.1.1 Procedure Orientation
4.1.1.1 Procedure-Oriented
one in which the user specifies a set of executable operations that are to be performed in
sequence and which specify a procedure. The key factor here is that these are definitely
executable operations, and the sequencing is already specified by the user [programmer].
Fortran, Cobol, and PL/I are examples. (The relation of these to domains of application is
discussed later.)
4.1.1.2 Nonprocedural
... is actually a relative term, meaning that decreasing numbers of specific sequential
steps need be provided by the user [programmer] as the state-of-the-art improves. [This
“decreasing numbers of specific sequential steps” aspect of Sammet’s concept of nonprocedural programming languages is rather different from the prevailing concepts.] The
closer the user [programmer] can come to stating a problem without stating the steps for
solving it, the more nonprocedural is the language.
Furthermore, there can be an ordered sequence of steps, each of which is “somewhat
nonprocedural”, or a set of executable operations whose sequence is not specified by the
user. Both cases contribute to more “nonproceduralness”.
Thus, before the existence of such languages as Fortran, the statement
Y  A  B * C  D / E could be considered nonprocedural because it could not be written
as one executable unit and translated by any system. [Some writers would still consider
an expression such as this, apart from its use in a statement, to be a nonprocedural feature
of a procedural programming language.] In 1992, the sentences CALCULATE THE SQUARE
ROOT OF THE PRIME NUMBERS FROM 7 TO 91 AND PRINT IN THREE COLUMNS and PRINT ALL
THE SALARY CHECKS are nonprocedural because there is no compiler available that can
accept these statements and translate them; the user [programmer] must supply the specific steps required. As compilers are developed to cope with increasingly complex sentences, the nature of the term changes. Thus, what is considered nonprocedural today may
well be procedural tomorrow. [This is, again, a rather idiosyncratic concept of nonprocedural classification.]
The best example of a currently available nonprocedural language is Prolog;
23 of 45
4.1.1.2.1 other nonprocedural systems (not really languages)
in which the individual [programmer/user] specifies the input and the desired output
without any description of the procedures needed to obtain the output.
4.1.1.2.1.1 report generators (RPG)
4.1.1.2.1.2 sort generators
4.1.1.3 Burton M. Leavenworth & Jean E. Sammet Taxonomy for Nonprocedural Languages & Systems (Encyclopedia of Computer Science, 3rd
ed, 1993, “Nonprocedural Languages”, pp. 934ff)
The most common term used has been nonprocedural, which is employed by a user [programmer] to indicate the goals to be achieved (i.e. what), rather than the specific methods
used to achieve them (i.e. how).
4.1.1.3.1 Some of the descriptive terms that have often been applied to the word
“language” to convey essentially the same concept:
4.1.1.3.1.1 nonprocedural
4.1.1.3.1.2 very high level
4.1.1.3.1.3 less procedural
4.1.1.3.1.4 goal-oriented
4.1.1.3.1.5 problem-oriented
[Also, see below.]
4.1.1.3.1.6 pattern-directed
4.1.1.3.1.7 declarative
4.1.1.3.1.8 functional / Functional (= Applicative) Programming (David S. Wise,
Encyclopedia of Computer Science, 3rd ed, 1993, pp. 573ff)
a style that uses function application as the only control structure. Rather than conditional
statements, one uses conditional expressions to yield alternative results; rather than an
assignment statement, one uses binding of parameter to argument to place a name on a
value; rather than explicit sequencing or looping of control flow, one uses patterns of
nested invocations to direct the generation of a result. [This last feature is known as “recursive function invocation”.]
4.1.1.3.1.8.1 Dataflow: Languages (Vason P. Srini, Encyclopedia of Computer Science,
3rd ed, 1993, pp. 418-9)
a functional programming language in which a variable may be assigned a value once and
only once throughout a program.
24 of 45
There are programming languages, such as Prolog, that also use single assignment to a
variable, but are not dataflow languages.
If the same variable name is used on the left side of an assignment statement in more than
one place in a dataflow language program, the second and other appearances of the variable are treated as new variables.
Many of the constructs found in block-structured languages, such as Pascal and C, are
usually supported in a dataflow language also.
Data structures, such as lists, records, and arrays, are also supported along with operations on them. The single assignment rule complicates modification to an element of a list
or an array. Copying entire lists or arrays when only a single element needs to be modified is expensive. Parallel data structuring mechanisms have been devised to avoid the
copying.
4.1.1.3.1.9 Logic Programming (Robert Kowalski, Encyclopedia of Computer Science, 3rd ed, 1993, “Programming Languages”, pp. 778ff; “…: Languages”, Keith L. Clark, pp. 783ff)
4.1.1.3.1.9.1 relational database
can be regarded as the special case of a logic program where all statements have the form
of conclusions without any conditions, variables, or function symbols. [I believe that this
applies to the expression of the database itself, rather than languages, such as SQL, which
manipulate the database.]
4.1.1.3.1.9.2 deductive database
can be regarded as a logic program that does not contain function symbols
4.1.1.3.1.9.3 Delaying Calls & Coroutining [beyond Prolog]
More modes of use of the Horn clauses of a logic program are retained if the query evaluator can delay the evaluation of some call if certain arguments are unbound. One use of
this is dynamic reordering of the calls of clauses. It also allows dataflow coroutining,
where the transfers between calls is triggered by the binding of shared variables. Some
successors of Prolog (e.g. Nu-Prolog & Prolog II) allow such delaying of calls.
4.1.1.3.1.9.4 Parallelism
As noted earlier, logic programming offers many opportunities for parallelism. Several
concurrent logic programming languages and parallel implementations of logic programming have been developed.
4.1.1.3.1.9.4.1 Or-Parallel Evaluation
An obvious way to parallelize Prolog is to allow for parallel search of the tree of alternative evaluation paths. This is called or-parallelism. Or-parallel versions of Prolog have
been implemented on multiprocessor machines. One such language, Aurora Prolog, has
the useful feature that it will run existing Prolog applications, often with considerable
speed-up.
25 of 45
4.1.1.3.1.9.4.2 Independent And-parallelism
In some or-parallel implementations, independent calls are also evaluated in parallel.
These are adjacent calls, the first of which is just about to be evaluated, that share no unbound variable.
4.1.1.3.1.9.4.3 Communicating And-parallelism
Allowing the parallel evaluation of calls that share variables is a much more radical step.
If this is coupled with delaying of calls when certain variables are unbound, it allows
concurrent dataflow programming, the parallelization of dataflow coroutining. Concurrent Prolog, GHC, Parlog, and Strand are concurrent dataflow LP languages. …
4.1.1.3.1.9.5 Constraints
It is possible to improve efficiency significantly by manipulating certain conditions as
constraints. Several logic programming languages incorporating constraints have been
developed.
4.1.1.3.1.9.6 Constraint Logic Programming Languages
Even more generality of use is retained by having primitives that automatically delay and
are capable of being called and solved for more than one mode of use. An example is a
primitive to solve simple equations such as X  Y  4 , which delays if X and Y were
both unbound, but which will solve the equation as soon as either becomes bound. The
constraint logic programming languages, such as Prolog III, Chip, and CLP(R) do this. At
some implementation cost, they actually do much more. …
4.1.1.3.1.9.7 Objects
An important area of research has been the development of systems that combine logic
programming and object-oriented programming or object-oriented knowledge representation. One such approach is based on an interpretation of objects as processes in concurrent logic programming languages.
4.1.1.3.1.9.8 Metaprogramming
This is a common and powerful logic programming technique for implementing more
powerful theorem-provers (sometimes called “inference engines”).
4.1.1.3.1.9.9 Types, functions, metalogic, higher-order logic, non-classical logic, integrity checking and abduction
Many proposals have been made to extend or modify logic programming by incorporating these features.
4.1.1.3.1.10 relational
4.1.1.3.1.11 problem statement
4.1.1.3.1.12 problem definition
[Also, see below.]
26 of 45
4.1.1.3.1.13 problem description
4.1.1.3.1.14 specification
[Also, see below.]
4.1.1.3.1.15 result specification
4.1.1.3.1.16 task description
4.1.1.3.2 Features of Nonprocedural Languages
4.1.1.3.2.1 Associative Referencing
4.1.1.3.2.2 Aggregate Operators
4.1.1.3.2.3 Elimination of Arbitrary Sequencing
4.1.1.3.3 Database Languages
Database languages have many of the characteristics we have been discussing. … The
relational algebra, which was developed originally by Codd (1972), consists of the operators SELECT, PROJECT, and JOIN, among others. Each operation of the relational algebra
takes either one or two relations as its operand(s) and produces a new relation as a result.
A relation has a precise mathematical definition, but can be considered to be a table for
our purpose. [Note the strong foundation on mathematical “set theory”.] … Many of the
newer database languages, such as SQL (Date, 1986), have extensive data manipulation
capabilities in addition to their retrieval functions [i.e., the relational operators previously
described].
4.1.1.3.4 Other Systems Related to Nonprocedural Languages
4.1.1.3.4.1 Report Program Generators (RPGs)
often mentioned when discussing nonprocedural languages. It is certainly true that the
output format of an RPG is specified by stating what is wanted rather than how it should
be produced. It should be noted, however, that the Calculation section of an RPG program is decidedly low-level. This confirms our statement that no language is nonprocedural in any absolute sense. A particular language may possess a certain feature in one
area and lack other features in that area or it may possess a certain feature in one area and
lack the same feature in other areas.
4.1.1.3.4.2 Spreadsheets
… a two-dimensional grid of cells, where a cell may contain a datum (number or string)
or a formula for computing a number based on values computed in other cells. There is
no notion of sequencing other than dependencies that are implicit in the cell formulas. …
4.1.1.3.4.3 Fourth-Generation Languages (4GLs)
rather poorly named and not clearly defined; most tend to have both procedural and
nonprocedural components. … The major nonprocedural elements of fourth-generation
27 of 45
languages are generally similar to database languages and report writers, and thus do not
represent a new nonprocedural concept. …
4.1.2 Domains of Application
4.1.2.1 [Machine-oriented: Machine and Assembly/Assembler Languages]
4.1.2.2 Problem-oriented
… it seems that the most effective use of this term is to encompass any language that is
easier for writing solutions to a particular problem than assembly language would be. …
a general catchall phrase. However, it is worth noting that many other people use the term
to refer to languages for very specialized application areas. [Also, see Nonprocedural
languages, above]
4.1.2.3 Application-oriented
… In reality, all languages are application oriented, but some are for larger or smaller
application areas than others.
For example, Fortran is primarily useful for numerical scientific problems,
whereas Cobol is best suited for business data processing.
On the other hand, PL/I and Ada are useful in both those application areas, and therefore
have a wider area of application.
4.1.2.3.1 General Purpose
sometimes used for PL/I and Ada (and even for Fortran), although in the author’s opinion
there is no truly general-purpose programming language.
4.1.2.3.2 Application areas sufficiently wide and important to justify particular
consideration:
4.1.2.3.2.1 numerical and nonnumerical (i.e. formal algebraic) scientific applications
4.1.2.3.2.2 business data processing
4.1.2.3.2.3 string and list processing
4.1.2.3.3 Special-Application-Oriented
Subjects other than these [above] (or combinations of them) seem to be more specialized
(e.g., graphics, simulation, machine-tool control, equipment checkout, robotics, expert
systems). Languages for application areas other than those defined as fairly general
should be called “special-application-oriented”. …
28 of 45
4.1.2.3.4 Special-purpose language
one designed to satisfy a single objective. The objective might involve the application
area, the ease of use for a particular application, or pertain to efficiency of the compiler or
the object code.
4.1.3 Problem-defining = Specification Language
one that literally defines the problem and may specifically define the desired input and
output, but it does not define the method of transformation. There are significant differences among a problem (and its definition), the method (or procedure) used to solve it,
and the language in which this method is stated.
4.2 Janossy/Samuels Taxonomy (CICS/ESA Primer, 1995, pp. 89)
Although there is no necessary connection between the traditional architecture [see Processing Modes, above] and the nature of programming tools used to build systems, the
chronology of software development has caused some de facto associations between architecture and software. Traditional /mainframe/minicomputer/ “production” systems (those
strategic applications run on a frequent periodic or continuous basis) tend to be constructed of procedural, third generation languages such as COBOL or PL/I, and are supported
by indexed files, hierarchical (IMS), network (IDMS), or relational (DB2) databases. A
procedural language forces the user to think through and encode every processing action
needed to achieve an end purpose, such as every file access, processing sequence, and
action. A nonprocedural language, on the other hand, allows the user to focus on input
and output, while the nonprocedural language [programming environment] handles the
processing analysis.
Except for DB2/SQL [which, by the way, many authors consider to be nonprocedural],
procedural software suffers from significant inflexibilities. The software development
lead times of third generation languages can appear excessive when contrasted with programming time requirements of modern nonprocedural languages on microcomputers. …
Programming in a modern nonprocedural language and sharing processing tasks between
a host computer and powerful but inexpensive desktop equipment is a natural direction to
explore.
4.3 Eric Lebherz Taxonomy (“Hypernews Computer Language
List”—
http://www.hypernews.org/HyperNews/get/computing/langlist.html)
4.3.1 Procedural
which states how to compute the result of a given problem. Each statement in the language tells the computer to do something. A procedural program is “a list of instructions”. Encompasses both imperative and functional languages.
29 of 45
4.3.1.1 Imperative
operates by a sequence of commands that change the value of data elements. Typified by
assignments and iteration.
4.3.1.1.1 Assembly
a symbolic representation of the machine language of a specific computer
4.3.1.2 Functional (in the narrow sense)
operates on higher-order functions, building operators that manipulate functions directly
without ever appearing to manipulate the data
4.3.2 Declarative
operates by making descriptive statements about data and relations between data. The
algorithm is hidden in the semantics of the language. This category encompasses both
Applicative and Logic languages. Examples of declarative features are set comprehensions and pattern-matching statements.
4.3.2.1 Applicative (a functional language in the broad sense)
operates by application of functions to values
4.3.2.1.1 Definitional
an applicative language containing assignments interpreted as definitions
4.3.2.1.2 Single Assignment
an applicative language using assignments with the convention that the variable may appear on the left side of an assignment only once within the portion of the program in
which it is active
4.3.2.1.2.1 Dataflow
language suitable for use on a dataflow architecture. Necessary properties include freedom from side effects, and the equivalence of scheduling constraints with data dependencies. Examples: Val, Id, SISAL, Lucid.
4.3.2.2 Logic
deals with predicates or relationships. Logic languages try alternatives for each goal in
succession, backtracking in a search for a common solution.
4.3.2.2.1 Constraint
languages in which a problem is specified and solved by a series of constraining relationships
4.3.3 Concurrent
describes programs that may be executed in parallel. This may be either: multiprogramming, sharing one processor, multiprocessing—separate processors sharing one memory
distributed.
30 of 45
4.3.4 Intermediate
a language used as an intermediate stage of compilation. May be text or binary.
4.3.5 Metalanguage
a language used for the formal description of another language
4.3.6 Query
an interface to a database
4.3.7 Specification
a formalism for expressing a hardware or software design.
4.4 http://cliki.tunes.org/Programming%20Languages
4.4.1 Actor
The actor paradigm is a term for modelling computation with concurrent (possibly transparently-distributed) entities, the actors, that communicate with asynchronous messages.
Actors may update their behaviour depending on the messages they receive.
See the pioneering works by Carl Hewitt, the developments by his successor Gul Agha,
or by other fine people like Akinori Yonezawa. Actors have been rediscovered twenty
years later by formal-methods people, yielding the join calculus. They have also been rediscovered by the industry, and a nice language that robustly implements the actor model
is Erlang.
Actors are the real thing of which object-oriented programming is the caricature. When
people say that OOP is based on an "intuitive" modelling of the world as objects in interaction, the intuition they invoke is the Actor model, but the actual model is a lessexpressive version where only one object is active at a time, with a linear flow of control.
Pages in this topic: Salsa NetCLOS
4.4.2 Collection-Oriented
The term for a paradigm of programming that involves operations on entire collections
and avoids loops. Note that programming languages adherents to this paradigm are intrinsically suitable to both sequential and parallel/distributed execution.



Jay Sipelstein, Guy E. Blelloch, Collection-Oriented Languages , Proceedings of
the IEEE, April 1991 (and CMU-CS-90-127).
Sergei Gorlatch, Christoph Wedler, Christian Lengauer Optimization Rules for
Programming with Collective Operations , IPPS/SPDP'99, 1999.
skeletons archive (Bird-Meertens Formalism, functional data-parallelism) .
31 of 45


A book: Arrays, Functional Languages and Parallel Systems Lenore M. Restifo
Mullin, Michael Jenkins, Gaetan Hains, Robert Bernecky, Guang R. Gao October
1991, Kluwer, ISBN 0-7923-9213-2, Hardbound.
Dr. Clemens Grelck 's Virtual Bookshelf , with a bibliography of papers related to
collection-oriented techniques, notably:
o Array Theory ;
o Dense Arrays ;
o Implementation of Arrays .
A list of collection-oriented programming languages:

















A+
AML
APL
Claire
FALCON
FISh
Glee
J
K
NESL
NIAL
Q shell
R
SAC
SETL
SPARCL
{log}
Pages in this topic: SPARCL SETL SAC R Q shell NIAL NESL K J Glee
FISh FALCON Claire APL AML A+ {log}
Also linked from: Haskell
4.4.3 Functional
Functional Programming is the term for a powerful paradigm for programming that originates in the early works about lambda calculus: computations consist in evaluating/expanding structured expressions, rather than executing instructions, as with imperative programming.
Because functional programming has such simple semantics, it makes proving correctness of programs, to manipulate programs, to parallelize them, etc., relatively easy.
32 of 45
Functional perspectives work when there is a logical perspective that permits encapsulating side effects as results within some context or system; consequently the benefits described here are not trivial to achieve.










Why Functional Programming Matters , a famous essay explaining how higherorder functions and lazy evaluation can help in creating modular, well-designed
programs, including examples.
LtU's functional programming topic .
The FAQ for comp.lang.functional
Claus Reinke's own little FP link
Real-World uses of functional programming languages.
The Journal of Functional Programming
There are fine functional programming groups at Glasgow , St Andrews,
Rocquencourt, etc.
the SEL-HPC Functional Programming Archive
Purely Functional Data Structures , a great book by [Chris Okasaki]?.
John Hughes' collection of tutorials .
Pages in this topic: Sisal Scheme SAC RELFUN Qi Q Pike OCAML
O'Haskell Needle NIAL NESL ML Lisp Lemon LIFE Joy JoCaml Hobbit
Haskell Functional and Object-Oriented Forth FISh Escher Erlang Eden Curry
Coq Clean Clarity Claire Charity Cayenne Category Theory Bla Better Scheme
Amiga E Alice Aleph ALF
Also linked from: C++ Concatenative Syntax Continuation Continuation-Passing
Style Declarative Dispatch Eugenio Moggi Fortran fxm Lambda Prolog Lambda
VM Linear Logic Comments Microkernel Debate Monad PL 101 Python Referential Transparency and State Simon Peyton Jones
4.4.4 Imperative
The term for a paradigm of programming that involves (mostly unconstrained) update of
the state of a machine through direct instructions.
The vast majority of programmers seemingly prefer to use computers this way.
Pages in this topic: NIAL FISh Claire
Also linked from: Functional Referential Transparency and State
4.4.5 Logic
Logic Programming is the term for a paradigm of programming that originates in the Curry-Howard Isomorphism, which relates types and proofs to terms and expressions. In
most cases, logical deduction or inference is equated with term evaluation or state update.
33 of 45



Logic Programming at The WWW Virtual Library .
Formal logic via functional programming : a dissertation.
Termination inference , a kind of program analysis for logic programs.


Schelog3 [MIA].
SPIKE . From its readme:
The SPIKE system is an automatic theorem prover in theories presented by conditional equations. SPIKE was written in Caml Light, a functional language of the
ML family.
Pages in this topic: Yarrow TyRuBa SPARCL Prolog NuPrl Mercury Maude
Lambda Prolog LIFE Goedel Escher Dynamo Curry Claire CafeOBJ
ASF+SDF ALF
Also linked from: Alan Bundy Axiom of Choice BOBJ Constraints Declarative
Induction and Co-induction Janus NCL OBJ Family Quotienting Referential
Transparency and State Scheme
4.4.5.1 Constraints
The term for a paradigm related to logic or declarative programming, where information
is specified as a constraint on the result, and the evaluator's task is to use this information
to limit the search space that some base set of algorithms would ordinarily have traversed
to find the answer.
Constraints-based programming languages are not as common as constraints-solving libraries, since in the general case there is no systematically-reliable approach to this kind
of evaluation style.
Generally, constraints are an interesting type of annotation.






Constraint Logic Programming a short introductory article from BYTE magazine.
Constraints Archive .
constraint.org - A Site for Constraint Programming.
Guide to Constraint Programming .
The Constraint Computation Center (CCC) .
The Language List: constraint at Computer Science Department (Centre Universitaire d'Informatique - CUI), University of Geneva, no longer manteined but useful.

UW Cassowary Constraint Solving Toolkit .
34 of 45
Pages in this topic: Screamer SPARCL NCL Morphe LIFE Janus Goedel AKL
Also linked from: Alice Garnet Microkernel Debate Mozart/Oz Type Systems Varieties
4.4.6 Object-Oriented
A paradigm of programming.
There's a craze about any new software using the term "Object-Oriented". But if you ask
people what it means to be "OO", most won't be able to tell anything, because it's only a
buzzword.
The meaningful ideas that have to be isolated and distinguished behind this fad are that of
having a unified way to manipulate objects, but few understand it even partially, and even
fewer are those fully conscious of what it means.
Another buzzword associated to "OO" is inheritance, often incorrectly presented as the
essence of "OO" design, whereas it is only a braindead special-case way of organizing
objects, often done with a lot of confusion.
Typical confusion in "OO" approaches are between (constant) values and (variable) stateholders, between (semantical) objects and (meta-semantical) environments, between
(specificational) abstraction level and (implementational) dispatch-time (run-time vs
compile-time), etc. In a sane design, these concepts would be distinguished and made orthogonal; they would not even intervene at all at the same place in the semantics.
For instance, most "OO" languages (like Java, C++) can't distinguish the notion of a constant, absolute, value, as soon as this value is not "atomic" in the hardware (a curious limitation for alleged "high-level" languages); all objects are then modifiable records, which
leads to all kinds of unsafety, bugs, and contortions when manipulating putatively constant recursive structures.
Languages with single-dispatch (among which are C++ and Java again) also confuse the
objects being manipulated with the environment in which they are manipulated; they
force the programmer to define the semantics of "an integer", or "a polynomial", whereas
anyone with a little background in formal mathematics knows that an isolated integer or
polynomial has no meaning; only the set of integers, or the set of polynomials, has meaning. More generally, isolated objects mean nothing, only structured sets of objects do; and
these language don't allow to manipulate those sets, to describe their properties. Languages with multiple dispatch, such as CLOS or Cecil, do a better job of not associating
environments to objects.
Even with multiple dispatch, all the widespread OO languages have a unique global environment to dispatch (multi)methods according to objects' class. This means that there is
only one fixed way of looking at objects, whereas mathematicians will also tell you how
35 of 45
the interesting properties of structures lie in the infinity of ways to isomorphically reformulate them. The only way round this unicity of view is the explicit wrapping of objects
into new classes; but most languages do not allow generic wrappers, and/or impose restrictions in the specification and implementation of wrapped objects.
Kent M. Pitman has written a great essay about object-orientation as a term, What's in a
name? Uses and Abuses of Lisp Terminology within his set of articles, ParentheticallySpeaking.
For true OO languages, see CLOS, Beta, Dylan, Self, Smalltalk, Java, OCAML.
For languages with true OO extensions, see Lisp, Perl, Scheme, Forth.
For false OO languages, see Ada, C++, Visual BASIC, Simula.




The great Cetus links .
Bob Hathaway's OO FAQ .
The FOOL workshop proceedings.
Copying and Comparing: Problems and Solutions , a paper dealing with the issue
of identity and value semantics in the paradigm.
Pages in this topic: kew TOM Slate Simula Self Ruby Python Pike Obliq Objective-C OCAML O'Haskell NetCLOS Needle Mozart/Oz Morphe LIFE
LENS Io Hobbit Haskell Goo Functional and Object-Oriented Ellie Eiffel Eidola E Dylan Claire Cecil CLOS Amiga E Agora ABCL
Also linked from: Actor Aldor Benjamin J. Pierce C++ CLIM Combining Languages Dispatch FramerD Hidden Algebra Java Luca Cardelli Object OO
OZONE RbCl Scheme Unified Unity Project XOS
4.4.7 Relational
The term for a paradigm of programming where relationships between objects are formalized as Relation objects. The few languages in this category generally adhere to relational
algebra or some subset of it.


The Relational Methods in Computer Science ("RelMiCS") home page .
RATH , a Relational Algebra Toolkit in Haskell, which also covers more general
things like category theory concepts.
Pages in this topic: RELFUN Libra
Also linked from: Feature-Oriented Programming
36 of 45
4.5 www.DMOZ.org/Computers/Programming/Languages
strong similarity to Google web directory Computers > Programming > Languages
4.5.1 Imperative = Procedural
4.5.2 Declarative
4.5.2.1 Constraint
4.5.2.1.1 Constraint Logic
4.5.2.2 Dataflow
4.5.2.3 Functional
4.5.2.3.1 Functional Logic
4.5.2.3.2 Spreadsheets
4.5.2.4 Logic-based
4.5.2.4.1 Constraint Logic
4.5.2.4.2 Functional Logic
4.5.3 Concurrent
4.5.4 Distributed -> Parallel Computing: Programming: Languages
4.5.5 Multiparadigm
4.5.6 Obfuscated
4.5.7 Specification Languages (related to Functional & Logic-based)
4.5.8 Markup Languages
37 of 45
4.6 Chris Reade on Functional vs. Procedural Programming
(http://www.kingston.ac.uk/~ku07009/MLWorkshop/start.htm
l)
4.7 Nick V. Scherbakov on Software Architecture
(http://coronet.iicm.edu/sa/)
4.8 Neal Ziring’s “Dictionary of Programming Languages”
(http://cgibin.erols.com/ziring/cgi-bin/cep/cep.pl)
4.9 Chris Wild on the “Windows Programming Model”
(http://www.cs.odu.edu/~wild/windowsNT/Spring00/progMod
el.htm)
4.10 Julia Case Bradley & Anita C. Millspaugh (Programming in
Visual Basic 6.0, 1999, Ch. 1, “Programming Languages—
Procedural, Object Oriented, and Event Driven”, pp. 3ff)
4.10.1
[Procedural]
There are literally hundreds of programming languages. Each was developed to solve a
particular type of problem. Most traditional languages, such as BASIC, C, COBOL,
FORTRAN, PL/I, and Pascal, are considered procedural languages. That is, the program
specifies the exact sequence of all operations. Program logic determines the next instruction to execute in response to conditions and user requests.
38 of 45
5 Taxonomies of Programming Methodologies
5.1 Google web directory Computers > Programming > Methodologies
5.1.1 Structured
5.1.2 Object-Oriented (& related)
5.1.2.1 Refactoring
5.1.2.2 Patterns & Anti-Patterns
5.1.2.3 Prototype Based
5.1.2.4 Aspect-Oriented
5.1.2.4.1 Reflective (related to Functional Programming Language Paradigm)
5.1.3 Literate Programming
5.1.4 Modeling Languages
5.1.5 Unified Process
5.1.6 Genetic
5.2 Encyclopedia of Computer Science, 3rd ed, 1993
5.2.1 Modular Programming (Daniel D. McCracken)
A program or system module can be defined as a logically self-contained and discrete
part of a larger program. A complete program can thus be considered to be a collection of
modules. A properly constructed module accepts input that is well defined as to content
and structure, carries out a well-defined set of processing actions, and produces output
that is well defined as to content and structure. A properly constructed module, as the
term is normally used, has only one entry point and only one exit point. If it is a subroutine, it always returns only to the statement following the one that called it into play.
[That is, we speak here of “named” or “out-of-line” modules.] …
5.2.2 Structured Programming (SP) (Edwin D. Reilly)
may be defined as a methodological style whereby a computer program is constructed by
concatenating or coherently nesting logical subunits that either are themselves structured
programs or else are of the form of one or another of a small number of particularly wellunderstood control structures. [Here we speak of “unnamed in-line” modules.] Such a
definition is inherently and deliberately recursive. …
39 of 45
[This is commonly understood to be a form of discipline imposed on high-level procedural programming languages. However, non-procedural programming languages commonly provide alternative forms of control structures that provide the effects of selection,
repetition (usually via recursion rather than iteration or looping), and only such sequencing as may be required by the specification of the problem (for example, nesting or operator precedence).]
5.2.3 Object-Oriented Programming (Peter Wegner)
A programming language is said to be object-based if it supports objects as a language
feature, and is said to be object-oriented if, additionally, objects are required to belong to
classes that can be incrementally modified through inheritance. …
Before defining the key notions of objects, classes, and inheritance, we will indicate some
general features of the object-oriented paradigm. the essence of object-oriented programming is the hiding or encapsulation (q.v.) of the “inner” state of entities and the
specification of interactive properties of entities by an interface of operations (the events
in which they may participate). This separates the inner functioning of entities like banks,
airplanes, or people from their external behavior in interacting with other entities. This
separation is realized by partitioning the state into chunks associated with objects so that
each chunk is responsible for its own protection against access by unauthorized operations. …
Early programmers thought of programs as instruction sequences. Procedure-oriented
languages (q.v.) introduced procedural abstractions that encapsulate sequences of actions
into procedures. Object-oriented languages encapsulate data as well as sequences of actions, providing a stronger encapsulation mechanism than procedures and, consequently,
a more powerful modeling tool. Both procedures and objects are server modules that may
be called by clients to determine a stimulus/response behavior in interacting with their
environment. The role of procedures is to transform input data specified by parameters
into values, while the role of objects is to serve as a repository of data (the current system
state) and to respond in a manner determined by the current system state. For example,
the response of a bank to a withdrawal request depends on the value of the current balance. Object-oriented programming is a modeling paradigm that models objects of the
real world by collections of interacting objects of a programming system.
The procedure-oriented paradigm has strong organizing principles for managing actions
and algorithms, but has weak organizing principles for managing shared data, while object-oriented systems organize data by restricting applicable operations to those associated with a specific object or class. Inheritance provides a second layer of structure by
structuring classes into hierarchies. We can think of classes as a mechanism for classifying objects into categories with similar interface behavior, and inheritance as a mechanism for classifying classes by factoring out properties common to several subclasses into
a superclass. …
5.2.4 Literate Programming (Harold Thimbleby)
Literate programming is a system of combining program and internal documentation so
that they may be co-developed with ease. A literate programming system provides automatic aids to readability such as substantial cross-referencing, indexing, and pretty-
40 of 45
printing. Special macro processing allows the program to be written in any order to improve and simplify the exposition. Macros are numbered automatically so that their usage
is easily cross-referenced. …
5.3 Joyce Farrell Taxonomy (Programming Logic and Design,
2nd ed., 2002, Ch. 12, p. 356ff)
5.3.1 An Overview of Object-Oriented Programming
Object-oriented programming is a style of programming that focuses on an application’s data and the methods you need to manipulate that data. Object-oriented programming uses all of the concepts you are familiar with from modular procedural programming, such as variable, modules, and passing values to modules. Modules in objectoriented programs continue to use sequence, selection, and looping structures and make
use of arrays. However, object-oriented programming adds several new concepts to programming and involves a different way of thinking. There’s even a considerable amount
of new vocabulary involved.
5.4 Julia Case Bradley & Anita C. Millspaugh (Programming in
Visual Basic 6.0, 1999, Ch. 1, “Programming Languages—
Procedural, Object Oriented, and Event Driven”, pp. 3ff)
5.4.1 [Object-oriented programming &] the Object Model
The newer programming languages, such as C++ and Visual BASIC, us a different approach [from the “procedural” languages]: object-oriented programming (OOP) and
event-driven programming [see above]. Microsoft refers to Visual BASIC as an eventdriven programming language, which has many (but not all) elements of an objectoriented language such as Java. Each release of Visual BASIC moves it a little closer to a
true object-oriented language.
In Visual BASIC you will work with objects, which have properties and methods.
5.4.1.1 Objects
Think of an object as a thing, or a noun. Examples of objects are forms and controls.
Forms are the windows and dialog boxes you place on the screen; controls are the elements you place inside a form, such as text boxes, command buttons, and list boxes.
5.4.1.2 Properties
Properties tell something about an object, such as its name, color, size, location, or how it
will behave. You can think of properties as adjectives that describe objects. [These are
often also called “attributes”.]
When you refer to a property, you first name the object, add a period, and then name the
property. For example, refer to the Caption property of a form called Form1 as
Form1.Caption (say “form1 dot caption”).
41 of 45
5.4.1.3 Methods
Actions associated with objects are called methods. Methods are the verbs of objectoriented programming. Some typical methods are Move, Print, Resize, and Clear.
You refer to methods as Object.Method (“object dot method”). For example, a Print
method can apply to different objects. Printer.Print sends the output to the printer
object; Form1.Print sends output to the form called Form1.
5.5 Art Gittleman (Computing with Java™: Programs, Objects,
Graphics: Alternate Second Edition, 2002, “1.5 Procedural
vs. Object-Oriented Programming”, pp. 18 ff.)
We contrast two styles of programming, procedural and object-oriented. Java supports
them both. The newer object-oriented style models our everyday intuition and if used
well, can make software more reusable and easier to maintain.
5.5.1 Procedural Programming
Procedural programming emphasizes the procedures used to manipulate the data. … As
programmers, we would spend our time writing code to implement these operations, giving much less regard to the data. [Maybe!]
The Big Picture: In a procedural program, expect to see lots of logic used to test the data
and do different operations depending on the type of the data. …
5.5.1.1 Focus on the procedures needed to solve the problem.
5.5.1.2 Separate functions and data.
5.5.1.3 Must check many cases to deal with different types of data.
5.5.2 Object-Oriented Programming
By focusing on the data more, object-oriented programming alleviates many of these
problems [and complexities with procedural programming of adapting procedures to ever
more types and variation of data].
Object-oriented programming combines data and procedures into an object [or object
class] that has its own attributes and behavior. … The object invokes one of its behaviors,
in contrast to the procedural approach in which a procedure operates on data.
The Big Picture: … In an object-oriented program, expect to see a type [or object class]
definition that defines permissible operations for objects of that type [or class]. Much of
the program will consist of objects invoking one another’s behaviors.
5.5.2.1 Focus on the objects needed to solve the problem.
5.5.2.2 Combine data and operations in objects.
5.5.2.3 Leave it to objects to provide the correct operations for their type.
42 of 45
6 Taxonomies of Problem Analysis and Program Design Methodologies
These categories have to do with the larger issue of how particular computer programs
(software) are developed in response to particular “problems” and requirements. As you
may gather from similarities in naming, these categories often have a close association
with some of the above Programming Methodologies. Historically, they were often an
outgrowth of the above categories. However, this set of methodologies deals with more
“strategic” programming issues, while the above deal with more “tactical” issues, such as
what particular set of facilities a programming language may provide.
6.1 D. S. Malik (C++ Programming: Program Design Including
Data Structures, 2002, Ch. 1, pp 10ff)
For some problems, the structured design approach to program design will be very effective. Other problems will be better addressed by OOD [see below]. For example, if a
problem requires manipulating sets of numbers with mathematical functions, you might
use the structured design approach and outline the steps required to obtain the solution.
… On the other hand, if you want to write a program that would make a candy machine
operational, the OOD approach is more effective. C++ was designed especially to implement OOD. Furthermore, OOD works well and is used in conjunction with structured
design.
Both the structured design and OOD approaches require that you master the basic components of a programming language to be an effective programmer.
6.1.1 Programming with the Problem Analysis—Coding—Execution
Cycle [Structured Design]
Programming is a process of problem solving. Different people use different techniques
to solve problems. Some techniques are nicely outlined and easy to follow. They not only
solve the problem, but also give insight into how the solution was reached. These problem-solving techniques can be easily modified if the domain of the problem changes.
To be a good problem solver and hence to become a good programmer, you must follow
good problem-solving techniques. One common problem-solving technique includes analyzing a problem, outlining the problem requirements, and designing steps, called an algorithm, to solve the problem.
Algorithm: A step-by-step problem-solving process in which a solution is arrived at in a
finite amount of time. [Here we are talking about the steps that a program will do, not the
steps that the programmer must go through to come up with those algorithm steps.]
In the programming environment, a problem-solving process requires the following three
steps [steps that the programmer must go through]:
1. Analyze the problem, outline the problem and its solution requirements, and design an algorithm to solve the problem.
2. Implement the algorithm in a programming language, such as C++, and verify
that the algorithm works.
3. Maintain the program by using and modifying it if the problem domain changes.
43 of 45
To develop a program to solve a problem, you start by analyzing the problem. You
then design the algorithm; write the program instructions in a high-level language, or
code the program; and enter the program into a computer system. Analyzing the problem is the first and most important step. This step requires that you do the following:
1. Thoroughly understand the problem.
2. Understand the problem requirements. Requirements can include whether the
program requires interaction with the user, whether it manipulates data, whether it
produces output, and what the output looks like. If the program manipulates data,
the programmer must know what the data is and how it is represented. That is,
you need to look at sample data. If the program produces output, you should know
how the results should be generated and formatted.
3. If the problem is complex, divide the problem into subproblems and repeat Steps
1 and 2. That is, for complex problems, you need to analyze each subproblem and
understand each subproblem’s requirements.
Dividing a problem into smaller subproblems is called structured design [compared
with “structured programming”, above]. The structured design approach is also
known as top-down design, stepwise refinement, and modular programming [but
beware of other more specialized definitions of these terms]. In structured design, the
problem is divided into smaller problems. Each subproblem is then analyzed, and a
solution is obtained to solve the subproblem. The solutions of all subproblems are
then combined to solve the overall problem. This process of implementing a structured design is called structured programming [but, again, be aware of the more
specialized definition of this term with respect to the three programming structures:
sequence, selection, and repetition].
After you carefully analyze the problem, the next step is to design an algorithm to
solve the problem. If you broke the problem into subproblems, you need to design an
algorithm for each subproblem. Once you design an algorithm, you need to check it
for correctness. You can sometimes test an algorithm’s correctness by using sample
data. At other times, you might need to perform some mathematical analysis to test
the algorithm’s correctness.
Once you have designed the algorithm and verified its correctness, the next step is to
convert the equivalent code into the high-level language. …
The final step is to execute the program. The compiler guarantees only that the program follows the language’s syntax. It does not guarantee that the program will run
correctly. …
As you can see, you need to do a lot of work before attempting to write programming
instructions. Usually, you do this work on paper using a pen or pencil. Taking this
careful approach to programming has a number of advantages. It is much easier to
discover errors in a program that is well analyzed and well designed. Furthermore, a
thoroughly analyzed and carefully designed program is much easier to follow and
modify. Even the most experienced programmers spend a considerable amount of
time analyzing a problem and designing an algorithm.
44 of 45
6.1.2 Object-Oriented Programming
The previous section discussed the structured design programming methodology. This
section briefly describes a programming methodology called object-oriented design
(OOD), the use of which is very widespread.
In OOD, the first step in the problem-solving process is to identify components called
objects, which form the basis of the solution, and determine how these objects interact
with one another. For example, suppose you want to write a program that automates the
video rental process for a local vide store. The two main objects in this problem are the
video and the customer. [Note that something akin to this step must also take place in
older design methodologies, as well, but usually not in such a clearly defined and standardized way.]
After identifying the objects, the next step is to specify for each object the relevant data
and possible operations to be performed on that data. For example, for a video object, the
data might include the movie name, starring actors, producer, production company, number of copies in stock, and so on. Some of the operations on a video object might include
checking the name of the movie, reducing the number of copies in stock by one after a
copy is rented, and incrementing the number of copies in stock by one after a customer
returns a particular video. [Note that identifying data, and grouping it into records and
files of various types, etc, where possible, is also a part of older methodologies. However,
the development of algorithms is then associated with the top-down analysis of the particular problem, more than with particular data, record, or file types. Because algorithms
are developed in conjunction with objects and object classes, and then combined to solve
larger problems, OOD is sometimes called a “bottom-up” design approach. Other bottom-up approaches pre-date OOD. However, they were mostly limited to the development of libraries of commonly used algorithms or functions which were bound to very
simple data types that were acted upon by the algorithms or functions—much more limited than the OOD approach.]
This illustrates that each object consists of data and operations on that data. An object
combines data and operations on the data into a single unit. In OOD, the final program is
a collection of interacting objects. A programming language that implements OOD is
called an object-oriented programming (OOP) language [see above.]
Because an object consists of data and operations on that data, before you can design and
use objects, you need to learn how to represent data in computer memory, how to manipulate data, and how to implement operations. [This is true of older design methodologies
as well.]
To create [object-oriented] operations, you write algorithms and implement them in a
programming language [again, similar to older design methodologies].
ARR 2003/07/22
45 of 45