www.DMOZ.org/Computers/Programming/Languages

4.5www.DMOZ.org/Computers/Programming/Languages

strong similarity to Google web directory Computers > Programming > Languages

4.5.1Imperative = Procedural

4.5.2Declarative

4.5.2.1Constraint

4.5.2.1.1Constraint Logic

4.5.2.2Dataflow

4.5.2.3Functional

4.5.2.3.1Functional Logic

4.5.2.3.2Spreadsheets

4.5.2.4Logic-based

4.5.2.4.1Constraint Logic

4.5.2.4.2Functional Logic

4.5.3Concurrent

4.5.4Distributed -> Parallel Computing: Programming: Languages

4.5.5Multiparadigm

4.5.6Obfuscated

4.5.7Specification Languages (related to Functional & Logic-based)

4.5.8Markup Languages

4.6Chris Reade on Functional vs. Procedural Programming (http://www.kingston.ac.uk/~ku07009/MLWorkshop/start.html)

4.7Nick V. Scherbakov on Software Architecture (http://coronet.iicm.edu/sa/)

4.8Neal Ziring’s “Dictionary of Programming Languages” (http://cgibin.erols.com/ziring/cgi-bin/cep/cep.pl)

4.9Chris Wild on the “Windows Programming Model” (http://www.cs.odu.edu/~wild/windowsNT/Spring00/progModel.htm)

4.10Julia 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.

5Taxonomies of Programming Methodologies

5.1Google web directory Computers > Programming > Methodologies

5.1.1Structured

5.1.2Object-Oriented (& related)

5.1.2.1Refactoring

5.1.2.2Patterns & Anti-Patterns

5.1.2.3Prototype Based

5.1.2.4Aspect-Oriented

5.1.2.4.1Reflective (related to Functional Programming Language Paradigm)

5.1.3Literate Programming

5.1.4Modeling Languages

5.1.5Unified Process

5.1.6Genetic

5.2Encyclopedia of Computer Science, 3^rd ed, 1993

5.2.1Modular 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.2Structured 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 well-understood control structures. [Here we speak of “unnamed in-line” modules.] Such a definition is inherently and deliberately recursive. …

[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.3Object-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.4Literate 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-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.3Joyce Farrell Taxonomy (Programming Logic and Design, 2^nd ed., 2002, Ch. 12, p. 356ff)

5.3.1An 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 object-oriented 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.4Julia 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 event-driven programming language, which has many (but not all) elements of an object-oriented 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.1Objects

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.2Properties

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”).

5.4.1.3Methods

Actions associated with objects are called methods. Methods are the verbs of object-oriented 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.5Art 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.1Procedural 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.1Focus on the procedures needed to solve the problem.

5.5.1.2Separate functions and data.

5.5.1.3Must check many cases to deal with different types of data.

5.5.2Object-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.1Focus on the objects needed to solve the problem.

5.5.2.2Combine data and operations in objects.

5.5.2.3Leave it to objects to provide the correct operations for their type.

6Taxonomies 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.1D. 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.1Programming 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.
   

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.

6.1.2Object-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

of