Volume Number: 25
Issue Number: 07
Column Tag: The Road to Code
by Dave Dribin
Brad Cox is one of the co-creators of the Objective-C language, along with Tom Love. Objective-C was originally designed as a Smalltalk-like object system on top of the C language. NeXT started using Objective-C for its NeXTstep operating system and later, when Apple bought NeXT, it became the language du jour for writing Mac OS X and iPhone applications. Brad was nice enough to talk with me for an interview with MacTech.
Dave Dribin: Please tell our readers who you are and what your background is with the Objective-C language?
Brad Cox: I worked with the ITT research lab, many moons ago, now. We were interested in building coordination systems to affect people's productivity, instead of the communication systems like email and chat and so forth. What people today call groupware. I couldn't see doing that in C and was casting around for higher-level approaches. When I learned about Smalltalk and object-oriented programming from the Byte article, I think in 1982, I realized I could do something pretty similar in C and that would be a better basis to build on.
Initial versions were the usual kind of lash up of sed and awk all kind of tools. That worked well enough so that we evolved it eventually to something based on lex and yacc. And I believe you know the rest.
DD: So it was originally implemented as a preprocessor that generated C code, or how did that work?
BC: That'd be accurate of any implementation that I know of. It just makes sense to generate C. But it might generate assembly language these days. But, yes, all early versions were certainly that way and I'm not sure about later versions.
DD: The square brackets are a distinctive part of Objective-C syntax. How did the square brackets come about and was this your doing?
BC: Yeah, that was me. Quite literally it was a search for something that wasn't taken. Curly braces were taken. Ordinary parentheses were taken. It was just a search for braces that wouldn't collide with something C used.
DD: What features did you want to add that you had to cut due to maybe technical or time restraints?
BC: Over the years there were a lot of them. What Smalltalk calls blocks was one of them. Garbage collection was another. And an interpretive language was a third. At various times, all of those were implemented in various forms, but none of them are a particularly good fit for a language like C. They required fairly heavy interference with how C did things, and we weren't happy with any of those.
DD: We are actually getting this just today. As of Mac OS X 10.5, Apple gave us garbage collection. And as far as 10.6, the Snow Leopard release, they are going to add blocks to Objective-C. So we're all very excited about that. They're even adding it to the C syntax.
BC: Yeah, I've always been an enthusiast for blocks, but getting access to the caller's stack frame is really tricky to do.
DD: In the static vs. dynamic typing debate, Objective-C straddles both camps with its dynamic runtime and static compiler. Was this a conscious decision or was it an implementation issue?
BC: Well, a lot of that was added after my time. When I was directly involved, its goal was simply to add dynamic typing to C's static typing. And the static typing you're referring to was largely added after my time.
The idea was that Objective-C features were to be a fairly lightweight kind of tool: a soldering gun not a silicon fab line. The things you'd use C for, the statically typed stuff would be ways of building the software ICs. And that'd be done in C. That was the idea at least.
As it began to catch on, various extensions were made that culminated in the static typing you see today.
DD: I think the dynamic typing is one of Objective-C's benefits, compared to languages like C++ and Java which are very statically typed.
BC: I've always thought of it as a difference between a soldering gun, which you use to assemble pre-existing components versus a silicon fab line, which is a far more technical and heavy weight kind of tool, which has its place, but they're different tools.
DD: So the dynamic typing makes it easier to connect things up?
BC: Yes
DD: So is the idea you that would bring everything together at runtime?
BC: Not exactly. By writing an Objective-C program you'd send this message to that. That's what I mean by hooking them up. By writing the source code that says I want to use a dictionary or map or whatever they call it in Objective-C these days. You'd describe that in source code and off it goes.
DD: So Apple's sold something like 30 million iPods and iPhones? How does it feel to have Objective-C running in the palm of so many people's hands?
BC: (laughs) Yeah, it's pretty nice.
DD: It seems that language design has been fairly stagnant. Java, C#, Python and Ruby, are not ultimately that different from Objective-C of 20-25 years ago. The functional languages are coming a little more to the forefront these days. Do you have any idea what the next Big Thing for language design or features is going to be?
BC: Well everybody says functional languages. I've spent a while trying to get my head around them, and I just run into syntax issues. It's like me and Lisp: we never got along.
DD: (laughs) I understand that completely.
BC: I have the same trouble with Haskell.
DD: So you have done some work with Haskell?
BC: Yes, uh huh. It's fairly exciting for DoD (Department of Defense) because the idea is that in a functional language, by writing the rules, you can pretty much write them directly off of policy. That means you can prove them correct by comparing them against policy. And that's very exciting stuff. I've been involved in some projects that try to do exactly that. Unfortunately, not hands on so I never reached the point of any fluency in Haskell.
DD: Do you think the language choice affects the end quality of the software, or are all object-oriented programming languages essentially the same?
BC: I think they're pretty much the same. Bearing in mind that distinction between soldering guns and silicon fab lines. That's a big difference.
DD: The fact that you have reusable components?
BC: Well silicon fab lines can reuse gate arrays, right. So the ability to reuse is not a fine distinction. The affect is mainly on the cost and how long it takes to do anything.
DD: So from reading your website and looking at your published works such as Superdistribution, it seems your focus has changed to software components. Could you talk a bit more about your current interests?
BC: I wouldn't say the focus has been changed. Remember, the reason I wrote Objective-C is that I needed a soldering gun. My interest was in components. I wanted office automation components that I could put together to build coordination systems. So the focus hasn't changed at all, I just needed to detour into languages to get there.
DD: Do you want to give a quick overview of how you used software components since Objective-C?
BC: Oh sure. I've been using an analogy recently taken directly from the construction industry. I'll put this in the context of DoD and what the government is trying to do. They're faced with the problem of massive scale. They have all of these different agencies, which I'll analogize to cities. And all the agencies want to use IT to improve their productivity. So they're building SOA services. SOA means Service Oriented Architectures.
Now those are granules at a very large scale. They're basically server-based applications that communicate largely through the HTTP protocol. So we have cities, actually in the government you have even larger things than cities, states and nations, but let's stay with cities for now. And each city wants to build IT-based systems based on these SOA-based scaled objects. So that's two levels of granularity right now that you can see directly in the real world that's now happening on a major scale in government and within industry.
Coming at it from the other end of the spectrum, we talked about these gate arrays scale components that are a very big deal in C++ land. And we talked about software IC use which are more like Java classes. So there's two more levels of integration at the low end of the spectrum.
One of my current interests is filling out the gaps between cities and Java classes which I think of as mud and sand. They're components, yes, but they're very small granularity components compared to what you really want to be working with. You want something like bricks. Reusable components that, yes, are built of mud and sand, but they're much larger than any Java class.
Now a very good example of what I'm talking about when I say a brick is a Tomcat web server: a servlet container. It makes a pretty decent brick. The only problem is that it's a pile of jar files. And jar files offer very poor encapsulation compared to what you need to actually trust that this web server still functions properly once underlying jars start changing version numbers.
DD: So you mean there's no way to know that version X works, but when you move up to X+1 that things haven't broken?
BC: Exactly. Or that some hacker hasn't inserted a virus, a big concern in DoD. Because what we want to get to is trusted components, and jar files don't support trust. For that reason which is fairly minor. Now there's a new standard coming on in Java land called OSGi which addresses this and that's my current interest. It's helping OSGi find it's way into everyday practice and then addressing the issue of trust, which involves a whole bunch of non-technical stuff like getting it through certification processes and onto trusted lists and things of that nature.
DD: Is that dealing with code signing and certificate management and that kind of stuff?
BC: It supports that but the usual case of OSGi is to wrap up a bundle, that's the OSGi name for what I'm talking about. Wrap it up so that it encloses some dependencies, and doesn't reference whatever you might drop into the classpath. You control what it can references when you create the bundle.
DD: I don't know if REST, CORBA, and SOAP fits in with components, as a communication path between components, but you mentioned using HTTP. Is that REST communication between these components?
BC: Well that gets me into something that's a little more advanced than I planned to talk about. But one of the reasons that I'm interested in these brick scale components is that it's a very real problem in DoD. DoD doesn't use just one protocol. It uses hundreds of protocols. Every new generation of plane comes out with a new kind of communication devices that doesn't interoperate with anything else.
One of the most exciting kinds of brick is the transport protocol brick. One is Tomcat for HTTP, another supports XMPP, and another one supports Link-16 a DoD Air Force protocol. And so for and so on for those hundreds of protocols.
So, I call those transport components to distinguish them from transform components which get involved in things like securing these protocols at the application level. So there's access control protocols like Sun's OpenSSO and there's confidentiality things. The NSA has this whole variety of encryption algorithms that can be encapsulated as confidentiality bricks. And it just goes on from there. There's a fairly long list of transport components that would end up being used in these systems.
And notice that these bricks are related directly to that analogy of houses that I referred to earlier. Because one thing every house needs, and wouldn't it be nice if they could use the same components to get it, is interoperability and security, which is exactly what I just talked about. Transport interoperability and compatible security.
DD: You mentioned a detour through languages to reach your goal of software components. What got you on that detour?
BC: I just didn't think I could do it in C.
DD: Could you have used Smalltalk directly or were in an environment where C was the language you had to interoperate with?
BC (18:12): Xerox was busy shooting themselves in the foot at the time. They wouldn't sell it to me, or to anybody. The were into this "We're a research lab and that's a research toy and go away."
DD: I've covered all my questions. Is there anything else you wanted to add?
BC: Well I could go on about components forever. Some of this can be easier to follow on my blog than in narrated form: http://bradjcox.blogspot.com/
I'll just wave the flag one more time for OSGi. I think it'll be very important once everybody gets on board. It'll be a bit of a culture shock to get there because it's not an easy tool to use or to learn. But I encourage your readers to start trying because it'll be important.
DD: Is this useful outside of DoD and government work?
BC: Oh yes. I don't believe it applies to Objective-C, yet, but it's coming on strong in Java land. All of the major IDEs, such as Netbeans and Eclipse, are in the midst of a transition to OSGi-based components. And as that matures and as the tools get better, it's going to start bleeding off into people's everyday work. It's a bit of a bleeding edge topic, although, OSGi is very old. The standard itself goes back as far as Objective-C. It's been around for a long time, but it's just now catching on big time in Java-land and it'll probably spread from there.
DD: Is it a replacement for jars, or does it work in conjunction with jars?
BC: The latter.
DD: Extra metadata?
BC: Exactly. A bundle is just a jar file some extra metadata that gets looked at when the bundle launches. So you can think of bundles as miniature SOA services that exist inside a JVM. And they have life cycles, so you can take your dictionary offline and everybody waits for it to come back. That's how you want it to happen.
DD: So you can do online upgrades of components without taking the whole system down?
BC: Exactly. You can literally upgrade very fine-grained things to a new version number, if the things are actually compatible at runtime, and nothing breaks. So the way you typically use it is launch a virtual machine, launch OSGi inside that virtual machine, and let it just stay there indefinitely. And upgrade it as you do software development.
It takes a bit of getting used to. It's a different mental model than when you work with Java, where you launch it and destroy it and launch it and destroy it.
I'd like to thank Brad for taking the time to participate in this interview. It's always great to hear from visionaries in our industry.
Dave Dribin has been writing professional software for over eleven years. After five years programming embedded C in the telecom industry and a brief stint riding the Internet bubble, he decided to venture out on his own. Since 2001, he has been providing independent consulting services, and in 2006, he founded Bit Maki, Inc. Find out more at http://www.bitmaki.com/ and http://www.dribin.org/dave/.
