Airs – Ian Lance Taylor

The two best ways of learning how to program are writing code and reading (good) code. I read a lot of code in my younger days, and I think it helped me. Programming courses give students plenty of practice in writing code. I wonder how many give students an opportunity to read good code. There should be a course in which all the students read and discuss a large program, like a literature class.

One problem with that idea is a lack of good code to read. Knuth’s TeX and Metafont books are good reading. But to really understand them you have to first wrap your head around TeX itself, which is a rather complicated macro processor. In some ways the code for TeX is easier to understand than TeX itself. Also, the code is in the Web version of Pascal, not a popular language today. The Lions book and TCP/IP Illustrated, Volume 2, show good coding, and are at least written in C, though again the code is rather old by today’s standards.

Are there any modern code bases that are helpful to read? It would be best if there were some commentary, or at least really excellent comments.

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).

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.

A mention of Squeak in a comment on my last post reminded me of Newsqueak, an interesting little language by Rob Pike. Newsqueak has nothing to do with Squeak. Newsqueak implements Hoare’s idea of Communicating Sequential Processes.

The interesting part of Newsqueak is the channel data type. A channel is a two-way communication path. Given a variable v of type chan of int, the assignment c< - 3 sends 3 on the channel, and the expression < -c receives the next value on the channel.

Thus a channel is basically a Unix pipe, represented as a fundamental data type. It can be used for synchronization as well as communication. This should make it easier to write safe multi-threaded programs.

I've never programmed in Newsqueak, and I don't know if there are even any implementations out there outside of Plan 9. And of course it's possible to use Unix pipes to communicate between threads today, although the required kernel calls and marshalling may make them less efficient than in-process channels. Still it's interesting to think about threading using channels.