OMG I still have the troff source for that paper, and all the code. That was a fun project, setting up the RPC client on a Sun in Ithaca to prompt remote machines to run my ODE solver and automagically asynchronously send the results back to the Sun. I was able to sweep initial condition space a lot faster that way, despite the network latency. It's pretty hilarious that, writing that paper in '87, I had this diagram of 'compute servers' with the remote Convex, Sequent Balance and the Intel Hypercube at Argonne and the Cray-2 in Minneapolis drawn in -- not to mention the VAX 9000 with an array processor across campus, calling the Sun RPC library in C to do the client-server communications.
(When the first version of XMosaic came out five years later and people were like "look! it browses files over the internets!" I was like, "So? I've been doing that with ftp and telnet and rcp and rsh for like a decade. I've written code to do that. I wrote a paper for a refereed publication with someone at Caltech while I was in France over ARPAnet. I'm supposed to get excited about browsing files?" But I did set up httpd and Xmosaic on my SGI box, and started making and little html files, just to see how it all worked. I had to admit, it was pretty nifty. I realized I could have done the whole RPC ODE project with a CGI script instead of Sun RPC. Today, I'd probably call it from a server-side python platform, and use Numpy for the numerics. Could be a good way to get up to speed with the Enthought suite. I might yet, lol!)
Anyway, the hardest part of the RPC ODE project back in 87 weirdly enough, was that there were different C and Fortran compilers on each of the remote and local Unix boxes, and doing mixed-language compiles (linking the Fortran solver to the C wrapper) was a little different on each, and not very well documented. I used m4 macros to make the source a little cleaner and consistent across platforms, but even 'make' was subtly different on each one. Plus, the CRAY was a 64 bit architecture, so single precision floating-point IEEE numbers on its version of XDR still had to be cast into double precision when shipping it back to the Sun 2. You can imagine how hilarious I found Microsoft's conniptions about how to deal with a 64 bit architecture like, just a few years ago.
Funny you should mention lambda calculus, as the CS department at Cornell was really theoretical, and yah -- the grad students there did mostly theory, code not so much. Oh well, missing out on all the fun, I guess. And, I was in charge of more iron and had courtesy accounts on a lot more big iron around the country, as a UNIX sysadmin than they could ever hope to use. The CS grad students had to like, apply for time on big iron and write grants to pay for it. Maybe that's why most of them did theory.
They didn't even have an undergraduate program at Cornell in CS until I was about to graduate with my BSc in Engineering in 82, and weirdly enough I would have had to transfer out of Engineering and into the Arts college to major in CS. And, as a new major, the engineering faculty doubted its value. No way was I going to CS in the Arts college after busting my ascii for three years in the College of Engineering! With a BA there would be nothing to distinguish me from an English major! Yikes!
Oh, well, thanks for looking up my first refereed publication, ForkBomber! Maybe I'll include the whole thing in my memoirs, with a data key holding the source. Never did release it anywhere. I'm pretty protective of my source code. ;)