if (c++ && x++)

[Bob Perez <bobp>]

After reading the various messages associated with the C++ threads 
I have some reactions I want to share. Unfortunately, this particular 
communications medium doesn't adequately convey emotional INTENSITY, 
so readers are asked to imagine an empassioned response with 
lots of shoe-pounding and expressive faces. 

Before I came to Xanadu I was a C programmer of very modest capabilities, 
certainly not representative of the body of professional developers 
I'm trying to attract to our platform, but knowledgable enough 
to be able to empathize with the situation they found themselve 
in when attempting to evaluate the various tradeoffs associated 
with a new development project. In fact, evangelizing developers 
to embrace the Macintosh in its early days provided me with a 
considerable amount of experience relevant to this issue.

In the 10 weeks that I've been here I've attempted to learn enough 
about C++, X++, and the various Xanadu semantics in order to 
appreciate what Developers will go through once they've committed 
to working on Xanadu frontends. In a word, Whew. [Note: my much 
longer answer would at this point have much to say about the 
many beautiful things I've noticed within X++ and Xanadu, so 
keep in mind that my bitch here is not with the material, but 
with the size of the syllabus].

C++ is an extraordinarily complex language. But the mental image 
that remains in my mind after all of the dust has settled is 
of a language that attempts to add the power of polymorphism, 
encapsulation, and inheritance to the expressive power of C, 
no matter how well it all really fits. The motivation for this 
particular marriage seems to me more related to the happenstance 
of C's current preeminence rather than any natural relationship. 
I approached C++ with the assumption that I'd be adding to my 
existing knowledge of C, but found instead that I was learning 
a new language with weird, inconsistent rules of syntax (Member 
access rules is one example, and why is it that in all of my 
readings regarding overloading I've encountered no explanation 
for keyword overloading? The poor C++ programmer now has even 
more ways to get confused about the keyword "static").

I'm particularly impressed with the success that's been achieved 
by our development team in transforming C++ into a language they 
can use without compromising their standards of design and programming 
style. The X++ sessions have been instructive: it's been fun 
to see OOP at work (as some of you know, I'm a recent convert), 
but it's also been interesting to see how many X++ creations 
were developed to overcome C++ shortcomings. The need for AT&T's 
2.0 revision (with talk of a 2.1 in February) underscores just 
how volatile is this language.

I called some of my friends at Apple and learned the following 
information. These figures are not for public distribution, please:

1) Apple's MPW C accounts for approximately 40% of the Mac C 
programmer's market (most of the remaining market goes to ThinkC).

2) Within this group, less than 20% of the installed base of 
MPW C users have purchased the C++ option.

This means that something like 8% of Mac C programmers have purchased 
C++ to date. A reasonable guess is that most of these are learning 
the language and that some percentage will opt to stay with vanilla 
C for production projects. My personal guess is that this figure 
will be quite high for the next year or so, on the order of 50-75%. 
This results in something like 2 to 4% of existing Mac C programmers 
who can be expected to be using C++ for production projects during 
the next year. I can't personally vouch for the accuracy of these 
figures, but they rolled off the tongues of people in a position 
to know the facts within Apple and seem reasonable.

Selling developers on the concept of developing Xanadu frontends 
has been relatively easy so far and it's been fun watching their 
reaction to my description of the system's power and features. 
But when it comes time for them to make a business decision regarding 
a specific committment to a new development project, it's quite 
a bit more complicated. One factor (among many) that they'll 
have to consider is spin-up time. Learning the Xanadu system 
will require a modest commitment. Learning C++ is yet another 
significant commitment, and then there's X++ on top of that. 
Add to this the substantial number of developers who haven't 
yet even investigated the world of OOP, and you've got a very 
lengthy learning curve that will seem prohibitively so to far 
too many potential developer prospects. I don't think that we 
can afford to hit the developer community with all 4 of these 
barrels at once and expect to get any significant response.

Apple had a similar problem to face with Macintosh in 1984 and 
just barely made their sales projections in that first year. 
I note that despite the company's heavy emphasis on Pascal in 
the first year, it wasn't until there were several C compilers 
on the market that Mac applications really started to appear 
(as early as summer of 1984 John Dvorak wrote in InfoWorld that 
a Macintosh C compiler would be the hottest new product in the 
industry). Now, of course, Apple is in the C compiler business.

The upshot of all this is that I believe quite strongly that 
we should not place any emphasis on C++ at this point. We must 
position C as the primary development environment for Xanadu 
frontend development and most of our initial efforts should be 
directed at assembling a package that supports a rich set of 
tools and libraries for vanilla C programmers. We can continue 
to treat C++ (and even Smalltalk) as a "preffered development 
environment", but our emphasis should be on straight C. This 
will make Xanadu frontend development a much more attractive 
proposal for 3rd parties.

Keep in mind all of the implications of this statement. When 
developers call with technical questions, they will be thinking 
in C and will want to talk C. Our Technical Notes will have to 
be written in C. Our example programs will have to be written 
in C, and so on. 

The bad news is that I believe this will require a significant 
shift in our thinking over the next few months. The good news 
is that I honestly believe that we'll have less work to do in 
putting together a comprehensive C package and that we'll achieve 
resultant market successes sooner.

I anxiously await reaction to this obvious heresy.

-- bobp