Java Reference
In-Depth Information
Other Programming Paradigms
Those three paradigms - imperative, object-oriented, and post-functional - are the three that Java 8 supports
nicely. However, there are many other programming paradigms out there, and it is important to know
about some of the dominant ones. Learning new paradigms helps you think about problems in different
ways, which means that you are better at solving your problems. Even more, however, knowing about other
paradigms allows you to have conversations with developers coming from different contexts, which is how
you will avoid intellectual and professional stagnation. There is a kind of stagnation that can creep into a
programmer's life after a few years: familiarity and relative satisfaction with a particular set of tools can
lead to the mistaken impression that those tools (and derivations from them) define the universe. If you are
starting to think that way, here are some ways to shake yourself loose of that trap.
Logical/Mathematical
Most of the references to “functional programming” are referring to this paradigm. In this paradigm, the
program is a set of mathematical functions, and the programmer's job is to define and manipulate the
functions themselves. The data that is moving through the application is largely irrelevant: the functions
are defined based on the types and shapes of that data. The particular implementation details of how these
functions are applied are left to the runtime or compiler. I was introduced to the logical/mathematical
paradigm through the programming language OCaml, which is a derivative of MetaLanguage (ML). If you
want to see how well this approach works with concurrency, see the programming language JoCaml, which
is the join calculus (i.e., fork/join) mixed with OCaml. Haskell is probably the current poster child for this
paradigm, and there is a strong case to be made for Erlang, too. This paradigm also includes Mathematica
and other “computer algebra systems,” as well as Coq and other “interactive theorem provers.”
This paradigm works very well when I/O is incidental to the work being done, and so it can be quickly
abstracted out of existence. If most of your time is spent in doing heavy lifting with data defined and
manipulated purely internally, then this paradigm works very well for ensuring that your code is executed
quickly and safely.
Homoiconic
This is considered another form of functional programming, although it is very different from the logical/
mathematical paradigm. Instead, the homoiconic paradigm draws from the mathematics of computability
theory. (For the mathematically inclined, homoiconic programming is the lambda calculus as a
programming language.) In the case of a homoiconic programming language, the program processs itself,
performing mechanical reductions on the application until there is nothing left except the answer.
This is a very strange concept for people to wrap their head around, but it is easy to see it in action. To
see it in action, start by assuming that I define this transformation:
For All x, Replace sq(x) With x*x.
Note that I am not defining a function or any kind of semantics: this is not a definition of a function. I
am saying that when a particular set of characters is encountered within the program, we should replace
them with a different set of characters. Now let's say that I define another couple of transformations:
For All f x y z, Replace map(f (x y z)) With (f(x) f(y) f(z)).
For All x y z, Replace sum(x y z) With x+y+z.
