Perspectives on the Cultures of Making and Relating

In a recent reflection on the book Cultures of Programming - The Development of Programming Concepts and Methodologies by Tomáš Petříček, Konrad Hinsen explores the historical evolution of programming through the lens of five distinct, overlapping cultures.

The core premise of Petříček's work is that programming is not a monolithic activity but a tapestry of interwoven cultural approaches.

Hinsen aims to bridge these concepts with the broader technological landscape and the specific nuances of scientific inquiry.

The Five Programming Cultures

According to the text, programming can be viewed through these five primary lenses:

• Mathematical: Programs are treated as mathematical objects; the goal is to ensure properties are provable.
• Hacker: Programming is an iterative, real-time dialogue with the machine.
• Engineering: Software is a technical product. Construction relies on established best practices to balance economic limits with desired quality.
• Management: Software is an industrial output; its success depends on the efficiency of the organizational structure.
• Humanist: Computation is viewed as an externalization of human thought processes and notation.

While most people have a "home" culture, they often shift their perspective based on the task at hand.

Categorizing the Approaches

Hinsen observes a fundamental split in how these cultures interact with software:

Category	Cultures	Primary Focus
Making	Hacker, Engineering, Management	The act of construction and delivery.
Relating	Mathematical, Humanist	The conceptual understanding and meaning.

If a project requires formally provable properties, that "Relating" requirement must be integrated into every stage of the "Making" process.

Beyond Programming: Craft vs. Industry

These cultural tensions are not exclusive to code. They mirror long-standing dynamics in other fields:

1. Industrialization: The pairing of Engineering and Management has driven manufacturing for ages—one focusing on the "how" (technical) and the other on the "who/when" (coordination).
2. The Artisan: The Hacker is essentially a modern craftsperson. They rely on sensory feedback, learn by doing, and typically work in small, autonomous groups.

The difference between a hacker's bespoke code and a corporate software suite is akin to the difference between a mass-produced custom-tailored suit and furniture from Ikea.

The Tension of Formalization

There is a natural conflict between the Mathematical and Humanist views. Formalization requires decontextualization.

$\text{Formal Proof} \implies \text{Removal of Context}$

While formal methods provide rigor, the properties they prove are often less relevant to the actual application context than the qualitative insights favored by the Humanist.

Application to Scientific Research

Science mirrors these same cultural struggles. Historically, early researchers operated like hackers: working in small teams, building their own tools, and organizing via non-hierarchical "learned societies."

Recently, however, science has undergone a process of industrialization.

Hinsen notes that Management culture is often an external imposition from funding bodies, which frequently clashes with the exploratory, unpredictable nature of discovery.

The Evolution of Scientific Software

Scientific software is a hybrid, inheriting traits from both programming and research cultures.

• 1950s–1970s: Dominantly a craft. Software consisted of small-to-medium Fortran programs with minimal dependencies.
• The Humanist Streak: A few researchers treated software like academic papers, subjecting it to peer review.
• The Engineering Shift: As complexity grew, libraries like LINPACK emerged. This led to the professionalization of the Research Software Engineer (RSE).
• Modern Era: Hacker culture persists in the form of computational notebooks and workflows.

The Missing Link: Mathematics

Despite the quantitative nature of science, "Mathematical culture" (formal methods) is surprisingly rare in research software. Hinsen attributes this to a lack of mature, accessible tools. Scientists prefer well-understood, stable mathematics over cutting-edge formal software verification.

Consequently, the only widely adopted formal method is static type checking.

Current State of Formal Adoption:

• Static Type Checking (Widely used/debated)
• Formal Verification (Rare)
• Automated Theorem Proving (Niche)

Whether a scientist loves or hates a compiler's type-checker, they are participating in the same cultural divide as any other developer.

---

Conceptual Example: The Hacker vs. The Engineer

# Hacker Approach: "Just make it work"
def solve(data):
    # Quick and dirty, iterative feedback
    return [x * 2 for x in data if x > 0]

# Engineering Approach: "Make it maintainable"
def solve_data_processed(input_values: list[float]) -> list[float]:
    """
    Processes input values based on corporate standard v2.1.
    Returns doubled positive values.
    """
    if not isinstance(input_values, list):
        raise TypeError("Expected a list")
    return [val * 2 for val in input_values if val > 0]