Welcome to the Deep Dive, where we unpack your
source material and find the insights that matter
most. Today we're diving deep into the life and
the monumental legacy of a figure who not only
defined modern computing, but then in this amazing
twist of intellectual honesty, spent his later
years trying to undo the very constraints he
himself helped create. We're talking about John
Bacchus. That's exactly right. Our sources paint
this really compelling picture of a man whose
career had, you know, three profound and very
distinct acts. Act one, inventing the first widely
used high -level language, Fortran. And this
just instantly brought computing out of these,
like, specialized labs and into the hands of
scientists and engineers. Right, for the masses.
So the scientific masses, yeah. Then act two,
formalizing how we even describe a language's
structure through the notation we now know as
Bacchus -Nor form or BS. that really cemented
the intellectual foundations of the field. And
then act three, delivering this fundamental philosophical
critique of the entire programming paradigm he
helped establish, that sequential procedural
von Neumann style. So our mission today is to
understand not just these three influential contributions,
but how they all connect. I mean, how the necessities
of the 1950s led to a revolution. Which then
demanded a formal structure. And then that structure,
I guess, revealed its own limitations, which
led to a philosophical overhaul. Exactly. And
Bacchus wasn't just foundational. He was heavily
decorated. We're talking about a recipient of
the National Medal of Science in 1975 and the
ultimate prize in computing, the ACM Turing Award
in 1977. And that Turing Award specifically recognized
his, quote, profound and lasting contributions
to the design of practical high level programming
systems, which is Fortran. Right. And then for
the formal procedures he created for specifying
programming languages. That's the BNF part. It's
this extraordinary recognition of both a practical
system builder and, you know, a deep. theoretical
formalist. A builder and a thinker. Yes. But
what's truly fascinating and what our sources
really highlight is that before all the accolades,
before the global scientific impact, his path
was, well, it was anything but straight. Yeah,
this isn't the story of some childhood prodigy.
Not at all. It's the story of delayed genius,
if anything. Okay, let's unpack this and start
right at the beginning. The surprisingly circuitous
route John Bacchus took to even find his way
into computer science. If you track his early
academic record, it's honestly just striking
how much he struggled to find any kind of focus.
He was born in 1924, grew up in Wilmington, Delaware,
and he started at the Hill School in Pennsylvania
where he did not exactly thrive. Right. He later
said he was just terrible at keeping track of
things. Which is pretty ironic for the guy who
would later invent the formal notation for language
grammar, right? Struggled is definitely putting
it politely. I mean, the sequence of events right
after high school, it looks... Less like a path
to greatness and more like a young man just running
away from any kind of structure. Oh, completely.
He enters the University of Virginia to study
chemistry, and that lasts less than a year. Why?
What happened? The records show he was expelled
for poor attendance. So we're talking about a
mind that would later design these systems for
ultimate efficiency. And at first, he couldn't
grasp the simple efficiency of, you know, showing
up to class. And this was the mid -1940s, so
World War II is in full swing. That expulsion
leads directly to conscription. It does. And
for a lot of intellectually restless young men
at the time, that proved to be a surprising and
I think necessary reset button. But it wasn't
an immediate jump into high tech. No. He starts
as a corporal in the U .S. Army, commanding an
anti -aircraft battery down at Fort Stewart,
Georgia. It's a very gritty, mechanical, command
and control kind of role. But it's during his
time in the service that his actual aptitude
starts to surface, right? Absolutely. He scores
remarkably high on one of those military aptitudes.
tests, you know, the ones designed to sort personnel.
And that score convinces the army to completely
shift his path. They saw this raw, high -level
processing capability and sent him to study engineering
at the University of Pittsburgh. So the military
basically recognized this latent talent and gave
him the structure he couldn't impose on himself.
But even after that, he's still not in computer
science. The search continues. It does. From
Pittsburgh, he moves again. He transfers into
a pre -medical program at Haverford College.
He's still searching for that field that would
engage his unique blend of practical problem
-solving and abstract thought. And this is where
his biography takes a really unusual turn. The
health crisis. A major personal health crisis.
And the way he responded to it, I mean, it's
such a strong indicator of the engineer he was
about to become. It really is. During a hospital
internship, he's diagnosed with a cranial bone
tumor. It was serious, life -threatening, but
it was successfully removed, and the procedure
resulted in a metal plate being installed in
his head. After recovering, he tries medical
school at Flower and Fifth Avenue Medical School,
but, you know, much like his attempt at chemistry,
he just found it uninteresting. He dropped out
after only nine months. So his mind just couldn't
tolerate the rote memorization, it sounds like.
I think so. especially after the intellectual
challenges of war and recovery. So, yeah, he's
failed out of one college, dropped out of two
subsequent programs, and he's had major brain
surgery. That's a really disruptive period. And
then comes the second operation. This is the
anecdote that I think just perfectly demonstrates
his mindset. It is perfect. He needed the original
plate replaced. But instead of just accepting
the standard surgical solution, What does he
do? He designs the replacement himself. He designed
it himself. He ultimately had a metal plate of
his own design installed in his head. It's the
perfect metaphor. He was innately a system designer,
solving a problem of necessity with custom engineering,
even when the system was his own body. Exactly.
He received an honorable medical discharge from
the Army in 1946. And after that, he moves to
New York City and initially trains as a radio
technician. And that's the spark, that hands
-on technical work. That seems to be it. It illuminated
the underlying principles, the mathematics of
systems. And that's what finally captivated him.
He fell in love with pure math. And through that,
he found his field. So he enrolls at Columbia.
He enrolls at Columbia University, earns his
bachelor's in 49 and his master's in 1950, both
in mathematics. He joined IBM that same year,
1950. And that's when his life as a revolutionary
truly begins. And once he was at IBM, the...
The raw, demanding nature of early computing
just forced him to address the biggest practical
problem facing the entire industry, usability.
It did. And that brings us to Section 2, all
about Fortran. And to really appreciate its impact,
you have to ask, what was programming even like
when Backus joined IBM in 1950? I think we, you
know, in the modern age, we just take compilers
and high -level languages for granted. But the
difference between what we do and what Backus
was doing. It's almost impossible to really grasp.
It was unbelievably difficult. His early work
involved the Selective Sequence Electronic Calculator,
the SSCC. It was a marvel of electromechanical
computing. And his first major project was this
practical, high -stakes, but just painstakingly
difficult task. Calculating the moon's position.
Calculating the positions of the moon, which,
you know, required continuous, accurate data.
So the reality of doing that was just manual,
tedious labor. You were writing code directly
in machine language or, you know, assembly at
best. You aren't writing A, F, E, plus C. No,
not at all. You were writing instructions for
register management, for memory fetches, for
carry operations. You had to have this intimate,
deep knowledge of the hardware architecture.
Down to the specific memory cell. Right. Down
to which memory cell held which variable and
how to sequence every single tiny operation through
the accumulator. The programmer's job was fundamentally
mechanical. It was just translating mathematical
logic into this excruciating sequence of hardware
specific instruction. It was slow. error -prone
incredibly error -prone and it required immense
amounts of time just to translate the math into
something the machine could understand the computer's
efficiency was completely bottlenecked by the
programmer's ability to communicate with it manually
so the computer could calculate in microseconds
but it would take a programmer weeks to just
manually lay out the instructions for a single
complex problem that's it exactly the translation
time just defeated the speed of the machine and
this inherent difficulty was the bottleneck it
was preventing computer from becoming truly useful
scientific tools. And Backus saw this. He saw
it clearly. And his first step towards solving
it was a language called speed coding. The stepping
stone to Fortran. In 1953, yeah, he developed
speed coding for the IBM 701 computer. Our sources
note this was the first high -level language
created for an IBM machine. It wasn't FORTRAN
yet, but it was this critical proof of concept.
What did it do? It introduced basic forms of
abstraction. It essentially let programmers write
code that was interpreted by a layer of software
into the necessary machine instructions. It just
immediately showed there was a huge need for
this. It proved abstraction was possible. And
by 1954, the difficulty of low -level programming
was becoming a real crisis for IBM, commercially
and intellectually. This is the inflection point.
This is it. This is where Backus assembles the
team to define and develop FORTRAN. Formula translation.
Formula translation designed specifically for
the new IBM 704 computer, which was significantly
more powerful than the 701. And Backus's mandate
was revolutionary. He had to create a language
that was easy to write, that looked like algebraic
notation. And this is the key part. That could
produce code nearly as efficient as handwritten
assembly. That was the fundamental challenge.
If the compiled code was too slow, scientists
would just ignore it and go back to the old hard
way. So Fortran wasn't just about making programming
easier. It was about creating an efficient compiler
that could manage all the hardware logistics
better than a human could do it manually. That
is the structural significance. Fortran became
the first widely used high -level programming
language because it solved that efficiency problem.
Think about something like array indexing. In
assembly, if you wanted to access AIJ, you had
to manually calculate the memory offset based
on the array's starting address, the column size,
and the indices, I and J. It was tedious. And
Fortran handled all that for you? All of it,
automatically. And the compiler did it optimally.
That's the real revolution. computer accessibility
by abstracting the machinery away. Programmers
could write formulas that looked like x, y, plus
z, i, plus 2 .0, and let the compiler worry about
the registers, the memory allocation, all of
it. So suddenly computers were practical for
the people who actually had the problems to solve.
physicists, chemists, structural engineers. This
single innovation unlocked computing for scientific
and engineering research globally. It shifted
the entire bottleneck from how do I talk to the
hardware to what mathematical process do I need
to automate? And that paradigm shift was recognized
pretty quickly. The success of Fortran led to
Bacchus getting the W .W. McDowell Award in 1967.
Yes, it did. But as soon as high level languages
were successful, they created a new, deeper,
more philosophical problem. Definition. Definition.
Exactly. Once you have a powerful tool like Fortran
and then dozens of other languages following
its lead, you need a way to make sure everyone
agrees on what the rules of that language actually
are. Which leads us directly into act two of
his career. This is section three, defining the
language of languages. the Bacchus Narriform,
or BNF. So once these languages emerged, the
technical community needed a precise, universal
dictionary for the grammar. Before this, descriptions
were just written in English, which is... you
know, inherently ambiguous. Disastrously ambiguous.
And the catalyst for standardization came from
an international context, mostly around the development
of the Algeol family of languages. And Backus
was a central figure in that. A central figure.
He served on the international committees that
developed both Algeol 58 and then the highly
influential Algeol 60. And it's important to
stress Algeol 60. didn't achieve the commercial
dominance of Fortran. Not even close. But it
became the de facto standard for publishing algorithms
just because of its clean, structured design.
And that design elegance was a direct result
of the clarity of its formal definition, which
was entirely due to Backus's invention. In the
context of the UNESCO report on Algeol 58, Backus
invented the notation we now know as BNF. So
what exactly is BNF? For someone who hasn't done
a deep dive into compiler theory, it sounds esoteric,
but it's foundational. It is. BNF is a formal
notation that can describe the syntax of pretty
much any context -free programming language.
To understand how revolutionary it was, think
about what came before. If I used English to
define a loop, I might write, a loop starts with
DO, then a variable, an equal sign, an initial
value, the word TO, a final value, and so on.
Right, which sounds... Clear enough. But then
you get into all the edge cases. What if the
variable has to be an integer? What if the initial
value can be a complex expression? Angular just
gets messy with footnotes and exceptions. It
gets messy immediately. BNF provides a set of
concise production rules that just eliminate
all ambiguity. For instance, a simplified BNF
rule might look like this. Expression. Term expression
plus term. Okay, break that down. It's defining
an expression recursively. It says an expression
is either a single term or it's another valid
expression followed by a plus sign and another
term. It's a mathematical definition of grammar.
So it takes all the ambiguity of natural language
and just replaces it with mathematical certainty.
And that precision is why BNF matters so much
for compiler development. The ability to formally
specify the language allowed for the eventual
automation of building the compiler itself. The
translator. Yes. And that's why BNF was explicitly
cited in his Turing Award. It established the
theoretical bedrock for the field. Instead of
a compiler writer having to interpret some ambiguous
English manual, they could just read the mathematical
grammar in BNF and program their compiler to
recognize tokens according to those exact rules.
It was transformative. It introduced rigor. Now,
there were some other approaches. You know, our
sources mentioned Lisp and APL had their own
notations. But by the 1970s, the Bacchus -Narr
context -free specification had become the industry
standard. And that standardization was critical
because it enabled automated tools. Things like
YAC, yet another compiler. Tools like YAC let
developers feed a BNF description of a language
to a program, and that program would automatically
generate a huge chunk of the necessary parsing
code for a compiler. This just massively accelerated
the creation of new languages. So this lets us
connect the dots perfectly. Fortran solved the
problem of writing programs efficiently. Making
computing practical. Right. And then BNF solved
the problem of defining programs rigorously,
which made language design systematic. It really
formalized computer science as a discipline.
He had basically given the world its first great
high -level language and then the mechanism to
define every language that would come after it.
And if he had retired right then... In 1970,
he'd be remembered as one of the greats. One
of the all -time greats. But he wasn't finished.
In the late 1970s, he enters Act III, a phase
that involves a deep, self -imposed critique
of everything he had helped build. And this is
where his career becomes truly fascinating. In
the late 70s, after achieving all this fame for
creating the dominant programming paradigm, this
sequential procedural style, he pivots to critique
it fundamentally. It shows a mind that just wasn't
interested in resting on past achievements. He
was constantly striving for a more elegant, more
expressive form of computation. And the public
declaration of this pivot was his 1977 Turing
Award lecture. The lecture that shook the industry.
Can programming be liberated from the von Neumann
style? That title is the whole thesis. He was
railing not against Fortran specifically, but
against the foundational hardware architecture
that Fortran was forced to obey. The von Neumann
architecture. Okay, we need to define the von
Neumann style clearly because it basically defines
almost every computing device we use today. It
does. The von Neumann architecture dictates that
the computer operates through a single channel
connecting the CPU where the processing happens
and memory where data and instructions are stored.
And the CPU just executes instructions one after
another, sequentially. Sequentially. Constantly
fetching data from memory, processing it, storing
the results back, one word at a time. Backus
called this the von Neumann. Because the CPU
spends most of its time just waiting for data
to be shuffled back and forth across this narrow
channel. Yes. And Backus argued that our programming
languages evolved to just mirror this mechanical
process. Procedural languages like Fortran, C,
Pascal, they were all designed around the fundamental
concept of the assignment statement. The assignment
statement being, you know, X plus one. Exactly.
And that statement is nothing more than saying,
go to this specific memory location, X, fetch
the value, do an operation like plus one, and
then store the new result back in that same location.
So he's saying that by making Fortran successful,
they had basically institutionalized a constraint
that was imposed by the hardware. That's the
core of his critique. He argued that this style
was fundamentally limited because it forces the
programmer to focus on mechanical, low -level
details of data movement, what he called word
-at -a -time programming, rather than the high
-level mathematical structure of the problem
itself. So he believed programmers were being
forced to think like the machine's memory fetcher,
not like a pure mathematician. Yes, a loss of
expressive power and elegance. He saw the entire
industry as being trapped in an imperative morass
where programs were just a sequence of state
changes rather than clean mathematical transformations.
And this lecture is sometimes seen as his apology
for creating Fortran. Is that accurate? It was
misinterpreted. It wasn't an apology. It was
an intellectual evolution. The problem was that
his proposed solution, function level programming
or FLP, was often mistakenly confused with existing
functional languages like Lisp. Which used lambda
calculus. Right. And Backus was aiming for something
different, something algebraically cleaner. His
antidote was to move toward a style that focused
entirely on combining functions to transform
data rather than assigning values to variables.
And to explore this idea, he designed a language
called FP. FP for function -level programming.
It was his direct attempt to embody these ideas,
and it was heavily, heavily influenced by Kenneth
Iverson's APL. A programming language. Yeah.
Which was already pretty radical. Very radical.
It was focused on array processing and used this
non -standard character set to denote these powerful,
primitive operations that worked on entire arrays
at once. FP inherited that spirit. So how did
it work? No variables? No loops? No. It operated
using a small set of combinators, which are functions
that take other functions as arguments and combine
them to create more completes functions. The
key is the programmer never directly interacts
with variables or assignment statements. So if
you wanted to sum a list of numbers. You wouldn't
write a loop and assign the running total to
a variable. You compose a function that maps
an addition operator across the entire data structure
at once. It was an algebra of programs. That
sounds incredibly rigorous, but also a huge departure
from the mainstream. How was its adoption? Adoption
was niche. An FP interpreter was distributed
with the 4 .2 BSD Unix operating system, which
is interesting, but implementations were few.
It was used mostly for educational purposes.
The conceptual leap was just too big. Too big
for an industry already so heavily invested in
procedural C and Fortran. But Backus didn't give
up. He spent the latter part of his career trying
to refine this concept, creating a successor
language called FL. FL. For function level. Right.
What was the fate of this second attempt? FL
was a long -term intensive internal research
project at IBM. Backus was focused on making
it even more rigorous so that you could mathematically
manipulate programs the way a mathematician manipulates
equations. But unlike Fortran, which IBM pushed
globally, FFL just stayed internal. Unfortunately,
yes. Development stopped when the research project
finished, and the source code for the compiler
was never made public. Only a few documenting
papers are left. Why do you think it failed to
gain traction when the original was such a colossal
success? It was a collision of philosophy and
timing. By the 1980s, when FL was being developed,
functional programming was gaining traction,
but it was centered around lambda calculus and
static typing languages like ML or what would
become Haskell. And FL was different. FL, following
that APL lineage, was philosophically... distinct.
It focused on the concatenation of primitive
operations using these powerful array centric
operators. It felt alien to the academic functional
movement. So his vision was kind of caught between
two worlds. Exactly. It was caught between the
highly practical procedural world he was critiquing
and the mathematically rigorous lambda calculus
world, which he didn't fully embrace either.
But the ideas didn't die. Not at all. The legacy
of FL is seen clearly in later versions of the
J programming language, which is Iberson's successor
to APL. J is a modern, powerful array processing
language that carries many of the structural
insights and the mathematical elegance that Backus
was searching for in FP and FL. So his critique,
if not his specific language, was enduringly
relevant. It was. His core philosophical drive
continued to influence that entire lineage of
array processing languages. It is just so rare
to find a figure in any field who so fundamentally
shaped its practical foundation, then formalized
its theoretical structure, and then stood back
to deliver it. a devastating philosophical critique
of the entire system. It really is. He created
the digital freeway, established the rules for
building all the future roads, and then said,
you know what? This whole infrastructure is fundamentally
limiting our speed. It speaks to his relentless
intellectual energy. He was never satisfied with
good enough. So his career spanned the absolute
necessity of early computing, from the manual
toil of calculating lunar positions on the SSCC
to the abstraction of speed coding. The revolution
of practical science with Fortran. The formal
definition of all language structure through
BNF. And finally, the profound philosophical
critique of that whole world with FP and FL.
And the recognition he received truly reflects
that triple legacy. It does. IBM Fellow in 63,
McDowell Award in 67, the National Medal of Science
in 75, followed by the Turing Award in 77. Later
honors included the Draper Prize in 93, and he
was named a Computer History Museum Fellow in
1997. He passed away in 2007 in Ashland, Oregon,
leaving behind this monumental, complex, and
ultimately challenging legacy. And as a final,
slightly more whimsical honor, the asteroid 6830
John Bacchus was named for him. A true giant.
But for the learner, for you listening to this,
I think the most important part of Backus' work
is the lasting question he posed. The idea that
programming is constrained not by our intelligence,
but by the physical architecture of the computer.
Right. If Backus, the creator of Fortran, ultimately
argued that the underlying sequential von Neumann
-style architecture limits how powerful and expressive
our programs can be, this raises a really persistent
and important question. And that is? Nearly 50
years after his critique, Are the programming
languages you use, Python, Java, JavaScript,
are they still fundamentally constrained by that
sequential, word -at -a -time, memory -shuffling
design of the processors they run on? Or have
model kerygimes, like object -oriented design
or massively parallel processing, truly found
ways to liberate us from that mechanical sequence?
It's something to consider the next time you
design a system or write a line of code. Are
you instructing the machine on the logical steps
of your problem, or are you just efficiently
managing the flow? of data across the von Neumann
bottleneck.