Back in 1983, Bob Jarvis founded a company named Wizard Systems. Wizard's main product was Wizard C, a C compiler that Bob wrote and that later turned into Borland's Turbo C. Since leaving Borland a year ago, Bob has been working on a new programming language. At this writing, the language doesn't have a name, its original name having failed to make it over the trademark search hurdle, so in this two-part interview I've referred to it as The Language.
Since the commercial success rate for new languages developed by individuals not employed by AT&T is less than stunning, I was curious about Bob's motives. I was pretty sure he wasn't putting in all this effort strictly for the experience. When he immediately pronounced the prospects for any new language developed today "dim," I got more curious. Eventually he told me what he has in mind for The Language, but not until he had given me his views on the aesthetics and maturity of C++, criticized Borland's and Microsoft's corporate strategies, reported on second thoughts on Ada at the DoD, and soul-searching about the right kind of parallelism at Cray Research, and shared some calculated guesses about the programming languages of the year 2001. Strangely enough, all of these things proved to be eminently relevant to my original question: Why is Bob Jarvis writing a new programming language?
DDJ: It seems daring to be writing a new language at this time. What do you think the prospects are for a new language developed today? BJ: I'd have to say they are dim.
DDJ: Dim, eh?
BJ: Let's put it this way: Almost all of the languages that are popular today started out with very modest goals, usually from a very small number of people tinkering in their basement. Some of them, like Niklaus Wirth, are obviously very respected designers, but Dennis Ritchie was at the time an unknown. And it took years and years for the languages to gain international popularity. They built by word of mouth. C, for example: Enough people liked it that it developed a kind of underground support network.
So I have very realistic views about the potential for new languages. I put together something that I personally find fun to program in, that solves some problems that I had, and hopefully other people will like it and want to program in it, too. Who knows where it goes from there?
DDJ: Still, I imagine you'd like it if your language inspired the kind of grass-roots support that C had. You were part of that support network for C when you wrote Wizard C, which has since become Turbo C.
BJ: And now of course it's modified into C++, but that's not my fault.
DDJ: You're not a fan of C++, I take it?
BJ: I am on record as being an anti-C++ guy. That should not be taken as a comment about Borland; I think that they made a very sound business decision in doing C++. I think they quite rightly decided that they wanted to satisfy that large demand. My objections to C++ are technical and aesthetic.
DDJ: Such as?
BJ: Well, it's much too large a language. There are too many features. There are statements that you can't tell whether they are expressions or declarations, and you may not be able to tell by parsing, even by the time you get to a semicolon. The same sequence of characters maybe validly interpretable as a declaration or as an expression. There is a resolution rule which you're supposed to choose if you can't decide, but that kind of parsing rule is pretty objectionable. It's certainly not the way I would define a language.
And some of the new stuff that they're doing with parameterized types falls in that same category. For example, the way that you define a parameterized type is you enclose it in angle brackets. Well, angle brackets are greater than and less than, and there are circumstances where you cannot tell whether a greater than is the ending angle bracket for a parameterized type or an operator in an expression in one of the parameters for that type. Worse, if you have a parameterized type that takes another parameterized type as its parameter, you end up with two closing angle brackets. And if you leave the space out, then you've created a right-shift operator, and you get a syntax error.
DDJ: Be that as it may, C++ is certainly entrenched.
BJ: Yeah. That's one of the reasons why, when the subject came up at Borland and there was some discussion about whether they should do a subset or the full language, I said, as much as I may not have liked the language, that we really needed to do the full language. Of course I wasn't alone in that view. And I think Borland has been proven right: They've sold a ton of compilers. But I think C++ has succeeded as much as it has because AT&T is very solidly behind it and is pushing a whole lot of people into using it.
I was talking to the people at Cray and, although I'm sure this is not the official opinion of Cray, one of their engineers said, "We don't have that much demand from our customers. We have a little, but not enough to do our own compiler yet." But AT&T is going to put more and more of the Unix operating system into C++; there will be additional utilities and additional functionality; X Windows, for example. So from Cray's standpoint, they're eventually going to have to do a C++ compiler for the simple reason that they have to run Unix on their machines.
DDJ: C++ has more than word of mouth behind it. Like Ada.
BJ: There have been a few very well publicized efforts like Ada of major teams getting together to design languages and then ramming them down people's throats. Ada is obviously still with us, but I was talking with someone from the Department of Defense about Ada programming on Crays, and it turns out that the only people that are doing Ada programming on Crays happen to be oil companies. Don't ask me why. The Department of Defense guy was saying, "Yeah, we don't do any Ada programming." And I said, "Wait a minute. Isn't it your language?" And he said, "Yeah, but all our people got exceptions, so we don't have to." Nobody wants to use it inside the DoD.
DDJ: But as you say, Ada is still with us, and C++ is all over us. Although it may not be much consolation to independent language developers among Dr. Dobb's readers, it seems that, if that big institution is in there pushing, a language can become well entrenched pretty quickly.
BJ: If you've got a company pushing a language, that can make for some very rapid success, and I think in the case of C++ that may have hurt the language, because it's very immature. It's changing very rapidly. For it to be as popular as it is and to still be changing so quickly, where virtually every six months to a year you're getting a major new release with massive new features, and where the standards committee is years away from completing a standard -- the fact there are all these people using it means that it's going to be around, but I think it's going to be a very unstable picture for quite a few years to come.
DDJ: I take it The Language avoids some of the problems you have with C++. Did you conceive it as an alternative to C++?
BJ: I started working on it as a sort of thought process while at Borland. We were doing all this C++, and although I didn't like C++, I also didn't really know it. I thought I should really learn the issues of object-oriented programming. Then there were also some techniques in incremental compilation that I wanted to explore.
DDJ: How did you start? How do you begin writing a new programming language?
BJ: I came up with three really strong ideas that I wanted. One, I wanted a systems programming language that you could use to write efficient systems programs, like operating systems and compilers. And I wanted to have OOP, but fairly modest OOP; not anything as elaborate as C++ has. And the third thing was that I wanted to make it easy to do incremental compilation, because I wanted to explore that area of program development. So I made a number of changes to C. I added some features and made some syntactic changes and took out a few things and came up with The Language.
DDJ: You make it sound easy. But there's more to it than that; what are you doing these days?
BJ: I've been writing a 32-bit operating system for the 80386 completely in The Language. So right now I have -- I got everything running fragilely about last July and have been refining it and extending it ever since, and am now looking into issues like networking and all that sort of stuff. But I can actually do development on the system, and it's actually a lot more stable than developing under DOS because it's a protected-mode operating system. It supports the DOS file system, has a command-line shell with long command lines and I/O redirection, and you can spawn processes off into the background; there's full multitasking. All the device drivers are written in The Language. I don't use any BIOS calls at all. I never switch it to 16-bit mode. And there's an integrated development environment with, so far, a very primitive source-level debugger. And I'm just having fun writing all this neat software.
DDJ: Assuming for the moment that you're doing all this for your own amusement and edification, what have you learned?
BJ: I've found out a few things. One is that the 80386 is a whole lot easier to generate code for than the 8086. In the space between February and July of 1990, I went from not having any 32-bit software at all to having a complete self-sustaining operating system. And that's including not having line one of a 32-bit code generator; I had a 16-bit code generator and a parser written. It took me about a month and a half to get a fairly stable 386 code generator running.
DDJ: What about performance?
BJ: I benchmarked it against the same source code. It turns out that translating C code into The Language involves a fair amount of manual rewriting of the declarations, but functionally you can take C code and it pretty much translates; and benchmarks are especially easy because they're all one module. To verify the numbers I even went back to my 16-bit code generator and reran the benchmarks, so that it was the same language and just the two different modes. And I consistently found that things like the Sieve ran five to ten percent faster in 32-bit mode, and the Dhrystone ran 25 percent faster. That's with a very simple-minded, not very finely tuned 32-bit code generator against Turbo C, with a code generator that has had four or five years or six years worth of hand tuning and optimization work. And this was on the same processor, so it was as close as you could get to an apples-to-apples code generation test between 16- and 32-bit models. I was very surprised by that. I did not expect to have such an improvement in speed between the two modes. That was very pleasing. So, for example, the disk performance in my operating system is actually better than DOS disk performance in several ways. It took me less effort than I thought it would to get high-performance systems programming. So the bottom line is that I feel like I've succeeded in that area: I think I've got a language that can be used to write fairly efficient systems programming.
DDJ: What about the object-oriented features of The Language?
BJ: If you compare the OOP features of The Language, they're very much like the Turbo Pascal OOP extensions: simple single inheritance, none of this stuff of friends and multiple inheritance. When you define a class, the methods have to be defined within the body of that class. You have all the control of public and private visibility and inheritability of objects and you have static and dynamic binding of methods, very much like virtual functions in C++.
DDJ: How was your experience in getting into object-oriented programming?
BJ: So far as OOP goes, my experience is that OOP isn't quite the panacea that everyone makes it. It's got some very interesting aspects, and for certain kinds of programming, like for developing windows kinds of environments, I think there's some real value to it. But we're not going to have software ICs and completely plug-compatible libraries. That's a lot of wishful thinking.
DDJ: Because?
BJ: Object-oriented programming makes it easier to design good library interfaces and good generic classes, but it doesn't make it mandatory. You still have the problem that, if you look at the problem that you have at hand today and design your libraries and your support classes to fit that problem, there's no guarantee that you've anticipated all the ways that the next problem could be different. It's only after you've gone through the task of trying to adapt this library to several different problems that you can be reasonably sure that you've got a fairly general solution. You still have to work fairly hard to get reusable software.
For example, in the integrated development environment in one of its fairly early versions, I had the editor bound together with the compiler, very much like Turbo C does it. But when the compiler spit out error messages it would write all over the editor as it was currently running. I said this is silly; it looks really terrible; I'm going to have to put in a message window like Turbo C has.
Well, I was able to take the editor class for text editors, inherit a new subclass for it for message windows, turn off all of the text-modification events, add maybe two or three subroutines, and it took me all of three hours to get a message window that allowed full horizontal and vertical scrolling, marking a block of text in the message window and cutting it and pasting it into another window, and positioning on a message and hitting return to put you on the source alongside the message. All of that functionality took a very short amount of time and a very small amount of code.
But the point is that I did have to go back and reengineer the editor class a little bit to make that easier. I find that the adaptability of software with OOP is very good, but occasionally you do have to go back to your base classes and make some modifications, because uses come along that you didn't anticipate.
DDJ: So I guess you're not saying that the emperor has no clothes, but that he may not be clad appropriately for unexpected changes in the weather.
BJ: There's a tremendous amount of hype out there about OOP. It's been very heavily oversold by some people. But I thought at the time I started this project that it had value and I still do. It's not quite what I thought it was going to be; you do have to change the way you think about your programs.
DDJ: What about the third aspect of The Language, which I think you said had to do with making incremental compilation easier?
BJ: Well, one of the changes I made was I got rid of include files and went to a binary module format very much like Modula-2 or Turbo Pascal has.
The early version didn't allow mutual references between modules. Things had to be in a very strict hierarchy of references. And one of the things I found, as I was adapting old C code that I had lying around and converting things over to use this new format, was that the references in my C code were pretty much spaghetti. I had very low-level modules with references back to top-level routines buried in them and so everything was referring to everything else, and all of that had not been visible because the linker was doing all that magic for me, and it didn't care about any circular references; it just resolved them.
So all of a sudden I was finding that the hierarchical structure of the modules in the program really didn't make any sense, because there was no such structure. And the process of building that structure to make these modules and to make the import/export of information between modules work better was quite difficult. I eventually realized that there are times when you really need to do recursion from a low-level routine back up to a high-level routine. So put in the ability to do cross-module references. I talked to the people who did Turbo Pascal and they had the same problem with their modules: They started out having a strict hierarchy and they had to give that up.
DDJ: The binary module format you mentioned; can you expand on that? What does that buy you?
BJ: Going to binary headers massively improves compile speed. I think the latest version of Turbo C++ also supports some form of binary headers, or precompiled headers, and I think that they found the same sort of massive speedup in processing things like Windows.h. You just precompile it once and then use the binary. When you build a large program in [the version of Turbo C I'm testing against], you end up recompiling all these headers over and over again, so to compile a large project you might actually compile 120,000 lines of source even though that consisted of 2000 lines of headers and 20,000 lines of C code. In this new model, when you have 22,000 lines of source, you compile 22,000 lines. So the speedup is twofold: First of all, the individual compilations units are faster to compile, but you're also visiting a lot fewer lines in the total build.
DDJ: What kinds of results are you getting?
BJ: The effective compile speed for a large application in The Language is not as fast as Turbo Pascal. I think Turbo Pascal is still up in the stratosphere of like 70,000 lines a minute on a fast machine. I'm only around 30,000 lines a minute on a fast machine, but that's against Turbo C, which clocks out at about 10-12,000 lines per minute on a fast machine without the binary headers. I'm sure [the new version's binary header capability] boosts that quite a bit.
Going to binary headers helps in a whole lot of ways. It simplifies the language. You don't have to do forward declarations in The Language. You have one place where you define it; anybody else that wants to use the symbol that you defined has to import the module that it's in, and that's it. Modula-2 and Pascal have a dual, two-part definition, so you have the interface definition and then you have the implementation. I just merge them together, and the public information gets sort of filtered out as it does the compile.
Editor's Note: Michael and Bob continue their conversation next month, speculating about the nature of development tools and computer systems in the years to come.
Copyright © 1991, Dr. Dobb's Journal