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: 103376,5cb36983754f64da X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2004-04-18 01:25:09 PST Path: archiver1.google.com!news2.google.com!fu-berlin.de!uni-berlin.de!dialin-145-254-041-207.arcor-ip.NET!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: Sun, 18 Apr 2004 10:24:42 +0200 Organization: At home Message-ID: References: Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: dialin-145-254-041-207.arcor-ip.net (145.254.41.207) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Trace: news.uni-berlin.de 1082276708 5515715 I 145.254.41.207 ([77047]) User-Agent: KNode/0.7.2 Xref: archiver1.google.com comp.lang.ada:7303 Date: 2004-04-18T10:24:42+02:00 List-Id: Alexander E. Kopilovich wrote: > Dmitry A. Kazakov wrote: > >> >> Requirements and terms of >> >>liability are pretty easy to set and check. >> > >> > Are you a lawyer? I think that a person who is not a lawyer should not >> > make statements of this kind anyway. >> >> I was not talking about technical details of a particular license >> agreement. I was talking about a common, long established practice of >> protecting customers from frauds. > > 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. Anyway, why the customers have to care this risk? > 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. > The problem is that with huge diversity of both software > products and user's background, attitudes and education, it is impossible > to represent clearly that trade-off as it is set in a particular product. > And even to represent it vaguely, but more or less enough for anticipated > courts, the professional lawyers are needed. 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 ... etc. Further, if you get poisoned in McDonalds, it will be responsible for that. That is. If you have lost your document in MS-Word, and this could be made provable (regulation might require some kind of log), then MS has to pay. >> I didn't asked about purpose of a text processor. I did about the >> software quality. > > 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. >> >> 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? >> Anyway the cost of various testing, simulating etc, hardware/software is >> measured in tens of millions of dollars. Their maintenance..., who knows. > > A particular simulator of/for a particular controller for investigating a > particular bug - tens of millions of dollars? For development/testing cars. > Perhaps you mean some ideal > error-preventing system, which will cost more than than accumulated cost > of all errors, which it prevents over current error-prevention/debugging > technique, 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. >> So a manager might think that this is more than enough to find a bug. > > What can he wish else, if a bug is already present and perceived? To leave the firm, because the "patient" is already dead. As I said, you cannot debug this. The chances are high that the error will be never found. So they have a choice between trying to locate the situation where it appears and then to compensate it somehow, or to trow all that mess away. >> Debugging is the least productive way for preventing software faults in >> embedded/real-time world. In many cases it does not work at all. > > But what to do when a bug was not prevented, and shows itself in released > product? To shoot yourself. > You are proposing to drop away this product and rebuild it using > some (very costly) ideal error-free methodology, from scratch? In many cases there is no other way. This why I am talking about a catastrophe coming. In the future we will have much larger percent of systems like this. Costs of their development will be astronomcal. With the current way of thinking: let's do something and see if it works, where we will come? -- Regards, Dmitry A. Kazakov www.dmitry-kazakov.de