Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

The C Language

19 views
Skip to first unread message

A. Dain Samples

unread,
May 28, 1987, 1:33:12 PM5/28/87
to
From samples Thu May 28 10:27:07 1987
Received: by renoir.Berkeley.EDU (5.57/1.25)
id AA27322; Thu, 28 May 87 10:26:53 PDT
Date: Thu, 28 May 87 10:26:53 PDT
From: MAILER-DAEMON (Mail Delivery Subsystem)
Subject: Returned mail: User unknown
Message-Id: <870528172...@renoir.Berkeley.EDU>
To: samples
Status: R

----- Transcript of session follows -----
>>> RCPT To:<com-sy...@ucbvax.berkeley.edu>
<<< 550 <com-sy...@ucbvax.berkeley.edu>... User unknown
550 com-sys-apple@ucbvax... User unknown

----- Unsent message follows -----
Received: by renoir.Berkeley.EDU (5.57/1.25)
id AA27318; Thu, 28 May 87 10:26:53 PDT
Date: Thu, 28 May 87 10:26:53 PDT
From: samples (A. Dain Samples)
Message-Id: <870528172...@renoir.Berkeley.EDU>
To: com-sys-apple@ucbvax
Subject: Re: The C Language

This debate/argument over language characteristics -- which is
better/best, which is dirty/clean -- is very much like two engineers
engaged in building a three-mile bridge arguing over the brand of
blue-print paper they use.

To say that languages survive and are used because they were there
first and are therefore entrenched is only trivially true. There are
two points to be made, each directed at two different users of
programming languages.

The first class of users are those that enjoy programming: they enjoy
the puzzles to be solved, they enjoy seeing ``Hello, world!'' come up
on a screen when programmed in an about-to-be-learned language, they
experience satisfaction when any set of programming sentences have been
successfully turned into a working program. These people then often
confuse cause-and-effect, or means-and-ends: ``I enjoyed that! And I
was programming in language X, therefore language X must be pretty good
to give me that kind of enjoyment.'' That is why we see religious
arguments over any and every programming language, from FORTRAN, to C,
to APL, to FORTH, to SNOBOL, to Algol, to Pascal, to LISP, to C++, to
... need I go on?

Let us not ignore the effect of the language, however. Some languages
are more fun to program in than others, and I agree with those who say
C is a ``fun'' language: it certainly is a never ending source of
surprise, it provides plenty of opportunity for puzzle-solving, and it
is a clever implementation of some pretty basic programming principles.

That is, I think it is fun until I try to get a serious, large project
completed. Then frustration sets in. But this brings me to the second
class of programmer: those trying to bring a serious, large programming
effort to successful completion. The primary reason that such people
use all of the ``bad'' languages, and the reason that people using the
``better'' languages don't seem to do any better than the users of
``bad'' languages is

THE PROBLEMS THAT PROGRAMMING LANGUAGES SOLVE ARE ORTHOGONAL TO
THE PROBLEMS THAT MUST BE SOLVED IN LARGE PROGRAMMING
PROJECTS.

In other words

THE PROGRAMMING LANGUAGE USED DOESN'T MATTER IN LARGE
PROGRAMMING PROJECTS.

Obviously, these are overstatements designed to make a point; in
reality, the problems are almost orthogonal, and language choice
usually doesn't matter. Again, in other words, the features of a
particular programming language do not attack the problems of large
systems. That is why the Shuttle software is written in FORTRAN (there
was a CACM article in the last couple of years on this). This is why
large financial programs are still written in COBOL. And that is why
DARPA is investing millions of dollars STILL, after all these years, in
how to develop large software systems (there seems there is this
project the President wants to do that requires several million
[billion?] lines of code).

Yes, translation and investment costs come into play, but only as a
second order effect.

The primary problems to be solved in any large system are communication
and consistency. But not JUST between programming units, but also
between programmers, programming teams, managers, managers' bosses,
users, applications engineers, salesmen, etc. etc. etc. And I
guarantee you, that solving these problems for PEOPLE is far worse than
solving them for PROGRAMS! So, the choice of a language is swamped by
the other problems to be solved, and it really doesn't make that much
difference in the global scope of things. It makes some difference,
granted, but not nearly as much as the lowly programmer having to work
with the language might think.

Develop a language that solves the programming-in-the-large problems, and
THEN we can have a meaningful, resolvable argument!

Summary: ANY programming language offers its form of fun, and has its
adherents. But any arguments about one language being better than
another make sense ONLY when we are talking about programming-in-the-
small (and even then they are religious arguments, as well they should
be). But when it comes to serious, large, important programming
projects, the decision of which language to use is not made until so
many other more important decisions have been made, that it almost
doesn't matter.

I mean, come on, do bridge engineers start a design meeting by saying,
``Well, what brand of blue-print paper shall we use on this project?''


In the spirit of spirited debate,

Dain

gw...@brl-smoke.uucp

unread,
May 28, 1987, 9:45:32 PM5/28/87
to
In article <870528173...@renoir.Berkeley.EDU> sam...@RENOIR.BERKELEY.EDU (A. Dain Samples) writes:
>Develop a language that solves the programming-in-the-large problems, and
>THEN we can have a meaningful, resolvable argument!

Thanks for a good article.
There is a widespread misconception that the proper programming
(or meta-programming) language would solve all our problems.
In fact, problems are solved by people thinking about them and
getting good ideas, not by mechanical methods (except for a few
especially boring classes of problems, or as AIDS for people
solving problems).
Programming language design can assist or hinder development of
proper computer solutions, but as you observe that's not the
really hard part.

Rick N. Fincher

unread,
Jun 1, 1987, 9:46:34 AM6/1/87
to

I'd like to interrupt here to thank Doug for his Posix postings to the net
it's poeple willing to do things like this that make the net so useful.
I was just getting ready to sit down and write code to do what Doug's
programs do (ie read Prodos directories in "C") when he posted his
programs. This will be a great help to a lot of folks and it comes at
an ideal time. With Apple pushing C as the development language for the
//gs, it is a good time to set some standards.

Thanks Doug

Rick Fincher
ranger@ecsvax

0 new messages