Michael Gogins

Atwood proves herself a master science fiction writer in these books, the first two of a trilogy (the third has not yet been published). Spoiler alert: this review begins with plot summaries!

Oryx and Crake tells the story, in reverse via flashbacks, of how Crake, a genius with a grudge against the world, designs both a plague to wipe out humanity and a new species, the “Crakers,” to replace humanity, all the while being employed by a Corporation to provide gene goodies for a toxic Corporation-ruled future. Crake employs or co-opts underground genetic partisans, “God’s Gardeners,” to help with his work. The story is told from the point of view of Crake’s less gifted friend Jimmy. Both men are in love with Oryx, a smart girl from a backwater country. The story proceeds through the death of almost everyone at Crake’s hand. As the plague rages, Crake cuts Orxy’s throat and is in turn shot by Jimmy, who survives because he has been inoculated by Crake in order to tutor his Crakers. At the end of the novel, Jimmy is left watching over the Crakers and trying to keep from being killed by rogue genetic pets such as wolvogs and pigoons. At the very end he chances on the camp of three more human survivors…

The Year of the Flood recounts the same events from different points of view. The God’s Gardeners group, which attempts to contest the Corporate future, has advance warning of the plague and some of its members survive, including a young woman, Toby. Another woman, Ren, survives because she has been held captive in a sex club where she has been working; she has also been Jimmy’s girlfriend. Toby, Ren, and some other survivors make their way out of the city, where they meet Jimmy…

In addition to being a more competent fiction writer than most science fiction writers, which is no surprise given her publishing record, sales, and critical reputation, Atwood also turns out to be a better science fiction writer than most science fiction writers. In this book, she cuts to the heart of a dilemma currently troubling the human race. We have gained a Godlike power over biology, including our own biology. But we are not living up to this responsibility, for which nothing has prepared us. The main characters in the books - Crake, Jimmy, the God’s Gardeners partisans, the Corporations, and even Oryx - epitomize and live through the twists and turns of this dilemma, which are not simple.

In the books, our failure to live up to our responsibilities may well lead to our extinction (at least, that is very much where things appear to be heading at the end of the second book). Crake, a genuine genius, takes all responsibility upon his sole self: exterminate Homo sapiens sapiens with a designer plague and replace us with a successor species custom-designed for Eden.

At the end of the second book, this extermination appears very close to success, and the Crakers, as Jimmy calls the new species designed by Crake and his co-opted biological partisans, are left on the stage. Along with, however, the pigoons and the wolvogs, creatures not created by Crake and that, in biological terms, would prey upon or compete with the Crakers. The pigoons are co-operatively social and intelligent (though apparently not linguistic or tool-using), they are a chimera with nervous systems partly derived from us. They are certainly more dangerous than any non-human creatures currently on this planet, though they would not be a serious threat to an intact human society. I do think they might well pose an existential danger to the Crakers, possibly this is Atwood’s intention. There are also a few human survivors, God’s Gardeners partisans forewarned to isolate themselves from the plague.

In reality, the only extermination program likely to completely succeed against us would be an impact from a very large and fast-moving extraterrestial body, something big enough to boil the whole surface of our planet. But that is not Atwood’s scenario. The Year of the Flood leaves the pigoons, the Crakers, and a few humans together in a big fat mess. In reality, if the humans pull through, enough human weapons and other hardware would remain to leave the humans firmly in control.

What would happen then would be another novel. Or perhaps Atwood’s third book.  Quite possibly Atwood will find a solution I fail to imagine. We will see.

Whatever the intent, or the weaknesses, of Atwood’s plot, our evolutionary dilemma is terribly real, and it lends Atwood’s tale a terrific power. The human race will not, cannot, remain in its present form for more than another generation or so. We cannot and will not remain as we are. In reality, it is not likely that we can be destroyed, even if we, or some Crake, try to kill us off. Therefore we will change, or we will be changed. Atwood’s novel very definitely lives in this change, and Atwood dreams its motives, fears, loves, and reactions.

There are multiple pressures for large-scale change. In the first place is our palpable overpopulation, which is causing a great wave of extinctions across the planet. These extinctions are irrevocably, possibly catastrophically, altering the ecosystem of our planet. In the second place is urbanization, also irrevocable, and which is changing every selection pressure that is acting upon the human race. Global warming is but one facet of this urbanization. Atwood is very clear on other dire features such as mass consumption, social stratification, and out-of-control Corporations. In the third place, the place of honor, is germ line genetic engineering. Currently, the human race uses germ line genetic engineering on a very large scale for agriculture. At this time, somatic genetic engineering is  being practiced upon a few human beings for medical purposes, with mixed results. Such research is inherently difficult and unpredictable, but the very existence of us and our fantastic capabilities compared with other creatures is a striking sign of what may be possible. Human researchers and institutions have achieved very difficult goals, such as safe jet travel and nuclear power, and I personally do not doubt that we will master genetic engineering.

So, in the next generation or so, it will almost certainly become feasible to do germ-line genetic engineering, with stable results, upon human beings. That means future human beings, or at least some classes of them, may live longer, be smarter in at least some ways, and be profoundly different in other ways. In all likelihood, such genetic engineering will result in multiple species of human beings. I believe the most profound result of genetic engineering on us will be changes in human social biology. This indeed is, in Atwood’s novels, the major agenda of Crake’s engineering: get rid of pair bonding, meat eating, male competitiveness, and other striking features of human society. It’s not clear where Atwood’s preferences go - perhaps simply to telling a good story, or to making us think. But of course other changes would be equally feasible. Ant-like changes. Perhaps a warrior caste, an intellectual caste, and so on. Perhaps more disposition to conform. Perhaps less.

Ultimately, what is 100% certain is that, since not all the effects of these changes can be foreseen by us, they will subjected to the same old judge that has decided every case of biological “justice” from the very beginning: natural selection, or an inscrutable God.

Change on an unprecedented scale can’t be stopped, so the right questions are: what is the right thing for us to do? What is the right kind of germ-line genetic engineering for human beings? Who shall our descendants be?

Crake’s post-humans are one proposal, but I am not at all sure it is Atwood’s. To me the Crakers seem painted in very satirical colors, though I could well be wrong about that….   A clue may lie in the recordings of the God’s Gardeners hymns to extinct creatures that are featured on Atwood’s blog.

Dear reader, please understand that I doubt I will share Atwood’s values and goals as perhaps to be revealed more fully in the third book. I definitely favor the germ line genetic engineering of our descendants, but I think I would probably aim for different targets. Atwood seems to be focused on changes to very basic human instincts, I would be more likely to focus on decreasing the incidence of mental illness, reworking our ethnic and national chauvinism on a higher level than basic sexuality, and in other ways attempting to widen the authority of reason without huge unpredictable side effects.  However, I think Atwood’s novels are excellent science fiction, and that they grapple with fundamental issues in an admirably thorough and compelling way.

I am eagerly awaiting the sequel!

I find it essential periodically to re-state my musical goal, so as to clarify just what that goal is and what steps I might follow to attain it.

My goal is to make good music, music that I want to hear and that other people will want to hear. And I want to do this by means of algorithmic composition and algorithmic synthesis, because not only is that what initially attracted me to composing, but also I have repeatedly found that while I can compose in other ways, the results are not impressive. I only seem able to make music that I actually want to hear by programming.

My work is pretty fundamental and really gets down in the basement about what is music, what is composing, and the foundations of music theory. The following sums up my research program. The following things are listed in decreasing order of logical priority, but they are roughly equally important from a practical point of view.

• I need algorithms that can generate any possible score. I have proved that this is possible and I have software that can do it, but it’s not that useful because most of the scores are not good, so…
• Those algorithms need to be parametrically mappable, therefore they must be controllable by purely numerical parameters. Having a map means one can compose by exploring the map. This is much faster, and more illuminating also, than writing a whole bunch of similar programs.
• The algorithms must operate on a basis that is musical, so that, when the parameter space is mapped, things the theory teacher would mark down/things the listener would have trouble hearing (these things are supposed to be the same, and pretty often are the same), can be avoided by sticking to certain regions of the map. This is what will make algorithmic composition actually usable for a wider variety of music: being able to explore compact and/or connected regions where the listening is not torture.
• It must be easy to generate listenable, glitch-free music that would be hard for composers without the algorithms to imagine. (Otherwise, why bother?) But I’m sure that if I can do the first points, this one is automatic; every method of algorithmic composition that I have tried so far has thrown out a fascinating piece here or there, it is just that usually they have a musical “clunker” or so in them, or there are too many uninteresting ones in the flow.

Currently, I do not have a toolkit that fulfills all these requirements. But I have managed to fulfill some of them in full, some in part; and others, I have ideas of how to fulfill.

The biggest missing piece right now is a space for representing music in which compositional operations are matrix operators (that I have implemented in CsoundAC’s Voicelead, VoiceleadingNode, and Score classes) and in which these operators are easy to create and control even when the number of musical voices in the space changes (I have ideas, but I don’t have a working model). The best I can come up with now is a space in which there are dozens or hundreds of potential voices, and ones or zeros on the diagonal of the operators turn those voices on and off. I haven’t done the experiments, yet, that will tell me if this is good enough. Right now, it feels kind of clunky, the matrices seem like they will be too big.

The other big missing piece is the linear treatment of time, i.e. making sure that chord progressions always follow each other in time and never stack up on top of each other, but I’m pretty confident that fractal interpolation based on iterated function systems of operators in voice space can do the job. Still, I need to do the experiments here, as well.

This advice assumes you already are a programmer – but that you want to be a much better one! It reflects my own personal methods, and may not work for everyone. Still, I hope you find it helpful. I know that I myself am a much better programmer now than I was when I started, and this is what I have learned.

My advice reflects decades of experience in multiple languages, multiple problem domains, and multiple applications that are used all over the world. I have written this in the order of the steps that you would take in developing a new software project; but I have also prioritized the importance of the critical steps.

In general, I am trying to impart a scientific approach to programming.

Before anything else, start a written log for your project. The purpose of the log is to clarify your thinking about the project, to record test results, and to save you from having to solve the same problem more than once. I prefer LaTeX for maintaining such logs, because LaTeX turns out to be easier to use, and to produce more beautiful results, than word processors. But using a spreadsheet or a word processor would also work. The log should be used on conjunction with comments that go into your source code control system whenever you check in a revision to a file (see below). In a sense, the log and the checkin comments are part of the same system. The present paragraph is the second most important paragraph in this advice.

At the beginning of the project log, write down as clearly and concisely as possible what the new software should do. This is the “Program Specification” (also called “Design Specification”) for your project. At first, you will not be able to be precise enough or complete enough. But be as clear and concise as you can be. As the project proceeds, you will clarify and re-clarify the “Program Specification.” It will become the Introduction to the “User’s Guide” for your software.

Use only general-purpose, high-level, widely used programming languages. These are (roughly in order of actual usage for critical software such as operating systems, or high-performance applications in warcraft, automobiles, medicine, finance): first C++ and C; then Java, C#, and Python; possibly FORTRAN, possibly Lua. Use only one language if at all possible; but in some cases, you will need to use more than one. For example, if your software needs to be user-programmable, then often it is a good idea to write the user-accessible parts in Python or Lua and the internals in C++. For another example, you may want to write some numerical routines in FORTRAN. The main reasons for using widely-used languages are (a) they are better maintained, and (b) when (not if) you run into difficult problems in using the language, you will probably be able to google for solutions because (remarkably often!) other people will already have encountered your problems and solved them for you.

Use the optimal language (or languages). Identify your problem domain (e.g. in my case computer music, trading systems, or e-commerce) and look at the leading software systems in that domain to see what languages they use. But if you think some other language would be better, go ahead and add it to the list. Make a scatter plot. The X dimension is frequency of usage in your problem domain (starting with the most used language). Rank the following in order of importance for your project: runtime efficiency, ease of writing code, ease of reading code, and size of user base. The weighted average of these features is the Y dimension of your plot (starting with the largest value). Plot each language as one point on both dimensions, and simply use the language that is closest to the origin. Use that language even if you have to learn it first. Do not use a language because you know it, or like it, or because it is fashionable – use the language that looks most likely to solve your actual problems. However, trust me – you can’t go wrong with C++.

If existing programs or libraries solve your problem, or part of it, then use them. Do not re-write software that already works. Prefer open source software to proprietary software – it is cheaper, it is easier to understand, and you can try fixing it yourself when (not if) you run into problems. Prefer third-party software with larger user bases, since such software is likely to be better maintained and to last longer. Also prefer software that runs on multiple platforms. Do not distract yourself from the difficulty of your real problems by playing with code for no good reason. The present paragraph is the third most important paragraph in this advice.

The choice of build system is almost as important as the choice of language. I prefer SCons, others CMake. Do not use autotools, or makefiles, or Visual C++ project files. Everything goes into one build file – libraries, programs, tests, documentation, installation, you name it. The present paragraph is the fifth most important paragraph in this advice.

You also need, in order of decreasing importance, a source code control system, a good visual source-level debugger, a good code editor, and a GUI form builder. There is no reason not to use an open source system, such as Git or Subversion, for source control unless your institution requires otherwise. In many cases Emacs is a good editor, in other cases Eclipse, in yet others Visual Studio.

Once you have got this far, create an empty source repository and empty build system for your project, write a stub application (or library, or whatever it will be), and compile it. The reason for doing a stub first is, that way you don’t begin by writing loads of code that turn out not to be correct for your platform or compiler. Every time you write some code, rebuild the project. Get rid of all compiler warnings if at all possible.

Now you are writing code that compiles without warnings. If your editor has an automatic code reformatting feature, use that (constantly, and with its default settings) instead of manually formatting your code. Don’t put blank lines in your code, except between class and function declarations and definitions; because the more code there is on a page, the easier it is to read, and your idea of where to put a blank line inside a function is not the same as mine.

Do not comment code; instead, use understandable names for functions, variables, and classes – including understandable names for loop indexes and such. One reason is that you will change the code and forget to change the comments – therefore, comments can actually end up making code harder, rather than easier, to read. An even more important reason is that doing this also helps you to clarify the code, which helps to make sure that it really solves your problems (see below).

But there are important exceptions. You need a “Reference Manual” for your software. Whenever you need to document something for the “Reference,” do it only using Doxygen comments in the code. Also, if you are not sure whether you yourself have clearly understood an algorithm that you are about to code, or you think somebody else reading your code might have trouble understanding how a function or algorithm works, put in comments that explain what is happening as clearly and concisely as possible – always using complete sentences that start with capital letters and end with periods. Whenever you clarify the code, either remove or clarify these comments as well.

Do not abbreviate, either in code or in comments. Spell out everything, even if it takes more typing. The reason is that you will search for names (often), and if you use abbreviations you will not remember which abbreviation you used.

As for checkin comments, keep them as short as possible; their real purpose is to help someone looking at the source code tree to find changes, who will then look at the source code and comments in source code for more complete information.

Do not use the C preprocessor if at all possible (or any other similar facility), except to prevent multiple inclusions of header file contents. The preprocessor not only makes code harder to debug, it also makes code harder to read.

In C++, put as much code as possible into your header files. Put member function definitions inline, in the class bodies, in the header files. Either put each class into its own header file, or put all related classes into a single header file. In many libraries, you can put all the code into header files, or even one header file; and if you can, you should. If you are writing a plugin that does not expose a programming interface for compile-time linkage, then put all the code into one regular source file, including all declarations (i.e. no header file at all). The idea is to have the smallest possible number of files. Bigger files are easier to search and to read, and fewer files make the build system easier to maintain. Modern compilers won’t complain. Similarly, you want to have the smallest possible number of declarations, hence it is better to define functions inline in the class bodies in the header files.

Now you are ready to design. Start with the basic ideas. They will vary from project to project. For a library, that might be the API declaration; for a program, it might be the basic data structures and algorithms, or a database schema; for a plugin, it might be a data flow graph. Finish the declarations, implement stubs for all functions, declare instances of all objects in the test code, and get it to compile without warnings. Now start actually implementing functions…

All of the above is preliminary. The following is the core of my advice. The last numbered item is the most important, but the first item is the one to which you should pay the most constant attention.

1. Do not write fancy, tricky code. Write plain, straightforward code. If at all possible, use only the facilities of the language itself. Never use a platform-specific system call or a function in a third-party library, if the C runtime library or the standard C++ library contains a function that does the same job. If your code is multi-threaded, prefer OpenMP, which is a part of the C++ and FORTRAN languages, to pthreads or Intel Threading Building Blocks. Use only the core, stable features of the language. Use standard algorithms if at all possible. Write code that kiddies can read and understand. Your code should look just like the short examples in a beginner’s text for your language. Believe me, such plain code will run faster and be easier to maintain than fancy code. Yet clear code has an even more important role in testing the correctness of your ideas (as explained below).
2. As you write your software, also write a program (or programs) to test it. Keep adding tests to this program or programs until your project is finished.  If you write code without testing all important use cases, your code will not be correct.
3. If your code has a client-server structure, or a protocol stack, make completing a round trip through the stack the priority, before adding any other functionality to your project.
4. Re-work the design of your code as often as necessary. This includes re-writing the “Program Specification.” Code expresses ideas. These ideas are like a scientific theory or set of engineering principles. Or rather, they are not like a theory; they are a theory – and a formal theory, to boot, since a programming language is a formal language. The ideas/code should capture the problem domain completely, without contradiction, and as concisely as possible. You must re-work your code until it produces the scientific or artistic “Ah-HAH!” sensation that tells you, both logically and intuitively, that you have captured the problem domain in this complete, consistent, and concise way. You can get the “Ah-HAH!” from a half-baked idea; but you cannot have a correct idea without the “Ah-HAH!”  If anything seems not quite right, or is bothering you even a little, you must rework the code. Such intuitions are the foundation of success in programming. Some examples of software that elicit this “Ah-HAH!” are the Standard Template Library in C++, the Jack system for Linux audio, the C programming language, the Scheme programming language, the Lua programming language, the SQL language for databases, the Swing user interface toolkit in Java, and the first spreadsheet programs. Examples of software that does not do this are the Java language itself, the C++ programming language, Microsoft Office, and all operating systems.

The reason for putting clarity and testing ahead of formulating ideas is that, in reality, you will not be able to write clear, concise code that runs without error until you have grounded your code in consistent, concise ideas that completely capture your problem domain. In other words, the tests are the engineering experiments that tell you whether your code/theory about the problem domain is correct.

Yet I have put the clarity of the code ahead even of passing all tests – because although it definitely is possible to write code that passes all tests, but does not express a complete solution to the problem, it is all but impossible to write such code clearly. In other words, the more clearly the code is written, the easier it is to spot what parts of the problem you have missed. The present paragraph is the most important paragraph in this advice.

If you need the utmost runtime performance from your code, first make sure you have the optimal build options, then cut to the chase and use a profiler. Write up all results in the project log.

Sometimes the debugger is essential, but for the most part, you should avoid it like the plague. As a project grows, the software quickly becomes complex, and then tracing through the debugger can become unbelievably time-consuming. Rather than debug, re-read the code line by line and try to figure out what it is actually doing. Formulate a theory of what went wrong, and put in print statements to test your theory. You can narrow down where the problem by trying this in different places, working from higher up in the code on down to lower levels. However, if your problem crashes or throws an exception, use the debugger right away, because it will automatically show the stack trace at the time of the crash or exception. Write up all theories and test results in the project log. Note that on platforms with something like DTrace, you do not need to explicitly code print statements. On such platforms you should maintain a library of trace scripts for the project, perhaps in the body of the project log (another reason for using LaTeX, which uses plain text files). The present paragraph is the fourth most important paragraph in this advice.

If you follow this advice, and especially if you internalize the philosophy of writing the clearest possible code and testing all use cases, you will be surprised at how little debugging you need to do. You will spend a very short time setting up your build system and stub project; what seems like forever fussing around, with your head hurting, while you re-work and re-work the ideas and clarify and re-clarify the initial code; then the “Ah-HAH!” will come, and you will finish coding all functionality and test cases in what seems like a remarkably short time – often, coding as fast as you can type.

When you are done you will also have a test suite, a “User’s Guide,” and a “Reference Manual;” and your code will probably port very easily to other operating systems.

The Foundational Questions Institute (FQXi) has now awarded first prize in its annual essay contest to Louis Crane for Stardrives and Spinoza. This is a follow-up to Are Black Hole Starships Possible? by Crane and Shawn Westmoreland, which I have already commented on below.

The theme of this year’s contest is “What is ultimately possible in Physics?” I am always interested in everything in the essay — the limits of science indeed, the future of technology and the possibility of interstellar travel, and the theological questions that Crane brings up at the end of his essay.

Some things about the essay make me rather uneasy. I truly do not know what to make of Lee Smolin’s idea that to create a black hole, even a small one, is to create an entire new Big Bang and subsequent new universe. My uneasiness arises from the fact that I am not at all comfortable with the idea of being, as a black hole engineer, the likely creator and destroyer of a very large number of civilizations. Either this goes way above my pay grade, or it shows me that I am a drastically larger creature than I thought I was, or it shows me that no sentient being can avoid these dizzying and dismayingly unpredictable responsibilities.

It also makes me uneasy that Professor Crane avowedly sees this project as fusing scientific and religious motives. I prefer to keep them separate. I believe that my God is rather taller than even the most ancient of black hole engineers. While I am attracted to the idea of divinization up to a point, I feel that to identify the human (or the transhuman) and the divine, even as the limit of a sequence as Crane implies, is, in the end, nothing more than self-idolatry.

Setting aside the potential for human beings to assume apparently God-like powers, I regard Louis Crane’s line of thought as being of the first importance. One of his most striking points is that an artificial black hole could be an experiment to decide between theories of quantum gravity, by measuring alternative predictions for the phenomenology of Hawking radiation near the Planck scale in the real world.

But, of course, for me personally, the most exciting thing is a practical proposal, or at least a not obviously impractical proposal, for starships and a starship-based civilization and economy. Among other things, this turns the heat way up on Fermi’s old question, “Where are they?”

Also, the essay proceeds in good Gödelian style by reasoning in a mathematical and scientific way about a foundational question that has well-defined meanings both operationally and philosophically. In this way, it is possible to make theological inferences based on matters of fact, or at least, to clarify dilemmas and meanings.

Despite my theological reservations, I applaud Professor Crane, and I consider the essay to have the potential for influencing the future of human civilization. If it does, it may submerge and resurface in accordance with the spirits of the ages and their technical powers.

In his conclusion, Professor Crane writes:

We have outlined a plausible future where a central project for the whole
world gives us an almost infinite extension of our range as a result of an immense
collective effort. Depending on subtle points of interpretation of general relativity,
this could come with a new understanding of our place in the universe,
in which we play a role in its cycle of creation.

Again prescinding from the theological implications, I quite agree that such collective projects are highly desirable. I even fear that without them, we may well either not survive ourselves, or become a good deal nastier than we already are.

Note to science fiction writers: I’m sure Crane is quite correct that no more efficient engine can be made, but it seems clear that making such an engine is beyond the efforts of any individual or small group, at least until such time as one person can successfully direct the work of an entire large army of robotic spacecraft. The levels of difficulty in technology, and in the evolution of civilizations, are real.

Can we get down now? Can we get going?

When I was 19 I thought and wrote about the future from the standpoint of a would-be “hard” science-fiction writer.

My basic thinking was to explore the long-term consequences of the nuclear balance of terror. I did not believe that the balance was truly stable (events have since proved me correct). I thought there actually would be a general nuclear war, and that it would leave survivors at least in the southern hemisphere, and that some of those survivors would still have nuclear weapons. In fact, the survivors either would have a monopoly on nuclear weapons, or they would keep on fighting until they had won such a monopoly. They would then spy on everyone using computer technology in order to keep that monopoly. They would become corrupt and brutal, and they would be very difficult to get rid of. I thought there would be no riddance of these dictators until we returned to frontier conditions by colonizing outer space. I felt (and still do) that the familiar science-fictional picture of a world pushed back into the dark ages by a nuclear war, affording survivors a test of virtue and a “fresh start”, is a romantic fantasy that ducks the hard questions.

We have not had a nuclear war — thank God.

But we have had several nasty near misses. And now, we have nuclear proliferation plus a great deal more surveillance than used to be possible. In fact, the logic underlying my original thinking still seems quite sound. Nuclear weapons (along with other factors) do seem to be pushing us into a world of widespread and frequent surveillance. It will, most likely, be an unofficial empire or, more likely, a co-dominium of great powers dedicated to preventing something like a nuclear war between Israel and Muslims that happens to kill a few hundred million people outside of the war zone, not to mention severe environmental consequences such as a decade of global cooling. If there is a co-dominium, then competition between the ruling powers, who are very unlikely to love each other, plus the resentment of the ruled, will create large zones containing what amounts to a dark age. Again, in spite of the increasing (although fragile) prosperity and health of the world on average, such zones do appear to be growing — Maoist sections of India, Nigeria, Congo, various drug-producing boondocks.

To possess true weapons of mass destruction — nuclear weapons or plagues — is completely irrational beyond the level of the absolute minimum required for deterrence. Once you have accomplished deterrence, additional weapons can only mean your own country, your own children, will be hit that much harder if the hammer comes down. To use such weapons would be even more irrational.

If the probability of their use does not decline to a very low level with time, then they will eventually be used. Any use will slam the world into a very bad place. Think 9/11 to the 10th power.

Answer me honestly now, using ordinary common sense: is the probability of use falling, or rising?

There is a nightmarish, “frozen” quality to this scenario. Nuclear deterrence makes it very difficult to actually win a large conflict. Conflicts, and even more the root causes of conflic, can continue to fester for long periods.

Heidi and I saw Gerhard Richter’s “Abstract Paintings” at the Marion Goodman Gallery today. The paintings grasped me, and the room tilted this way or that depending on which painting held me in its gaze. Some of them — many of them — are quite colorful and beautiful. On the whole, the room had as much or more bodily impact than any other room of paintings I have entered, which is saying a lot since I have been going to galleries and museums since I was a child going with my parents, both of whom painted. My mother indeed was a fine artist herself, and both of her parents.

When I got home I turned to Richter’s own anthology of writings, The Daily Practice of Painting. I found that Richter accepted from an interviewer the appellation Informel, a term coined to denote informal process, especially in abstract painting.

Of course my own work in music depends utterly on formal languages and is as highly structured as you like. Still, there is something very important in common with Richter’s working method. Both of us spend a lot of time allowing some process to produce material, in ways not completely controllable or predictable in advance, and then we try to find whether the result is any good or not. This repeated decision making has very informal grounds, and in that sense algorithmic composition, appearances to the contrary, is as Informel as action painting.

But there may be more to it than that, and this bears thinking about. Certainly I am trying to bring into the algorithms themselves some sort of structure, some sort of guidance, something that filters according to musical perception and even tradition. But I can’t afford to lose the unexpected, the surprise, that which will demand a decision that must indeed be Informel. This is a fine dialectic. This automation is something I need to think about more — all the more necessary, to the extent that I do succeed in modeling perception or tradition.

Richter says painting is not imitating Nature, but I feel that the automatic processes both are an aspect of Nature, and to some extent an imitation of Nature, or simulation of it.

So, perhaps here is a way in which artifice and Nature are similar — when captured or simulated in algorithmic form, they both exemplify computational irreducibility. Both Nature and tradition embody generative structures.

But no matter how many or how sophisticated such generative processes may be, artist and audience alike must reduce them to the Informel — accept, or reject, on grounds that can never be completely explicated or formalized.

Several years of experience composing in PTV space demonstrates beyond a doubt (to me, at least) that designing score generators to operate in voice-leading and chord spaces has extremely significant long-term artistic potential. I would say that the gamble of work invested has more than paid off as hoped. I would even go so far as to say that, upon it, probably rest hopes for algorithmically generating music of historic significance, or for the future appeal of generative music to wider audiences.

But experience also demonstrates that there are fundamental problems in current geometric representations of music. The main problem is that while composers easily produce voice-leadings from one arity of pitch-class set to another, modeling this in geometric music theory is not trivial and has not been done in a satisfactory manner. It’s not a show-stopper, but a solution would greatly magnifiy the significance of the approach.

The reason for preferring geometric music theory (as in the work of Tymoczko, Fiore, or Chew) over pattern-based or heuristic approaches (such as that of David Cope) is that the geometric approach seems more mathematically concise, more scientifically fundamental, and more stylistically flexible. I believe it is increasingly evident that the geometric approach is grounded in deep, cross-cultural structures of musical perception. I hope that musicologists will get even more scientific and do more real psychological experiments to empirically validate the extent of this grounding and to identify the theories that best fit the evidence and are most productive for future research.

However, of course, composing is not musicology. For me, the path forward lies in staying current with the musicological research, especially with respect to geometrically modeling progressions in functional harmony and of arbitrary arity, while trying to come up with computer implementations that work for real composing. It may be necessary to move to spaces that do not so directly map voices to dimensions. The spaces also need to incorporate other dimensions of voices in addition to just pitch-class or pitch.

I can and will proceed to investigate simultaneously both generative algorithms, and the fundamental spaces involved in adequate representations of compositional operations. With respect to algorithms, the two basic algorithms will probably remain rewriting systems (such as Lindenmayer systems) and attractors (such as iterated function systems). Mapping onto musical spaces is certainly easier with rewriting systems, but the highly desirable goal of enabling parametric composition seems to be easier to achieve with attractors.

Defining spaces that represent chords of arbitrary arity with additional attributes of each voice such as loudness, duration, and instrument assignment, and finding convincing mappings to such spaces from the attractors of iterated function systems or other parametrically mappable dynamical systems, would hit the ball miles out of the park and that is what I am trying to do.

I have indeed been trying to do this since 1984, when I got the idea after hearing Benoit Mandelbrot lecture on the Mandelbrot Set at the University of Washington during the period I was taking a seminar in computer music with John Rahn. That’s a long time to work on a single problem! But the thing is, I definitely am far closer to a solution than I was at the beginning. I know how to do the parametric mapping. I can prove that some such systems are musically universal. I now know how to model and generate voice-leadings and chord progressions, instead of just sprays of notes.  I have preliminary ideas on functional progressions and perhaps even prolongations. The only remaining problems are the arity problem and the attractor mapping problem.

The mapping problem has several potential solutions, such as fractal interpolation, or simply collapsing the dimensions of attractors down to a few. The arity problem is the only remaining fundamental problem.

Iran appears to be acquiring nuclear weaponry. So far, or rather since Nagasaki, the leaders of the nuclear powers have been, just, rational enough not to use their weapons. If Middle Eastern nations acquire them, perhaps their leaders also will be so rational — indeed, I would expect so. But what if paramilitary forces get them?… the kind of people often called (and sometimes rightly) fanatics? Such people are not always deterrable in the same way as the leaders of nations, for their identities are not bound to actualities, but rather to potentialities that nuclear retaliation cannot so easily destroy.

The documented behavior of Pakistan is very alarming. No doubt the leaders of Pakistan would not like their weapons to fall, uncontrolled at any rate, into the hands of paramilitaries. The same can (probably) be said of the leaders of Iran. But both nations have diligently fostered paramilitary forces that, quite possibly, are not thoroughly under control by their masters. It is not nearly as unlikely as one would wish that nuclear weapons will never fall into the hands of people who will not and can not be deterred.

What is more, it is obvious that nuclear weapons are far from the last word in weapons of mass destruction. It is very probable that, with the continued development of science and technology, weapons of mass destruction will become easier and easier to make, to hide, and to use. At some point one imagines it possible to make them in a decently equipped university or even high school.

So, it seems that in the future paramilitary forces will be increasingly likely to acquire, and to use, true weapons of mass destruction. Each use will terrorize people into a hard reaction. Each hard reaction will embolden the terrorists and create more of them. A hard reaction that is hard enough to actually stop this cycle will first reduce to ashes nations hosting terrorists, and then set up a regime of universal spying and intimidation.

It seems we are headed for a time of harrowing, in which the paranoia that has created weapons of mass destruction either triumphs in a very repressive regime, or fanaticism has been selected out of people — either by nature, or by artifice.

I think the best we can hope for here is to deliberately breed fanaticism out of people, which will require creating a new basis for human identity that is not fixated on nation states or other such entities that have a duty to fight. I am not a pacifist. I could and would fight under some circumstances.

But I know a bind when I see one.

By a strange coincidence, only a few days after I read the proposal for a dark matter engine, I find on the arXiv another, probably even more significant proposal by Louis Crane and Shawn Westmoreland of Kansas State University: Are Black Hole Starships Possible? (http://arxiv.org/abs/0908.1803).

The gist of Crane and Westmoreland’s paper is that physics appears to permit the construction of small black holes that function as power generators and rocket engines of the highest possible efficiency. The technology required to construct and manage such an engine is impressive, but does not appear to be beyond the capabilities of the near to medium future. Our current understanding of the physics is not complete, so better understanding could rule out the construction of such engines, or make them even more difficult to make — or make them easier to make!

A black hole engine can perhaps be fed with mass to keep it going, it can be contained and steered with particle beams, and the energy it radiates can be used to manufacture more black hole engines. If possible, then, the black hole engine appears to be an ultimate technology. You build an army of robots near the Sun, they collect and channel solar energy to a sphere of gamma-ray lasers that implodes radiation to form a small black hole, you feed it and steer it, and then you use the first black hole to make as many more as you like. Each black hole produces enough energy to drive a heavy, shielded, human-crewed starship to relativistic speeds.

Although I am not competent to rule on the feasibility of black hole engines, I am competent to make the following observation. We are living in the critical decades that will determine the long-term future of the human race. In this and the next generation or so, we will probably know if dark matter engines, or black hole engines, or some other ultimate technology is possible for us — or not. We will certainly know if there are other water-bearing planets near us — or not. And we will certainly know if other technological civilizations are traveling in space near us (a black hole rocket creates a rather spectacular high-frequency gravitational contrail), or trying to signal us — or not.

These staggering questions can be arranged into a simple table that determines the alternative futures of the human race.

1. If black hole engines are not possible and there are no neighboring technological civilizations, then it is up to us try to keep ourselves going in this one solar system. We have no choice, we must go into ourselves rather than out into interstellar space.
2. If black hole engines are not possible but there are neighboring technological civilizations, then we try to keep going in this one solar system, but we also must deal with the consequences of unknown messages (possibly including detailed instructions for building aliens and a town for them from scratch) from beyond. It is our choice how we respond.
3. If black hole engines are possible and there are no neighboring technological civilizations, then we have no enemies or competitors, and it is our choice to expand into interstellar space in a movement that makes all past frontiers paltry and produces a human civilization of hitherto unimaginable size and glory.
4. If black hole engines are possible and we do have neighbors, then everything is up for grabs. The stakes are so vast we can’t even imagine them. We are instantly exterminated as dangerous vermin (black hole warhead approaching Earth at 99% c can’t be detected in time to stop it from literally shattering the planet); we find ourselves in a desperate war for survival with planets splattering left and right; we are enslaved or exploited by hucksters will millions of years of experience; we join a commonwealth with the wisdom to protect and nurture all members; starfarers are sparse enough to co-exist without war or politics; who knows!…. What happens may be our choice — or not.

By the way, I view the posting by reputable researchers of a paper such as arXiv:0908.1803 as an extremely encouraging sign of the times.

Dark matter rockets, or rather reciprocating ramjets, are proposed by Jia Liu in http://arxiv.org/abs/0908.1429. Dark matter particles annihilate on collision. The spacecraft opens its engine to sweep in dark matter, closes the opening, and compresses the dark matter until it annihilates to produce energy. This is as efficient as it gets. The other end of the engine is then opened to function as a jet. This work cycle repeats to accelerate the spacecraft. According to Jia, speeds vary on dark matter density and distribution, but relativistic speeds seem feasible — small fractions of c for the most part, but much higher near kernels of dark matter distribution. It does not take long, or far, for the spacecraft to accelerate to cruising velocity. Braking is just firing in reverse.

The best thing about this scheme is that, if it works, we are not going to run out of fuel anytime soon. Since the demise of the Bussard ramjet, which it resembles except in fuel, there has not been a plausible “hard science fiction” scenario for interstellar propulsion on a large scale (antimatter could in principle be manufactured near stars and used for interstellar hops, but not for longer journeys, and not perhaps on a large scale).

I imagine very small “cylinders”, or perhaps a wheel or turbine of some kind.

Granting the dark matter engine, what else is required for a plausible human expansion into interstellar colonies?

First, journeys are still waaay too long, so either some safe form of hibernation must be developed, or else the human life span must be extended at least to several centuries.

Second, it must become more economic to mine, manufacture, farm, and indeed live in outer space than on Earth, and it must be possible to do this from a base of one or a few starships.

About the economics, there can be no doubt. There is just so obviously oodles more of what we want and need floating around free for the taking out there, than there is buried somewhere on someone else’s property around here.

About the base scale, that is problematic on several counts. One can imagine some sort of partly automatic, self-regulating machine ecology. But what is the minimum size? If it is too big, then cultural factors kick in — the scale of initial investment might turn out to be daunting: politically imprudent, culturally unimaginable.

Of course, we haven’t actually detected any dark matter just yet, but we shouldn’t let a little thing like that cramp our imaginations. After all, as Vera Rubin proved, something is definitely making the galaxies spin faster.