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,5cb36983754f64da X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2004-04-19 07:15:42 PST Path: archiver1.google.com!news2.google.com!fu-berlin.de!uni-berlin.de!tar-meneldur.cbb-automation.DE!not-for-mail From: Dmitry A. Kazakov Newsgroups: comp.lang.ada Subject: Re: No call for Ada (was Re: Announcing new scripting/prototyping language) Date: Mon, 19 Apr 2004 16:29:08 +0200 Message-ID: References: NNTP-Posting-Host: tar-meneldur.cbb-automation.de (212.79.194.119) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: news.uni-berlin.de 1082384141 6962373 I 212.79.194.119 ([77047]) X-Newsreader: Forte Agent 1.8/32.548 Xref: archiver1.google.com comp.lang.ada:7336 Date: 2004-04-19T16:29:08+02:00 List-Id: On Mon, 19 Apr 2004 05:53:17 +0400 (MSD), "Alexander E. Kopilovich" wrote: >Dmitry A. Kazakov wrote: > >> > The problem is that in software it often isn't easy to differentiate a >> > fraud or liable negligence from a reasonable risk, to which the user was >> > knowingly agreed. Almost all computer professionals will agree that given >> > the current state-of-art, there is a risk-cost tradeoff for common >> > software products. >> >> I disagree. 90% of software impose no risk in development. Risk exists, but >> it is related to management, marketing etc. > >If you have complete and unambiguous requirements before software development >phase than yes, this development may be error-free. But this means only that >you shifted all the risk to the requirements. If your analysts are much >stronger than your programmers then that may be good tactics. But if not... >you will possibly get a sound failure without any prior warnings/symptoms. Have you seen MS-Word requirements? Has it any? >> > And with the risk of eventual software error being >> > pushed too down the cost will skyrocket. So users have a good reason to >> > agree with some risks - because they need (or want) the functionality, >> > provided by the product, but only for a certain price, and not higher. >> > This is a user's choice - either to take a proposed risk, or not to buy >> > the product. >> >> There is no such choice. You know it very well. This is why there are >> regulations, to prevent you from buying rotten food in supermarkets. > >We have common understanding of what it means for a food to be rotten - for >many centures. What comes relatively recently - it is just means (methods, >devices) for quick and precise recognition of this state, while its general >definition was commonly agreed long ago. No difference. It is no rocket science to see if MS-Word crashes. >> As I said before, you need not to look into the code. You have to look at >> the procedure. Compare it with food regulations. Most of them tell that the >> flesh shall be kept under some definite temperature, no longer than ... > >But new software product isn't a copy, you know, and there can't be exact and >complete procedures for its development. Should it mean that they are irrelevant? >> > Being accesible and usable for large number of diverse people is one of >> > the most essensial qualities for some kinds of software. >> >> Nonsense. This is not a quality to be paid for. It is MS's business. We >> should pay for a text processor, not for an ability to swallow a market >> segment. > >You are wrong here, and particularly in the case of MS Word. It is an >important quality for this kind of text processor to be shared by very many >users. Presence of this quality means (for a user) that documents can be >shared, sent and received (note that this isn't just issue of file format, >because different processors may print the same file format slightly >differently, and this is significant for many documents); visual formats and >styles can be more or less easily shared; and learning is much easier for >beginners because very often there are neighbours who already mastered this >text processor. MS-Word supports several formats, so I do not know what you mean. >> >> >> Again, there are issues essential to the existence of our >> >> >> civilization. >> >> > >> >> > You are so focusing on our civilization... don't you think that >> >> > civilization is quite a complex thing, and it is not easy to determine >> >> > what is essential for it? But at least you don't refer to the God's >> >> > will, and this is good. >> >> > >> >> >> Software development becomes one of them. Ada is just an indicator of >> >> >> how things are going on. >> >> > >> >> > Don't you see that these two your sentences contradict each other? >> >> > Ada essentially defies the general notion of "software", Ada expects >> >> > you to analyze each your problem deeply, with all its specifics, not >> >> > relying upon some general "software" fashions and solutions. It does >> >> > not mean that you should forget all your previous experience and it >> >> > doesn not preclude any general computer science - you can use all that >> >> > if it helps you, but you can't rely upon that, you can't get excuses >> >> > from that. >> >> >> >> Where is any contradiction? >> > >> > You said that software development - general process for general >> > notion/issue - becomes critically important. Then you said that the things >> > are going very badly in this respect. Then you hinted that the negligence >> > to Ada is a symptom as the latter. But Ada essentially defies general >> > notion of "software", so you logically should perceive the negative >> > attitude towards Ada as a good symptom, that is, a symptom of widened >> > understanding of importance of general notion of "software". >> >> Sorry, but I cannot follow you. How a negative attitude to something (Ada), >> which defines X, could be a symptom of widened understanding of importance >> of that X? > >A funny thing happened... Inadvertenly we created a good case - a proof of >that even a clear and unambiguous sentence may be confused if it is not >expected. Look, I wrote "defies" (from "defy"), not "defines"! > >I wrote it twice, and this was exactly what I meant, but nevertheless you >either overlooked the absence of "n" in this word or decided that this were >just typos, in both cases. After that you naturally had no chance to follow >the logic of the text. And even after second iteration you appear unable >either to recognize the meaning of that word or to believe that your opponent >could say such a strange thing. > >Well, I agree that this was an accident - two perfectly legal sentences with >very different, almost opposite meaning happened to be in dangerous lexical >proximity; and the situation was aggravated by the fact that the language of >dialogue was not native for both speakers involved. > >It is too hard to prevent *all* significant errors -;) Sorry, I just could not imagine how Ada can defy general notion of software. >> What makes you to think that the current level of error-prevention is so >> high that the next step would cost as much as the space-shuttle program? It >> is just guessing, a far from reality one. > >Experience... not just my own experience, but experience of 20th century. >When you are trying to increase the level of error-prevention in large scale >then you have to worry very much about not increasing the level of >progress-prevention and the level of diversity-prevention. In 20th century >we have several examples - some very famous, some less known, but nevertheless >quite substantial, where too strong attitude towards error-prevention (without >worrying about side-effects) was a major contributing factor for sound >catastrophes. That is, the achieved good level of error-prevention made the >final catastrophes much more sound. Stop, first you tell us that the experience of making the food producers liable is not applicable for the software. Now you tell that the experience in error-prevention as the major brake of the progress (in avionics? paper-fasteners?) is. Isn't it a bit selective? -- Regards, Dmitry Kazakov www.dmitry-kazakov.de