Re: signature like constructions

[Dmitry A. Kazakov <mailbox@dmitry-kazakov.de>]

On Fri, 08 Aug 2003 19:37:02 GMT, "Robert I. Eachus"
<rieachus@attbi.com> wrote:

>Dmitry A. Kazakov wrote:
>
>> 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.

I have formulated it not very precisely, so you catched me. (:-))

No, imagine that the requirements do not change, they do not exist!
How could something unexisting change? (:-)) The problem space is so
remote, layered that nobody takes care to understand it. This is not
an excuse, it is awful, but we have to live with that.

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

But this does not solve the problem. You simply push it to the
compiler developer side. So they shall manage all the complexity. If
in my scenario all living beings will soon or later become application
programmers, then in yours, everyone will be a compiler developer.
That's even worse! In any case a catastrophe is ahead.

I tend to agree with Martin Condic. Let's make language small, but
powerful enough to implement most of the Annexes. Instead of
Unbounded_String, a better type system which would make it easy to do.

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

Ask a manager what is better: a bird in the hand or two in the bush.
They do not want to wait for miracles, and, well, if miracles do
happen, then, you know, people usually crucify that unfortunate
miracle-makers!

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de