| The attached memo is reposted -- without change -- on its tenth anniversary.
Unfortunately, it could be written today with little change, except for
the name of the products. As far as I know, only Rich Witek is still at Dec.
Martin.
_ _ _ _ _ _ _
| | | | | | | |
|d|i|g|i|t|a|l| Interoffice Memorandum
|_|_|_|_|_|_|_|
To: Mary Cole, HL1-1/008 Date: 20-Nov-80
From: Martin Minow
CC: Dave Cutler, ZK1-1/C27 Dept: D&MS AD
Rich Witek, ZK1-2/L02 DTN: 247-2017
Tom Stambaugh, ML1-2/T29 EngNet: PHENIX::MINOW
Subj: Using C for New Products
This is a follow-up on our corridor conversation yesterday. I'm
copying Dave Cutler as he believes that C is a poor language
choice (and his opinions should be on record).
I believe that C should be used to implement new software
products for a number of reasons:
o Transportability
Anything done on a new system should be available on all
"larger" DEC systems (specifically, RSTS, RSX, and VMS).
This allows us to minimize software development effort. It
also allows our software OEMs' to offer the same product on
a range of machines.
Furthermore, as the development of VMS showed, the
availability of a transportable existing system (PDP-11
RSX-11M) simplifies and speeds the development of a new
system (VAX VMS) as software can be developed without
waiting for new hardware.
o Not DEC-specific
In the forthcoming personal computer market, I believe that
offering a manufacturer-unique (and especially an
architecture-unique) language will prove to be a long-term
disaster. BLISS, MUMPS, and BASIC-PLUS come to mind -- much
excellent software developed on these languages is
unavailable (even within DEC) on our entire range of
systems.
I would find it hard to believe that a competent OEM will
choose a manufacture-unique language for developement, given
the volatility of the small computer marketplace. This
suggests that a DEC-specific language will be seen as a
negative factor by many OEMs.
o Simplicity
C has almost no "high-level" constructions (such as
Using C for New Products Page 2
BASIC-PLUS array operators and variable-length strings).
The C philosophy is to define such functionality by
implementing subroutine packages (since, even if provided by
the language, this functionality is generally implemented by
subroutines).
Another important consideration is that C lacks
language-specified I/O. (C implementations generally
provide a "standard" I/O library.) Thus, C programs have
been used for process control (all I/O is hardware-specific)
and have been directly interfaced to RT11, RSTS, RSX, and
VMS executive services.
o Portability
The ability to implement software without access to (or
consideration of) the target system is the most important
reason to choose C.
The DECUS C compiler runs on all members of the PDP-11
family (from PDT's to VAX's). There is no reason to believe
that a "production" PDP-11 compiler would not do the same.
This means that software development and maintenence need
not require the existance of a (large) central facility for
recompilation. (It also means that people can work at home
without tying up the phone lines, but that is another
matter.)
The DECUS compiler and the VMS compiler under development
allow the programmer to conditionally compile statements
which are specific to the individual operating system, which
considerably improves transportability. (The DECUS compiler
allows compile-time selection of RSX or RT11 and run-time
selection of the base operating system -- especially RSTS or
VMS emulation versus "native" modes. This allows ".SAV" and
".TSK" images to be transported without recompilation.)
There are, of course, some counter arguments:
o Production using DECUS software?
The only C compiler currently available "from DEC" is
distributed by DECUS. It has a few minor limitations (it
lacks floating-point and a few language features), but is
otherwise a reasonable basis for development. I have been
using it for two years and, in that time, have had to fix
less than ten compiler bugs (some of which I introduced).
The I/O library, which I wrote, runs compatably on
everything its encountered (haven't tried TRAX yet). There
are several dozen copies floating around DEC, many on
PDT-150's.
In any case, the decision to use C would imply a comittment
to implement and market a PDP-11 C. This would complement
the VMS product and should be profitable in its own right.
Using C for New Products Page 3
Perhaps the simplest implementation path would be to license
one of the existing PDP-11 C compilers (from Mark Williams
Co., Whitesmith's, our Yourdon). (Mark Williams would be my
initial choice as their compiler was written by the
developer of DECUS C.)
o Efficiency
Languages such as BLISS (or MACRO) are recommended because
they generate better (smaller or faster) code. One of the
major lessons we learned in RSTS/E is that a more efficient
language (BASIC-PLUS-2, for example) may be so expensive to
use (20 minute task-builds) that programmer efficiency
decreases. Using the RT11/RSTS implementation, a
compile-assemble-link cycle takes about two minutes for a
500 line program. (RSX task builds take rather much
longer.) A production system should be faster.
In general, C offers efficient code (certainly as good as
Fortran, better than Pascal) and extremely efficient use of
the programmer's resources. In most instances, individual
differences among programmers will be a greater factor than
compiler quality.
In conclusion, two quotes from the literature on C:
"Since C is a relatively low-level language, it is
adequately efficient to prevent people from resorting to
assembler, and yet sufficienctly terse and expressive
that its users prefer it to PL/1 or other very large
languages.
"A language that doesn't have everything is actually
easier to program in than some that do. The limitations
of C often imply shorter manuals and easier training and
adaptation."
"... Keeping the language down to modest dimensions has
brought real benefits. Since C is relatively small, it
can be described in a small space and learned quickly.
A compiler for C can be simple and compact. Compilers
are also easily written; using current technology, one
can expect to prepare a compiler for a new machine in a
couple of months, and to find that 80 percent of the
code of a new compiler is common with existing ones.
This provides a high degree of language mobility."
From Kernighan and Ritchie, The C Programming Language.
Regards.
|
| A few comments from a ten year perspective.
-- it doesn't help being "right" if you aren't believed. Had we followed
my advice and wrote our programs in C, they would be transportable to
Unix. However, if we didn't port the VMS "Swiss Army Knife" run-time
libary, they wouldn't be usable even if they could be compiled.
-- Several respondants to VaxC 3314 noted that C++ is replacing C in the
Unix community. For direct programming, perhaps. But, for most
programmers (in the broad sense), both languages have been replaced
by spreadsheets, statistical packages such as SPSS, and other
user-oriented languages. I wrote that memo, in a low-level
page-layout language, Runoff, If I had written it on Unix, I would
have used roff or nroff -- both similar to Runoff.
If I were to write that memo today, I would use my Macintosh: WriteNow
and PageMaker are simpler and better at these tasks. Both are essentially
"compilers" for Postscript. (Both can generate a Runoff-like markup
language, RTF, that can be directly translated into Postscript.)
If I were to look ten years into the future; I would guess that people
will use C and C++ for "traditional" programming (though I worry that
C++ trades data-interaction confusion for subroutine-interaction
confusion and would be very concerned about use of C++ in safety-critical
systems because I'm not fully convinced it's deterministic; however that may
be worth a separate discussion.
One of the replies asked what I would worry about in the next ten years.
Right now, I would answer "safety." Around 1982, I discovered that
Decus C, a public-domain C compiler for the PDP-11 that I midnight-projected
was used to program many robot manipulators. An uncaught code-bug
could quite literally kill someone. (The people who developed the
robot manipulators were well aware of this, of course.) Several commentators
bemoaned the fact that C's design precludes some compiler optomizations.
True, but it was very easy to connect Decus C's generated code with its
input source file, which is needed for hand-verification.
Also, having once written Dec's "fastest backup" in Basic-Plus, I'm
unconvinced that optomizing compilers are the key to fast code.
Some specific comments to replies in VaxC 3314:
re: .7
>I noticed that productivity, reliability, and maintainability don't occur as
>bullet list items in the base note. Is that because these aren't considered
>relevant qualities? If not, why not? If they are, then how do C, C++, and the
>other languages fit in?
In 1980, I had about 2 years off-and-on experience with C (Decus C wasn't
really working and I had fiddled a bit with C on R&D's Unix V6 system).
For my purposes, the simplicity of C improved my productivity. Most of
my "umproductive time," even now, is spent digging through VMS RTL manuals
to devise ways around RMS's limitations. (That's my experience, your's
may well vary.) I cannot count the number of times I had to write a
file-copy program whose only purpose was to fiddle record formats.
>The arguments in favor of C based on simplicity and portability are deceptive.
>They are both important, valid points, but it's also important to know that
>writing non-portable C is easy, perhaps easier than in more rigorous languages
>such as Ada.
About two years ago, I took some algorithms out of code written in Mad in
1963 and Algol-60 written in 1968. I strongly believe that portability
has little to do with the language and everything to do with documentation
and programming style. In the mid 1970's, I learned this lesson in a
very clear fashion when Dec sent me to Volvo to help convert their
real-time system from a CDC system to RSX-11D. They had written all of their
code in Fortran, using such a rigid and complete programming specification
that about 95% of the conversions could be done by a simple "read a card,
parse the Fortran, write the result" program (written, of course, in
Fortran). This includes both language syntax changes and changes to
low-level I/O specific modules.
> And saying that C lacks language-specified I/O doesn't do
>justice to the large quantity of C code that relies on Unix I/O; stdio.h is
>part of the C standard. In other words, C was successful because of its
>simplicity and portability, which together add up to availability (as does the
>free C compiler shipped with Unix systems), but C doesn't, by itself, solve
>all portability problems.
First, C wasn't free but bundled. (Of course, Decus C and Gnu C are
essentially free.) The differences in I/O is managed are in many ways
crucial. To see this, you might try using only the base operating system
functions to create a file, write something to it, and close it.. On Unix,
(ignoring a few lines of error-checking) your program would be
filedes = creat("file.name", O_RDWR);
write(filedes, "hello world!\n", 13);
close(filedes);
On VMS, you first have to do battle with RMS, creating a FAB, RAB, and
whathaveyou, then decide which of the many file formats you need, then
know (in advance) the length of the longest line, then ... and so on.
Oh by the way, if you should decide that you want "hello world!" on
the terminal, you practically have to start over, since terminals can't
be made to look like files.
Of course, in my word processor, I just pull down the "File" menu and
select Save.
>I believe that C++ will replace C precisely because it addresses the
>productivity issue. Ada will win in so-called "mission critical" applications
>only so long as customers (mostly DOD, but others) value reliability more
>than efficiency and productivity.
Perhaps, but only if care is taken to allow me to use your classes and
methods. Based on what little C++ programming I've done, I remain slightly
suspicious. Also, we'll need a new generation of compiler and linker
technology to avoid spending 90% of the program's time in method dispatch
and subroutine linkage.
>One language omitted from discussion is Modula, which has many of the same
>advantages as C, with more reliability and maintainability, but much less
>availability and market presence.
I don't think Modula existed in 1980. Pascal was still a university toy
(and still didn't have separate compilation units then). C and Bliss were
by no means unique, even then. In the early 1970's, I was using PL360 --
a *very nice* C-like language for the IBM 360. Even Mad (around 1964) had
several useful low-level features (you could define operators and write
code-generator stubs in you programs).
Except for the somewhat unique area of developmental programming, I don't think
that language choice will be very interesting to most programmers, since
I think that most programmers will be too busy telling the computer (out loud)
to do 3-D modelling and financial planning to notice the machine itself.
For a number of years, I've felt programming will follow the history
of writing in the Middle Ages. After moveable type made writing accessable
to a larger audience, the profession of writer split into a number of
independent disciplines. I think this split will occur for programming too:
-- stenographer writes for folk too busy to write for themselves: programmer
-- calligrapher writes artistically: hacker (as in Stallman)
-- lawyer writes extremely difficult material that must be
accurate: "system's programmer."
You'll have to supply an equivalence for "clergy."
Martin.
|
| Re: .2:
Plenty to talk about here. Too bad you didn't re-post the contents
of the VAXC conference topic, but then, the evidence was getting pretty
strong against C and that's not your point... (sorry for being
slightly underhanded there, but in my opinion, re-posting your
viewpoints while not reposting the opposition is misinformative and
misleading...)
Re: productivity:
Getting code out the door isn't productivity. Productivity is the
efficient application of (human) resources over the life-cycle of a
project. My kudos to those people who really like C and write
excellent code in it, which is readable and supportable. However, for
the most part the C code I've seen has uniformly low quality and
reliability, not to mention the inherent performance losses by writing
in such a language. This adds up to long term support costs
skyrocketing, both in terms of persons spending their time answering
customer questions, and deciphering code to figure out what the heck
it's supposed to be doing. Number of keystrokes when typing in the
source does not equate to productivity.
And to be portable, as you recommend in your memo, you either have
to own your own comprehensive toolbox of reusable components which
themselves are portable, or waste much of your time reinventing the
wheel again and again. (Admittedly, there aren't many languages which
address the issue much better than C, but C's philosophy of "Unix -
everywhere!" isn't portability.)
Now, I've seena nd used some products Martin has worked on, and in
my experience they're excellent and high-quality products (even the
ones involving C... ;-) but in my opinion, that's more the exception
which proves the rule than a typical example of the quality of C
programmers and C programming out there.
The best point to make out is that there are many languages which
remove the problems C has, and can more seriously address quality
issues. Why people are rallying around a language which was designed
around being easy to write a compiler for (with a secondary goal of
direct translation of source to machine instructions,) escapes me.
-mjg
|
| re: .3:
Plenty to talk about here. Too bad you didn't re-post the contents
of the VAXC conference topic, but then, the evidence was getting pretty
strong against C and that's not your point...
Well, yes. since my point was not the superiority of C over, umm, Fortran
but rather more general issues of productivity. Dec made several conscious
decisions to use company-specific products (Bliss and VMS) and it seems
reasonable to ask whether (and in what ways) those were either correct
or incorrect.
My kudos to those people who really like C and write
excellent code in it, which is readable and supportable. However, for
the most part the C code I've seen has uniformly low quality and
reliability, not to mention the inherent performance losses by writing
in such a language.
Well, thank you. I've been writing "readable and supportable" code for
almost 30 years now (we'll ignore the stuff I wrote in Illiac-1 machine
language). I don't think language choice is central to "supportability."
The first public Decus presentation I gave in 1972 was on using Basic-Plus
in commercial environments (and this was Basic-Plus with single-letter
variable names).
And to be portable, as you recommend in your memo, you either have
to own your own comprehensive toolbox of reusable components which
themselves are portable, or waste much of your time reinventing the
wheel again and again. (Admittedly, there aren't many languages which
address the issue much better than C, but C's philosophy of "Unix -
everywhere!" isn't portability.)
I'm afraid I must disagree with you there. Consider DECtalk. The first
release of the firmware had about 15,000 lines of C and, as I recall,
only one programming bug (linguistic errors were not counted). It was
delivered on-time and on-budget. DECtalk was derived from C code developed
at a university research center by a linguist who taught himself Fortran and
then learned C to move code to Unix. Some of the code ran on a Dec-10, some
on a Unix 11/60. I ported it to VMS/Vax11-C, then to Decus C, then moved it
to an RT11 system, meanwhile keeping working base-levels on the original
system. I.e., the only differences between the Unix/Dec-10 and RT11 systems
hidden by conditional compilation.
As a result of this *committment* to portability, it took only two weeks
from the time we got the first semi-working hardware to the time it
said it's first word (I don't remember if it was the traditional "mama"
or the more modern "Hello world!") The two weeks was needed to debug
the real-time executive (most of which was written in C)..
Another result of an emphasis on portability is that the linguists could
continue to work on the much more friendly Vax and PDP-11 environments.
Last year, I prototyped a DSSI bootstrap on a Macintosh by writing a
fake hardware level. Again, pushing the code through several compilers
and architectures removed a lot of "lint" and the more convenient
Mac development environment meant that much less debugging was needed on
"actual" hardware.
The best point to make out is that there are many languages which
remove the problems C has, and can more seriously address quality
issues. Why people are rallying around a language which was designed
around being easy to write a compiler for (with a secondary goal of
direct translation of source to machine instructions,) escapes me.
I think the reason people rally around C is that it is a marketable,
but not vendor-specific skill (as opposed to, say, being a Bliss hacker).
The problems with bad programmers are no worse than the problems we faced
in the 1960's with bad Fortran programmers. For that matter, they are the
same problems we face with bad writers of English and, I would maintain,
should be dealt with in the same way: by teaching advanced programming
courses the same way you teach advanced English writing courses.
Martin.
|