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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,15edb893ef79e231 X-Google-Attributes: gidfac41,public X-Google-Thread: f4fd2,23202754c9ce78dd X-Google-Attributes: gidf4fd2,public X-Google-Thread: 103376,15edb893ef79e231 X-Google-Attributes: gid103376,public X-Google-Thread: 114809,15edb893ef79e231 X-Google-Attributes: gid114809,public X-Google-ArrivalTime: 2002-01-23 10:03:05 PST Path: archiver1.google.com!news1.google.com!sn-xit-02!supernews.com!newsfeed.direct.ca!look.ca!newsfeed1.earthlink.net!newsfeed2.earthlink.net!newsfeed.earthlink.net!news.mindspring.net!not-for-mail From: Richard Riehle Newsgroups: comp.lang.lisp,comp.lang.ada,comp.lang.eiffel,comp.lang.smalltalk Subject: Re: True faiths ( was Re: The true faith ) Date: Wed, 23 Jan 2002 09:49:10 -0800 Organization: AdaWorks Software Engineering Message-ID: <3C4EF796.DA604391@adaworks.com> References: <%njZ7.279$iR.150960@news3.calgary.shaw.ca> <3c36fbc5_10@news.newsgroups.com> <4idg3u40ermnp682n6igc5gudp7hajkea9@4ax.com> <76be8851.0201101909.9db0718@posting.google.com> <9jtu3u8cq92b05j47uat3412tok6hqu1ki@4ax.com> <3C3F8689.377A9F0F@brising.com> <3219936759616091@naggum.net> <3C483CE7.D61D1BF@removeme.gst.com> <7302e4fa4a.simonwillcocks@RiscPC.enterprise.net> <3C4D9B03.60803@mail.com> <3C4DE2F3.9020904@mail.com> Reply-To: richard@adaworks.com NNTP-Posting-Host: 9e.fc.c5.a0 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Server-Date: 23 Jan 2002 18:02:19 GMT X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en Xref: archiver1.google.com comp.lang.lisp:25091 comp.lang.ada:19251 comp.lang.eiffel:5511 comp.lang.smalltalk:18537 Date: 2002-01-23T18:02:19+00:00 List-Id: Bruce Hoult wrote: > In article <3C4DE2F3.9020904@mail.com>, Hyman Rosen > wrote: > > You don't get to redefine the problem so that your favorite technique > > becomes the solution. > > Yes you do. The aim is to solve the customer's problem. They don't > give a damn whether you copy objects or pass them by reference. They > don't even know what the options *mean*! It depends on what you mean by customer. A customer of a class/type declaration is usually another programmer. I am a member of that class of customers, and I do care and I do know what the options mean. One of the things I like about Eiffel is the careful attention given to the design of the class contract. I want to know, from that contract, what to expect of my engaging it. For example, what kinds of things can go wrong, what are my responsibilities as a user of the contract, and what performance considerations I might want to consider in choosing a particular contract. And, yes, I want to know if it includes some form of storage management, and have some idea of what that storage management feature will have on my own program. The next few observations remind me of something I once heard regarding programming rules. "Those who make up rules about programming tend to be people who no longer write production programs." > -- programs are hard to analyse for correctness because of GOTOs. > Solution: don't use them Generally true. Knuth has a lengthy article on this in his book, Literate Programming. To simply say, "Don't use go to, is a bit simplistic." I have seen perfectly good examples where, during fine tuning of a program, someone has achieved significant performance improvement with a go to. Some languages support goto-less programming better than others. Some eliminate the option altogether and also eliminate the benefits of it. Go to is an option that should be used sparingly, almost never, but is handy when you actually need it. I realize one can "prove" that it is never needed. So be it. Sometimes it just might be useful. > -- programs are hard to analyse for correctness because of destructive > assignment. Solution: don't use assignment. I understand this is a joke. However, it conforms nicely to some of the fundamental notions of functional programming. > -- programs are often buggy because of off-by-one errors in loop > control. Solution: use implicit loops and/or mapping functions > controlled by the size of the collection they are operating on. Well, in Ada this never seems to be a problem. In Eiffel it is never a problem. It is often a problem in programs that use the C family of languages. However, I think C# has a fix for this. > -- programs are often buggy because of errors in memory management. > Solution: automate memory management. A naive suggestion, at best. Which automated form of memory management will you suggest? There are many from which one can choose. Each has its own benefits, depending on the kind of software you are writing. This is one of the things C++ gets right. Ada also. The problem of automated memory management is one of the things that makes Java ill-suited to many kinds of embedded, real-time software applications. Jim Rogers makes a good point about this vis a vis Ada. In Ada, we have the option of selecting the memory management model we wish to use, letting it be automatic or not, and targeting each type to a different model of memory management when that is a appropriate. This is a level of flexibility not typical of most other languages. Yes, I know one can do this in C++, but expressibile and expressive are not the same thing. Ada is really expressive in allowing this kind of automated memory management for a given type. That is as it should be since Ada is intended for safety- critical, real-time embedded software systems. Richard Riehle