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 17:58:31 PST Path: archiver1.google.com!postnews1.google.com!not-for-mail From: aek@vib.usr.pu.ru (Alexander Kopilovitch) Newsgroups: comp.lang.ada Subject: Re: signature like constructions Date: 8 Aug 2003 17:58:30 -0700 Organization: http://groups.google.com/ Message-ID: References: <3F337798.2030008@attbi.com> <0o57jvsu8svaarn54n1j7js0casiclfqhb@4ax.com> <3F33FBD5.5010109@attbi.com> NNTP-Posting-Host: 195.242.18.29 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1060390711 29276 127.0.0.1 (9 Aug 2003 00:58:31 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 9 Aug 2003 00:58:31 GMT Xref: archiver1.google.com comp.lang.ada:41267 Date: 2003-08-09T00:58:31+00:00 List-Id: Robert I. Eachus wrote: > 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. Do you mean that the "Paradise may be regained"... if not for average programmer then at least for an average star -:) ? That is, that by training yourself in that direction, and keeping your nerve, it is possible to follow even rapidly and rather randomly changing requirements with proper documentation and analysis in real time, inside a not very friendly environment? Do you mean that the common defensive strategy against probable but unpredictable changes of requirements -- that is, keeping yourself not too near to them, and more relying upon agreed tools (which seem less vulnerable for spontaneuos customer's or management's dances) -- is not the best strategy, and that it is really possible to chase a moving/jumping problem, all the time at near distance, without significant delay? > [...] > 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. You have seen the miracles being used more that in one or two cases -- so you are lucky. I think that most of us feel that the miracles, if happen, will be most probably betrayed. That's why "Adding an understanding of ISAs and machine architecture to that is very rare" indeed. Alexander Kopilovitch aek@vib.usr.pu.ru Saint-Petersburg Russia