Third Party Suicide?

[Marc Stiegler <marcs>]

After reading hugh's message about the consequences of our garbage
collector, I started worrying. When people started talking about
living without CFRONT as a basis for a compiler, I started worrying
some more. How totally are we writing off developers outside our
own office space, even if we manage to get this kluge to serve our
own local purpose?

As you know, I always wind up spending a lot of time attempting to
draft messages that will stimulate thought without provoking
religion (though I certainly fail often enough in spite of the effort :-)
Well, this time, while I was in the throes, I received a message
from kelvin throop. I have excerpted a piece which sums up many of
my concerns quite nicely, probably better than I would have myself:
--------------
As you know, I haven't commented on much traffic on this loop for
quite a while.  The reasons are a linear combination of embroilment
in other development projects, a feeling that issues were being resolved
just fine without my butting in, and, frequently, lack of comprehension
of the vocabulary and issues being discussed (it's all InScruTable to
my NonTransMutable mentation).

However, the past day's discussion of C++ compiler issues related to the
macros that implement garbage collection has triggered my Master Caution
And Warning alarm.  Just in case it hasn't had the same effect on you,
I'd like to compare notes on what's going on here.

One of the main concerns I had with the choice of C++ as a development
language for front-ends (as opposed to the black box back-end), was that
we were trying to drive a piling to the shifting sands of a
language that was neither standardised nor widely implemented except
through CFRONT.

Aside from the obvious and already-discussed risks, we now seem to have
fetched up against the consequences of betting on a language
that hasn't achieved the stability of widely-distributed commercial systems.
We're pushing the language to its limits, and it looks like we're running
into the inevitable limitations in a new product.  I've seen this happen
in project after project since 1969, when we were trying to write an
operating system in a high-level systems programming language that had been
developed in-house for the express purpose of developing that system.
>>From Multics-PL/I to the first generation of applications that tried to
use Ada, the symptoms are familiar.

If we're trying to do things that blow up the only existing reference
implementation of C++, to the extent that we're seriously considering
shifting to a language environment that does not even target (at
present) the two most widely distributed front-end architectures (the
PC and Mac), it looks like we've got the "first real user of the
language" blues, and bad.

I don't really know what the precipitating factors are for this
apparent problem, particularly since, as usual, there appear to be several
causes which must be weighed together, nor do I remotely know enough about
what's going on to begin to offer suggessions.  At this point I just want
to remind folks that development projects which have bet on ragged edge
features of leading edge languages have, historically, been prone
to disaster and slippages, sometimes measured in years (in fact,
had Multics not run afoul of PL/I, we might not be using Unix today).

If we are, indeed, constructing a development environment that forces
unfamiliar tools upon our front end developers, requires them to code
in an obtuse and hard to debug manner, and does not provide easy
integration with existing code implemented with industry-standard compilers,
perhaps we should take a couple of steps back from the abyss and think about
what we are doing.  In such a situation, should

        *  Scrapping the garbage collection architecture,
        *  Using C as the reference front-end implementation
           language, with C++ as an option,
and/or  *  Redefining the level of interface between the front-end
           support code and the application to be more at arm's length
           and hence language-independent (as is ADS, for example)

be off the agenda?
-----------------
How clearly have we thought through the implications of what we are
doing for (or to) our third parties?


Bobp, this is of course of most concern to you. Has there been an intense
discussion yet of what a C-based frontend to all this stuff would look
like? If not, I would propose that you grab hugh and markm and discuss
it (I propose a 3-person meeting, since 3-person meetings seem so much
more effective). 

In general, are Walker and I confused? Are people really talking about
taking an approach which rejects CFRONT implementations of C++ for
the foreseeable future?

--marcs