In the End

There’s a lot of thunder about Apple’s new developer licensing, in which programmers are required to use one of three members of the “C” family of programming languages. iPhones (and soon iPads) really do matter, so people are sensitive to anyone controlling or wrecking the process by which apps get created. The prevention of developers from using their languages of choice is inflaming an “Apple hates its developers” conception.

I think people are confusing implementation with design.

Nearly 25 years ago, I took Barbara Liskov’s computer laboratory course. The grade was apportioned 25% for each of design, implementation, testing, and documentation. While there was no way to get an “A” without implemenation, it was relatively easy get a “B” without writing a single line of code. As Computer Science wasn’t even my major, I chose to nail design, testing and documentation in the abstract. Implementation was done with a language (CLU) that Prof. Liskov had invented to illustrate the class material. I’ve never seen the language used elsewhere. However, a year later I was able to internalize her philosophies very well when I took over maintenance and development of an autonomous automatic telescope. The previous designer had thoroughly mastered CLU, but implemented everything in C. This same guy had written a Scheme interpreter for his HP-41CV calculator. Most people write their Scheme interpeters in Scheme, but he did it in Focal assembly.

Back then, the boundaries between design and implementation were clearer: terminal time was so valuable that Prof. Liskov only allowed students to use them after writing out the programs on paper. Today I think the single most important thing about computers is that experiments are cheap, and this allows us to experiment in design. But that’s not an excuse for pretending that implementation is design.

Language matters to developer productivity, but so does everything else. While Objective C is much more like Smalltalk than other C dialects, I find that I can be roughly an order of magnitude more productive in Smalltalk. On the other hand, I think I can be much more productive still in Common Lisp. In the early days of Teleplace (nee Qwaq), I think Lisp was more the native tongue of CEO Greg Nuyens, Croquet architects David Reed and David Smith, and product architect Brad Fowlow, while Smalltalk works much better for Croquet Architects Alan Kay and Andreas Raab. But Smalltalk is working out just fine, thank you. Most of our Object C code is now being written by a Java hero. Within the implementation realm, there are other things that matter just as much.

The programming environment matters a lot to implementation effectiveness. Apple’s XCode is not too horrible. I’d still prefer a Lisp Machine from 20 years ago, but XCode isn’t going to cripple my project. As long as Apple keeps XCode competitive, I don’t care too much about them doing so by concentrating only on making it work with their favorite languages. It matters to me that XCode is free as in beer. I would care much more if, like Oracle or Microsoft, Apple were to actively cripple the development environment such that one could only use it all through expensive support and a priesthood of proprietary “ecosystem” experts.

Language implementations and development environments have rarely been profitable, and there has been little commercial reason for developers to devote time to making them better. But Apple may be on to something in using the license not as a means of controlling language, but as a means of controlling development environment, and from there to controlling delivery platform. I think they want to make it non-trivial for a developer to take an app developed for iPhone with some cross-platform dev-tool, and re-target it for Android or others. My experience so far, though, is that just as with game platforms (who have used similar tactics), there’s enough difference in core capability that you have to rewrite an app anyway — at least for all but the most trivial apps. (Of course, trivial apps might make up the bulk of the market, but that’s not really what I’m interested in as a developer, any more than I’m interested in trivial writing.)

Effectiveness is not meted out by the label on a compiler. Or on a dev-tool. You can screw things up in any language.

You can create hidden meaning. A year or more ago I added some behavior to the end of a long call chain. As originally written, each method took a boolean used in a few scattered places down that chain. I need for the end of that chain to sometimes print a varying message when and only when the boolean was true. The code was already pretty fragile, we were close to a release, and I wanted to convince myself that my change was safe — so I let the “boolean” be true, false, or a string to be treated as true. (Yes, Liskov covered Stamp Coupling.) But when a colleague wanted to modify the code this week (shortly before another release), that hidden meaning was certainly not apparent. My code sucked. (It’s all relative, though. Liskov taught us that Stamp Coupling as only one degree more evil than Data Coupling.)

You can create hidden languages. Last week I wanted to modify some other code, so I asked it’s author. He couldn’t remember, but “Hey,” he said. “It’s only code. Just read it.” In fact, our system is written to use straight Smalltalk within some domains, and another language called “Tweak” at others. The latter requires compiler support and is effectively Content Coupled based on whether or not the active process is a Tweak process whether the receiver a message carries Tweak semantics. My first attempt unwittingly crossed these domains. I may have had entirely different and simpler bug in my code as well, but my point is that this wasn’t clear. In the end I got things working only by very carefully managing the interaction between these two languages that were both “Smalltalk”.

I feel that an important reason that my favorite languages can be more effective is that they give you plenty of rope to manage complexity by hiding meaning and hiding languages. In the hands of an expert, that’s powerful. But it also increases the risk of hanging yourself up. Honestly, I’d rather have the iPhone Apps I use work well, then to make it even 10 times easier for me to do the 10% of my job that is implementation.

Relative to the tools of real engineering, all computer languages suck. My first degree was in ship design. People have been building ships for 5000 years and failure is obvious. There’s a clear model of what matters. Success is generally achieved at the expense of expressiveness by the individual shipyard worker. Shipbuilding implementation failures are very rare today, and still most of these come from individual failures. Software has been around for 50 years. Half of all projects fail, and nearly 100% of implementations fail at some point. The source of design or implementation failure is rarely obvious. I think design failure is typically from creating the wrong solution or at the wrong time. There was no shipbuilding (implementation) failure in the LNG tankers mothballed in the shipyard I worked in one summer. Just the wrong solution for that era’s energy markets. High-productivity languages are important to me because they tend to be the ones that support timely, apt, or flexible solutions for large projects. But as of today I’m not sure if they really better at programming-in-the-large, or if they simply allow larger projects to be done by smaller teams of talented cowboys? iPhone apps are small. If it’s large enough for programmer productivity to matter, than you’re building the wrong thing, and you will fail, and not because of an implementation failure.

As implementers, I increasingly think think we developers (and our productivity) don’t matter much, any more than shipyard workers do. There are two potential outcomes to this trend:
– Programmers will become commodities like teachers or writers, and just as poorly valued.
– When languages-cum-dev-environments are capable of regularly empowering better design, the systems that do will start to matter.
I think both true will someday be for different kinds of activities, just as the writing value chain today sometimes greatly rewards some writing projects, but not most. Today, languages and development environments just aren’t good enough to reliably make that kind of difference.

Our Teleplace product greatly empowers collaboration and it supports programming the environment itself. But there’s perhaps an order of magnitude more interest in administrative issues than in programming, and neither is generally being done collaboratively in-world. I think there’s yet another order of magnitude more support questions about end-users fighting with MS Windows about such things as device drivers, monitor and audio management, or networked home directory access. Here’s a state of the art system, and programmer productivity just doesn’t matter relative to other things that do.

Some of the shock about Apple’s license is centered on the semantics of what an application is “originally written” in, per the language of the license. Apple is talking about implementation. Programmers are talking about design, which is kind of silly, because that’s not the programmers domain or forte. How often do we roll our eyes over the user’s or salesman’s ridiculous ideas? Each such interaction indicates a design failure, not an implementation (programming) failure.

I can understand Apple wanting to control implementation – managing complexity and managing value chain. I expect this is ultimately impractical because of hidden meaning and hidden language. But it is certainly impractical with respect to design. Apple doesn’t control what’s in our heads. We can and should design in any medium, including paper, and limiting implementation to C-based “goodspeak” isn’t going to stop that. Developer-submited applications in any language are at some point linked to Apple-supplied libraries written in another. It’s annoying but perfectly reasonable for Apple to only support that for semantics defined by their favorite language. A different application implementation language would have to support those semantics exactly. That’s not possible for some languages, but it is possible for the binaries produced by quite a few. Apple can only effectively claim those rights that it can enforce, and even if they required developers to submit source, it couldn’t hope to catch all translations. In the late ’90’s I got sick of writing industrial systems in C, so write an entire ANSI-conforming Common Lisp implementation that translated Lisp not to machine code or C-as-portable-assembler, but to (more-or-less) idiomatic, human-readable C. I had about 20 big companies using it. There was great interest from NASA’s JPL because they where writing AI system in Lisp for autonomous deep-space probes, but all flight applications had to be reviewed in C, as C was one of the few flight-certified languages available to them. I had always thought that my product failed because we were not a software company: I single handedly did all compiler and library development, QA, packing, documentation, marketing and sales. But now I think we failed because translation just didn’t matter. JPL rewrote applications where they needed to and got certified when they had to. Rewriting — in any language — is always an improvement anyway. I was solving a problem that mattered to developers, but didn’t ultimately matter to any business process.

But I could be wrong. I do feel that people who care should fight for things they believe in. The last two years my daughter went to LA with her high-school chorus. The teacher put tape over everyone’s door after lights out, in order to be able to tell in the morning who had left their rooms. My daughter got in trouble because someone else had ripped off her tape one night. Silly rule, as it put the innocent at risk for getting unfairly punished and completely failed to stop the guilty. This year, a friend of my daughter decided to illustrate this in the obvious way — by ripping the tape off of every single door. Sometimes griefing is good. A little revolution now and then is a good thing. So if it matters to you, develop and use an effective translator. I don’t think Apple would be any more effective in controlling translation than the RIAA in controlling copying. It’s pretty pointless to prohibit that which you cannot prevent. But it’s also pretty silly to wine too much about the prohibition. My guess, though is that it just doesn’t matter that much for iPhone-scaled apps.

In the end, my view is that Apple’s license covers implementation, not design. Language is not that crucial to implementation, and implementation is not that crucial to success. Design and other things matter more.

If I don’t care about the license, then why am I working myself into a lather about it? Why spend an afternoon writing this, when I’m supposed to be hacking away in XCode? Indeed, in preparation of getting the next Apple Developer’s environment with the screwy license, I had to finally upgrade my operating system to Apple’s Snow Leopard. That broke my build and wasted my time, and that made me mad.

After the LA trip, my daughter was pretty mad at her friend in that unpleasant teenage way. It turns out that she was simultaneously mad that her friend had devoted so much effort to action on such an unimportant thing, and partly that her friend had not involved her! A lot of people have asked me what I thought about Apple’s silly rule. I think I’m kind of mad that people really think the license is important. I’m more concerned that the value chain of Oracle and Microsoft (or of Bank of America) is so important to people without creating actual value, or that people accept protection rackets in software and security (or in banking or medicine). I guess I simultaneously want people to stop frittering away rage in unimportant things, while at the same time want to show Apple how silly their planners are being.