Programming Paradigms

Sep 8 16:04 UTC 2010

This item is for the discussion of different programming paradigms.

The four main paradigms are as follows:

1.  Imperative Procedural.  Programs are structured around explicit 
commands that mutate state.  The main abstraction facility is the 
procedure.  These tend to be very familiar because they are closely 
aligned with how computers actually work, with a mutable main (and 
secondary, and tertiary...) store and imperative instructions that 
manipulate that store, realizing side-effects.  Representative 
examples include C, ISO standard Pascal and FORTRAN.

2.  Imperative Object-Oriented.  Programs are organized around objects 
that combine data and the operations that act on that data.  The main 
abstraction facility is the class; classes may be put into 
hierarchies, with subclasses deriving behavior and sometimes data from 
superclasses.  These hierarchies often model real-life taxonomies of 
objects, making this a particularly appealing paradigm for modelling 
real-world objects.  For example, a duck is a bird and a sparrow is a 
bird; both fly.  Representative examples include Smalltalk, Objective-
C, Java, Ada-95, Eiffel and C++.

3.  Constraint-based Logic.  Programs are organized as corpi of data 
and relationships between that data, and assertions about the data 
that either succeed or fail.  The canonical example is Prolog.

4.  Functional.  Programs are structured around expressions that 
operate on immutable state, and are side-effect free; these are often 
called "pure" functions.  This model is attractive because it's much 
closer to the models of mathematics and thus easier to reason about, 
and in many cases, formally prove correct.  Immutable state is also 
significantly easier to manage on, e.g., shared-memory multiprocessor 
computers such as those that are becoming increasingly available.  
Functional programming has started gaining considerable interest 
lately because of this.  Representative examples include Haskell, 
Standard ML, and several dialects of Lisp.

Several languages also cross multiple paradigms, and languages that 
embrace more than one are starting to gain popularity.  For instance, 
Scala, another of the recent languages targetting the Java virtual 
machine, combines elements of Object-oriented and functional 
programming, as does OCaml, which merges a nearly-pure functional 
language with a powerful module system.

Languages within each paradigm category can differ substantially in 
important ways.  For instance, whether a language is strongly or 
weakly or statically or dynamically typed; whether it's a compiled 
language or interpreted; whether it's meant for building large 
applications or falls in the domain of "scripting" languages.

Discuss.

response 2 of 2:

Nov 14 17:11 UTC 2010

The vast majority of my programming has been of the "imperative
procedural" variety, in languages like Fortran, Basic, C, Pascal, and
various assembly languages.  I've a bit of background in the
object-oriented and functional approaches, however.

In the early 1980s I became enamored of Simula 67, the original
imperative object-oriented language, after reading O-J Dahl's classic
paper about it and the object-oriented approach in the book "Structured
Programming".  The academic mainframe at the university where I taught
was a DEC-10 running TOPS-10 and had a very good implementation of
Simula 67, so I was able to get a lot of hands-on experience with the
language.  I found Simula 67 - with its Algol-like syntax and support
for high-level concepts such as classes and coroutines - to be a
delightful environment in which to program.  (I assigned one of my
classes to write a text-adventure game in Simula 67 with classes to
represent locations, objects, and such.  This was well before the
object-oriented languages like C++ and Java became commonplace in
computer science education.)

I suppose my somewhat sketchy Lisp activities count as experience with
the functional paradigm.  Lisp isn't a purely functional language, but
it does support a functional style.  I'm comfortable with the Lisp way
of thinking about things, probably because of my exposure to Church's
lambda-calculus - on which Lisp is based, to a large extent - in courses
I took on mathematical logic, well before I became involved with computers.