TITLE: Functional Programming, Inlined Code, and a Programming Challenge
AUTHOR: Eugene Wallingford
DATE: July 28, 2016 2:37 PM
DESC:
-----
BODY:
I recently came across an old entry on Jonathan Blow's blog
called
John Carmack on Inlined Code.
The bulk of the entry consists an even older email message
that
Carmack,
lead programmer on video games such as Doom and Quake, sent
to a mailing list, encouraging developers to consider
inlining function calls
as a matter of style. This email message is the earliest
explanation I've seen of Carmack's drift toward functional
programming, seeking to as many of its benefits as possible
even in the harshly real-time environment of game programming.
The article is a great read, with much advice borne in the
trenches of writing and testing large programs whose run-time
performance is key to their success. Some of the ideas
involve programming language:
It would be kind of nice if C had a "functional" keyword to
enforce no global references.
... while others are more about design style:
The function that is least likely to cause a problem is one
that doesn't exist, which is the benefit of inlining it.
... and still others remind us to rely on good tools to help
avoid inevitable human error:
I now strongly encourage explicit loops for everything, and
hope the compiler unrolls it properly.
(This one may come in handy as I prepare to teach my compiler
course again this fall.)
This message-within-a-blog-entry itself quotes another email
message, by
Henry Spencer,
which contains the seeds of a programming challenge. Spencer
described a piece of flight software written in a particularly
limiting style:
It disallowed both subroutine calls and backward branches,
except for the one at the bottom of the main loop. Control
flow went forward only. Sometimes one piece of code had to
leave a note for a later piece telling it what to do, but
this worked out well for testing: all data was allocated
statically, and monitoring those variables gave a clear
picture of most everything the software was doing.
Wow: one big loop, within which all control flows forward.
To me, this sounds like a devilish challenge to take on when
writing even a moderately complex program like a scanner or
parser, which generally contain many loops within loops. In
this regard, it reminds me of
the Polymorphism Challenge's
prohibition of if-statements and other forms of
selection in code. The goal of that challenge was to help
programmers really grok how the use of substitutable objects
can lead to an entirely different style of program than we
tend to create with traditional procedural programming.
Even though Carmack knew that "a great deal of stuff that goes on
in the aerospace industry should not be emulated by anyone, and
is often self destructive", he thought that this idea might have
practical value, so he tried it out. The experience helped him
evolve his programming style in a promising direction. This is
a great example of the power of the pedagogical pattern known
as
Three Bears:
take an idea to its extreme in order to learn the boundaries of
its utility. Sometimes, you will find that those boundaries
lie beyond what you originally thought.
Carmack's whole article is worth a read. Thanks to Jonathan Blow
for preserving it for us.
~~~~
The image above is an example of the cover art for the "Commander
Keen" series of video games, courtesy of
Wikipedia.
John Carmack was also the lead programmer for this series. What
a remarkable oeuvre he has produced.
-----
