|
|
This advice assumes you are already a programmer – but that you want to be a much better one! It reflects my own personal method, 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 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, airplanes, 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 need, in order of decreasing importance, a good visual source-level debugger, a good code editor, and a GUI form builder. In many cases Emacs is a good choice, in other cases Eclipse, in yet others Visual Studio.
Once you have got this far, create an 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. The 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.
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.
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.
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 this is preliminary. The following items are the core of my advice. The last item is the most important, but the first item is the one to which you should pay the most constant attention.
- 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).
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
I am reading Rene Guenon’s The Crisis of the Modern World.
Guenon has a reasoned prejudice against science that is however quite mistaken. He is rhetorical rather than cogent, has a number of outright crank views… and yet is brilliant, brilliant, brilliant.
What is right about Guenon, what is wrong, and what do I fail to grasp?
What is right is that there is a transcendental dimension to human life. It is universal. It is ultimate. It is authoritative. Indeed, it is authority in its native form. And I agree with Guenon (and Leo Strauss, and Eric Vogelin) that a civilization that flees from it or denies it is likely to destroy itself, or be destroyed.
What is wrong is that science, contra Guenon, does have an intrinsic transcendental value (it is true, not one often well stated or understood by scientists, but it is clear enough in that most real scientists are primarily motivated not by utility, but rather by the beauty of the world and of the order of the world). I detect an angry, dismissive, unconscious, defensive tone or attitude in Guenon with respect to science and technology.
What is is probably wrong is Guenon’s implication that tradition, in some sense, was politically formative or normative for civilizations before the 6th century BCE. As far as I can tell the wanderings and conquests of tribes and peoples was, is, and has always been depressingly and familiarly biological. But I may not grasp what he is trying to say, I may be reading too much into it.
I suspect, though I cannot well argue, that the move towards missionary religions (Buddhism, contemporary reactions in Hinduism, Judaism, Christianity, Islam) is well motivated, not wrongly motivated.
Perhaps a clue lies in Judaism. It is a missionary religion in that it views itself as holding revealed truth and in the end receiving all the world in the Moshiach’s Kingdom, and yet it is tolerant in that it fully acknowledges the righteousness of gentiles, and does not aspire to on its own hook immediately to convert the world.
What is wrong is that initiation by some preceding initiate is necessary in all cases. It was not necessary for the founders of the traditions. And it is certain that there were founders, because at one time there were not even any human beings.
I may fail to grasp that traditions were mutually tolerant. This may be the case (before the 6th century BCE). Or it may not, I do not know the history well enough. I am reasonably confident that it used to be a lot harder to travel this globe, and that may have a lot to do with tolerance — perhaps it was not possible to think about conversion.
What is wrong is absolutely crank theories such as Hyperborea, which historically have lead on naturally (e.g., Julius Evola or the Ahnenerbe SS) to anti-Semitism, racism, and all manner of truly vicious follies.
What I fail to grasp (perhaps I will grasp it later) is how Guenon deals with people like Second Isaiah or St. John of the Cross, who are, it is transparently obvious, initiated in the only important sense and who are yet committed to a missionary religion. One could say the same of the historical Buddha (or the perhaps several original founders of Buddhism).
The question for me is, why does a liberal such as myself, completely committed to the scientific world-view, find himself so eager to hear wild birds like Guenon, Strauss, Vogelin, Eliade?
A lamp: Thomas Merton?
I must keep working on my perception that fundamentalism is a contemporary form of idolatry, the characteristic sin of our age. The “revelation” is the idol, however, not the God of revelation. Interestingly, Guenon seems to scorn such reactions.
Mirror idolatries? – Everything in Nature is computable. Truth is revealed in some book.
Jews versus Arabs is a reductio to some sort of absurdam.
Parametric composition is the art of composing music by means of an algorithm whose output can be more or less continuously varied by adjusting a few numerical parameters. If changes in the pieces depend continuously upon changes in the parameters, then related pieces must lie next to each other in the parameter space. Such a parameter space is intelligible. It can be explored interactively, for example by zooming in and out, to discover certain classes of pieces, and more interesting pieces in each class. The parameter space becomes a sort of Mandelbrot set, and each parameter point in the space represents a piece, which is a sort of Julia set.
So, one would like there to be an algorithm that can generate any possible piece of music, and one would like to be able to compose by interactively exploring this space. I have informally proved that such an algorithm and such a parameter space exists. The proof goes like this. Any piece of music can be represented by a set of coefficients for the duplex Gabor transform over a subset of time and frequency. These coefficients form a finite 2-dimensional array of real numbers. Any such array can be approximated as closely as desired by computing the measure on a complex-valued iterated function system (IFS). From Michael Barnsley’s Collage Theorem, it follows that the measure changes continuously with changes in the coefficients of the IFS. Finally, although the IFS parameters can vary in number, any subset of IFS parameters can be mapped onto the unit square by identifying the upper corner of the square with the largest IFS in the subset, and the lower corner with the smallest IFS in the subset. Linear interpolation then suffices to identify each point in the unit square with a unique set of IFS coefficients, and each set of IFS coefficients in the subset can be interpolated from some point in the unit square. Thus, the unit square becomes a parameter map for generating any piece of music in the specified subset of time and frequency and the specified subset of IFS parameters. By making the subset of IFS parameters sufficiently large — perhaps a few hundred or a few thousand coefficients — the procedure becomes musically fruitful. Probably most pieces of music of moderate duration can be approximated by at most a few tens of thousands coefficients. After all, Barnsley showed that most digital images could be approximated by at most a few thousand IFS coefficients, and a digitized piece of music contains no more than about ten times as much data as a digitized image.
What I have not done is to create a musically useful implementation of this algorithm. It is too compute-intensive. On current personal computers, computing a single IFS and rendering the generated duplex Gabor transform (I have performed the experiment) takes several minutes at least. To be musically useful, the algorithm would have to be able to generate thousands of these points in less than a minute, and even then it would take hours of exploration to discover interesting pieces. It might be possible to send each parameter point out to a di fferent computer on the World Wide Web, using a system like that of SETI@Home, so this brute-force approach should still be investigated. After all, the algorithm lends itself to computing each IFS, or indeed each coefficient in any one Gabor transform, in parallel.
However, on a single computer, computing so many sounds in this way is much too slow and takes much too much memory. Of course, instead of using Gabor transforms to represent the complete sound of each piece, it might also work to represent only the score for each piece. Scores contains millions of times less data than sounds. However, then the representation of the scores becomes an issue — there are many, many ways of representing scores. Ideally, one would like to be able to specify an orchestra of N voices over some subset of time, frequency, and loudness, and then be able to generate any subset of points in this set. Even better, one would like the representation to be close to how composers hear and imagine music. We know that the Gabor transform (sonograms, more or less) or, even better, various wavelet transforms are indeed close to at least some basic aspects of how composers hear and imagine sounds. What concise, compressed representation of scores is similarly close to at least some basic aspects of how composers hear and imagine scores?
|
|
