Re: ADA Popularity Discussion Request

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

jayessay wrote:

> ... I don't use much static typing anymore.  It just
> doesn't offer much because it is largely dependent on having all
>requirements set in concrete (which they almost never are).
>
>Have a look at this:
>
>http://martinfowler.com/articles/newMethodology.html

Well, personally I have no need to look at any article for acknowledging that
in very many (probably majority of) software works the requirements are
neither comprehensive nor stable - I know that too well. But your claim - that
this is almost always so - is severe exaggeration; there are enough software
works where where all requirements are (or at least presumed to be) indeed
set in concrete. And Ada language was and is targetted primarily at the
domains where the latter is generally true.

> Personally, I think the sort of "agile" method I've been mentioning
> here is in many ways analogous to developing a theory in mathematics
> than what happens in "engineering".  There is a lot of creative
> "noodling" that goes into this buttressed by very high levels of
> rigor, with a very bottom up approach where each definition,
> proposition, lemma and theorem are incrementally determined and
> tightly integrated.  There are of course many differences, but it at
> least indicates the very different mind set.

I'm just wondering why do you think that this mind set can be successful
in long run, when it is adopted without understanding and adoption of rigid
requirements and limitations, which are associated with it in mathematics.

Apart from that rather subjective notion of mind set, please note that there
are two highly important aspects of the difference - *scheduled* reliability
and associated immediate risks.

All that widely acknowledged reliability of mathematical theories can't be
achieved quickly - it is a long way for a theorem to be accepted as proved -
that involves many checks by many persons and enough years to wait for a
possible discovery of a hidden gap in the proof. Real-world projects these
times are usually constrained by economy and competition and therefore can
neither wait so much nor allow extensive public reviews.
(Note, that besides of really firmly established theories, mathematics - and
especially applied mathematics - has also so-called "methods", which quite
often aren't reliable - sometimes they lead to a success, but in other cases
they fail - and there may be no known way to predict what will happen in a
particular case without trying the method... or going into specifics of the
case to significant depth, and then using explicit or implicit references to
previous experience. No wonder that those generally unreliable, but sometimes
effective methods often can be developed much faster that solid theories.)

Then, creative imagination do not face immediate real-word risks; therefore
one can try to rely upon too fresh proof of some theorem (or upon too bold
interpretation) and see what can be built atop of it.  If your risks are low
- just waste of some time, waste of some (not too much) money - then you may
run as a creative programmer; but if your risks are high - immediate loss of
lives, severe breach of security, strong and massive negative impact on
environment, etc. - then your must run as responsible engineer, strictly
limiting immediate impact of your creative imagination.

And as usual, there are grey zones - where either both risks and possible
gains are substantial or where taking risk in one aspect of the whole matter
may significantly decrease risk associated with other aspects. Some would
call this a gambling, others would call this a balancing.

> Not type usefulness, most everyone agrees types are useful, even
> necessary.  It is _static_ typing that is of questionable usefulness
> in any domain that doesn't have clear, well defined requirements
> (which is to say the vast majority of cases).

I think that after that rather prolonged arguing about usefulness of dynamic
vs. static typing using "field performance" kind of arguments, it is time
to try to describe the difference between them in some more general terms.

First, for static typing, let's repeat that "Ada is for problem space".
That means, that description of problem space is considered as primary
strategic goal for Ada language. Static typing is natural thing for such
a description - a typed variable is a natural instance of a coordinate in that
space. So, the discussion is actually about whether it is generally good to
strive for (precise) description of problem space.

But what is an alternative? If static typing provides us means for description
of problem state, then what does dynamic typing provide?

I guess that dynamic typing provides description of "event space", that is,
a particular stage of the whole process, on whatever level of the latter.
In this sense, with dynamic typing, the variables represent a kind of local
coordinates along the process's trajectory (at the process's current state).

It also seems to me that there must be some duality between these two kinds
of typing; perhaps the pair of universal objects from category theory -
product and coproduct (which are dual to each other) - somehow relates to
that comparison (where product stands for static typing, and coproduct stands
for dynamic typing).

Then, static typing, with its capabilities for descrpiption of whole problem
state, promotes analytical approach, while dynamic typing, with its
concentration on local events (on various levels), promotes synthetic approach.

So, if a challenge is the most significant aspect of the job then dynamic
typing may bring noticeable advantages; but from the crash investigator's
viewpoint, dynamic typing is a horrible thing, and the stricter is static
typing - the better: strict static typing will not eliminate crashes, but
it will make investigation task much easier (note, that an investigator
often must not only discover what causes the crash, but also make someone
responsible).




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