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 programming
Following 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 loopsin 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 paradigma style of building the
structure and elements of computer programsthat 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 steps

To 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 handlers
2. Build the user interface
3. Code event handlers and write common code
4. Debug the program
5. 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."