Code Without Fear

April 21, 2024

Programming is hard. It’s hard to work with tools, to formulate ideas into code, and to make that code work. As developers, we are inevitably forced to manage many responsibilities at once, more than can be reasonably managed by a single human. This can have a huge psychological strain: when one responsibility deeply focused on, the others go into subconscious¹, yet the programmer still feels obligated to handle them - this results in a perpetual state of fear that feels a lot like wading through a Norwegian peat bog². It results in fragile programs and a stressful programming experience.

In my few years of programming experience, I’ve been thrilled to find a few practices³ which greatly reduce these fears. This has led me into an obsession of finding new tools to further reduce these development strains in hopes of attaining a more directed workflow.

Source Control

Let’s begin with something that is minimally controversial. Rapid modification and refactoring of code leads to a fear of losing progress. This adds an extra cost for experimentation and rolling back: every change to the code must be done very carefully to avoid messing things up and losing the ability to revert, or the information of what was changed.

Version control systems (especially Git), though imperfect (it’s still technically possible to lose progress), work wonders on this front.

Memory Safety

Memory Management

It’s also generally agreed upon that manual memory management (i.e. C’s malloc/free, C++’s new/delete) is dangerous and difficult to do correctly.

Garbage Collection is used by most modern languages, and completely removes the need to worry about this; RAII (Resource Acquisition Is Initialization) and destruction guarantees/borrow checkers are a more busy (but more efficient) method.

Buffer Overflows

Languages that don’t enforce array boundaries and allow/encourage pointer arithmetic make avoiding buffer overflows the responsibility of the programmer.

Language-level bounds checks (done internally and automatically) are the obvious solution to this, and they’re done by most languages.

Efficiency

Asymptotic Efficiency

It’s pretty hard to avoid worrying about asymptotic efficiency in general, but it’s ideal to factor out the algorithm (or data structure) into a minimal size so its complexity can be best analyzed and performance best tuned. This also separates the focus of efficiency from the remainder of the code.

Constant-Factors

Worrying about constant-factor efficiency when writing code is a major distraction.

Ideally, non-library code shouldn’t have to change at all to gain this efficiency: using optimized compilers and libraries is usually much more effective doing fancy (and usually bug-prone) tricks with code.

Null

In languages with ubiquitous nullable types (which have ignorable null-variants), programmers must decide between (1) checking if every variable is null before using it, or (2) attempting to mentally track invariants of which variables are null, and which functions can return null, almost certainly making mistakes, which lead to runtime errors.

Luckily, the solution is incredibly easy and natural in languages with ADTs: make a data-type that is used for nullable values (i.e. Option/Maybe), and make the associated value only accessible after a null-check.

Exception Propagation

Traditional try/catch/throw-style exceptions are flawed in the same way as null: the programmer must live in fear of functions unexpectedly throwing exceptions.

The solution follows the same idea: embed the variable behavior within the types rather than adding it as a language feature. Namely, create a data-type for values that might cause errors (i.e. Result/Either).

Syntactic Correctness

Syntax errors, though less and less common with greater language fluency, are a delayed-feedback burden (a lot like type errors), because, in editors that don’t check for them, they are only caught at compile/run time. It can also be more difficult to understand the error by the time compilation happens, since large swaths of (previously) untested code are sent to the compiler all at once.

In-IDE Linting is also the solution to this fear: syntax errors can be exposed as they are written, giving the programmer verification that their code is correct when they write it.

Type Alignment

Type errors are omnipresent in dynamically-typed languages. Though these languages may offer greater flexibility and a lower barrier to compilation/running, they also completely remove many type-alignment guarantees, and therefore force their burden on the programmer, which causes extreme mental strain when writing non-trivial programs.

Compilation (with type checking) and, linting (with type checking) are both solutions to this: a downside of compilation is that it is frequently delayed (must be manually triggered), and is often presented in a sub-ideal format⁴. Linting is also imperfect for many languages, so the ideal antidote to this issue is using both linters and compilers.

API Usage

Type-alignment and name matching in terms of API usage is yet another task IDE-integration and linters can facilitate. Primitive auto-completion⁵ can’t come up with function names you haven’t yet used, so the name must be manually typed, and feedback is delayed until compilation-time/run-time.

Off-By-One Errors

Off-By-One Errors are infamous annoyances: they always seem to happen around loops (especially while loops): this is because, by their nature, they are a mismatch of the data that is being transformed/read/written/created and some assumption about that data (usually some local variable).

There are two primary ways to avoid such mismatch, both involve eliminating loops (imperative style): (1) make no assumptions about (and hold no state related to) the data: instead do a dispatch on the data itself to determine which path to execute (usually this involves recursion), (2) use high-level sweeping operations (i.e. map, filter, fold, zip, etc.) which are pre-coded to avoid such errors (and often employ (1) under the hood).

Managing State

Global/Shared Variables

Global and shared⁶ variables are often frowned upon, because their state is hard to track over time. Globals are rarely necessary, and there’s typically an isomorphic way to write the programs without global variables that is no less natural, and no more complex.

Local Variables, over time

While the above idea is very common, most developers don’t seem to mind mutable local variables at all, which surprises me. Mutable local variables exhibit many of the same flaws that global variables do (especially as the function grows in complexity): their state can unexpectedly change during refactors and reordering of statements, and their state is often difficult to trace over time. I think most developers (including myself) have grown to accept these complexities simply because they’re idiomatic to imperative style.

It’s possible to avoid this complexity, though, namely by using immutability. Minimizing state changes of local variables reduces the complexity of function bodies, and makes them inherently easier to understand, taking mental load off of the programmer.

Complex Data Structures

In many languages, it’s very unnatural to represent sum types (union-types with associated data) (it’s impossible to restrict access to the data in a struct given the state of an associated enum). As such structures grow in complexity, it becomes very difficult to work with it in a clean and bug-free way (this is basically the combined fears of mutable state and detachment of state and data).

ADTs (Algebraic Data Types), by definition, allow enumerations with associated data, and come with natural syntax to do a dispatch (and unwrapping of data) according to that enum. They eliminate the mental burden of trying to bodge together a type that simulates this, and deal with whatever shoddily-glued invariants were used to implement the type every time it is used.

Functional Manifesto in Disguise

If you haven’t already noticed, the above points almost entirely argue moving away from imperative and towards functional style. I don’t intend for this post to be solely an argument for functional, though, but rather a call to be aware of these fears that we frequently ignore, and to actively search for ways to avoid them. I think functional is a big step towards doing this, but it is by no means the essence of it: I suspect that, even if functional is more widely adopted, we would find more fine-grained fears that also arise in functional programming, and any style we could adopt for that matter.

My hope is that, over time, as we eliminate as many development-time burdens as possible, we can focus less and less on trivial mechanical struggles and more on the problems at hand, on higher and higher levels of abstraction.

TL;DR

As developers, we (often unknowingly) tolerate unnecessary mental burdens while coding. Use the following tools to avoid them:

• Source Control
• Linters + IDE integration
• Functional Style
  • Aim for high-level transformation chains rather than iteration and state
  • Avoid mutability
• ADTs (no null or exceptions, no bodged sum types)
• Languages that guarantee…
  • Memory Safety
  • Type Safety (static typing)
• Optimized compilers and libraries rather than optimized (overall) code

The language and the tools you use should take a maximal load off of your shoulders.