programming paradigm 

A programming paradigm is a fundamental style of computer programming, serving as a way of building the structure and elements of computer programs. Capabilities and styles of various programming languages are defined by their supported programming paradigms; some programming languages are designed to follow only one paradigm, while others support multiple paradigms.

Programming paradigms that are often distinguished include imperative,declarative, functional, object-oriented, procedural, logic and symbolic programming. With different paradigms, programs can be seen and built in different ways; for example, in object-oriented programming, a program is a collection of objects interacting in explicitly defined ways, while in declarative programming the computer is told only what the problem is, not how to actually solve it.

Object-oriented programmingFollowing the widespread use of procedural languages, object-oriented languages like Simula, Smalltalk, C++, C#, Eiffel and Java were created. In these languages, data and methods of manipulating the data are kept as a single unit called an object. The only way that a user can access the data is via the object's "methods"; as a result, the inner workings of an object may be changed without affecting any code that uses the object. There is still some controversy raised by Alexander Stepanov, Richard Stallman[8] and other programmers, concerning the efficacy of the OOP paradigm versus the procedural paradigm. The necessity of every object to have associative methods leads some skeptics to associate OOP with software bloat. Polymorphism was developed as one attempt to resolve this dilemma.

Because object-oriented programming is considered a paradigm, not a language, it is possible to create even an object-oriented assembler language. High Level Assembly (HLA) is an example of this that fully supports advanced data types and object-oriented assembly language programming – despite its early origins. Thus, differing programming paradigms can be thought of as more like "motivational memes" of their advocates – rather than necessarily representing progress from one level to the next. Precise comparisons of the efficacy of competing paradigms are frequently made more difficult because of new and differing terminology applied to similar entities and processes together with numerous implementation distinctions across languages.

Structured programming

Structured programming is a programming paradigm aimed at improving the clarity, quality, and development time of a computer program by making extensive use of subroutines, block structures and for and while loops—in contrast to using simple tests and jumps such as

the goto statement which could lead to "spaghetti code" which is difficult both to follow and to maintain.

It emerged in the late 1950s with the appearance of the ALGOL 58 and ALGOL 60 programming languages, with the latter including support for block structures. Contributing factors to its popularity and widespread acceptance, at first in academia and later among practitioners, include the discovery of what is now known as the structured program theorem in 1966,[1] and the publication of the influential "Go To Statement Considered Harmful" open letter in 1968.[2]

Structured programming is most frequently used with deviations that allow for clearer programs in some particular cases, such as when exception handling has to be performed.

functional programming 

In computer science, functional programming is a programming paradigm—a style of building the structure and elements of computer programs—that treats computation as the evaluation of mathematical functions and avoids changing-state and mutable data. It is a declarative programming paradigm, which means programming is done with expressions. In functional code, the output value of a function depends only on the arguments that are input to the function, so calling a function f twice with the same value for an argument x will produce the same result f(x) each time. Eliminating side effects, i.e. changes in state that do not depend on the function inputs, can make it much easier to understand and predict the behavior of a program, which is one of the key motivations for the development of functional programming.

Functional programming has its roots in lambda calculus, a formal system developed in the 1930s to investigate computability, the Entscheidungs problem, function definition, function application, and recursion. Many functional programming languages can be viewed as elaborations on the lambda calculus. Another well-known declarative programming paradigm, logic programming, is based on relations.[1]

as Mathematica), Racket,[9] Erlang,[10][11][12]OCaml,[13][14] Haskell,[15][16] and F#[17][18] have been used in

functional style. The Julia language also offers functional programming abilities. An interesting case is that of Scala[26] – it is frequently written in a functional style, but the presence of side effects and mutable state place it in a grey area between imperative and functional languages.

Process-oriented programming 

Process-oriented programming is a programming paradigm that separates the concerns of data structures and the concurrent processes that act upon them. The data structures in this case are typically persistent, complex, and large scale - the subject of general purpose applications, as opposed to specialized processing of specialized data sets seen in high productivity applications

(HPC). The model allows the creation of large scale applications that partially share common data sets. Programs are functionally decomposed into parallel processes that create and act upon logically shared data.

The paradigm was originally invented for parallel computers in the 1980s, especially computers built with transputer microprocessors by INMOS, or similar architectures. It evolved to meet deficiencies in the message passing paradigm of Occam and enable uniform efficiency when porting applications between distributed memory and shared memory parallel computers.

The first example of the paradigm appears in the programming language Ease designed at Yale University[1][2] in 1990. Similar models have appeared since in the loose combination of SQL databases and objected oriented languages such as Java, often referred to as object-relational models and widely used in large scale distributed systems today. The paradigm is likely to appear on desktop computers as microprocessors increase the number of processors (multicore) per chip.

Program development stepsTo begin with, writing a program involves several steps (we will consider others in the future):

1. Define the external specification including the user interface and event handlers2. Build the user interface3. Code event handlers and write common code4. Debug the program5. Document the program

We will discuss some of these now, and return to others later.

1. The first, most important and creative step is defining the external specification of the program. You cannot write the instructions for doing something until you know what it is you want done, so before you start writing a program, you need a clear picture of what it will do when it is finished. You have to imagine it running -- what does the screen look like? What actions can the user take? What happens when he or she takes each of those actions?

This step is analogous to an architect imagining then drawing pictures and plans for a house to be built. When the architect finishes, he or she turns the plans over to a building contractor who constructs the house. If the plans were complete and well written, the house will come out as the architect imagined it.

Similarly the external description of a program should give enough detail that a programmer could use it to write the program as you envisioned it.

You should prepare a written description, an external specification, of the program you are going to write before you begin writing it. For a short program, this description may be only one page long, but for a large program like Microsoft Word, it would be very long and detailed.

The external specification should show the appearance of the user interface -- which controls are on the screen and how they are laid out.

It should also specify the events that can occur -- the actions the user can take, and what the computer should be programmed to do for each of them. (As we will see later, all events are not caused by user action).

2. Build the user interface using the VS development system.

3. Code the event handlers. For each event you define in step 1, you must write an event handler, a subprogramtelling the computer what to do when that event occurs.

4. When you first run your program, it will not work properly. Debugging is the process of finding and correcting your errors. In testing a program, you should give it extreme inputs in an attempt to force errors.

Some IT managers require programmers to write their debugging test plans before beginning to program. They assume that if the programmer does not have a clear enough external description to do so, they do not understand the problem well enough to program it.

5. The job is not finished when the program is working correctly. The programmer must prepare documents describing both the external specification and the internal design of the program. This documentation will be of value to users and programmers who must maintain and modify your program.

Many people may work as a team if a project is large. There might be architects, programmers, testers and documentation writers.

It may sound like you just work your way through these steps in order, but, in practice, you will find yourself going back at times. For example, while writing event handlers, you might decide you need to change the user interface, so you need to back up and change the external specification.

You might be tempted to skip some of these steps when working on simple programs like those in this class, but when working on a larger program, that would be a big mistake. The best way to save time on a programming project is to spend a lot of time on the external design. A well-designed program will be easy to code, debug and document. As they say "the best way to go fast is to go slow."