Unfortunately, I’ve started to notice that as programs get smarter and as interface designers get more clever, machines are becoming more like people. Interfaces for web sites and phones are increasingly adjusting based on your past interactions. In many ways this is good, as over time the interaction gets smoother and easier. However, it means that there is a lack of consistency: an input today does not produce the same effect as the same input did yesterday. It also means that there is an increase in ambiguity: it’s difficult to tell the difference between working correctly and being slightly broken.

In effect, the computing world is becoming increasingly tuned for people who prefer dealing with people rather than people who prefer dealing with machines. On average this is of course a good thing, as most of the population seems to find it frustrating to deal with machines. But it’s somewhat ironic considering that the programmers doing most of the work tend to be people who prefer dealing with machines.

I don’t want to give up the advantages I get when things go well, so I guess I’m stuck in an increasingly inconsistent and ambiguous world.

When life changes for an existing city, you can either adapt the city or you can replace it piece by piece. The U.S. pretty reliably picks replacement. It’s interesting to see a place which tries harder to adapt, a spirit no doubt encouraged by the historical nature of the buildings.

Stockholm is also notable for how easy it is to get around on bike. The bike lanes here are serious alternatives to pedestrian or car traffic, with their own signs and traffic lights. They aren’t universal, but they seem to cover the city and the immediate suburbs pretty well. This too is of course fitted into the existing streets and bridges, somehow. Particularly impressive is a few construction sites I’ve come across where a temporary bike lane was built because the existing one was being built over.

Creating high quality bike lanes may seem like an inefficient use of public funds, but of course it’s really no less efficient than building roads. The U.S. does still mostly agree that roads are a common good, and it seems like, in cities, real bike lanes could be as well.

So now McChrystal is out amid reports of bickering and infighting. But we’re still going to follow the same plan under General Petraeus. The basic dynamic of the situation is unchanged. How is this not going to be a disaster?

The U.S. made progress in Iraq, against my expectations, by showing that people had more to gain by participating in politics than they did by staying out. In particular, the Iraqis showed themselves what a civil war would look like, and many of them backed away. Iraq remains a long way from normal, and the former middle class remains largely outside the country, but it’s hugely better than it was four years ago.

Afghanistan is a much bigger country than Iraq with a much smaller population. The political dynamics are by necessity quite different. The political class is much smaller. I don’t see why one would expect the same process to work.

It’s also worth questioning what the U.S. has to gain from Afghanistan. Al Qaeda has relocated into Pakistan. No reasonable person would want to let the Taliban regain control, but there is no U.S. national interest in Afghanistan. There is no oil. The recently trumpeted minerals wealth has little national interest to the U.S., no slouch in mineral wealth itself. What is going to keep us there for the time it takes to turn Afghanistan into a modern society?

At this point I think the military approach is entirely wrong. I think an economic approach would be much more effective. Maybe we should try to make Kabul as secure as we can and as rich as we can, and open its gates to anybody who will enter without weapons. Hand out radios and food. Let the Taliban fight for the rest of the country, but show most of the people that a better way is available. I don’t know if this would work at all, but it would be cheaper in lives and money than the current approach.

Since we’re not going to do that, I just hope that I’m wrong again, and that something useful comes out of this, even if I can’t see what.

Unfortunately, death is not a disease to be cured. It’s a fundamental aspect of life. In the competition for food and other resources necessary for life, the most significant competitors of any individual organism are the other members of its own species. They are the ones who seek to occupy exactly the same niche. Complex organisms which do not die will have more size and experience than their descendants, and will therefore tend to outcompete them. It follows that species whose organisms do not die will tend to not evolve. They will over time be outcompeted by other species which do evolve. Thus death is a key evolutionary strategy for any successful species. The fact that individuals may prefer not to die is irrelevant to long term evolutionary history.

What this means is that death is a finely tuned aspect of ourselves, just as finely tuned as our rather remarkable ability to reproduce ourselves. And it’s not just an aspect of ourselves, it’s an aspect of our evolutionary forebears for eons.

It may seem superficially that humans pass through a period of childhood, then enter a phase of stasis, and then decline and die. However, in fact humans change slowly throughout their lives. Arresting the aging process would be just as complex as arresting the growth process during the teenage years. All our bodily systems are shaped by evolution to head in a particular direction. Stopping that means changing all aspects of our bodies. It would mean a person aged 20 who does not turn into a person aged 30. That means changing a hundred different aspects of how the body grows.

The fundamental argument of the people seeking to conquer death is that the body is a machine, and that we can figure out how to fix the machine so that it does not fail. However, the bodily machine was created by an evolutionary process, not by human design. Think of the ugliest least comprehensible computer program you’ve ever seen, code which is uncommented and full of cross dependencies. Think of the hacker who wrote that code–code that works but is unmaintainable. Imagine letting that hacker work on a computer program for a million years, continually micro-optimizing and never doing a comprehensive overhaul or redesign. Now you have to reverse engineer it. That’s what figuring out the human body is like. Every system in the body has deep layers of complexity and is related to other systems in strange and surprising ways. Despite all the near-miraculous advances of modern medicine, we are still only scratching the surface of understanding how the body works. Increasing computer power will help, of course, but we don’t even know the questions to ask. This is going to be a task of many generations, and even as we start to understand it will take far more work before we have any idea how to actually change anything.

Of course I could be entirely wrong, and I do think that research on aging should continue. I just don’t see any reason for optimism. A human who does not age would really be an entirely different species. What reason do we have to think that we can create such a species any time in the foreseeable future? If we could create it, what reason do we have to think that we can somehow convert ourselves?

Actually, other than being Swedish, they are entirely different from Larsson’s novels. Larsson reads like an intelligent Dan Brown with real characterization. The Beck novels are police procedurals, telling the story of solving a crime from the perspective of a policeman, Martin Beck. The novels were also intended to be an examination of Swedish society, which sounds daunting but is quite effective in practice.

The Beck novels have some extremely funny scenes, scenes which are made all the funnier by the fact that nobody in the story considers the amusing at all, and indeed they would not be funny if you were involved in them in real life. For example, the police breaking into what turns out to be a completely empty room in The Terrorists (Terroristerna), resulting through a series of completely plausible mishaps in several shootings and near fatalities.

Henning Mankell, a popular current Swedish mystery writer, is clearly strongly influenced by Sjöwall and Wahlöö. Many of Mankell’s novels are quite good, but I prefer the earlier ones.

I just completed the implementation of this in gccgo. It turned out to be fairly complex, so I’m writing some notes here on how it works.

The language requires that panic runs the deferred functions before unwinding the stack. This means that if the deferred function calls runtime.Callers (which doesn’t work in gccgo, but never mind, it will eventually) it gets a full backtrace of where the call to panic occurred. If the language did not work that way, it would be difficult to use recover as a general error handling mechanism, because there would be no good way to dump a stack trace. Building up a stack trace through each deferred function call would be inefficient.

The language also requires that recover only return a value when it is called directly from a function run by a defer statement. Otherwise it would be difficult for a deferred function to call a function which uses panic and recover for error handling; the recover might pick up the panic for its caller, which would be confusing.

As a general gccgo principle I wanted to avoid requiring new gcc backend features. That raised some difficulty in implementing these Go language requirements. How can the recover function know whether it is being invoked directly by a function started by defer? In 6g, walking up the stack is efficient. The panic function can record its stack position, and the recover function can verify that it is at the correct distance below. In gccgo, there is no mechanism for reliably walking up the stack other than exception stack unwinding, which does not provide a helpful API. Even if it did, gccgo’s split stack code can introduce random additional stack frames which are painful to account for. And there is no good way for panic to mark the stack in gccgo.

What I did instead was have the defer statement check whether the function is it deferring might call recover (e.g., it definitely calls recover, or it is a function pointer so we don’t know). In that case, the defer statement arranges to have the deferred thunk record the return address of the deferred function at the top of the defer stack. This value is obtained via gcc’s address-of-label extension, so no new feature was required. This gives us a value which a function which calls recover can check, because a function can always reliably determine its own return address via gcc’s __builtin_return_address function.

However, if the stack is split, then __builtin_return_address will return the address of the stack splitting cleanup code rather than the real caller. To avoid that problem, a function which calls recover is split into two parts. The first part is a small thunk which is marked to not permit its stack to be split. This thunk gets its return address and checks whether it is being invoked directly from defer. It passes this as a new boolean parameter to the real function, which does permit a split stack. The real function checks the new parameter before calling recover; if it is false, it just produces a nil rather than calling recover. The real function is marked uninlinable, to ensure that it is not inlined into its only call site, which could blow out the stack.

That is sufficient to let us know whether recover should return a panic value if there is one, at the cost of having an extra thunk for every function which calls recover. Now we can look at the panic function. It walks up the defer stack, calling functions as it goes. When a function sucessfully calls recover, the panic stack is marked. This stops the calls to the deferred functions, and starts a stack unwind phase. The stack unwinding is done exactly the way that g++ handles exceptions. The g++ exception mechanism is general and cross-language, so this part was relatively easy. This means that every function that calls recover has an exception handler. The exception handlers are all the same: if this is the function in which recover returned a value, then simply return from the current function, effectively stopping the stack unwind. If this is not the function in which recover returned a value, then resume the stack unwinding, just as though the exception were rethrown in C++.

This system is somewhat baroque but it appears to be working. Everything is reasonably efficient except for a call to recover which does not return nil; that is as expensive as a C++ exception. Perhaps I will think of ways to simplify it over time.

PG&E is the only company from which I can buy my electricity. Electricity distribution is a classic natural monopoly; why would two different companies put up wires to everybody’s house? Since modern life requires electricity, and since I can only get it from PG&E, I am a PG&E customer. Proposition 16 appears to be designed solely to preserve PG&E’s monopoly position, by making it much harder for communities to create their own municipal power companies. It would be hard enough to get a majority vote in favor of government run power; I think we can assume that a 2/3 majority would be effectively impossible. It’s pretty darn annoying that PG&E is spending $35 million, including money they collect from me, on this. Is that a good use of my money?

Municipal power is not impossible. For example, Palo Alto, California, uses a municipal power utility. It was notable during the rolling blackouts that affected most of California in the early 2000s that Palo Alto was immune. So it’s not as though PG&E deserves to be protected because they are doing a particularly good job. When a real crunch time came, they did a very poor job indeed.

It’s difficult for me to imagine why anybody would vote in favor of such a blatant power grab by a private company. But then, of course, there’s the $35 million. The opponents of proposition 16 have reportedly raised less than $100,000. I assume that if PG&E succeeds we will see more and more cases where private companies spend lots of money on ballot initiatives in their favor. I hope that it fails, and if I have any readers in California I encourage you to vote against proposition 16 this Tuesday.

Even allegorical fairy tales are weakened by a lack of internal story consistency.

There has been a long effort to prepare for this, by moving GCC’s code base from C to the common subset of C and C++. While people naturally think of C++ as an extension to C, they are different languages and there is a lot of C code which is not valid C++. In the GCC code base, one of the biggest issues was that enums are more restricted by the type system in C++ than they are in C. Another was that in C++ you may not use the same name as a typedef and a struct tag, except for the special case of making the struct tag be a typedef for the struct itself.

Gabriel Dos Reis did the first substantial work on moving the GCC code base to the common subset, and many other people contributed. I think it’s fair to say that I did the lion’s share of the work, starting with my surprise presentation on the advantages of C++ at the 2008 GCC Summit. I did a lot of work to improve the -Wc++-compat warning option to warn about C code which was not in the C/C++ common subset, and I did a lot of work to make GCC code compile with that option without warnings.

C++ will not magically make the GCC code base better. However, I believe that it will give us some useful tools to incrementally improve the code base over time, making it easier to read, easier to modify, and more efficient. I say this not based on theory, but on my experiences with gold and with the gccgo frontend. I’ve already started writing some draft C++ coding conventions which I hope we can use to guide our efforts.

On the other hand, the GCC project has some problems. The major individual contributors to GCC are hired to work on it. That means that they have a lot of time and resources to use to improve the compiler, which is good. However, it also has some negative effects. It’s difficult for new volunteers to join the community. It’s hard for them to learn the code base and it’s hard for them to keep up with the pace of change. It’s also hard for them to learn the conventions of how the project works, and they get little help in getting their patches in. Also, the people who work on GCC have learned the intricacies of the code base over time. They do not rely on the internal documentation. The effect is that the internal documentation for some parts of the code base is quite weak, and none of the main contributors are motivated to fix it.

Another, separate, problem is that there is no single person or group with a clear ability and willingness to decide on the direction of the project. In the past the direction has been set at different times by people like Richard Stallman, Richard Kenner, Jeff Law, and Richard Henderson. None of them are playing that role today. The effect is that nobody can see whether significant new features should or should not go into the project, which leads to a tendency for inconclusive discussions and unreviewed patches. People hoping to contribute are left with no clear path forward. (I should mention that groups like the GCC Steering Committee and the GCC Release Managers are effective but do not take on this role, which is more that of an architect.)

A third problem is that GCC has no public relations activity. The project web page tells you what GCC is but says nothing about how it compares to other compilers or how it has improved over time. There are some common criticisms of GCC, such as the belief that it is measurably worse than proprietary compilers, or that it is stagnating, which the project makes no attempt to discuss or dispute.

None of these issues are critical. As I said, GCC is highly successful. But they are areas where I think GCC could improve. Unfortunately, pointing out these issues is insufficient; it’s necessary for peole to step up to take on these roles. The various companies which pay people to work on GCC are generally less interested in these aspects of the project, which makes it that much harder to find people to work on them.