/functional-programmer

name: functional-programmer
description: Functional programming principles, patterns, and practices. Use when working with functional languages (Racket, Clojure, Erlang, Haskell, Idris, Scheme, OCaml, F#, Elixir, etc.) without language-specific skills available, or when applying functional paradigms in multi-paradigm languages.

Functional Programmer

Purpose

This skill provides guidance on functional programming principles, patterns, and practices. Functional programming treats computation as the evaluation of mathematical functions, emphasizing immutability, pure functions, and declarative style. This skill serves as a foundation when working with functional languages or applying functional paradigms in multi-paradigm codebases.

When to Use This Skill

Use this skill when:

• Working with functional languages (Racket, Clojure, Erlang, Haskell, Idris, Scheme, OCaml, F#, Elixir) without language-specific skills available
• Applying functional programming patterns in multi-paradigm languages (Java, Python, JavaScript)
• Designing systems that benefit from immutability and pure functions
• Refactoring imperative code to functional style
• Working with data transformation pipelines

**Note:** Language-specific skills (e.g., clojure-programmer, racket-programmer) supersede this skill when available.

Core Philosophy

Code as Mathematical Expression

Functional programming views programs as compositions of mathematical functions. A function always produces the same output for the same input, with no hidden state or side effects. This mathematical purity enables powerful reasoning about code behavior.

**Quote to remember:** "Programs must be written for people to read, and only incidentally for machines to execute." — Harold Abelson, SICP

Data Transformation Over Mutation

Rather than modifying data in place, functional programming creates new data structures through transformation. This immutability enables:

• Safer concurrent programs (no race conditions)
• Easier reasoning about program state
• Simpler testing (functions are deterministic)
• Time-travel debugging and undo mechanisms

Composition as Primary Abstraction

Build complex behavior by composing simple functions. Small, single-purpose functions combine to create sophisticated systems. Composition is the fundamental abstraction mechanism in functional programming.

Fundamental Principles

Immutability Makes Time Explicit

Data structures cannot be modified after creation. Instead, transformations produce new structures. This makes time and change explicit rather than hidden.

**Quote to remember:** "Time is a device that was invented to keep everything from happening at once." — Ray Cummings (1922), often misattributed

**Why immutability matters:**

• Eliminates entire classes of bugs (unexpected mutations, race conditions)
• Enables safe sharing without defensive copying
• Simplifies reasoning (values don't change underfoot)
• Facilitates time-travel debugging and undo

**Implementation:** Persistent data structures with structural sharing, copy-on-write, or immutable-by-convention.

Pure Functions Enable Reasoning

Pure functions always return the same output for the same input, with no side effects. This referential transparency enables equational reasoning about code.

**Why purity matters:**

• Test without complex setup
• Compose freely (outputs match inputs)
• Parallelize safely (no shared state)
• Cache results (memoization)
• Reason algebraically (substitute equals for equals)

**Managing effects:** Push side effects to program boundaries. Separate pure core logic from effectful actions. Use effect systems when appropriate.

Higher-Order Functions as Abstraction

Functions as values enable abstracting over patterns, not just data. This is more powerful than data abstraction alone.

**Why higher-order functions matter:**

• Express patterns once, apply everywhere (map/filter/reduce over any collection)
• Build domain-specific abstractions (custom control flow)
• Parameterize behavior, not just data
• Construct complex operations from simple parts

Declarative Style Expresses Intent

Express *what* to compute, not *how*. Describe desired results rather than step-by-step procedures. This shifts from mechanical instructions to logical assertions about the result.

**Why declarative style matters:**

• Code reads as specification
• Implementation can optimize without changing meaning
• Easier to verify correctness (matches problem statement)
• Separates concerns (what vs. how)

<fp_decision_framework>

When to Use Functional Programming

From the software-engineer skill, use functional approaches when:

• Transforming data through pipelines
• Ensuring correctness through immutability
• Working with concurrent systems
• Composing small, reusable operations
• Avoiding state-related bugs

**Key principles:**

• Pure functions (no side effects)
• Immutable data structures
• First-class and higher-order functions
• Composition over inheritance

<paradigm_decision_table>

When to Choose FP vs. Other Paradigms

| Situation | FP Strength | Consider Alternative When | |-----------|-------------|---------------------------| | Data pipelines | Composition, immutability | Complex branching logic needed | | Concurrent systems | No shared mutable state | Inherently stateful (games, GUIs) | | Correctness-critical | Equational reasoning, testing | Performance-critical tight loops | | Reusable operations | Higher-order functions | Team unfamiliar with FP | | Domain modeling | ADTs, pattern matching | Extensible data (expression problem) | | Parsing/transformation | Declarative specification | Complex imperative protocols | | Mathematical computation | Pure functions match math | I/O-heavy applications | </paradigm_decision_table> </fp_decision_framework>

<fp_thinking_patterns>

FP Thinking Patterns

<data_transformation>

Data Transformation Over Control Flow

Prefer expressing operation