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 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,c9629eba26884d78 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-08-08 12:37:03 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!cyclone.bc.net!sjc70.webusenet.com!sjc72.webusenet.com!news.webusenet.com!wn14feed!wn13feed!wn11feed!worldnet.att.net!204.127.198.203!attbi_feed3!attbi_feed4!attbi.com!rwcrnsc51.ops.asp.att.net.POSTED!not-for-mail Message-ID: <3F33FBD5.5010109@attbi.com> From: "Robert I. Eachus" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: signature like constructions References: <3F337798.2030008@attbi.com> <0o57jvsu8svaarn54n1j7js0casiclfqhb@4ax.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit NNTP-Posting-Host: 66.31.71.243 X-Complaints-To: abuse@comcast.net X-Trace: rwcrnsc51.ops.asp.att.net 1060371422 66.31.71.243 (Fri, 08 Aug 2003 19:37:02 GMT) NNTP-Posting-Date: Fri, 08 Aug 2003 19:37:02 GMT Organization: Comcast Online Date: Fri, 08 Aug 2003 19:37:02 GMT Xref: archiver1.google.com comp.lang.ada:41260 Date: 2003-08-08T19:37:02+00:00 List-Id: Dmitry A. Kazakov wrote: > I do not think that we really are in a big disagreement. (:-)) Agreed. I wasn't really picking on you, but targeting the discussion as a whole. > Yes. But the example provided by Georg, as far as I understand it, > aims at a case where there is already an implementation of 2D points, > which has to be reused. He wished to show that it is problematic with > tagged types, but still works with generics. > > Your example is a case of monolitic design, all from scratch, which is > clean and desirable, but becomes less and less frequent in modern > times. It is a right perspective, but there is a little chance that we > would climb so high. (:-)) Ah, here we do disagree. When the requirements change, that is not a reason not to understand and document the current requirements. And if one of those requirements is to live within a body of existing code, that is from one point of view just another requirement. Of course, when I do requirements analysis, as far as I am concerned, figuring out which requirements are likely to change and preparing for that evolution is part of the process. This is why I keep saying you should program in the problem space rather than some solution space. The problem space evolves much more slowly than the problems you are asked to solve. > This is true, but again unrealistic in a large, distributed, long > living project. In which case a "better" solution is one which > requires only maintainable changes in the existing infrastructure and > still works somehow... See above. Incidently, another issue that should never be overlooked in the design process is version skew. If I write a program in Ada that uses say Charles and gtkAda, that is three potential versions to worry about (Ada compiler, Charles, and gtkAda). That is three potential versions that may change and get out of alignment, and that is about the limit for anything you are going to maintain. Since the potential version conflicts increase as n*(n+1)/2. So with just the compiler, that is 1, with two libraries as above, that is 6, when you get to four interfaces, and the OS interface if you program to it counts as well, that is 15, and next to impossible to keep up with. This is one reason I argued in favor of the Annexes in Ada 95, each Annex could eliminate one version from that equation. In the next version I hope to see a database binding, perhaps to ODBC added. I'd like to see a standard graphics library as well, but I don't think we are to the point where that can happen. (And a container library will surely happen, I hope it is Charles.) There is nothing wrong with deciding that a certain interface has not yet reached stability and leaving it out of the standard, but the more interfaces that can be "built-in" the larger the domain of problems that can be easily dealt with. > This is a question of balance between understanding of the problem and > understanding of the software tools used to solve it. From the dawn of > computers to present day, the first component prevailed, allowing to > implement "everything [problem] in anything [language]". But in a > long-term perspective, I am talking about 20-100 years, the balance > will definitely change, otherwise we will be unable to maintain the > complexity of software [not the algorithms, note]. It will be a > virtual reality with its own virtual problems, if you wish. (:-)) And > the question is whether templates are the right tool to deal with ever > increasing complexitiy. I do not think so. I personally see it as an advantage to understanding not only the languages you may program in, but how they map to machine code, and how the actual computer implements that ISA. If you need efficient code, you need to understand all of these. Unfortunately today finding people who understand the problem domain and the programming language is hard enough. Adding an understanding of ISAs and machine architecture to that is very rare--but it can work seeming miracles. There are a lot of features in Ada 95 that were added soley to allow drilling through Ada and reaching certain ISA or machine architecture features. If you are used to working in a language which doesn't have those features, you can't compete. The recent discussions here of how to implement latitude and longitude are a case in point. A lot of work went into both defining the language so that fixed-point types could be used efficiently for implementing various angle measures. Further work went into the compilers to make those features work. But the result is that in Ada you can implement angles as degrees and fractions of a degree, radians, thousanths of a second, or grads or whatever you need, and get the best possible machine code for it. Similarly, the Information Systems Annex allows efficient implementations of money, and so on. But the whole concept of programming in the large is to allow those things that need implementation close to the machine to be packaged and all of the nitty gritty to be packaged in a single unit, and the user can work with a higher level of abstraction. A good example is the Atlas tool for generating implementations of LINPACK. It generates an implementation level that is tuned for the particular hardware, while the used can call the higher level primitives without worrying about optimization strategies. -- "As far as I'm concerned, war always means failure." -- Jacques Chirac, President of France "As far as France is concerned, you're right." -- Rush Limbaugh