Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

["Alexander E. Kopilovich" <aek@VB1162.spb.edu>]

Dmitry A. Kazakov wrote:

> >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?

Obviously no. I never been affiliated with Microsoft in any way, and never
seen its internal documents.

> Has it any?

I think yes, but they may be in rather economical, ergonomical etc. than
software engineering terms. They may have more technical (and perhaps more
volatile) refinements for parts, components, modes etc. 

> >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.

But there is a difference in consequences. If you swallow a rooten food then
you probably (although not certainly) will be poisoned and fall ill, maybe
severely ill and even may die. But MS Word crash, however unpleasant, very
rarely has serious consequences. Most probably it will just annoy you for
several minutes or, perhaps, spoil some of your time - perhaps one or two
hours at most. Cases when a document - and not just any document, but an
important document was irrecoverably lost by a crash of MS Word - are very
rare, even exotic.

Buy the way, I have not heard much about MS Word crashes... actually I can't
recall even single story of that - for me it means that this is quite rare
and/or unimportant event. Perhaps it depends on whether (and how heavily)
this MS Word is used in conjunction with other applications.

> >> 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?

Not at all, I never said that they are irrelevant or unimportant. They are
certainly interesting and deserve attention. I only stated that they aren't 
generally and neccessary the fundamental and primary thing in development.
That may be so in some cases, but it isn't so in other cases. That is, those
procedures may be primary and determining thing in some cases, but they are 
secondary and dependent in other cases.

> >> > 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.

Well, if you want to share your MS Word documents with assorted parties then
I'd recommend RTF (Rich Text Format) vs. default DOC format because of the
issue of compatibility between various releases of MS Word (MS Office) - with
RTF you most probably will be safe, while with DOC some incompatibilities are
really possible if the releases of MS Word aren't the same.

> >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.

But could you imagine how Ada can DEFINE general notion of software?
I must confess that this is unimaginable for me - how any programming language
can DEFINE general notion of software. Actually I think that you was ready
to tolerate DEFINE there simply because it has some positive character in the
context, that is, hints to some positive quality of Ada.

Well, I'll explain how Ada DEFIES general notion of software. Ada does that
in two ways:

First, Ada expects dealing with detailed specifics of the problem, and detests
generalized approaches that ignore that specifics without prior consideration.

Second, Ada does not recognize software as an application domain that has its
own specifics - domain-specific features, primitives and structures. (The fact
that Ada somehow recognizes several other languages is largely irrelevant to
the issue.)

This is current situation. The first "way of defying" is fundamental for Ada.
It can't be betrayed without committing suicide... or at least losing
personality. But the second one can be changed in some future.

> >> 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?

Well, I already explained the first. As for the second, strong desire for
error-prevention can easily slide from prevention of actual or probable
causes of errors to prevention of possible causes of errors and then to
prevention of conditions that may generate possible causes of errors. This
is a way for preventing progress. And this is not just imagined way - this is
a real, many times (and in various scales) observed way. It does not follow
from that experience that we should not pursue error-prevention; that our 
experience tells us only that we should be aware of that danger and resist
attempts to give error-prevention machinery too much power.

As for "selective" - yes, certainly selective, with a reason for each case.
With all my admiration for Euclid, we do not live in Euclidian space, reality
is not governed by finite number of Euclidian axioms, so we shouldn't make
general and absolute statements about reality, and must be selective...
according to our abilities for that.



Alexander Kopilovich                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia