Airs – Ian Lance Taylor

I’m back from vacation following the GCC summit.

Since I was on vacation, I wonder: why are science and technology museums so often aimed at children, and art museums so often not? It’s as though science is naturally presented as educational, whereas art is something you simply appreciate.

To me it would seem more natural to do it the other way around. Art museums should show you information about the artist, the milieu, the technology used, how it developed. Science museums should show you the results, and should drop the interactive exhibits and the kid stuff. No doubt I feel this way because I know more about science than about art. Presumably museum curators tend to be the other way around.

There are certainly excellent science museums aimed at adults, like the New York Natural History Museum. A surprisingly good museum is the Transportation Museum in Owls Head, Maine. I’m sure there are many others, but somehow most of the ones I’ve been to are disappointing.

I’m at the GCC Summit in Ottawa, and short on time. I gave a double presentation today, on gold (slides) and on writing gcc in C++ (slides).

No science fiction writer ever predicted what actually happened when we went to the Moon: we came home and never went back. Why did that happen? It happened because 1) going to the Moon is expensive and dangerous; and 2) after we got there once, there was nothing to gain by going there again.

There are lots of advantages to putting machines in space around the earth: nearby satellites have lots of uses. And indeed there is a thriving business in sending those satellites into orbit. There is very little advantage to putting humans into orbit around the earth, but it is close enough that we do it anyhow. There is a market for space tourism, but it is not clear how large it is. There are enough multi-millionaires to fill up the available tourist launch capacity for now, but how many of them will want to go into space twice?

I think that people should move off Earth permanently (not everybody, just those who want to go). It’s the ultimate environmentalist position (Earth—love it or leave it). It’s the best way to ensure the continuation of the human species. I’d love to go into space myself (but I expect that by the time I could afford it, I will be too old).

The problem is that space is an insanely dangerous environment. You might think that it would be unpleasant to be in a blizzard in Antarctica, but that’s peanuts compared to space. It will never be easy to live in space—it will always be dangerous, and it will always be expensive. That means that people will never move there unless they see some significant benefit.

The benefit might be science, but very few people will risk their lives for science. The benefit might be living space, but the people who are short on living space are not the people who can afford to move to space. The benefit might be exploration, but explorers tend to want to come home.

This is an area that is full of unknowns. Right now, though, I don’t see any potential benefit to moving to space that is nearly sufficient to overcome the risk and expense. I hope I’m wrong.

Although it hasn’t been my habit to track other blogs closely, Ben Collins-Sussman wrote an interesting post about Programmer Insecurity. The gist of the post is that programmers need to share code early in the development process. They should not develop code in their own cave, and then unleash it on an unsuspecting world.

This is particularly an issue for the case of modifications to an existing free software project. And it’s particularly true for design rather than code. It’s most important to do your design in the open, and let other developers comment on it. Unfortunately, there can be a catch-22 here: a design without code can be vaporware, so people won’t necessarily pay attention to it. But a poor design supported by good code will also not receive a good reception.

The flip side to public development is that free software programmers can be quite harsh. This is magnified by the nature of the medium used to communicate, e-mail, and it is magnified by the fact that people from different cultures have different expectations. It’s very easy for people to send an e-mail message which is intended to be friendly criticism but which is received as an attack. I’m sure that many free software projects have permanently alienated new developers through this sort of mistake.

So my advice for new contributors is to design in the open and to learn how to read e-mail to extract the useful information while ignoring the attacks. These are two separate skills which need to be developed by aspiring free software programmers.

And my advice for people who want to become maintainers is to develop the skill of making helpful comments which are not disparaging. This requires the use of euphemisms and careful attention to language, which are not characteristics of all good programmers.

I’m not a particularly nice guy on the inside, but I’ve learned to play one by applying a set of transformation to my thoughts. A few examples:

• You’re wrong => That turns out not to be the case.
• This is stupid => I think you need some more thought here.
• Learn to use the indent program => You should add spaces there, there, and there.
• We already know this is a terrible idea => You may want to review this e-mail thread.
• Have you heard the word “portability”? => You need to consider other types of processors.
• What idiot told you to do it this way? => Here are some good examples that you may want to follow.

You get the idea. The point is two-fold: developers should try to extract facts from e-mail while ignoring the language, and developers should try to use friendly language to put across their points.

I recall a Microsoft magazine ad from the mid-1980’s, back when Microsoft was best known for the compiler. The ad was four pages long. The first page said that their new development environment had the three things every programmer wanted. I didn’t use Microsoft tools in any case, but when I looked at that page, I immediately thought “I only want one thing from my development environment: I want it to be faster.” The “three things” were on the next three pages of the ad: they were speed (of compiling the program), speed (of debugging the program), and speed (of the generated code). That was an ad writer who really understood what programmers want.

I’m a long-time emacs user and I’ve never used a more integrated development environment. I played around with Eclipse a few years back and at the time it was slow. In emacs I turn off font-lock mode because it is slow. When it comes to writing code I want to be able to just write.

Of course Eclipse, and font-lock mode, bring another advantage: they make it more likely for your code to be correct as you write it, since they can point out typos right away. I typically don’t find typos until I compile the code. So I definitely see an advantage to using an editor which parses your code as you type–as long as you never have to wait for it.

Speed of compilation is still an issue, at least with C/C++. Using a compilation cluster is easy with distcc, as long as you have a few machines to run compiles on. You’re still limited by how long it takes the largest piece of your program to compile, which can easily be 30 seconds. And of course the link time is serialized, although I have ideas on how to speed that up. The ideal compilation time should be no more than a few seconds–short enough that you don’t switch onto another task. I have not used Eclipse for Java development, but I gather that compilation can be very fast. I hope that Tom Tromey’s work on incremental compilation can help with C/C++.

I don’t personally find that speed of debugging is much of an issue for me these days. The debugger is not the first tool I reach for to find problems in code, and when I do, I normally find that gdb is fast enough.

Speed of development is one of the big advantages of the interpreted languages like Python. There have been interpreted environments for C/C++ in the past, trying to provide the same development time benefits while still permitting fast execution. None of them have caught on, and these days a development environment will only catch on if it is near zero-cost. I’ve never used one, so I don’t know what it is like.

In any case, I still fully agree with that old Microsoft ad: the only way to judge a development environment is by how fast it lets you write code, by how fast you can debug the code, and by how fast the program runs. Any bells and whistles which aren’t directly related to making things faster are irrelevant.