Conjuring Spirits |
|
|
|
|
I changed my mind about jumping into computer programming 101 today. I made the mistake of reading over the forward, preface, and first couple of chapters of SICP last night and now this morning I'm not feeling quite up to the task. I need to think more carefully about my audience and what exactly I want to say to you. Recall that this journal isn't supposed to read like a textbook in which we set out with a particular goal and head for it by as straight a course as we can follow. This journal is supposed to be more like what happens when a couple of students come by my office possibly with some specific questions but more often just wanting to talk about computing. We talk, scribble some stuff on the white board, possibly pull out a laptop or gather around the digital display on my desk, and generally fill one another's heads with ideas which we then go off and ponder and share with our friends and colleagues.
In yesterday's journal entry, I introduced the notion of a process in talking about servers. I rather hastily explained that a process is a disembodied dynamic entity distinct from machines (computers) or the programs that run on them. I remember the first time that I had someone explain to me what a process was in a way that I understood and that appealed to my sense of the beauty and mystery that surrounded computing. It was in the very first paragraph of the first chapter of SICP:
Computational processes are abstract beings that inhabit computers. As they evolve, processes manipulate other abstract things called data. The evolution of a process is directed by a pattern of rules called a program. People create programs to direct processes, In effect, we conjure the spirits of the computer with our spells.
The authors continue with the metaphor of conjuring magical spells talking about how a process is like a sorcerer's idea of a spirit that cannot be seen or touched. If I were to try to write a similar characterization of processes today it would probably come out as some muddled combination of my own sense of wonder and fascination with computation and my desire to be precise and not overly simplify or mislead. Here, I'll give it a try.
A computational process refers to a continuing sequence of activity which takes place whenever physical entities interact with one another to produce changes in those entities over time but in particular when those entities correspond to the components of a traditional computing device. As such a process evolves over time, it produces patterns that serve as the basis for subsequent activity or can be read off by an external observer for some purpose. The evolution of a process is directed by a set of rules which dictates how the physical entities interact. This set of rules is called a program and can itself evolve over time as it is itself emdodied in the physical entities and their pattern of activity.
Argh! That was awful and probably incomprehensible. Does this mean that any random pile of stuff constitutes a process? I'd have to say yes. And why didn't you retain some mention of data? Programs and data are one and the same, just considered from different perspectives. Did you have to make programs out to be just as dynamic and changeable as processes? Couldn't help myself.
I expect that Abelson and Sussman would agree with the above characterization though perhaps they'd protest at my tortured prose. Sussman is my academic grandfather and has been in computing far longer than I have but as far as I can tell he is just as fascinated with computers now as he was when he started out in this field. By the way, I don't want to leave you with the impression that Gerry Sussman and I are good buddies. I've got lots of friends in the field of computer science and some of them are even quite influential, but I don't know Gerry Sussman personally, however much I've enjoyed and been influenced by his writings over the years. And if you think it strange that a grandson wouldn't have much truck with his grandfather or conversely, remember that your academic children are the PhD students who completed their doctoral dissertations with you. I expect that Sussman has more than a dozen academic children by now and perhaps close to a hundred academic grandchildren.
My primary area of expertise within computer science is called "artificial intelligence" and the people in my field are interested in getting computers to do things that currently only people are able to do. Indeed lots of my colleagues aren't willing to stop with what people can do, they're interested in getting computers to do things far beyond what people can do, perhaps beyond what people can even imagine doing. Some far out dreams but the reality of what computing can and is doing now is already pretty amazing.
It didn't take long after figuring out how to build a computing device for someone to think about programs that could reproduce, adapt and repair themselves. John von Neumann, an early computer pioneer and mathematician, was interested in programs (automata) capable of self-reproduction and evolution in his "The General and Logical Theory of Automata" [Pages 1-41 in Cerebral Mechanisms in Behavior - The Hixon Symposium, edited by L. A. Jeffress. John Wiley, 1951] and in machines that repair themselves and deal with noisy or corrupted input in his "Probabilistic Logics and the Synthesis of Reliable Organisms from Unreliable Components" [Pages 43-98 of Automata Studies, editied by C. E. Shannon and J. McCarthy. Princeton University Press, 1956]. And von Neumann wasn't the first by any means; Alan Turing had expressed thoughts along similar lines and a host of scientists and artisans down through the ages thought about or tried to construct automata that mimicked biologogical organisms. I expect that would consider what computer scientists take for granted in working on modern computers nothing short of magic.
I could easily write a program and then insert that program, much as as a dormant seed, into web page managed by a web server running on a machine physically located in Providence Rhode Island, USA. Someone trying to access that web page from a browser running on a machine, say in Tbilisi, Georgia, could download my web page containing the dormant program thereby causing the program to run on her machine in Georgia. The program might just pop up a little window and say "Hi! Greetings from Providence, Rhode Island" or it could perform a wide range of other tasks and services from asking for donations of time or money to support a good cause to deviously inserting copies of itself into web pages that it finds on the machine in Tbilisi thereby spreading the seeds for its reproduction.
The file residing on the machine in Providence and containing the web page with its embedded program would have been converted into to an alternative electronic format and then transmitted around the world in an eye blink quite possibly and unbeknownst to the person in Tbilisi having detected and corrected for multiple transmission errors at numerous steps along the way. This part, the reliable transmission of data along unreliable communication channels, is something most of us take for granted but it's nothing shy of a miracle to me.
The fact that I could breathe life into a program and then have it propagate to the far corners of the globe there to be revived and remotely carry out my bidding is nothing short of amazing. And, as deviant and destructive as is the prospect of designing software that infects other people's computers is, the very idea that it is possible is fascinating.
And while I wouldn't characterize any program that I know of as being smart in the incredible way that a little girl who skips rope and can learn to tie her shoes is smart, computer programmers have instilled in their programs capabilities of extraordinary scope and subtlety. And, it is even more astounding that this technology is available to anyone with a computer and an internet connection.
I apologize if I seem overly awed by the availability of computer technology at least in the form of well-crafted, free open-source software. And I hope that the future will bring with it even more access to useful information and technology; access to information so that everyone can learn about and make use of technology and access to technology so that everyone can gain access to and make better use of information. Technology and information feed on and amplify one another.
Growing up with technology all around me, I was always picking up pieces of machinery and wondering how I might use the pieces to build things. I used to frequent junk yards to find parts for cars and building materials for houses, but also simply because I liked to clamber over cast-off technologies. I remember finding a junk yard near Lynchburg Virginia that received a lot of scrap metal from a company that manufactured nuclear reactors. I was always finding, buying (for just a little more than the cost of the scrap metal), and then lugging home all sorts of neat machines some of which I didn't really understand what they did. Once I had them home I would try to incorporate them into other machines and tools, e.g., a stainless steel vacuum chamber became a wood stove and an old DC motor became a generator. At some point in this journal, perhaps I'll try to recount some of my favorite hacks.
On one visit to the junkyard, I found a pile of hydraulic pumps, pistons, valves and mechanical linkages and I was so excited. All the way home, I was planning how to build my own hydraulically operated earth moving equipment - owning a mountain required that you maintain your own roads and I was always wanting to clean out a drainage ditch, pull up a stump, or dig a foundation for some new out building. I was pretty handy with an arc welder and cutting torch and I could get steel plates and beams easily enough so I planned to fabricate the body of the earth mover from scrap steel. I figured I'd use an old gas engine I had lying around to power the big hydraulic pump and then run everything else, tracks, scraper, bucket, boom, etc., using hydraulic motors and pistons controlled by valves.
The problem was that when I itemized out the various "little" pieces of my design that I couldn't find in the junkyard and presumably would have to purchase new, the cost of my homemade tractor/loader skyrocketed. The promise of all this technology was tantalizing but, practically speaking, it was out of reach. Most of that hydraulic equipment remained in a corner of my shop until we sold the house on Squirrel Mountain; it seemed to hold so much potential that I couldn't bear to throw it out.
In large part, the technologies embedded in software systems aren't like my junk hydraulic parts. You can grab an industrial-strength web server from Apache, full-featured databases from PostgreSQL or MySQL, embeddable scripting languages like PHP and Java, and a host of powerful tools from the GNU Project and the Free Software Directory. Alone or along with a group of your friends you can build systems that rival those of major corporations and you can find on-line communities consisting of like-minded individuals interested in sharing, improving and developing new software, e.g., SourceForge.
Ok, I got a little over enthusiastic. I sound like I'm selling an eat-all-you-want-and-still-lose-weight diet plan - sounds too good to be true. If you're going to make real use of all the wonderful software that's available on-line or better yet contribute to the available software by writing your own applications, you'll need to know a bit more about computers, networks, programming, software development and the design of computer systems. The good news is that if you're sitting at a computer, the necessary knowledge is right at your fingertips, you just need to get in there and start learning. The best news of all is that getting there is a good part of the fun - oh alright, there's also the frustration when things don't go as quickly as you think they should, the consternation when something that really should have worked doesn't and the exhaustion when what you thought was a small project turns out to suck up all of your available energy and free time.