larry@JPL-VLSI.ARPA (04/01/86)
The only thing I would add to Ed Berard's comments is some comments of my own on the myth of Ada's complexity. I don't mean that Ada is NOT complex; rather I think we tend to underestimate the complexity of our favorite languages. We usually know them so well that we forget the trouble we had bending our mindsaround the new syntax and semantics of the language. Further, we usually have to get deeply involved with an operating system. In ForTran, for instance, to do real-time programming you have to have available and understand the interac- tions of a dozen or two subprograms, typically the ISA (Industrial Society of America, I believe) standard extensions. Another universe of examples could be given in the C language. I'm peripherallyinvolved in the process of porting a number of SW tools from Berkely Unix to AT&T System V Unix and VAX-11 VMS. What a headache that is. There are at leastthree major types of concurrency involved and several variations on each
larry@JPL-VLSI.ARPA (04/01/86)
What fun to work at home. My lady's CAT just jumped on the END-MESSAGE key!
Murphy's Law strikes again.
There are at least three major types of concurrency involved and several variations on each. Dynamic memory and inter-process communication has the same problem. And different compilers treat pointers in subtly different ways that cause
more problems than major differences would have.
It's for this reason that many C and Unix experts have been involved in efforts to create standards (ANSI X3J11 and IEEE P1003, respectively). And AT&T is
gently pushing an upwardly compatible superset of C know as C++ which adds some
of the features now available in Ada. (More specifically, C++ resembles
Simula-67.)
So perhaps in a couple of years we'll be able to do in the C/Unix world what we
can already do in Ada: insulate modules from each other and from the machine
but still be able to tailor the entire system to specific hardware.
Larry @ jpl-vlsi