C history question

[R. Vuurboom]

In article <2120 at munnari.oz.au> ok at cs.mu.oz.au (Richard O'Keefe) writes:
>of XOR.  There are quite a lot of cheap hardware instructions which C
>doesn't reflect at all (Rubin's complaint): e.g. PDP-11s have rotate
>instructions, but C has no "rotate" operator.  

I've been pondering this point for a while now. Every time Rubin brings
up this complaint (give him an A for perseverance :-) various friendly
and not so friendly counter arguments are proposed.

These counter arguments appear to me to fall into three categories.

The "feel free" category (if you want to clutter the language with all
sorts of (marginally) useless constructs feel free to design a new 
language).

The "C is not assembler" category.

The "besides you can" (...besides you can easily implement it as <follows
more or less nifty macro>).

To me there's an underlying principle (paradigm, dogma if you will :-) to 
all three of these arguments i.e. 

Language design (evolution) ought essentially to be a top down activity
where concepts such as consistency and orthogonality (for example) should 
play an important role.

I think most people would agree that the Pascal school strongly embodies
this language paradigm. Without a doubt this has been the leading paradigm of 
the seventies and eighties. So much so in fact that this top down approach
crossed over from software to hardware with the increasing implementation
of high level language support in the increasingly cisc architectures.

First point to note is that this trend is being reversed in risc architectures.

Second point to note is that this was not always the case. I remember reading
an interview (I think) with one of the designers of Fortran. His or her
statement was something like:

"Language design? What language design? We made it up as we went along.
All we were interested in was in proving that compiled code could be just
as fast as hand assembled. If some machine instruction was easily representable
 as a high level construct then sometimes we went ahead and stuck it in. That's
how Fortrans multi-way branch came into existence, for example"

Now I'm sure that C was not defined quite so willy nilly. However C's 
roots go back into the sixties before the top down paradigm was reigning.
If you compare C to Pascal its obvious that someone along the line of
C's heritage took a long hard look at the underlying machine architecture
and instruction set. Again here it is obvious that a number of constructs
in C found their way into the language simply because of the existence
of the associated machine instruction. 

This entire discussion would be neither here nor there were it not for
the glaring fact that both C and Fortran are still very healthy languages
today and both threaten to outlive Pascal in usefulness. Which I believe shows 
that to a certain extent bottom up language design (or at least allowing for
bottom up design principles) has turned out to be a very effective design 
method which is standing the test of time.

I have little doubt that if this group (with its current paradigms) existed
some 20 years ago and someone proposed a new construct answers would have
been like this:

A ++ operator? Look Ritchie, if you want to go ahead and clutter up the
language feel free to design your own. Besides you can implement it as
#define PLUSPLUS(x)  x=x+1
which is almost as fast. A good optimizer...

Its the very fact that 20 years ago bottom up design paradigms were not
considered invalid (heretical) that helped give C its lean and fast feeling.
(I say "helped" since top down principles (block structure case in point)
also gave C its power and flexibility).    

To summarize:

The (bottom-up) language evolution/design principle that Rubin advocates
was not considered heretical 20 years ago in fact it was considered a valid
paradigm.

There is a good case to be made that this very principle has made C
(and Fortran) stronger languages than Pascal for example where
this principle was generally avoided. 

Risc architectures have shown a swing in emphasis from top-down to
bottom-up design techniques with successful results. The question is:
will the renewed introduction of this paradigm continue into language
design of the nineties? And in particular: the language evolution of C
and its derivatives?
-- 
wiskunde: Dutch for mathematics. Literally: Knowledge of certainty   
wis: certainty			kunde: 	Knowledge
Roelof Vuurboom  SSP/V3   Philips TDS Apeldoorn, The Netherlands   +31 55 432226
domain: roelof at idca.tds.philips.nl             uucp:  ...!mcvax!philapd!roelof