Airs – Ian Lance Taylor

A long time ago a friend of mine pointed out a sign of trouble in any program: defining a new container model. If you are working in a language that provides containers in the standard library, then use them. If you need a container with specific behaviour, then make it look like the standard containers. If you come across a program which introduces a new model, beware.

I’ve recently been adding Go support to SWIG. SWIG can be used to build interfaces between various different languages and C++. SWIG is a nice program in many ways: it provides a lot of power and flexibility in defining the interface. Internally, though, big chunks are written in C++ but it uses a totally different container model. I assume this is for historical reasons dating back to a beginning in C or possibly even Python. In C++, though, it’s a mess. There is no type checking: it’s all void * pointers. Practically every type (strings, lists, hash tables) converts to everything else implicitly. It brings all the weaknesses of a pure dynamically typed language into C++, without providing any of the benefits.

Sometimes one encounters a programmer who carries a container model from program to program, rewriting it into different languages as needed. The result is a program written for one person. Don’t do that. Use a language in the idioms of the language; don’t try to make it look like a different language. Use the containers which the language provides.

In my youth there was a lot of support for object oriented programming. It was generally agreed that we had a software productivity problem: it was too hard to write programs. The solution was supposedly to adopt object oriented programming techniques. This was expressed in its purest form in Smalltalk, and was brought to the masses in Object Pascal (later Delphi) and C++, followed by Java.

Object oriented programming had a few different ideas, all of which centered around the notion of separating data into relatively small and independent units. Methods are defined independently of specific data, and a given method may be applied to different data units. Data units are grouped by sets of methods, and the method sets can be put into inheritance and abstraction hierarchies.

Object oriented approaches were greatly oversold, and it became clear over time that while they did have many good ideas, they were not the solution to the problems of programming. One of the problems of the object oriented approach is that it encourages you to focus on the relationship between sets of methods that apply to data, rather than focusing on the structure of the data itself. In C++ or Java terms, it’s easy to spend more time thinking about the inheritance relationships between classes than about the individual objects.

Over time, C++ shifted toward a somewhat different style of programming found in the Standard Template Library. This style is based on templates, and focuses on containers and algorithms. I’ve seen people advocate this approach to the point of saying that a good program should have no non-abstract loops: that everything should be done via an appropriate algorithm.

The issue I find with these approaches in practice is that they tend to lead to too much abstraction. Fundamentally all programs deal with data. The goal of a program is to manipulate the data in some way. The goal of abstraction and class inheritance is to permit you to write less code. The goal of data encapsulation is to make your program more maintainable over time. Abstraction beyond those points may make your program better by some artificial index, but it is not really helping you get things done.

If you find yourself asking yourself whether to introduce a new level in your class hierarchy, or you find yourself writing a new template which will only be instantiated once, then you may be falling victim to the abstraction penalty. Shake it off and return to focusing on what your program really needs to do.

The first computer networks widely used outside of academia were things like CompuServe, Prodigy and then AOL. They were walled gardens: all you could access were the things they provided. With the wider spread of the Internet, they slowly granted increasing access to the Internet. Eventually everybody just used the Internet directly via an Internet Service Provider. AOL still exists, but it has fallen far from its glory days. The lesson I took was that walled gardens don’t work.

The success of Facebook belies that lesson. It seems clear that many people conduct a large portion of their Internet life entirely within Facebook. Facebook provides various different forms of communication—e-mail, chat, photo sharing, etc.&mdashbut it all exists only within Facebook. Sure, you can point offsite, but it’s hardly the main form of communication. Facebook is a newer and larger version of the walled gardens of yesterday.

I don’t myself find Facebook to be interesting or useful. I do have an account, but I only go to the Facebook site when I get some message from it. Typically it’s because somebody wrote something on my “wall;” why they didn’t just send me an e-mail message, I don’t know.

Widespread use of Facebook does not necessarily translate to revenue, but all the rumors these days are that they are making plenty of money. The introduction of games which people are willing to pay small amounts of money for was a brilliant idea in this regard—at least, I assume that Facebook gets a small cut.

So my lesson about walled gardens was wrong. Walled gardens works fine if they are compelling enough. That would be fine if Facebook takes its position as a platform seriously enough, if they work to provide neutral access to everybody. So far they do. Their history of trying different approaches is not too encouraging in this regard, but the economics support it. I just wish that I liked the site more.

I was thinking recently about my visit to SCO back in 2003. Since then SCO has been through bankruptcy and their various court cases have collapsed several times, although they are still struggling on. Their argument was always very weak. I could see that at the time, although I was also scared that the court might come to the wrong decision anyhow. Fortunately that has not happened to date.

What I think most about was Blake Stowell’s question to me as I was leaving. Blake Stowell was at the time SCO’s Director of Public Relations. He asked what I would do if I owned some proprietary code that somebody else had copied, implying that SCO’s behaviour was not merely legally justified but was even morally justified. It was a long time ago, but the impression that I recall was that he sincerely thought that SCO was doing something which reasonable people would consider to be OK, and wanted to see whether I agreed. My answer at the time was not very good.

It’s a question which I now think brings us to the heart of copyright laws. If I write something myself, what rights do I have to prevent other people from making derivative works? If I buy the rights to something that somebody else wrote, do I have the same rights with regard to derivative works? Does it matter how those derivative works are being used? I’m raising these rhetorical questions not as a matter of law—the law is what it is—but as a matter of what we, as a society, ideally want to permit. SCO was acting as the copyright equivalent of a patent troll: they acquired the rights to something which they did not create, and attempted to gain revenue from other people using the same ideas. Should we permit that?

In considering issues like this, it’s very important to not mix up copyright with real property. It’s natural to start thinking that something that I write is like something that I own. If I own a car, it’s not OK for somebody to drive it without my permission. The issues with code are far less clear. Copyright is a balance between the rights of the authors and the rights of everybody else. Copyright does not last forever, unlike my ownership of the car. There are various exceptions to copyright, such as fair use. Even if we take SCO’s very best case, they were talking about a tiny percentage of code being copied from an earlier version of Unix into the Linux kernel. Did that give them the right to charge people for using the Linux kernel? If the code was removed from the Linux kernel, as did in fact happen later, would they still have the right to charge based on an expansive notion of derived work?

Intuitively I think that while the original author has considerable rights to control code that she or he writes, those rights tend to decrease with time and distance. It’s not obvious to me that control over an author’s work is something that can be sold or inherited. It also makes a difference whether the work is used in its entirety or whether a portion of the work is excerpted. It also makes a difference whether the work is used by itself or in combination with work by other authors.

Unfortunately these issues are all fuzzy. For law to be useful, the issues have to be spelled out, which is hard, and tends to give too much weight to the author at the expense of the rest of society. And the rules appropriate for books and music may not be appropriate for code.

A sane copyright law has to make it clear that legal assertions like the ones that SCO made claiming to own Linux are unsupportable. The remedy for minor code copying is to remove the copied code; it is not to grant ownership rights to the larger package into which the code was copied.

SCO’s actions were not justified. The fact that they appear to be failing is a triumph of justice.

I’ve run a small e-mail server at airs.com for many years, providing POP and forwarding services for friends and family. In the early days of the net several people found it useful to have a fixed e-mail address which they could forward to their ISP. Later on commercial services appeared, like pobox.com, and these days there are many options available.

The spam wars have made running a small e-mail server steadily harder. I’ve had to change a number of characteristics about the system over the years. One aspect that is difficult to change is that since the server forwards e-mail, in some cases it forwards spam which get through my own spam blockers. That spam is sometimes picked up by the system to which the e-mail is forwarded. When that happens, my server can be marked as a spam source.

When this has happened in the past, it’s been ISPs marking my server as a spam source, and they’ve always provided a way for me to tell them that my system is OK. This has always worked fine (it does require updating in the rare cases when I change the IP address of the server).

Recently I’ve been seeing something new: spam blocking networks which are shared by various recipient systems. What is interesting here is that these spam blocking networks make at least some of their money by charging people to send e-mail into their network. So, for example, returnpath.net decided to block e-mail from my server. They don’t provide any information about why they’ve done so, which makes it hard for me to fix the problem. I can enter the IP address to temporarily remove my server from their blacklist, which of course I have done. But what they really want to do is charge me $200 to have my server listed as a valid e-mail sender. Shortly after signing up with them for the sole purpose of removing my server from their blacklist, I got an e-mail from one of their sales reps offering to sell me their services to ensure that my e-mail messages got delivered. So far I have declined to pay, and some of my e-mail, e.g., to John Levine’s compilers list, is getting blocked.

In other words, what we have here is a spam blocking network which makes money by charging people to send e-mail messages through their spam blocking services. It’s an interesting little low-key protection racket. They have to keep it low-key, since they have to provide a decent quality spam blocking service; otherwise, people won’t use them and they will have nothing to sell to e-mail senders. They have to limit the spamminess of their customers, since otherwise, again, people won’t use their blacklist and they will have nothing to sell. Unfortunately, small e-mail servers like the one I run are caught in the middle. I can hardly pay off every spam blocking service. I don’t want to have to pay off any of them, merely to run a forwarding service.

I’m sure things will change again, but the current situation is not a very good one.