Since this was once my domain of expertise -- programming languages -- I
can't resist jumping in here. (01)
Sean wrote: (02)
>> "3. DARPA developed Ada as the standard for systems programming.
>>
>> Result: C (a language that violated nearly every one of the
>> design goals for Ada) became the standard for system programming." (03)
Well, DARPA intended Ada as THE standard for programming "embedded
systems" -- software/hardware that controls part of the operation of a
vehicle or appliance. Embedded systems are principally event-driven but
tend to include complex procedural algorithms as well, some of which are
intensely numeric in character. (Thinking of plotting the trajectory of
an incoming aircraft so as to predict its position when the AA shell
arrives.) So Ada had to be as good as Fortran for mathematics
programming and have real-time event-driven features as well. Ada was
intended to replace assembly-language for the task-specific code, while
standardizing in the language the event and thread supporting features
of the runtime environment. The design of Ada assumed that most
elements of the Ada runtime environment would be written in
machine-specific assembly language -- the idea was to have a common
pattern for use by the real-time application programmer. (04)
Systems programming languages, OTOH, almost never need to use
floating-point arithmetic and rarely involve complex procedural
algorithms. C was indeed intended as a systems programming language.
It was the third such language developed at Bell Labs in the period
1966-1971 and neither A nor B even had a "float" datatype. And C has no
real-time or event-driven features in the language at all! The
presumption in C was that systems functions programmed in assembly
language with C-language interfaces would provide the fundamental
support for events, threads, interrupts and other real-time concepts.
And in the first 3 implementations -- the HIS6000, the PDP-11 and a Bell
special -- the systems interfaces were all different! (05)
Sean said:
>> My impression was that Ada was Pascal++, (06)
Jean Ichbiah (designer of Ada) would be horrified. While he and Klaus
Wirth (designer of Pascal) both participated in the (doomed but very
innovative) Algol68 work, they had entirely different views of what a
programming language should be/do. Klaus was all about "experimental
languages" to teach students about software ideas and make programming
easier. Jean was all about making software reliable; so the objective
of his work was to make languages expressive and impose discipline on
the programmers. For different reasons, they both believed in strong
typing, but all the other commonalities of Pascal and Ada were common to
many of the experimental languages of the late 1960s, and most of them
were found in C as well. (07)
>> but that C was really
>> FORTRAN 75 (i.e. Fortran NOT updated by a committee, cf "A camel is a
>> horse designed by a committee"). The jaundiced view is that C took
>> off because it allowed you to program without thinking, and to get
>> round the constraints which good practice imposes. (08)
Randy said:
> There is virtually nothing in common between FORTRAN and C. (09)
Spot on. Certainly there is almost no common thinking in the intent of
the languages. (010)
That said, we must realize that the university mathematics programming
communities of the 1980s found it necessary (more on that later) to
program in C rather than Fortran, and created a whole C-for-engineering
discipline that made demands on later C compilers and libraries that
would not even have occurred to Brian Kernighan in 1972. So, by 1985, C
was a common mathematics programming language, with more caché than
Fortran 77, and (finally) with first-rate compiler/library support for
mathematics, even though that had never been the intent of the language. (011)
> As to
> your "jaundiced view," little could be further from the truth. C is a
> challenging language to program in owing to its very low-level
> formalisms, its deliberate refusal to abstract away many of the
> characteristics of the hardware targeted by its code generator and its
> silent acceptance of many programs that are non-portable and / or
> flatly incorrect.
>
> The "jaundiced" characterization of C is that it's a portable assembly
> language. (012)
There is truth to all of the above, and to both jaundiced views. (013)
I have a third "jaundiced view". (014)
Ada's problem was the Department of Defense. They ruled that no subset
of the Ada language, and no extension of the Ada language, could use the
name Ada. Further, they broke one of Ichbian's design elements by
requiring an implementation behavior (for maximum efficiency) that was
only suitable for the final running code of the embedded system. This
combination of rules meant that no university team could construct a
student programming language that was a useful subset of the Ada
standard, e.g. equivalent to Pascal. And it further meant that
developing a (military) standards-compliant version of Ada, so as to use
the name, required a lot of useless work for support of most programming
tasks. So university students did not learn Ada. DoD the father
strangled their gifted infant Ada at birth! (015)
C, on the other hand, had no useful subsets, and only one commonly used
compiler for over 5 years. For all practical purposes, it was the
*only* programming language available on the unix operating system until
1979 (when a Fortran 77 compiler, and the Franz LISP system, and some
others, appeared). Now, unix was the only easy to assemble and use
operating system for the best cheap and powerful hardware platform of
the 1970s -- the Digital Equipment PDP-11. University labs bought
PDP-11s by the truckload, and anyone who wasn't using the computer for
real-time applications installed unix on it, because the operating
system was *free* (to universities) from Bell Labs. So university
students of the late 1970s, particularly in science and engineering
labs, learned to program in C, because they had no real choice. Bell
Labs the father inadvertently proselytized their bastard systems
programming language C to students all over the world. (016)
The rest is history. In my jaundiced view, I refer to this as "the
Catholic Church method -- get 'em young." What you teach the students
today will be the de facto commercial standard of tomorrow. (017)
-Ed (018)
P.S. And in my case, the disclaimer below definitely applies, and
matches Sean's personal one. ;-) (019)
--
Edward J. Barkmeyer Email: edbark@xxxxxxxx
National Institute of Standards & Technology
Manufacturing Systems Integration Division
100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528
Gaithersburg, MD 20899-8263 FAX: +1 301-975-4694 (020)
"The opinions expressed above do not reflect consensus of NIST,
and have not been reviewed by any Government authority." (021)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (022)
|