Databases Reference
In-Depth Information
The focus of a functional programmer is to rethink the loops and conditionals in
terms of small, isolated transforms of data. The results are services that know what
functions to call based on what data is presented to the inputs.
10.4.5
The new cognitive style:
from capturing state to isolated transforms
Imperative programming has a consistent problem-solving (or cognitive) style that
requires a developer to look at the world around them and capture the state of the
world. Once the initial state of the world has been precisely captured in memory or
object state, developers write carefully orchestrated methods to update the state of
interacting objects.
The cognitive styles used in functional programming are radically different.
Instead of capturing state, the functional programmer views the world as a series of
transformations of data from the initial raw form to other forms that do useful work.
Transforms might convert raw data to forms used in indexes, convert raw data to
HTML
formats for display in a web page, or generate aggregate values (counts, sums,
averages, and others) used in a data warehouse.
Both object-oriented and functional programming do share one similar goal—
how to structure libraries that reuse code to make the software easier to use and main-
tain. With object orientation, the primary way you reuse code is to use an inheritance
hierarchy. You move common data and methods up to superclasses, where they can be
reused by other object classes. With functional programming, the goal is to create
reusable transformation functions that build hierarchies where each component in
the hierarchy is regenerated when the dependent element's data changes.
The key consequence of what style you choose is scalability. When you choose the
functional programming approach, your transforms will scale to run on large clusters
with hundreds or thousands of nodes. If you choose the imperative programming
route, you must carefully maintain the state of a complex network of objects when
there are many threads accessing these objects at the same time. Inevitably you'll run
into the same scalability problems you saw with graph stores in chapter 6 on big data.
Large object networks might not fit within
RAM
, locking systems will consume more
and more
CPU
cycles, and caching won't be used effectively. You'll be spending most
of your
CPU
cycles moving data around and managing locks.
10.4.6
Quality, validation, and consistent unit testing
Regardless of whether imperative or functional programming is used, there's one
observation that won't change. The most reliable programs are those that have been
adequately tested. Too often, we see good test-driven imperative programmers leap
into the world of functional programming and become so disoriented that they forget
everything that they learned about good test-driven development.
Functional programs seem to be inherently more reliable. They don't have to deal
with which objects need to deallocate memory and when the memory can be released.
