Re: signature like constructions

["Robert I. Eachus" <rieachus@attbi.com>]

Dmitry A. Kazakov wrote:

> I do not think that we really are in a big disagreement. (:-))

Agreed.  I wasn't really picking on you, but targeting the discussion as 
a whole.

> Yes. But the example provided by Georg, as far as I understand it,
> aims at a case where there is already an implementation of 2D points,
> which has to be reused. He wished to show that it is problematic with
> tagged types, but still works with generics.
> 
> Your example is a case of monolitic design, all from scratch, which is
> clean and desirable, but becomes less and less frequent in modern
> times. It is a right perspective, but there is a little chance that we
> would climb so high. (:-))

Ah, here we do disagree.  When the requirements change, that is not a 
reason not to understand and document the current requirements.  And if 
one of those requirements is to live within a body of existing code, 
that is from one point of view just another requirement.  Of course, 
when I do requirements analysis, as far as I am concerned, figuring out 
which requirements are likely to change and preparing for that evolution 
is part of the process.  This is why I keep saying you should program in 
the problem space rather than some solution space.  The problem space 
evolves much more slowly than the problems you are asked to solve.


> This is true, but again unrealistic in a large, distributed, long
> living project. In which case a "better" solution is one which
> requires only maintainable changes in the existing infrastructure and
> still works somehow...

See above.  Incidently, another issue that should never be overlooked in 
the design process is version skew.  If I write a program in Ada that 
uses say Charles and gtkAda, that is three potential versions to worry 
about (Ada compiler, Charles, and gtkAda).   That is three potential 
versions that may change and get out of alignment, and that is about the 
  limit for anything you are going to maintain.  Since the potential 
version conflicts increase as n*(n+1)/2.  So with just the compiler, 
that is 1, with two libraries as above, that is 6, when you get to four 
interfaces, and the OS interface if you program to it counts as well, 
that is 15, and next to impossible to keep up with.

This is one reason I argued in favor of the Annexes in Ada 95, each 
Annex could eliminate  one version from that equation.  In the next 
version I hope to see a database binding, perhaps to ODBC added.  I'd 
like to see a standard graphics library as well, but I don't think we 
are to the point where that can happen.  (And a container library will 
surely happen, I hope it is Charles.)  There is nothing wrong with 
deciding that a certain interface has not yet reached stability and 
leaving it out of the standard, but the more interfaces that can be 
"built-in" the larger the domain of problems that can be easily dealt 
with.

> This is a question of balance between understanding of the problem and
> understanding of the software tools used to solve it. From the dawn of
> computers to present day, the first component prevailed, allowing to
> implement "everything [problem] in anything [language]". But in a
> long-term perspective, I am talking about 20-100 years, the balance
> will definitely change, otherwise we will be unable to maintain the
> complexity of software [not the algorithms, note]. It will be a
> virtual reality with its own virtual problems, if you wish. (:-)) And
> the question is whether templates are the right tool to deal with ever
> increasing complexitiy. I do not think so.

I personally see it as an advantage to understanding not only the 
languages you may program in, but how they map to machine code, and how 
the actual computer implements that ISA.  If you need efficient code, 
you need to understand all of these.  Unfortunately today finding people 
who understand the problem domain and the programming language is hard 
enough.  Adding an understanding of ISAs and machine architecture to 
that is very rare--but it can work seeming miracles.

There are a lot of features in Ada 95 that were added soley to allow 
drilling through Ada and reaching certain ISA or machine architecture 
features. If you are used to working in a language which doesn't have 
those features, you can't compete.  The recent discussions here of how 
to implement latitude and longitude are a case in point.  A lot of work 
went into both defining the language so that fixed-point types could be 
used efficiently for implementing various angle measures.  Further work 
went into the compilers to make those features work.  But the result is 
that in Ada you can implement angles as degrees and fractions of a 
degree, radians, thousanths of a second, or grads or whatever you need, 
and get the best possible machine code for it.  Similarly, the 
Information Systems Annex allows efficient implementations of money, and 
so on.

But the whole concept of programming in the large is to allow those 
things that need implementation close to the machine to be packaged and 
all of the nitty gritty to be packaged in a single unit, and the user 
can work with a higher level of abstraction.  A good example is the 
Atlas tool for generating implementations of LINPACK.  It generates an 
implementation level that is tuned for the particular hardware, while 
the used can call the higher level primitives without worrying about 
optimization strategies.


-- 
"As far as I'm concerned, war always means failure." -- Jacques Chirac, 
President of France
"As far as France is concerned, you're right." -- Rush Limbaugh