Okay, I'll risk my career and admit it: I not only know how to draw a
flowchart, I still find myself using them from time to time.
I have one of those little green plastic flowcharting templates to help
draw the symbols and arrowheads, but I don't use it much anymore. (I don't
like to take it out of its climate-controlled vault; the chill might warp my
I'll bet a few of you are smiling wistfully right now, secretly yearning
for The Days of Boxes and Green Plastic: the expansive surfaces of
glistening unblemished flowcharting paper, each patterned page awaiting its chance to
represent pure logical art. What mere "problem" could possibly withstand our
iterative onslaught of ink and thought? Get thee behind me, General Ledger!
Yes, they were simpler days, or perhaps it was just me who was simpler.
Ah, but those first tastes of process abstraction (imposing order upon
thought, what a concept!) were just too alluring.
My first exposure to flowcharts wasn't until college. I know for a fact
that I was much simpler then, but fortunately so were the programming
problems I faced. There always seemed to be a way to get that virtual boxcar
attached to the virtual train without having to lift it off the virtual
tracks. No list went unlinked, no record went unwritten, and no parameter
went unpassed, by value or by reference. Simpler days, indeed...
When I look back at my proudest individual programming achievements, I
can't help but start with that first college-level Pascal programming
course. The instructor was meticulous and unwavering: no global variables
without solid justification (which meant no global variables), all local
variables descriptively named and declared alphabetically, and every
procedure well begun with a standard commentary prologue.
That's how they lure you in. "Come on! Here! Impose order on an unruly
universe... You can do it!" Yes, that was my first foray into flowcharting,
and something in me changed.
I remember rushing to my then-future wife one bright summer day, waving
my multipage fanfold printout, and proudly exclaiming, "Look! This Pascal
assignment took over a HUNDRED LINES of CODE! Isn't that AMAZING!?" She
smiled, and I fell in love (which is the only hard proof in existence that I
do, in fact, have moments of brilliance).
Next it was a thousand lines of this and a thousand lines of that
logistic equations, with variable zooming, grid lines, and decimal input
fields; fractal monster functions, continuous yet nowhere differentiable;
images of reality that no one in the history of man could ever have seen in
the days before transistors on silicon. I came to know the Turbo Pascal
graphics library by heart. Programming these ugly beige boxes to display
such unfathomable beauty was reaching deep into the viscera of the silicon
beastie and twisting. I liked it. I was hooked on programming.
Then I got a job, and it was my guts' turn to be twisted... "Oh,
Mandelbrot sets are fascinating and beautiful and all, but we really need
that big honkin' component test plan you promised us. Okay?" The joy of
individual, top-to-bottom programming just for the fun of it was still
there, but there was also a different, even better, kind of joy: the joy of
contributing to something much, much larger.
My first big chance to prove myself part of the team was during the
development of a new optimizing compiler back end for our box. The theory of
compiler front and back ends was new to me then, though its simple elegance
was instantly compelling.
The idea is simple: separate the compilation process into two phases a
"front end" and a "back end." The front end converts source code to an
"intermediate representation" (IR) a form that completely and
unambiguously represents the form and function of the compilation unit, but
which does not presuppose any particular hardware configuration. Then, a
compiler back end gets involved, and converts the IR into optimized,
hardware-specific instruction streams and data structures.
The sweet part is this: any software that can be compiled into a given
IR will run on any hardware that has a matching back end. Now, if this
sounds familiar, it should. It's arguably the very heart of the write-once
run-anywhere promise of Java.
At the front end, we have javac, Jikes, or anything that generates
proper bytecode. (There is at least one RPG-to-bytecode compiler, for
instance.) The IR, of course, is the classfile format. The back ends are the
various JITs, AOTs, and true interpreters that make our JVMs work so well.
Imposing order upon thought... What a concept! Maybe those boxes and
arrows and diamantine decisions led somewhere after all.
Blair Wyman is a software engineer working for IBM in Rochester, Minnesota,
home of the IBM iSeries.