Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!columbia!rutgers!husc6!think!ames!ucbcad!ucbvax!RENOIR.BERKELEY.EDU!samples From: samples@RENOIR.BERKELEY.EDU (A. Dain Samples) Newsgroups: comp.sys.apple Subject: Re: The C Language Message-ID: <8705281733.AA27424@renoir.Berkeley.EDU> Date: Thu, 28-May-87 13:33:12 EDT Article-I.D.: renoir.8705281733.AA27424 Posted: Thu May 28 13:33:12 1987 Date-Received: Sat, 30-May-87 07:54:23 EDT Sender: daemon@ucbvax.BERKELEY.EDU Lines: 114 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: <8705281726.AA27322@renoir.Berkeley.EDU> To: samples Status: R ----- Transcript of session follows ----- >>> RCPT To: <<< 550 ... 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: <8705281726.AA27318@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