The Last Engineers: A Record of Vanishing IT Traditions (6)

Episode 6: FORTRAN

The Language of Immortal Equations

This article is a documentary-style creative column that begins with a reader's question. While not based on an actual program interview, it is structured to layer the atmosphere that once existed in Japanese technical workplaces with questions about the current AI era.

In the first episode, I spoke with Mamoru Kodai about fuzzy control.

It was an era when machines were trying to understand human "vague" intuition. There, one could find engineers who did not mock human ambiguity.

In the second episode, I spoke with Shiro Sanada about assembly language.

Registers, addresses, interrupts, clocks. It was a story of an era when humans took on the machine's burdens right alongside machine code.

In the third episode, I spoke with Juzo Okita about COBOL.

Abacuses, banking figures, currency counting, ATMs, overnight batches, land myths. COBOL was a language that transferred the physical skills of bank clerks and the memories of society into machines.

In the fourth episode, I spoke with Hikozaemon Tokugawa about TRON.

Domestic OS, Super 301, trade wars, Huawei, and the AI myth. TRON was the memory of engineers who tried to design the engine room of society themselves.

In the fifth episode, I spoke with Giichi Aihara about the fax machine.

The fax machine was not a machine for sending paper. It was a machine for sending responsibility. From an era when money moved with a single sheet of paper to an era where markets are shaken by a few lines on social media, the form of information warfare has changed, but human gullibility has not.

In the sixth episode, we visit FORTRAN.

FORTRAN.

It is an old language.

That is what people say.

FORTRAN in this day and age? Is it still alive? Isn't it just left in old university laboratories? In an era with Python, Julia, C++, and AI, why use a language from decades ago?

It is easy to ask that.

However, that question alone does not reach the essence of FORTRAN.

FORTRAN is not an old language.

It is a language that has been verified for decades to see if mathematical formulas could withstand reality.

This time, the question sent in by a reader was as follows.

"I thought FORTRAN was a language from the past. However, I hear it is still used today in supercomputers and scientific and technical calculations. Why does such an old language still exist?"

To trace the answer to this question, we visited a former numerical analysis engineer.

An old house on a hill overlooking a port town.
From the study window, you can see the sea and the shipyard cranes.

That is where Yasuo Nanbu, seventy-eight, lives.

He is an engineer who once worked in the research department of a heavy industry manufacturer, involved in numerical calculations for fluid analysis, structural analysis, thermal analysis, turbine design, rocket parts, and nuclear-related facilities.

On his desk were thick textbooks on numerical analysis, yellowed FORTRAN listings, bundles of punch cards, magnetic tape labels, plots of old calculation results, and files marked 'Verified' in red ink.

Nanbu-san pressed his finger on an old program listing and said quietly.

"FORTRAN was a language for feeding mathematical formulas to a computer."

FORTRAN is a name derived from Formula Translation. IBM's FORTRAN was created in 1954 and commercially released in 1957, making it a very important language in the history of modern high-level languages and compilers. IBM itself positions FORTRAN as one of the influential pieces of software that opened the door to modern computing.

Nanbu-san smiled slightly.

"Young people today say they write code. In our day, it was closer to say we passed formulas to the machine. Differential equations, matrices, iterative calculations, convergence criteria. How to make the machine calculate the formulas that were on paper. That was our job."

The fields where FORTRAN has been used are not flashy.

However, they are all directly connected to the real world.

Weather forecasting.
Ocean forecasting.
Fluid analysis.
Structural analysis.
Heat conduction.
Nuclear power.
Aerospace.
Material calculations.
Numerical linear algebra.
High-performance computing.

The Fortran-lang documentation also states that Fortran is used in fields that introduced computing early on in science and engineering, such as weather and ocean forecasting, computational fluid dynamics, applied mathematics, statistics, and finance, and that it is an important language in high-performance computing.

Nanbu-san looked at the crane outside the window.

"Whether a bridge will collapse. Whether a wing will vibrate. Whether a furnace will get too hot. Where a typhoon will go. What kind of force is applied to a ship's hull. You can't tell those things by sheer willpower. You have to calculate them."}]

We have no choice but to calculate.

Those words carried weight.

There are phenomena that cannot be seen by human senses alone.

Airflow.
Water flow.
Heat diffusion.
Stress concentration.
Vibration growth.
Turbulence.
Shock waves.
Boundary layers.
Eigenvalues.
Convergence error.

They are invisible to the eye.

However, they exist in reality.

Turn the invisible into mathematical formulas.
Discretize the formulas.
Turn the discretized data into matrices.
Have the computer solve the matrices.
Verify whether the results can withstand reality.

FORTRAN was there on the front lines.

FORTRAN is not a language for creating pretty screens. It is a language for confronting reality. If the calculation results are wrong, it doesn't just end with a mistake on paper. Bridges, wings, reactors, and machines—reality itself will provide the final answer.

It is reality that provides the final answer.

These words describe the world of FORTRAN well.

The program ran.
The calculation finished.
The graph was generated.
The paper was written.

Even so, it is not the end.

Is the value physically correct?
Are the units correct?
Are the boundary conditions valid?
Is the rounding error within an acceptable range?
Is the mesh too coarse?
Has it converged?
Does it break if the initial conditions are changed slightly?
Does it match the experimental values?

Mr. Nanbu showed me an old graph.

Hand-drawn axes.
Lines drawn by a plotter.
Notes written in red pencil.
In the margins, there were words like 'Recalculate,' 'Check boundary conditions,' and 'Compare with experimental values.'

Computers provide answers. But they don't necessarily provide the correct ones. It is dangerous to mistake the two. The belief that it must be correct because a computer produced it is the most dangerous faith of all.

These words resonate just as strongly in the age of AI.

Now, we ask questions to generative AI.
The AI returns plausible answers.
It produces text, code, formulas, and graphs.

However, what is output and what is correct are two different things.

Mr. Nanbu's expression turned slightly stern.

"We live in an era where AI writes code. That is convenient. But convenience and correctness are different things. A calculation running and a calculation matching reality are different. If you mistake the two, you will learn the hard way in scientific and technical computing."

In the world of FORTRAN, they have been learning that lesson the hard way for decades.

Mistaking an array index by one.
Confusing single precision with double precision.
Mixing up unit systems.
Getting boundary conditions wrong.
Using incorrect initial values.
The matrix becoming ill-conditioned.
Looking like it converged when it actually hasn't.

Each one of those things changes the result.

Sometimes, it changes design decisions.

Sometimes, it changes safety.

"Old FORTRAN code sometimes contains a strange line. Why is the coefficient slightly changed here? Why is this condition treated differently? Why is this array allocated with extra space? Young people call it messy. But those are the scars from past battles with reality."

Scars from battles with reality.

That expression is similar to the "thickness of social convenience" mentioned in the COBOL chapter.

COBOL code was filled with exceptions for regulations and business operations.

FORTRAN code is filled with exceptions for physics and numerical calculations.

It diverged at the boundary.
The turbulence model didn't fit.
It deviated from experimental values.
It became unstable under specific conditions.
The results changed slightly when the compiler was changed.
It became faster when vectorized, but the rounding errors changed.
It stopped matching old results when the supercomputer was changed.

The traces of such battles remain in old code.

Mr. Nanbu pointed to a line in an old printout.

"You can't understand this line just by looking at the comments. When the people who knew why it was done that way are gone, it just looks like old code. But sometimes, that one line is what keeps the calculation stable. Deleting it is easy. Knowing what will happen after you delete it is the hard part."

FORTRAN is a tenacious language.

Why is it so tenacious?

There are several reasons.

It is strong in numerical calculation.
It is easy to handle arrays.
The compiler has been optimized for many years.
There is a massive amount of existing assets in scientific and technical computing.
There are verified libraries.
Old code is still being used in research and industry today.

For example, LAPACK, a representative library for numerical linear algebra, is written in Fortran 90 and provides routines for solving systems of linear equations, least squares problems, eigenvalue problems, and singular value problems.
BLAS, meanwhile, is a standard set of basic building blocks for vector, matrix-vector, and matrix-matrix operations; it is efficient, highly portable, and widely used in the development of high-quality linear algebra software like LAPACK.

Mr. Nanbu smiled a little ironically here.

"Young people think they are doing calculations in Python. Of course, that is fine. But they should care a little about who is actually multiplying the matrices behind the scenes. Even if it is Python on the screen, there are times when the old numerical calculation craftsmen are still working in the basement."

The basement.

In this series, I have visited that place many times.

Fuzzy control was in the back of the kitchen for home appliances.
Assembler was behind the registers and addresses.
COBOL was behind the forms of banks and government administration.
TRON was in the engine room of society.
FAX was in the corridor of paper and responsibility.

FORTRAN is in the basement of mathematical formulas.

Behind the glittering screens of the AI era, matrices are being multiplied, eigenvalues are being found, and differential equations are being solved.

"AI, too, is calculation in the end. Vectors, matrices, optimization, error, convergence. Even if the names change, the calculation remains. No matter how fluent the language becomes, in the world of numbers, what remains at the end is error."

What remains at the end is error.

Mr. Nanbu's words are not just an old man's tales.

They are a warning to the AI era.

Generative AI has persuasive power in the world of language.

Plausible explanations.
Well-structured sentences.
Plausible-looking code.
Beautiful graphs.
Confident answers.

However, in the world of numerical calculation, atmosphere does not work.

The answer is questioned by digits.
It is questioned by units.
It is questioned by convergence.
It is questioned by reproducibility.
It is questioned by verification.
It is questioned by experimentation.
It is questioned by reality.

Mr. Nanbu said, staring at old calculation results.

"Humans feel relieved when they see a pretty diagram. If it is a graph produced by AI, they want to trust it even more. But what was calculated behind that diagram? Which formula was used? Which boundary conditions were set? If you don't look at that, it is just a picture."

Just a picture.

These words also strike home for modern presentation materials.

A clean diagram created by AI.
An automatically generated report.
A plausible-looking simulation.
A convincing growth forecast.
A fluid visualization.

It looks like there is a mathematical formula there.

However, whether the formula is connected to reality is another matter.

Mr. Nanbu continued.

"In the old days, there were people who would only bring the calculation results. But we would ask first: What about the mesh? What are the boundary conditions? How did you determine convergence? Did you compare it with experimental values? Are the units correct? When asked this, they would usually go silent."

Allow me a slight digression in the style of Rintaro Takechi here.

Recently, there has been a lot of talk about AI, ASI, omniscience, and human wisdom becoming ten thousand times greater.

A fictional character named Masayoshi Sonda of Sodom Bank seems to be preaching that future intelligence will solve everything, touting giant data centers and the AI myth.

Mr. Nanbu makes a bitter face when he hears such talk.

"It is fine if intelligence becomes ten thousand times greater. But what are the units? What are the boundary conditions? How was the error evaluated? Who checked the convergence? In the world of mathematics, those are the things you ask."

This sounds like a joke, but it is not.

Many AI myths talk about quantities.

How many times smarter it will become.
How many trillion parameters it will have.
How many gigawatts it will use.
How many trillion yen will be invested.
In how many years it will reach ASI.

However, having quantity is different from being verified.

Mr. Nanbu closed the old FORTRAN listing.

"A large number is not the same as a correct calculation. It is not correct just because a supercomputer was used. It is not correct just because an AI said so. What matters is whether that calculation has withstood reality."

Whether it has withstood reality.

That is the reason why FORTRAN has remained for so long.

It did not remain because it is old.

It remained because it has withstood reality.

Of course, FORTRAN has its problems.

Old formatting.
Fixed-form source.
GOTO statements.
COMMON blocks.
Implicit type declarations.
Hard-to-read legacy code.
Absent maintainers.
Lack of documentation.
Overly long subroutines.
Compiler-dependent behavior.
Subtle differences during porting.

I understand well why young people dislike it.

Mr. Nanbu does not deny this either.

"Old FORTRAN code is certainly hard to read. Even the person who wrote it might scratch their head twenty years later. But listen, being hard to read is not the same as being worthless. It contains decades of accumulated verification."

Decades of verification.

That is something modern, new code does not yet possess.

You can rewrite it beautifully in a new language.

However, the moment you rewrite it, the history of that verification can be lost.

Will it produce the same results?
Will it hold up under extreme conditions?
Does it match old experimental data?
Can it reproduce the results of past papers?
Will it affect industrial safety margins?

Replacement is not merely translation.

It is the task of taking on the burden of verified reality all over again.

"Young people say that if you rewrite it, it becomes clean. It certainly does become clean. But in computation, being clean is not enough. If messy old code has been cross-referenced with experimental data for decades, there is meaning even in that messiness."

FORTRAN is an old language.

However, the word 'old' has two meanings.

One is that it is obsolete.
The other is that it has been used for a long time, tested, and has survived without breaking.

FORTRAN is also the latter.

Mr. Nanbu took an old punch card out of his desk drawer.

Small holes were lined up in a regular pattern.

"Back in the day, there was tension even in a single card like this. If you made one mistake with a hole, the calculation would fail. Now, you can fix things on a screen as much as you want. It has become convenient. But when things become convenient, mistakes also seem trivial. That is what scares me."

Punch cards.
Magnetic tape.
Mainframes.
Vector computers.
Supercomputers.
Clusters.
GPUs.
Cloud.
AI.

Computing environments have changed.

However, the questions remain the same.

Is that formula correct?
Is that approximation valid?
Is that margin of error acceptable?
Can that calculation be reproduced?
Does that result hold up in reality?

FORTRAN was a language that continued to carry those questions.

Mr. Nanbu finally closed an old file.

On the cover, it was written by hand:

"Verified"

Those three characters held a weight that we in the AI era are beginning to forget.

Generated.
Outputted.
Visualized.
Summarized.
Optimized.

These are not yet "Verified."

Mr. Nanbu said:

"First, let me see the calculation results. That is where it remains whether or not that formula stood up to reality."

Episode 6, FORTRAN.

It is the story of a language of mathematical formulas that, while said to be dead, continues to run in the depths of scientific and technical computing even now.

FORTRAN is not an old language.

It is a language that has left behind in machines the mathematical formulas that have stood up to reality.

Next time, dedicated word processors.

Bungo, OASYS, Shoin, Thumb-shift, vertical writing, ruled lines, New Year's cards, and on to Pomera. We will visit the era when the act of writing Japanese was still a special task within a machine.

Text by Rintaro Takechi