Programming Paradigms

A paradigm is a way of thinking.

A paradigm is an abstract model. It is an exemplary model for how a model is constructed. It is a way of producing models.

Programming is the process of defining a model of a computational problem.

Programming paradigms are models for the way to think about (abstract) a problem in a computational manner. It is a theoretical framework within which algorithms, objects, functions, and other abstract representations are formulated. It is composed of techniques, styles, and a culture for how computation is achieved. It is a pattern that serves as a school of thought regarding methodologies for computing.

A programming paradigm is a way of programming.

Programming paradigms are often closely coupled with programming languages. And why shouldn't they be? Programming a `programming language` consists of defining a model for defining models of computation. Since a paradigm is an abstract model, a language naturally couples with a paradigm.

It might be worth noting here that paradigms and language are naturally coupled in metaphysics as well (a metaphysical model being a paradigm). Our language contains many abstractions and concepts. Other languages contain other, different, abstractions and concepts. It would stand to reason therefore, that an individual language lends itself towards easily expressing one certain metaphysic over another, different, metaphysic.

One may now wonder what use a programming paradigm has over another. Well, just as a metaphysical model or a scientific paradigm makes one perceive and solve a problem in a particular way; so too does a programming paradigm make a programmer generate an algorithm in a certain way. Over the years different paradigms have flourished, and programmers engage in heavy debates about their relative merits, arguing vehemently in favor of the paradigm that they have become attached to. Which is unsurprising considering the ferocity with which humans defend a metaphysical model. We as humans are keenly attached to our memes, we value them as much, if not more, than we cherish our bodies.

Among the myriad of paradigms, four are generally agreed to be the "most important" or "principal" paradigms. They are:

Explaining the details of each of these paradigms can be complicated. Each came from its own general theoretical model and background. Each has its merits, and each has its flaws.

Procedural:

Procedural programming was developed as a natural representation of the way computers were designed. Computers work by taking a piece of memory, reading it, deciding what to do, and then doing that thing to another piece of memory. In other words they move through a set of instructions.

A procedural program thus can be characterized as:

Do A to x

then Do B to x

then Do C to y

Procedural code is familiar to people, because it resembles a recipe; the recipe format is also a good way to write procedural code. Just like a recipe, the first part of the program is usually describing the data to be manipulated, and the second part of the program is how to manipulate those pieces to get the desired results. Lets consider the Peanut Butter and Jelly sandwich:

Ingredients:

• Peanut Butter
• Jelly
• Bread

Instructions:

1. If bread is unsliced then slice two pieces, otherwise get two pieces of bread.
2. Fetch some peanut butter
3. Get a single piece of bread and apply fetched peanut butter to bread
4. Fetch some jelly
5. Get a single piece of bread and apply fetched jelly to bread
6. Place the buttered side of the buttered bread slice upon the jellied side of the jellied bread slice
7. Done.

It required a long program to express a pretty simple procedure, but it is very easy to follow. It was also easy and quick to write. This (quick prototyping) is one of the biggest advantages of procedural code. If you have a short script that does one thing (especially if you only ever need to do it once) it is usually easiest and fastest to write a simple procedure to solve the problem.

Functional:

Functional programming was inspired by mathematics. A functional program is generally the most direct way of representing a mathematical problem, and can be characterized as:

f(x) = B(A(x))

Functional code contrasted with procedural code seems to work backwards; it tries to describe what the problem is, and the solution is the program. Everything in a functional paradigm (at least in principle) can be understood as a black box taking zero or more things and returning what is desired. A peanut butter and jelly sandwich represented functionally:

• A pbj is peanut buttered bread and jellied bread together
• bread is a single slices of bread
• slices of bread is sliced bread or slice some bread
• jellied bread is jelly side of bread with jelly on it
• peanut buttered bread is peanut buttered side of bread with peanut butter on it

This is much shorter. Simple or so it seems, though I can tell you it took longer for me to write that than the procedure above. It often requires careful forethought on the part of the programmer to write functional code. This tends to lead to cleaner more stable programs. So stability and brevity are advantages of functional programming.

Flexibility also arises from functional programming. Note, that if bread is a variable and jellied is a function, then jellied can be used to apply jelly to anything that is "jelliable". Thinking of it this way; our functional program can, in theory, be used to make PBJ with pita instead of bread, or with rocks (not sure why you would want to, but..). In fact this program could be easily re-factored to make any variety of simple sandwiches, or sandwich like things.

Procedures are useful. There is something sort of intuitive about a procedure. Now we're dealing with definitions. Definitions are powerful abstractions, however, we have to trust the computer to know how a definition becomes an instruction.

Logical:

Programming in a logical manner is about defining the logical relations between various things. Instead of defining the algorithm in terms of transformations or instructions; things are instead defined in terms of the properties that objects have, and the relations those objects have to each other. The algorithm is about asking how things relate. Logical programming would be characterized as:

Ax(Jx&Px -> Kx)

Logical programs like functional programs are based upon defining things. If we think about the PBJ algorithm. Instead of giving the steps involved in making the sandwich or defining the actions to be taken, we instead define the properties and relations of the objects involved:

• bread is sliced.
• Sandwich is pbj if a bread is buttered and a bread is jellied, and these bread are together.
• bread is buttered if bread has peanut butter on it, and were using the buttered side.
• bread is jellied if bread has jelly on it, and were using the jellied side.

You may have noticed that this is even more terse than the functional version. Unfortunately for most people it is also more confusing, and it is more confusing for the computer too. The computer is constantly attempting to try different ways of making the sandwich, until it can figure out a way to satisfy all conditions.

However, the great thing about this is that this very same code can tell you so much more than the other programs. Functional and procedural code does only one thing. The program was designed to tell you how to make a pbj. Suppose you know you have the peanut butter, jelly, and the bread and you know you need a sandwich. You could ask the very same program what you can make with these ingredients and it would be able to figure that out too. It can do all of this because it understands the relationships between all the pieces.

Object Oriented:

Object Oriented programming was based upon the real world. Conceptually it was formulated with the idea that objects exists, they do things, they have properties and you can do things to them. In object oriented programming everything is such an object. You have a bread object, and a peanut butter object, and a jelly object, and also a pbj object. Each of these things has properties, and what can be done to each of them is described. The OO version would look something like this.

• Bread can become Slices.
• Bread can be sliced by making slices of bread
• Bread can also be stacked.

• Slices have sides, a side can have its own properties.

• Peanut Butter can be spread.

• Jelly can be spread.

• Jelly can be any fruit.

1. my bread is a kind of bread
2. my peanut butter is a kind of peanut butter
3. my jelly is a kind of jelly
4. slice my bread
5. grab a slice and spread my peanut butter on a side
6. grab a slice and spread my jelly on a side.
7. Take jellied side of slice and stack on buttered side of other slice.

Notice first, that much like the procedural program, it is long winded. Also like the procedural program it is a set of declarations and then steps.

It is also awesomely powerful. We talk in it about something that can be sliced: an apple, a carrot, a loaf of bread. We don't need to worry, as long as it's slice-able. Also we didn't need to determine if it was sliced, if we try slicing bread that is already sliced we end up with sliced bread either way. This kind of abstraction is common in object oriented programming and can be very powerful.

Procedural and functional programming lacks this flexibility. If we wanted to slice bread functionally we would try to slice the already sliced bread, and we'd end up with bread bits. :)

The procedural code would probably just end up confused, not knowing how to slice sliced bread.

Also I added the seemingly irrelevant fact that jelly can be any fruit. When dealing with objects, it's easy to define extra seemingly irrelevant properties in the declarations. It's not going to hurt anything that doesn't care about what kind of fruit the jelly is made from, but it is going to allow fruit discriminators more choice. Again refactoring the procedural code for fruit type becomes complicated. Refactoring the functional program is a little less complicated, but still not trivial. The logical code alone has this kind of flexibility, it is as simple as asserting the fact that "jelly is raspberry if it is made from raspberries."

(The way OOP is actually represented in languages is another problem, but that is for another time).

You might observe some things from this.

• Logical and functional programming is about making statements about the way things are. (declarative)
• Object Oriented Programming and Procedural Programming are about telling the computer what to do. (imperative)
• Functional and Procedural programs pass data to a conclusion.
• Object Oriented and Logical programs manipulate the properties of data.
• Object Oriented and Functional programs are designed for portability. What you can do in one context, you should be able to do in another context.
• Logical and Procedural programs are optimized for single purposes.

I think I've been fair to the paradigms. I should mention that all of these paradigms have borrowed from each other, as each has introduced abstractions too powerful to ignore. The 'If' statement which is now littered through all procedural languages came from a functional language (lisp). You can define things in modern procedural programs, and you can run a procedure in logical programs. Which I suppose leads to the last unmentioned paradigm. The MMA of programming. Multi-paradigmatic programming.

The problem with being locked into a paradigm is that it forces a solution to be a particular way regardless of how the solution is actually best achieved. Certain problems are best represented in certain ways. Do we really need a whole object to count the number of letters in this essay? Is it worth the complication designing a GUI as a set of logical conditions?

We as humans like getting attached to our metaphysical models. We perceive the world through that lens and everything makes sense to us. We see other people with esoteric beliefs and wonder how they can't see the obvious solution we see. But what do we miss? What beautiful sight do they behold in their metaphysical model? When things are hard for us that seem easy for others, why do we not seek to unify our model with theirs?

Wouldn't it be best to model our universe based upon seeing things as all they are? As functions, objects, sets, data? What makes a materialistic world really that different from an idealistic world (note: metaphysical terminology, not ethical terminology)? Both are composed of pieces.

Finally why do we conflate our model with the real world?

Why do we conflate our model with the programming problem we are trying to solve?

So it goes with metaphysics, so also it goes with programming. Embrace flexibility. Master all the models. Mix them. Make referentially transparent objects, and procedurally alter the predicates of objects.

There is no value in faith, see things as they really are, use what works.