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,1116ece181be1aea X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-09-29 01:34:34 PST Path: news1.google.com!newsfeed.stanford.edu!newsmi-us.news.garr.it!NewsITBone-GARR!area.cu.mi.it!newsfeeder.edisontel.com!fu-berlin.de!uni-berlin.de!tar-alcarin.cbb-automation.DE!not-for-mail From: Dmitry A. Kazakov Newsgroups: comp.lang.ada Subject: Re: Is the Writing on the Wall for Ada? Date: Mon, 29 Sep 2003 10:43:16 +0200 Message-ID: References: <6jm2nv86sjlodss01sfvikv38jbilkusl7@4ax.com> <0465nv0eg57udvk6sp4jv8jaigt7dm5nm5@4ax.com> <8at7nvg0psj4pqohp2afnkmp56k4lja4jj@4ax.com> NNTP-Posting-Host: tar-alcarin.cbb-automation.de (212.79.194.111) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: news.uni-berlin.de 1064824470 9823946 212.79.194.111 (16 [77047]) X-Newsreader: Forte Agent 1.8/32.548 Xref: news1.google.com comp.lang.ada:127 Date: 2003-09-29T10:43:16+02:00 List-Id: On 26 Sep 2003 10:22:29 -0700, aek@vib.usr.pu.ru (Alexander Kopilovitch) wrote: >Dmitry A. Kazakov wrote: > >> >> ... the language design assumtions do not influence the >> >> software design approach in a direct way. >> > >> >In practice there are always expectations about future implementation opportunities >> >and problems, and those expectations usually influence design substantially. >> >> Those are not related to the language design. > >Sounds strange - implementation opportunities (or expectations about >them) are not related to the language design? Because software patterns are more or less universal. You probably refer programming habits which are different for programmers in C++ and Ada, but again these habits have more to do with a qualification and backgound than with a particular language. >> >But what is more significant, if you aren't familiar with the problem domain, >> >then programming (or software engineering) terminology necessarily becomes your >> >internal design language; general notions (like List, Queue, etc.) usually >> >aren't enough, and for the rest part of the design you will use either forms >> >from a programming language or their imprecise glimpses. >> >> Right, but mostly, because the problem domain issues are very often >> minor comparing with the software design issues. > >I think that this impression is caused exactly by the effect I just >mentioned: >when our (programmers) knowledge about problem domain is only partial >and/or >vague, we naturally try to compensate that at the software design >level (for >example, providing much more flexibility that might be needed if we >knew the >problem domain better). No, it is because for real problems, there is usually neither funding nor interest. See the crux point about making money vs. knowledge? To make money, you have to avoid real problems. >> >> I do not see why it should >> >> be more difficult to make incomplete products in Ada. >> > >> >Because it takes much more expertise in the language for making useful imprecise >> >glimpses of the language's forms in Ada than in C++. Just becase Ada was designed >> >primarily for use in environments where competence in the problem domain can >> >be assumed (and therefore those things should no be needed), while C++ inherits >> >all its basic OO machinery from universal modelling language (Simula-67). >> >> It is a strange statement. You are comparing design purposes with >> heritage. > >But this was the way C++ was originally designed - it more or less >honestly >inherited all its object machinery from Simula-67 (dropping >coroutines). So, >those (original) object features in fact weren't designed for C++, >they were >designed for Simula-67. > >> It is apples and oranges. > >Do you really think that apples and oranges never can (or should) be >compared? -:) It is a question of taste! (:-)) >> I do not see how C++ OO constructs >> make designing incomplete products easier than Ada OO constructs. > >For me it is quite obvious. Take, for example, that multiple >inheritance. In >C++ you have it, and therefore you can simply say: "I inherit >Democracy from >Population and Constitution", retaining the details for vague future >(next >phase of design - detailed design, which possibly will never happen). >You can't >say that in Ada - here you'll be forced to give some kind of >preference either >to Population or to Constitution. And if you aren't aware about >relations >between the Population and Constitution, you naturally will feel Ada >less >convenient in the case, because she pushes you to say something about >the >things you don't know... while C++ permits you to be silent about >them. You are overestimating use of MI in C++. Then any additional work one have to do in Ada as compared with C++, when MI (no matter interface or implementation) is necessary, actually pushes for incomplete products. A deficiency cannot be an advantage. It only could be if a feature, instead of being incompletely or inconsistently implemented, is altogether abadoned. This is not the case if we consider inheritance. >> >> >> Half-baked design is a result of half-baked programmes and uneducated >> >> >> managers. >> >> > >> >> >I think, no. It is most often a result of substantially incomplete problem >> >> >statement and incompetence (of the team) in problem domain. >> >> >> >> These are the consequences. >> > >> >Sometimes, but far from always. Quite often people that are generally educated >> >and sufficiently competent in some problem domain(s) are throwed to other problem >> >domains (in which they are incompetent) without any preliminary training. And >> >those people will have no other choice but to start with some vague model. >> >> To be competent, largely *implies* to know the limits of oneself >> competence. This is the key point. > >The problem here is that the configuration space of skills/competence >is not so plain, it is not restricted to classical scientific and technical >domains. After all psychiatry is a scientific domain, or what did you mean? (:-)) >So, one easily can consider his competence limited just because it is >concentrated >at some *level*, and not in some real world problem domain. > >> An incompetent manager is a universally one. > >He may think otherwise - Surely! >he may be well aware of his level. He may >think that he can manage a group of, say, 50-100 people, but, perhaps, not 1000. >So, his competence is quite limited in his view. Sort of that. To manage 50-100 people ... what these people are supposed to do is no matter. >After all, methematicians also usually do not restrict their >competence to some >problem domains as far as it pertains to square equations -:) . Yep, to think that to lead a 50-men software project is as simple as to solve a square equation, that sounds familiar! >> knowledge is loosing its value in people's view. > >People, quite understandably, failed to find much value in Dark Matter >(which is too dark and too far) and in intermediate boson (which is too >intermediate), They patiently waited for decades for miracles or at least >explanations, but finally quit. As long as people are waiting for miracles, there is no place for knowledge. --- Regards, Dmitry Kazakov www.dmitry-kazakov.de