Fearless Tinkering is Functional

Is functional programming worth learning? This series is the sales pitch I wish I had received when first being introduced to the world of functions.

🪝

Sometimes functional programming gets a bad rap. Critics from industry cite a laundry list of issues, including a lack of commercial validation, high barrier of entry, sparse library catalog, poor documentation, unfamiliar academic culture, and dismal entry-level job market. Advocates counter with a number of success stories and appeals pointing to ongoing improvements. “Things really are getting better!” Deserved or otherwise, skepticism is hard to overcome.

It’s certainly never been the case that a functional language was the de facto industry standard like Java, Python, and JavaScript have been. By choice¹ or by fate, the lack of mainstream adoption has had predictable costs on functional ecosystems. When 10,000 new programmers are learning an imperative language to every individual learning a functional one, can a functional approach really compete?²

My answer is yes. While they have merit, none of the above critiques are inherent. In fact, I’ll argue that the functional paradigm already has best-in-class discoverability and experimentation thanks to fearless tinkering.³

Fearless in Theory

Fear and Complexity

There’s an endless list of things that invoke fear in programmers, such as:

Each of these areas can be terrifying on their own. To make matters worse, software rarely contains just a single source of horror. Very simple programs written by very thoughtful programmers can host a multitude.

Without the right tools, conquering these fears can feel impossible. How can one produce trustworthy software with untrustrworthy tools? Some adopt a defensive programming style, but institutionalizing apprehension isn't an end in itself. What use is an infinite roll of duct tape when a ship takes water? If tape can’t solve the first leak, should one patch the next, or accept fate and lose hope in the voyage? Does a decision even matter when the ship is already sinking? Maybe swimming to shore and joining a new boat would suffice… at least until that crew wants to tape their leaks. By then, that too will be someone else’s problem. The cognitive burden of faulty software is real and difficult to remedy. Programming is a social exercise, and teams will burn out accommodating learned helplessness.

Most fears boil down to uncertainty about complexity. As Fred Brooks explained in No Silver Bullet, there exists essential complexity that cannot be avoided and accidental complexity that can.⁴ Out of the Tar Pit followed up by diagnosing state, control flow, and code volume as the most frequent culprits underlying accidental complexity. The nature of complexity is festering and exponential, so tackling root causes is always better than addressing symptoms. Put another way, preventing leaks by addressing the inherent structural deficiencies of a ship’s build is favorable to being skilled at plugging holes.

Fearless tinkering is the ability to engage a domain and confidently reason about it while unencumbered by accidental complexity. Whether the domain is concurrency, software upgrades, or something else, a fearless tinkerer can rely on the structural guarantees of their context to safely explore their domain and target the essential complexity of the task at hand. A fearless tinkerer sails a ship where entire classes of leakage are rendered an impossibility. What kinds of leaks are prevented? How are they decided? As discussed in the following sections, these guarantees are determined by the algebra of one’s program.

On Functional Programming

The functional style encourages transformation-based workflows over state-based workflows. To motivate this approach, functional languages offer an assortment⁵ of party tricks:⁶

Functional programming doesn’t solve complexity but helps one meet it by surfacing its roots. To do this, functional languages deliver battle-tested approaches to the state, control flow, and volume.

Functional languages make stateful complexity explicit. By pairing immutable defaults with performant and easy-to-use APIs, functional languages minimize the need for mutable state. Introducing any mutable state thus becomes an intentional and highly visible action. Given the elimination of destructive updates, compilers are empowered to reward programmers with greater expressiveness and safety at less cost. Some functional languages make explicit their “effects” with types, creating a distinction that allows separate reasoning of “effect-free” and “effectful” code.

With a greater reliance on declarative constructs (expressions) over imperative ones (statements), functional languages eliminate a number of control flow complexities. Jump-based statements that break compositionality are replaced with expressions that can be substituted for their value. Bigger programs can be faithfully decomposed into smaller ones. This allows for local reasoning on individual parts to hold up when global reasoning is needed about the whole. Thanks to the sole determination of a function’s outputs on its inputs, purely functional programming creates an experience where “what you see is what you get.”

Compositionality also addresses program volume in functional languages. Programs and their domains can be mechanically decomposed into their essential concepts. For instance, programmers can collapse verbose wrangling and glue-code into neat reusable patterns using higher-order functions and composition. Typed functional languages use various flavors of polymorphism to replace infinitely-many functions over one domain with an economy of functions over infinite domains. Typed functional languages also reduce cognitive volume by offloading the rote calculations of dynamism onto the programmer’s better-suited counterpart in computers. As elaborated in the following section, relegating implementation details to the relevant semantic layer makes declarative APIs naturally terse. Judicious use of abstraction capabilities assists in uncovering rock-solid, lean foundations for APIs and broader ecosystems.

Armed with the properties of functional languages, programmers can reclaim their cognitive sovereignty and fearlessly explore software in action.

Ideas over Implementation Details

Declare it. Answer how with what. Break the causal chain and unshackle from the past. The world is simply what you say it is.

• a sage functional programmer, probably

If language is a tool for thought, then one should value dialects enabling natural communication. Blunted alternatives that intersperse anything meaningful with robotic recitations of language internals or error-prone adaptations to outside alterations are frustrating to tolerate. A language that yields such fragile mental models is ill-fit for real-world scenarios like context-switching, requirements evolution, and the eventuality of a system’s growth beyond what can be kept in one’s head. The essential complexity programmers face is already challenging enough.

When the business calls for an algorithm to determine how many users visited their website last week, no one’s first thought should have to be about for-loops, heap allocations, hashing strategies, logic gates, or cosmic rays. No, an API that’s better suited for immediate communication might yield something like:

all_users -> filter_by(visited_since(-7 days)) -> count()

Declarative programming simplifies the act of learning because it a) meets one at their layer of abstraction and b) lets one focus solely on what’s in front of them. A well-designed declarative API lays out all the vocabulary and structure one should need, such that formulating solutions through sentences is as natural as placing blocks in a game of Tetris. Learners can focus on describing the place they actually care about instead of the windy road taken to get there. By only necessitating the specification of a goal state, programmers are unburdened by the interconnected history of their model's state transitions.

Constraints Liberate

Freedom at one level leads to restriction at another. A constraint at one level leads to freedom and power at another level.

• Rúnar Bjarnason @ Scala World 2015, Constraints liberate, Liberties constrain

Observing the underlying properties of a program is the key to unlocking its simplification. Pure functions are simple because of the numerous constraints imposed on them. The restriction of mapping input sets onto output sets eases the discovery of additional relationships in one’s program. Employing popular functional techniques to prune superfluous code paths can make further invariants lurking in our programs more apparent. By building an arsenal of common operations with associated constraints, one can unlock a valuable toolkit of powers to call upon in various programming situations.

One could rightly object that the need to learn new mathematical abstractions is trading one kind of complexity for another. In practice, there are but a small handful of core abstractions that programmers will typically run into and are thus worth their collective weight.⁷ Learning frequently occurring abstractions is useful for formalizing one's understanding of the domains they characterize. The major benefit of learning said abstractions is that once you’ve understood them, you’ve understood them for all their applications.

log4Info(msg):
    upload_ssn()
    return “info: ” + msg

f(x):
  global += x
  return global

>>> f(5)
5
>>> f(5)
10

>>> average(1, average(2, 3))
1.75
>>> average(average(1, 2), 3)
2.25

>>> wells_fargo.make_transations([
  deposit($200),
  withdraw($100),
  withdraw($100)
])
>>> wells_fargo.show_activity()
Transaction Log:
  -100, -25 (overdraw fee),
  +200,
  -100, -25 (overdraw fee)
Current Balance: -$50

neg_to_bool(x: int) -> Union[int, bool]:
    if x < 0: return False
    else: return x

square(a: int) -> int:
    return a * a

>>> square(neg_to_bool(-10))
*** error!

$ git merge develop
Auto-merging index.html
CONFLICT (content): ...
CONFLICT (modify/delete): ...
Automatic merge failed;

$ cat index.html
<<<<<<< HEAD
  <h1>Fearless Tinkering is Functional</h1>
=======
  <h1>Fearless Tinkering is Algebraic</h1>
>>>>>>> develop

from_list = lambda input: set(input)
to_list = lambda input: list(input)

>>> x = ['foo', 'bar', 'bar']
>>> x == to_list(from_list(x))
False
// ['foo', 'bar', 'bar'] vs ['foo', 'bar']

is_odd(x: int) -> bool:
    if x == 0: False
    if x == 1: True
    if x == 2: False
    if x == 17: True

>>> is_odd(10000)
*** error!

To Be Continued...

That's all for now! The next two parts of this article will continue with examples of functional programming in practice. Then, we'll discuss how exploiting one's underlying algebra allows any technology to create fearless experiences. Lastly, the final article will introduce several promising functional technologies on the horizon and speculate about their fearless futures.⁹

✌️

Footnotes