Functions, parsers, and plots
Back in 1985 I was an undergraduate at Sonoma State University, and I was chatting with some people there about whether we could use a computer to print a graph of a function, like y=f(x). Today, most pocket calculators can plot functions, and certainly any smart phone with the right application. But back then, if you wanted to see what a function looked like, you had to do it by hand. Prof. Gordon Spear, an astronomer who knows a lot about scientific programming, said effectively it could not be done. We only had Fortran on our computers as a programming language, and Fortran (he said) did not lend itself to writing “parsers,” programs that can understand equations.
I wasn’t at all happy with his answer that it couldn’t be done! So . . . I set out, and in about two days I had written a Fortran program to plot functions.
But I learned he was indeed right, parsers are not easy in Fortran. So . . . I stole a parser instead! My program was called Funplot, and Funplot worked like this: You entered a function as a string, just as you would type it into a Fortran program. My program created a Fortran subroutine as a text file that encapsulated this string, then used low-level operating system calls to compile and link this Fortran function into Funplot itself. Once compiled, Funplot could then use and plot this function. Naturally all these steps were invisible to the user; the user only saw the beautiful plot of their function a few seconds after entering it.
In essence, I had cheated! I had “stolen” the parser from the Fortran compiler itself!
What does this show?
First, this is still one of my best memories in research, because it points to a universal, timeless problem that I see today, over thirty years later: computer engineers like to say things are difficult or impossible, when what they mean is that they are difficult or impossible to do elegantly. Elegance in computers should be secondary – applications should solve the problems people have, and who cares what they look like inside! I still get very, very mad when someone tells me a computer cannot solve their problem.
Second, it shows some way in which the field of IT has changed. Thirty years ago the challenge was to do the impossible: attaining something very useful with too little memory and too little computational power. Computer engineers loved these challenges, and their personalities reflected it. The modern generation of computer engineer has grown up expecting computational resources can meet their challenges, and because of this, I often believe the field is filled with a different personality type than long ago.