Chapter 1: Why Fortran? The Language That Refuses to Die

"Much of my work has come from being lazy. I didn't like writing programs, and so… I started work on a programming system to make it easier to write programs." — John Backus, who led the team that created Fortran

Overview

You have heard that Fortran is a dead language. It is not. It is the language that predicts your weather, simulates nuclear reactors, models the climate, designs aircraft wings, and runs on nearly every machine in the TOP500 list of the world's fastest supercomputers. The reason it persists is not nostalgia, and it is not that nobody has gotten around to replacing it. The reason is speed. For dense numerical computation — multiplying matrices, marching a simulation forward in time, sweeping a stencil across a billion-cell grid — nothing in mainstream use is reliably faster, and that fact traces back to two design decisions made in the 1950s that turned out to be exactly right for scientific computing.

This chapter makes the case for the whole enterprise. We are not going to write much Fortran yet — that starts in earnest in Chapter 2, when you install a compiler and run your first program. Here the job is different and, in its way, more important: to replace the caricature of Fortran that you have almost certainly absorbed — punch cards, GOTO statements, angry uppercase — with an accurate picture of a living, evolving, quietly dominant language, and to explain why it dominates where it does. If you understand the "why" now, every technical choice in the rest of the book will read as a consequence rather than a rule to memorize.

In this chapter, you will learn to:

• Place Fortran in time, from its 1957 origin to the 2023 standard, and say what each major revision added.
• Point to the specific scientific domains and named production codes where Fortran is the tool of choice.
• Explain — without equations, for now — the two things about Fortran (arrays as first-class objects, and the promise that function arguments do not secretly overlap in memory) that let its compilers generate such fast code.
• Answer the person at a party who tells you Fortran is dead, with facts and with grace.
• Navigate this book: its ten parts, its four reading tracks, and the heat-equation solver you will build across all forty chapters.

Learning Paths

How to read this chapter by track. - 🔬 Scientist ("my Python is too slow") — read §1.3 closely; it is the argument that will make you fast. Skim the history in §1.1. - 📖 Standard — read straight through; this chapter frames everything that follows. - 🔧 Legacy ("I inherited old code") — §1.1 and §1.4 are your orientation; the "punch-card" Fortran you fear is defined in §1.1 and dismantled in Part IV. - ⚡ HPC ("I need parallel code") — §1.3 explains why Fortran is the substrate of high-performance computing; §1.2 names the codes you will meet on a cluster.

1.1 The Oldest Living Language

In 1957, a small team at IBM led by John Backus delivered something that most of their colleagues thought was impossible: a program that could translate mathematical formulas, written in something close to ordinary algebraic notation, into machine code that ran nearly as fast as code written by hand. They called it the FORTRAN system — from Formula Translation — and it changed computing permanently. Before Fortran, programming meant writing the numeric instructions of a specific machine, one at a time. After Fortran, a scientist could write X = (A + B) / C and trust the compiler to figure out the rest.

Definition (high-level language). A programming language that lets you express computation in terms of human-meaningful abstractions — variables, expressions, loops, procedures — rather than the raw instructions of a particular processor. A compiler is the program that translates a high-level language into the machine instructions the processor actually executes. Fortran was the first high-level language to win broad adoption, and the compiler was its revolutionary act: it proved that a machine could generate fast code from human-readable formulas.

The team's obsession — and the thing that made Fortran matter — was speed. In 1957 the prevailing wisdom held that no compiler could ever match a skilled programmer writing machine instructions by hand, and that scientists, who counted every microsecond on machines that cost millions of dollars, would never tolerate the overhead of an automatic translator. Backus's group understood the stakes precisely: if their compiled code ran even twice as slowly as hand-written assembly, the project would be a curiosity and nothing more. So they poured the bulk of their effort into the optimizer, and against the odds they won — FORTRAN produced code that rivaled what expert programmers wrote by hand, and the central objection simply collapsed. That founding conviction, that a high-level language has no right to exist unless it compiles to genuinely fast code, is stamped into Fortran's character to this day. It is why a book about Fortran is, inescapably, also a book about performance.

That first system is now called FORTRAN I, and what followed is one of the longest evolutionary lineages in all of technology:

 1957   FORTRAN I      first release; formula translation, fast compiled code
 1958   FORTRAN II      subroutines and functions — separate compilation
 1962   FORTRAN IV      cleaner, machine-independent; hugely influential
 1966   FORTRAN 66      the FIRST standardized programming language (ANSI)
 1978   FORTRAN 77      structured IF/THEN/ELSE, CHARACTER type — the classic
 1991   Fortran 90      THE modernization: free-form, arrays, modules, dynamic memory
 1997   Fortran 95      refinements: FORALL, PURE, ELEMENTAL
 2004   Fortran 2003    object orientation, C interoperability, procedure pointers
 2010   Fortran 2008    coarrays (parallelism!), submodules, DO CONCURRENT
 2018   Fortran 2018    more parallel features, better C interop  ← our baseline
 2023   Fortran 2023    conditional expressions, enumerations, typeof

Notice a detail hidden in that table that tells the whole story. Through 1977 the name is written FORTRAN, in capitals, the way you shout the name of a machine. From 1990 onward it is Fortran, in ordinary title case, the way you write the name of a language you live with. The change was deliberate, and it marks the great divide of this book. FORTRAN 77 and earlier is the language of the caricature: fixed columns, COMMON blocks, GOTO, variables typed by the first letter of their name. Fortran 90 and later is a modern language — one with arrays, modules, dynamic memory, and, by 2008, built-in parallelism. They are related the way Latin is related to Italian: the same lineage, but you would not confuse a speaker of one for a speaker of the other.

💡 Intuition: When someone says "Fortran," ask which Fortran. The distance from FORTRAN 77 to modern Fortran is larger than the distance from C to C++ — and almost everyone who dismisses the language is picturing the 1977 version, which turns forty-seven this year.

This book teaches modern Fortran, with the 2018 standard as the baseline and modern style — free-form source, implicit none, modules, intent on every argument — as the default from the first line of code. We will meet the old language too, in Part IV, because you will inherit it and need to read and modernize it. But we will always label it as legacy, and we will always show you the modern replacement beside it. You are learning Italian, not Latin — though by the end you will be able to read the Latin when you find it carved into an old codebase.

📜 From History: The 1966 standard made FORTRAN the first programming language ever standardized by a national body. That act — agreeing, across competing hardware vendors, on exactly what the language meant — is a large part of why fifty-year-old Fortran programs still compile and run today. Standards are unglamorous, and they are the reason the science encoded in old Fortran has not evaporated.

1.2 Where Fortran Runs Today

It is easy to believe a language is dead when you never see it — and if your world is web development, mobile apps, or data science notebooks, you genuinely never will. Fortran lives in a part of computing that is enormous, consequential, and nearly invisible to the public: high-performance scientific computing, the business of running the largest calculations humanity performs.

Definition (high-performance computing). Often abbreviated HPC: the use of the most powerful available computers — clusters of thousands to millions of processor cores — to solve problems too large for an ordinary machine. Weather forecasting, climate projection, and the simulation of physical systems from galaxies to reactor cores are the classic HPC workloads.

Consider a single, ordinary morning. Overnight, the national weather services of the world ran their forecast models — enormous simulations of the atmosphere — so that a number could appear on your phone telling you whether to bring an umbrella. The most widely used research forecast model, WRF (the Weather Research and Forecasting model), is written in Fortran. So is CESM, the Community Earth System Model, one of the codes behind the climate projections that inform national policy. When an aerospace engineer simulates air flowing over a wing, or a chemist predicts how a molecule will behave, or an astrophysicist models a supernova, the odds are very good that the code doing the heavy arithmetic is Fortran. Quantum-chemistry packages such as VASP and Quantum ESPRESSO, structural-analysis codes descended from NASTRAN, and countless in-house simulation codes at national laboratories are Fortran through and through.

And beneath almost all of it sits a layer most programmers never think about. The numerical libraries that every language reaches for when it needs serious linear algebra — LAPACK and BLAS, the routines that solve systems of equations and multiply matrices — are written in Fortran. When your Python code calls numpy.linalg.solve, or your MATLAB session inverts a matrix, or your R script fits a linear model, the actual number-crunching very often happens inside compiled Fortran that has been tuned over four decades. You have been running Fortran for years without knowing it.

🔗 Connection: That LAPACK sits underneath NumPy is not a historical accident you can ignore — it is a practical skill. In Chapter 21 you will call LAPACK directly from Fortran to solve $A\mathbf{x} = \mathbf{b}$, and you will see how little stands between you and the fastest linear algebra on the planet.

The list of domains goes on, and each one is an entire industry. In seismic processing, oil and gas companies turn petabytes of echoes bounced off underground rock into three-dimensional maps of what lies beneath — a computation done, overwhelmingly, in Fortran. In nuclear engineering, the codes that model neutron transport through a reactor core, and that help certify that a reactor is safe, are Fortran, some descended from programs first written in the 1960s and validated against decades of measurements. Astrophysicists simulate colliding galaxies, exploding stars, and the formation of the cosmic web with Fortran codes that run for months on the largest machines in existence. Computational chemists and materials scientists predict, from the equations of quantum mechanics alone, whether a compound will superconduct or a drug molecule will bind. Even parts of finance run on legacy Fortran, in the quantitative systems that price complex instruments — another "old" technology that refuses to die because it does its job.

What unites these fields is a shape of computation: enormous amounts of floating-point arithmetic, over enormous arrays of numbers, repeated over enormous numbers of steps. A single climate run may execute quintillions of arithmetic operations; a single reactor simulation may march its state forward for simulated seconds that take real days to compute. At that scale, a factor of two in speed is not a nicety — it is the difference between a result this week and a result next month, or between a simulation that fits in the compute budget and one that never runs at all. This is the world Fortran was built for, and the reason its speed is not a bragging point but a survival trait.

What about the supercomputers themselves? You will often hear that Fortran "runs on every supercomputer." Be careful with that claim, because it is easy to state in a way that is false. Every machine on the TOP500 — the semiannual ranking of the world's fastest supercomputers — runs the Linux operating system, and Linux is written in C, not Fortran. What is true, and what matters, is that a very large share of the scientific application cycles on those machines — the actual computation the machines were bought to do — is spent inside Fortran codes. The operating system is C; the science is very often Fortran.

⚠️ Common Pitfall: Do not oversell Fortran, and do not let anyone oversell it to you. "Fortran runs the supercomputers" is the kind of slogan that gets a careful listener to dismiss the whole argument. The honest, and still remarkable, statement is this: for the dense numerical kernels at the heart of scientific computing, Fortran remains one of the dominant languages, and often the fastest. That is enough. It does not need embellishment.

This is our first recurring theme, and it will return in almost every chapter: Fortran is not dead. It is infrastructure — the load-bearing kind you only notice when it fails, which is why you do not notice it at all.

1.3 Why It Persists, Part One: Arrays and the No-Aliasing Advantage

A language does not survive seventy years and stay dominant in a competitive, performance-obsessed field out of sentiment. Fortran persists because it is fast — specifically, because compilers can turn Fortran into extremely efficient machine code for numerical work. Two design decisions, both made very early, are most of the reason. You will not fully appreciate them until Part VII, where we measure their effects, but you should meet them now, because they explain the shape of everything in between.

The first decision: arrays are first-class objects. In Fortran, an array is a genuine thing the language understands — it knows the array's shape, its bounds, and how it is laid out in memory — and you can operate on a whole array at once. If a, b, and c are arrays of the same shape, then

a = b + c

adds them element by element, in a single statement, with no loop written by you. The compiler, knowing it has an entire array operation in front of it, is free to unroll it, vectorize it, or hand it to multiple processors. Contrast this with C, where an "array" is really just a pointer to the first element and the language has no built-in notion of its shape; every array operation is a hand-written loop over raw memory addresses, and the compiler must work harder to recover the structure that Fortran never threw away in the first place.

🚪 Threshold Concept. Once you start thinking of an array as a single object you compute with — rather than a bag of elements you loop over — a great deal of Fortran, and a great deal of its speed, falls into place. Whole-array operations are not just less typing; they hand the compiler the information it needs to make the operation fast. We build this habit deliberately in Chapter 5, the pivotal chapter of Part I.

The second decision: function arguments are assumed not to alias. This one is subtler, and it is the secret weapon. When you pass two arrays into a Fortran procedure, the language promises the compiler, by default, that they do not secretly refer to overlapping regions of memory.

Definition (pointer aliasing). Two names alias when they refer to the same memory. If a compiler cannot rule out that x and y might be the same storage, it must assume that writing through x could change y, which forbids many reorderings and optimizations. Fortran's rule that procedure arguments do not alias frees the compiler to optimize aggressively; C, where any two pointers might alias, historically could not — which is exactly why C99 added the restrict keyword, a way for the C programmer to promise the compiler what Fortran guarantees automatically.

The consequence is concrete. Consider a routine that reads from one array and writes to another. In Fortran, the compiler knows the input and output cannot overlap, so it can load, compute, and store in whatever order is fastest — and modern processors are dramatically faster when they can stream through memory predictably. In C, without a restrict annotation, the compiler must assume the worst: that every write might have changed the thing it is about to read, forcing it to reload and serialize. The same algorithm, the same hardware, and Fortran's version can be substantially faster for no reason other than what the language lets the compiler assume.

⚡ Performance Note: These are not small effects. Loop-order and aliasing differences routinely account for factors of several, and occasionally an order of magnitude, in numerical kernels. We will measure exactly this in Chapter 27, where you will see the same computation run 10× faster from a change of loop order alone — a direct consequence of the array layout Fortran chose in 1957.

It is worth seeing the shape of the difference even before you can write either version fluently. Suppose you want to scale every element of a large array by a constant and add it to another array — the humble operation that appears a thousand times in any simulation. In C, you write the loop yourself, over raw indices:

for (int i = 0; i < n; i++)
    y[i] = y[i] + a * x[i];

and unless you promise otherwise with restrict, the compiler must worry that x and y might overlap in memory, which limits how aggressively it can reorder and vectorize the work. In Fortran, you write the operation on the arrays themselves:

y = y + a * x

and the compiler knows the shapes, knows the arrays are distinct, and is free to vectorize the whole thing — to use the processor instructions that operate on many numbers at once — without a second thought. The Fortran is shorter, it reads closer to the mathematics, and it hands the compiler more freedom, not less. You are not trading control for convenience; you are giving the compiler exactly the information it needs to be fast. That trade sits at the heart of the language, and once you see it, you will see it everywhere.

Here is the theme, stated plainly, that will recur throughout the book: arrays are Fortran's superpower, and performance is not accidental. The language was built around the shapes of numerical computation, and its compilers have had sixty years to exploit that. When your computation is a dense sea of floating-point arithmetic over big arrays — which is what most of physical simulation is — you are running downhill, and the language is on your side.

🐍 Python Comparison: "But NumPy is fast!" Yes — because NumPy's array operations are implemented in compiled C and Fortran, so when you write a + b in NumPy you are calling down into exactly the kind of code this book teaches you to write. The moment your computation cannot be expressed as a handful of big NumPy calls — the moment it becomes an element-by-element loop with data dependencies, as real simulations invariably do — pure Python falls off a cliff, often 50–100× slower, and you reach for Fortran. We measure that gap ourselves in Chapter 15.

1.4 Why It Persists, Part Two: Legacy, Domain Fit, and "Modern Fortran Is Good"

Speed is the headline, but three more forces keep Fortran firmly in place.

There is an ocean of existing code, and it is correct. Decades of scientific Fortran — millions upon millions of lines — encode physics that has been validated against real experiments, tuned against real data, and trusted with real decisions. A weather model is not just software; it is the accumulated judgment of generations of atmospheric scientists, expressed in code. Rewriting it in a fashionable language is not a weekend refactor; it is a multi-year project with a high risk of quietly breaking science that no living person fully remembers the reasons for.

Definition (legacy code). Working, deployed, often old software that an organization depends on and must keep running. In scientific computing, "legacy" is not an insult — it is frequently a synonym for "validated," "trusted," and "irreplaceable." The Fortran you inherit is usually load-bearing.

This gives us another recurring theme, and a professional ethic worth adopting now: legacy code is not a burden. It is an inheritance. The right response to a crusty old Fortran code is not to sneer at it or rewrite it from scratch, but to understand it, test it, and modernize it — improving the engineering while preserving the science. Part IV teaches exactly that discipline, and its motto is one you should tape to your monitor: never rewrite what you can refactor.

Fortran fits its domain the way a key fits a lock. Every language is shaped for something. Python is shaped for gluing systems together and expressing ideas quickly; JavaScript for the browser; SQL for querying tables. Fortran is shaped for numerical computation on arrays. Its native support for complex numbers, its rich library of mathematical intrinsic functions, its whole-array operations, and its column-major layout are not features bolted on for scientists — they are the center of the language. When the thing you are building is a numerical simulation, Fortran's defaults are almost always what you want, and the code reads much closer to the mathematics than the equivalent in a general-purpose language.

Modern Fortran is genuinely good. This is the point that surprises people most. The Fortran of 2018 is a modern programming language by any reasonable standard. It has modules for organizing code into clean namespaces with explicit interfaces. It has derived types — your own data structures — and full object orientation: inheritance, polymorphism, abstract interfaces. It has allocatable arrays that size themselves at run time and clean up after themselves. It has coarrays, a parallel programming model built into the language itself, which most languages can only reach through external libraries. It has standardized interoperability with C, and through C, with everything. It is a language you can write well and enjoy writing — and that is the theme of the whole book: modern Fortran is a modern language. If your mental image is punch cards and GOTO, that image is four decades out of date.

🔧 Modern vs Legacy: A taste of the difference, which we will develop at length in Part IV. The same idea — a block of shared program state — looks like this in the two eras:

fortran ! Legacy (FORTRAN 77): global state by memory overlay, fragile and untyped COMMON /STATE/ X, Y, N

fortran ! Modern: a module — a real namespace, with types and controlled access module state use kinds, only: dp implicit none real(dp) :: x, y integer :: n end module state

The modern version is not merely prettier. It is checked by the compiler, it cannot silently corrupt memory, and it can be reasoned about in isolation. That is the transformation this book teaches.

Put those four forces together — raw speed, an irreplaceable base of validated code, an exact fit to the numerical domain, and a current standard that is genuinely modern — and the persistence of Fortran stops looking like inertia and starts looking like what it actually is: a rational choice, made again and again by people who care intensely about performance and have carefully measured their options. No national lab keeps its flagship code in Fortran out of sentiment. They keep it there because when they seriously tried the alternatives, Fortran was faster, safer to evolve, and closer to the physics. Every year that a research group renews its investment in a Fortran code is a year that a room full of skeptical, budget-conscious experts looked at the whole landscape and concluded, once more, that this seventy-year-old language is the best tool for the job. That is a far more convincing endorsement than any slogan, and it is the quiet fact that this entire book is an elaboration of.

1.5 The "Dead Language" Myth, Debunked

Where does the myth come from, then, if the reality is a living and dominant language? It is worth understanding, because a good rebuttal starts by taking the other side seriously.

The myth has real roots. For one, Fortran genuinely did stagnate: the leap from FORTRAN 77 to Fortran 90 took thirteen years, and during that long gap the language really was frozen in its worst form while C, and then C++, surged. For another, most people's only encounter with Fortran is a glimpse of old FORTRAN 77 — fixed columns, uppercase, GOTO — which is genuinely unpleasant and genuinely obsolete, and they reasonably conclude that the whole language is like that. And finally, Fortran is invisible: it lives in national labs and research groups, not on GitHub's trending page or in job ads for startups, so the parts of the industry that are loudest online simply never see it.

Now the rebuttal, in facts:

• The language is actively evolving. A new standard shipped in 2023, with another in preparation. A dead language does not get new features every few years. We survey the 2023 additions in Chapter 39.
• The tooling is being rebuilt in the open. The fortran-lang community has, in just the last few years, produced a package manager (fpm), a standard library, an online playground, and a brand-new interactive compiler (LFortran). This is the activity of a language on the way up, not out.
• The jobs exist and go unfilled. In several sectors — national laboratories, weather and climate agencies, aerospace, energy — there are, by widespread report, more Fortran positions than there are people who can fill them, precisely because the language is wrongly assumed to be dead and few new graduates learn it. We return to this, with career specifics, in Chapter 40.
• The computation has not moved. The scientific problems Fortran is good at — simulating physical systems on big arrays — are not going away, and no competitor has displaced it from them. C++ is formidable but more complex and not obviously faster for these kernels; Julia is promising and worth watching but young; Python is the orchestrator, not the engine.

🧩 Try It Yourself: Before reading on, spend two minutes forming your own one-sentence answer to a skeptical colleague who says "why would anyone learn Fortran in 2026?" Write it down. At the end of the book, compare it to what you would say then. The gap is the measure of what you have learned.

None of this means Fortran is the right tool for everything — it is emphatically not. You would not write a website in it, or a mobile app, or a quick data-wrangling script; for those, reach for the languages built for them. Fortran's claim is narrow and deep: when you need to run a large numerical computation fast, it is one of the best tools in existence, and often the best. Knowing when to use it — and being one of the shrinking number of people who can — is a genuine professional advantage.

1.6 How This Book Works

You are holding a large book, and it is large on purpose. Fortran taught properly is not small, and we carry you the whole distance — from installing a compiler to running code across the nodes of a cluster. Here is the map.

Ten parts, in a deliberate arc. Part I builds the foundations: types, control flow, arrays, procedures, I/O. Part II adds the modern features — modules, derived types, object orientation. Part III connects Fortran to C, to Python, and to the wider ecosystem. Part IV teaches you to read and modernize old code. Part V does the numerical computing Fortran was born for. Part VI handles scientific data and visualization. Part VII makes your code fast, and Part VIII makes it parallel. Part IX shows how real scientific software is engineered, and Part X looks ahead.

Four reading tracks. You met them at the top of this chapter: 🔬 Scientist, 📖 Standard, 🔧 Legacy, and ⚡ HPC. Every chapter's Learning Paths box tells you what it offers each track, so you can read the whole book front to back or cut a path straight to what you need.

Every chapter is more than prose. Alongside the main text you get exercises that make you type, compile, and run; two worked case studies; a self-check quiz; a one-page reference card; and a short guide to going deeper. The code is real, modern Fortran that compiles with gfortran, always shown with the command that compiles it and the output it produces.

⚠️ Common Pitfall — a promise we keep about honesty. No program in this book was executed while the book was written. Every "expected output" was computed by hand. This is a deliberate discipline: a confidently wrong worked example is worse than no example at all, so we would rather reason carefully and let you catch us when you compile it yourself. When your result matches ours, you will know you got it right — and if it ever does not, you have found a bug, and we would like to hear about it.

And you will build something. This brings us to the sixth theme — Fortran and Python are better together — and to the project that ties the whole book into one story.

Project Checkpoint

Reading about a language teaches you its vocabulary; building something teaches you the language. So running through all forty chapters is one continuous project, and this is where you begin it.

You are going to build a two-dimensional heat-equation solver. Picture a square metal plate. You hold its edges at fixed temperatures — say, one hot edge and three cold ones — and you want to know how heat spreads through the interior over time until it settles. This is one of the fundamental problems of computational physics, it is the gateway to an entire family of simulations (fluid flow, diffusion, wave propagation), and it is small enough to hold in your head and real enough to matter. Its governing law, which we will not solve until Chapter 24, is the heat equation:

$$ \frac{\partial u}{\partial t} = \alpha \nabla^2 u $$

where $u$ is temperature, $t$ is time, and $\alpha$ is how readily the material conducts heat. You do not need to understand that equation yet. You only need to know that by the end of this book you will have written a program that solves it — and not a toy program. Your solver will grow, one chapter at a time, into something modular, tested, optimized, and parallel, running across many processor cores and writing out visualizations you can watch evolve.

Your checkpoint for Chapter 1 is a decision, not code:

1. Choose your domain. The default, and the one the book works through in full, is the 2D heat equation. If you would rather build a fluid-flow solver or an N-body gravitational simulation, you may — the structure is identical, and every checkpoint will translate. But if you are unsure, take the heat equation; it is the path of least resistance and every worked example will match your code.
2. Write down, in two or three sentences of plain language, the problem you will solve. For the heat equation: "A square plate, hot on one edge and cold on the others. I want to simulate how the interior temperature evolves over time and see it reach a steady state." Put it in a file called README.md in a new folder named heat-solver/. That folder is where your project will live for the rest of the book.

That is the entire assignment: pick the problem, and name it. In Chapter 2 you will install a compiler and write the first line of the program itself — the humble program heat that, forty chapters from now, will be a real simulation you built and understand completely.

Summary

This chapter argued that Fortran is a living, dominant, and worth-learning language, and set up the book that teaches it.

The two things worth remembering from this chapter: first, that when someone says "Fortran," you should ask which Fortran — the distance between the eras is enormous. Second, that Fortran's speed is not magic but the payoff of two old design choices — first-class arrays and no aliasing — that you will learn to exploit deliberately in Part VII.

Spaced Review

This is the first chapter, so there is nothing yet to review — instead, here are four questions you will be able to answer by the end of the book. Note your instinct now; revisit it later and measure how far you have come. (Answers, of course, are the rest of the book.)

1. Why can a change of loop order alone make a Fortran numerical routine ten times faster?
   

   Where you'll learn it

   Column-major memory layout meets the CPU cache — [Chapter 5](../chapter-05-arrays/index.md) sets it up, [Chapter 27](../../part-07-performance/chapter-27-why-fortran-is-fast/index.md) measures it.

2. How would you call the LAPACK routine dgesv from Fortran to solve $A\mathbf{x}=\mathbf{b}$?
   

   Where you'll learn it

   [Chapter 21](../../part-05-numerical-methods/chapter-21-linear-algebra-lapack/index.md).

3. How do you wrap a Fortran routine so Python can call it, and how much faster is it than pure Python?
   

   Where you'll learn it

   f2py, in [Chapter 15](../../part-03-interoperability-and-ecosystem/chapter-15-python-interoperability/index.md).

4. What is a coarray, and how does it let a Fortran program run across many processors with no external library?

   Where you'll learn it

   Chapter 32.

What's Next

Enough about why. Chapter 2 gets a Fortran compiler onto your machine — on Linux, macOS, or Windows — and walks you through the compile–link–run cycle with your first real program. By the end of it you will have written, compiled, and run Fortran of your own, and started the heat program that this whole book is quietly building toward. Let's install a compiler.