From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,38159b1b5557a2e7 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2004-01-28 08:26:49 PST Path: archiver1.google.com!news2.google.com!newsfeed2.dallas1.level3.net!news.level3.com!news.mainstreet.net!feedwest.aleron.net!aleron.net!sjc70.webusenet.com!news.usenetserver.com!pd7cy2so!pd7cy1no!shaw.ca!border1.nntp.ash.giganews.com!border2.nntp.sjc.giganews.com!border1.nntp.sjc.giganews.com!nntp.giganews.com!local1.nntp.sjc.giganews.com!nntp.comcast.com!news.comcast.com.POSTED!not-for-mail NNTP-Posting-Date: Wed, 28 Jan 2004 10:26:39 -0600 Date: Wed, 28 Jan 2004 11:26:38 -0500 From: "Robert I. Eachus" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Standard Ada Preprocessor References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: NNTP-Posting-Host: 24.147.77.160 X-Trace: sv3-qnox0yQdNg8I350JFQDaIZk25QgEdidblcTAGmterfWRTtu8zelh9tLHZaKd6NH2hEm8aEjNzqUXiha!KhvElckPw1MeHhxl2rLKmWtdvBh6CjIZB5tFpnVjUwSvRUJv6StxY0iivPm//g== X-Complaints-To: abuse@comcast.net X-DMCA-Complaints-To: dmca@comcast.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.1 Xref: archiver1.google.com comp.lang.ada:5004 Date: 2004-01-28T11:26:38-05:00 List-Id: Alexandre E. Kopilovitch wrote: > Robert I. Eachus wrote: > >>I think the right approach is to keep improving Ada for software >>engineers and let programmers use C++. > > No, thanks. We programmers will use all the languages we see as good and > possible for our current task and circumstances. Including Visual Basic, Java, > Lisp, Smalltalk, assemblers etc., and including certainly Ada and C++. Agreed. I was being a little flip in the comment. My meaning was that programmers tend to ignore the software engineering issues raised by C++. I expect software engineers to continue to use whichever language is most appropriate for the purpose. I've probably now written more Ada than PL/I but it is close. (Remember I helped develop an Ada compiler that ran on Multics, and then worked on Stratus VOS for a while.) C is probably now third instead of Fortran. Since I tend to be heavily into numeric/linear algebra code, I still write Fortran from time to time--but more C than Fortran. I haven't written much Pascal in the last twenty years, but that could change. Same for BASIC, although some people do use Visual BASIC for user interfaces, that is not the type of code I usually write. (I learned C++ and did some programming in it just for the experience. In fact, I did the same thing with Prolog and a couple of other languages.) I don't know if you consider SQL, XML, and HTML as a programming languages, but recently I have written a lot of all three. And of course I have done my share of sh, csh, and Lisp programming. I even programmed some numerics code in APL... >> We are doomed to live in a world where most code is poorly designed. > > Code is man-made, and man-made things of all kinds are mostly poorly designed. That is usually referred to as Sturgeon's Law: "Sure, 90% of science fiction is crud. That's because 90% of everything is crud." ;-) >> All we can do is try to keep an island of sanity, > > Island can't be defended by itself. It was proven several times that even > good air forces cannot defend their airbases by themselves, without sufficient > support on the ground. > > Certainly you know all that very well. Of course. Again my meaning was not that we should give up entirely, but that some fights were not worth fighting over and over again. In fact, to restate my position: 1) There are good pre-processors available for Ada, for when you need to use a preprocessor with Ada. 2) There is no need for a STANDARD Ada pre-processor, because most of the need for that sort of thing in Ada is better done in Ada. I'd rather spend my efforts in the standards area on making Ada a 99% solution instead of a 90% solution. 3) I have discovered lots of "tricks" that allow you to avoid using a pre-processor with Ada. Here they are. If you like, you can use them. If you don't like, fine. 4) In particular, remembering that addresses in address clauses need not be static is a huge help. In fact, I have sometimes put declarations with address clauses in inner scopes. Then I made the addresses non-static according to Ada rules just so that the (unused) record declaration will compile with a different compiler. Also use named numbers to make "portable" representation clauses tolerable. I always put the complex expressions in one package specification and write: "for Some_Record_Type use Component_1 at Start_1 range First_Bit_1 .. Last_Bit_1; Component_2 at Start_2 range First_Bit_2 .. Last_Bit_2; Component_3 at Start_3 range First_Bit_3 .. Last_Bit_3; ..." Wherever record rep clauses are needed. Of course, Start_n, First_Bit_n, and Last_Bit_n are named numbers (usually more descriptive) from that package. That way the decision as to whether to have multiple versions of that one file, or use complicated (static) expressions to handle both little and big endian architectures can be made when I need to port the application to a new environment. Having all of the numbers used in rep specs in one place is a big help however you manage them, so I do it even if I am never planning to port the code to a new compiler or OS. -- Robert I. Eachus "The war on terror is a different kind of war, waged capture by capture, cell by cell, and victory by victory. Our security is assured by our perseverance and by our sure belief in the success of liberty." -- George W. Bush