XML DOM Binding for Ada 95 - matter of style

XML DOM Binding for Ada 95 - matter of style

[DENNY VRANDECIC]

Hello group,

I am writing an XML DOM Binding for Ada 95 (as part of my master thesis) -
not really the whole parser, just a binding to a parser that is more
complete (i.e. implements more modules of the DOM Spec) than the otherwise
great XmlAda by ACT. The binding will be given to the community for free
under a BSD-like license.

I'd love to write the binding in such a way, that later the user may easily
switch to a native DOM Implementation (like a further developed XmlAda),
which I'm sure will finally come. But for that I have to make one hard
decision: which standard to follow?

On the one hand, the W3C published IDLs in their standards, and I may choose
just to stick close to these IDL-Specs. The result doesn't have an Ada-like
feeling - the procedures names are written in one word, the exception
handling is cumbersome, and more. But I follow the W3C standard closely, and
that's a good thing, isn't it? And most of the interface could be created
automatically. There would be less discussions on the details of this way,
as their is a standard IDL describing the interface and a standard mapping
of IDL to Ada 95. Everything is standard, everything is fine.

On the other hand, I could adhere to the Ada style guide, and make the
binding feel very Adaesque. Ada users would learn it easier, it would better
fit in the program, the stylecheckers would appreciate it and much more. But
with creating this interface I would probably have to make much more
decisions, which could be questioned, and thus this way would harder lead to
an accepted standard interface, thus making switching the implementation
later harder.

It's a Catch-22, so I'd love to draw on your experience. I will deliver a
talk on Friday at the University of Stuttgart, Germany, about this, and
discuss it with the people there to form a stronger opinion about it, and I
would love to hear your opinion on it beforehand and afterwards. I like to
make this decision with you, as eventually this binding is done for the
community.

Sorry for my bad english, I'm no native speaker. If you have further
questions or comment, that or not of interest to many, you may also send
them via eMail (denny_at_nodix.de).

Thanks for your time,
Denny Vrandecic
Student of computer science, University Stuttgart

Re: XML DOM Binding for Ada 95 - matter of style

[Martin Dowie]

"DENNY VRANDECIC" <nodix@tiscali.de> wrote in message
news:bg8ac5$20i3$1@ulysses.news.tiscali.de...
> On the one hand, the W3C published IDLs in their standards, and I may
choose
[snip]

How about providing both? One as a wrapper to the other.

Re: XML DOM Binding for Ada 95 - matter of style

[Denny Vrandecic]

Denny Vrandecic wrote:
> > On the one hand, the W3C published IDLs in their standards, and I may
>> choose
>>[snip]
Martin Dowie answered
> How about providing both? One as a wrapper to the other.

Simply put: double work, same pay.
There is no easy way of wrapping one around the other, especially Exception
Handling is a rather tricky issue that differs tremendously between the IDL-
and the Ada-way.
To avoid double work and still write the one binding that is most useful for
the Ada-Community I ask here for your opinion and advice.

Thanks though,
Denny

Re: XML DOM Binding for Ada 95 - matter of style

[Stephen Leake]

"Denny Vrandecic" <nodix@tiscali.de> writes:

> Denny Vrandecic wrote:
> > > On the one hand, the W3C published IDLs in their standards, and I may
> >> choose
> >>[snip]
> Martin Dowie answered
> > How about providing both? One as a wrapper to the other.
> 
> Simply put: double work, same pay.

Well, same pay for you in the short run (one thesis), but significant
gain for both you and the community in the long run.

> There is no easy way of wrapping one around the other, especially
> Exception Handling is a rather tricky issue that differs
> tremendously between the IDL- and the Ada-way. To avoid double work
> and still write the one binding that is most useful for the
> Ada-Community I ask here for your opinion and advice.

You should start with a thin binding (the IDL way). That will allow
easy upgrade to any future versions of the DOM spec. 

Then anyone who wants to use it will write a partial thick binding
(the Ada way). Eventually, all those people will get together and
write a common thick binding.

-- 
-- Stephe

Re: XML DOM Binding for Ada 95 - matter of style

[Martin Dowie]

"Denny Vrandecic" <nodix@tiscali.de> wrote in message
news:bg8noh$22ti$1@ulysses.news.tiscali.de...
> Simply put: double work, same pay.
> There is no easy way of wrapping one around the other, especially
Exception
> Handling is a rather tricky issue that differs tremendously between the
IDL-
> and the Ada-way.
> To avoid double work and still write the one binding that is most useful
for
> the Ada-Community I ask here for your opinion and advice.

In that case I'd go with the W3C and then hope someone puts a
convenient Ada-ish wrapper on top for you someday. :-)

Re: XML DOM Binding for Ada 95 - matter of style

[tmoran]

>just to stick close to these IDL-Specs. The result doesn't have an Ada-like
>feeling - the procedures names are written in one word, the exception
>...
>binding feel very Adaesque. Ada users would learn it easier, it would better
>fit in the program,
  The first is called a "thin" binding, the latter a "thick" binding.
For some comments on the tradeoffs, see the Introduction and section 2.1
in our TriAda paper "CLAW, a High Level, Portable, Ada 95 Binding for
Microsoft Windows", available on-line at www.rrsoftware.com  Also see
IEEE Std 1003.5-1992 "POSIX Ada language Interfaces", search c.l.a.
for "thick" or "thin", or search www.adaic.org/site/wide-search.html

Re: XML DOM Binding for Ada 95 - matter of style

[Marin David Condic]

Another argument against that notion is that you then have yet another 
proliferation of a different "standard". I'm looking at Trudy Levine's 
column in the most recent Ada Letters and noticing the wide 
proliferation of possible container libraries out there and I'm sure 
this is not a comprehensive list mentioning every one that is publically 
available. (Not to mention all those sitting in private libraries that 
were home grown but not distributed.) Do we really need to see yet more 
variations of a library where the fundamental purpose and functionality 
has not changed?

My opinion is this: The XML standard for document content is the only 
real compatibility one needs to maintain. The interface to access it 
ought to be treated more as a "suggestion" with what is natural for the 
language of implementation being the deciding factor. Don't be different 
just for the sake of being different - keep names of things 
similar/recognizable and provide mostly the same operations, etc. - but 
do it in a way that makes sense for Ada.

BTW: I never really liked the XMLAda approach of using discriminated 
records and thought it should have been built in a more Object Oriented 
way using tagged records. (Thus giving fuel to the C++/Java critics of 
Ada where they can observe that given an object oriented design, Ada 
apparently can't implement it in an object oriented way with 
inheritance, etc.) It would be a good thing to look to fix in any 
enhanced interface to the XML-DOM.

MDC

Stephen Leake wrote:
> 
> 
> Well, same pay for you in the short run (one thesis), but significant
> gain for both you and the community in the long run.
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

Re: XML DOM Binding for Ada 95 - matter of style

[Preben Randhol]

Marin David Condic wrote:
> BTW: I never really liked the XMLAda approach of using discriminated 
> records and thought it should have been built in a more Object Oriented 
> way using tagged records.

What is the gain?

I thought one of the problems with Booch was that it was using tagged
types too much. Does Charles also use this approach?

-- 
Ada95 is good for you.
http://www.crystalcode.com/codemage/MainMenu/Coding/Ada/IntroducingAda.php

Re: XML DOM Binding for Ada 95 - matter of style

[Matthew Heaney]

"Preben Randhol" <randhol+abuse@pvv.org> wrote in message
news:slrnbihv85.4jd.randhol+abuse@kiuk0152.chembio.ntnu.no...
> Marin David Condic wrote:
> > BTW: I never really liked the XMLAda approach of using discriminated
> > records and thought it should have been built in a more Object Oriented
> > way using tagged records.
>
> What is the gain?
>
> I thought one of the problems with Booch was that it was using tagged
> types too much. Does Charles also use this approach?

One problem is that you have to make two instantiations: one for the root
package, in which the root type is declared, and another, for the child
package in which the actual container (derived) type is declared.  This is a
royal pain.

Charles deliberately avoided this technique, because no inheritance is
necessary.  Static mechanisms are used instead, which are simpler and more
general.

So don't use a tagged type hierarchy when there's a simpler mechanism
available.  I haven't seen the XMLAda approach, but I am totally sympathetic
to approaches that do *not* use tagged records.

I'm not against tagged type ("object-oriented") programming, it's just that
many programmers seem to treat this as a hammer looking for a nail, and
automatically use a tagged type to solve a problem that is better solved
other ways.

Look for a new release of Charles early next week.

http://home.earthlink.net/~matthewjheaney/charles/

Re: XML DOM Binding for Ada 95 - matter of style

[Simon Wright]

"Matthew Heaney" <matthewjheaney@earthlink.net> writes:

> "Preben Randhol" <randhol+abuse@pvv.org> wrote in message
> news:slrnbihv85.4jd.randhol+abuse@kiuk0152.chembio.ntnu.no...

> > I thought one of the problems with Booch was that it was using
> > tagged types too much. Does Charles also use this approach?
> 
> One problem is that you have to make two instantiations: one for the
> root package, in which the root type is declared, and another, for
> the child package in which the actual container (derived) type is
> declared.  This is a royal pain.
                       ^^^^^^^^^^

I would say "mildly tedious", but then I would, wouldn't I!

It's not clear to me that this is a consequence of using tagged
types?? perhaps .. anyway, what people complain about, until they've
got used to it or developed a tool to generate the code for them, is
the instantiating, not the taggedness.

Re: XML DOM Binding for Ada 95 - matter of style

[Randy Brukardt]

"Matthew Heaney" <matthewjheaney@earthlink.net> wrote in message
news:Ly8Wa.716$jg7.380@newsread3.news.pas.earthlink.net...
> "Preben Randhol" <randhol+abuse@pvv.org> wrote in message
> news:slrnbihv85.4jd.randhol+abuse@kiuk0152.chembio.ntnu.no...
> > I thought one of the problems with Booch was that it was using tagged
> > types too much. Does Charles also use this approach?

You can't use tagged types too much. IMHO, virtually everything should be
derived from Controlled or Limited_Controlled (which by definition makes
them a tagged type). But...

> One problem is that you have to make two instantiations: one for the root
> package, in which the root type is declared, and another, for the child
> package in which the actual container (derived) type is declared.  This is
a
> royal pain.
>
> Charles deliberately avoided this technique, because no inheritance is
> necessary.  Static mechanisms are used instead, which are simpler and more
> general.

Right. *Inheritance* is what can easily be overused. It has its place, but
it can easily be overused. And users have a hard time understanding
"overriding", which is usually necessary to use these sorts of types.

We did Claw that way mainly because we wanted to be able to say that it was
"Object-Oriented"; if I was designing it with no marketing implications, we
may have chosen a different structure. (I'm not sure, because we never did
any analysis on non-O-O choices.)

In the specific case of container libraries, if it takes more than one
instantiation to get a basic container, it is too hard to use. If it's much
more complex than that, I'd rather build my own from scratch (none of them
are that much work to implement, especially as you almost never need the
full generality). And I don't think it is important to have a version for
every need. A version that works well for most needs is enough -- if you
have truly critical needs, you ought to build something custom that meets
those needs exactly. But most container needs aren't that critical. It's
more important to be able to use them to quickly build a solution that you
can profile to find out whether it is good enough or not.

                Randy.

Re: XML DOM Binding for Ada 95 - matter of style

[Marin David Condic]

Well, if one believes that there is no value in the Object Oriented 
Design methodology, then I suppose there is no gain. :-)

First, the code would reflect the design. Everything in the XML DOM 
description is done with an eye towards an object oriented 
implementation - a base level node from which all the other nodes are 
derived, overriding and extension of operations, etc. You don't have to 
implement it as object oriented code utilizing tagged records, etc. Its 
just the most natural expression of the design.

Second, should there be extensions in the form of adding new node types 
or new operations to the DOM, the Object Oriented approach makes the 
extension less painful than it would be to modify the discriminated 
record implementation. Maybe it never changes, so maybe that's not a 
gain. Do you really think the standards committee is going to disband 
and declare XML & the DOM frozen for all time? Tagged record 
implementation would sure make it easier for someone else to build upon 
it if the need should arise.

IMHO, something like the DOM - an OOD expression of a desired 
functionality - is exactly the reason Ada invented tagged records. To 
implement it with discriminated records (a feature I always found to 
have too many "gotchas!" built into it anyway) seems awkward and clumsy. 
If you don't think using tagged records to implement something like this 
design is appropriate, what are you saving them for? :-)

MDC



Preben Randhol wrote:
> Marin David Condic wrote:
> 
>>BTW: I never really liked the XMLAda approach of using discriminated 
>>records and thought it should have been built in a more Object Oriented 
>>way using tagged records.
> 
> 
> What is the gain?
> 
> I thought one of the problems with Booch was that it was using tagged
> types too much. Does Charles also use this approach?
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

Re: XML DOM Binding for Ada 95 - matter of style

[Matthew Heaney]

"Marin David Condic" <nobody@noplace.com> wrote in message
news:3F2A5303.6080902@noplace.com...
>
> IMHO, something like the DOM - an OOD expression of a desired
> functionality - is exactly the reason Ada invented tagged records.

The purpose of tagged records is to implement dynamic binding.

If the problem calls for dynamic binding, then maybe a tagged type is
appropriate (but maybe not).

If the problem does not require dynamic binding of operations, then you
probably don't need tagged types.

> To
> implement it with discriminated records (a feature I always found to
> have too many "gotchas!" built into it anyway) seems awkward and clumsy.
> If you don't think using tagged records to implement something like this
> design is appropriate, what are you saving them for? :-)

I have never had a problem with discriminated records, so I don't know what
"gotchas" you're referring to.

Tagged types are one tool among many.  Use them when they make sense.

It probably doesn't make sense to use a tagged type when there is no dynamic
binding.

Even when there is dynamic binding, using case statements or subprogram
pointers is often simpler.  It depends on the problem.

Note that the Charles library implements the full view of the container type
as tagged, but only to add controlledness to the type, so that memory
management is automatic.  The partial view of the type is not tagged, and
there is no dynamic binding.

http://home.earthlink.net/~matthewjheaney/charles/

Re: XML DOM Binding for Ada 95 - matter of style

[Marin David Condic]

So things like type extension don't count? :-)

I see tagged types as the way to fully implement the Object Oriented 
paradigm in Ada. Other mechanisms in Ada could be used to support parts 
of the OO paradigm - sometimes they have to be brutally flogged into 
that service - but none really creates the full OO paradigm as do tagged 
types. Not all programs require OO nor are they best expressed in the OO 
method. I work on software like that every day. But if you have an OO 
design, I'd think that trying to beat it into submission with the blunt 
instrument of a discriminated record is not the best approach. If it is 
an OO design, create an OO implementation with the correct Ada idiom for 
that - the tagged record and its surrounding package components.

MDC

Matthew Heaney wrote:
> 
> 
> The purpose of tagged records is to implement dynamic binding.
> 

-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

Re: XML DOM Binding for Ada 95 - matter of style

[Matthew Heaney]

"Simon Wright" <simon@pushface.org> wrote in message
news:x7vn0eu4iwc.fsf@smaug.pushface.org...
>
> It's not clear to me that this is a consequence of using tagged
> types?? perhaps .. anyway, what people complain about, until they've
> got used to it or developed a tool to generate the code for them, is
> the instantiating, not the taggedness.

But you have to perform the instantiation because the type you really need
is a derivation.  If there were no derivation (no inheritance), then there
would be no need for the second instantiation and the problem would
disappear.

The other issue is that iteration can only be done using a class-wide type,
which means all operations are dynamically bound.  Not only is this less
efficient, it is unnecessary, because all the types are known statically.

The only time it would make sense to use dynamic binding is if the type of
the container object weren't known until run-time.  But this is very
atypical.

There is also a space penalty, because each iterator object must also carry
a tag, in addition to the internal pointer.

Re: XML DOM Binding for Ada 95 - matter of style

[Matthew Heaney]

"Marin David Condic" <nobody@noplace.com> wrote in message
news:3F2BA9C8.9030700@noplace.com...
> So things like type extension don't count? :-)

The type extension exists in order to implement the dynamically bound
operation.


> I see tagged types as the way to fully implement the Object Oriented
> paradigm in Ada. Other mechanisms in Ada could be used to support parts
> of the OO paradigm - sometimes they have to be brutally flogged into
> that service - but none really creates the full OO paradigm as do tagged
> types.

Except for the private derivation needed to get controlledness, Charles
manages to be "object-oriented" without using inheritance.  There is no
brutal flogging.

In fact Charles could be ported to Ada83 without much pain.


> Not all programs require OO nor are they best expressed in the OO
> method. I work on software like that every day. But if you have an OO
> design, I'd think that trying to beat it into submission with the blunt
> instrument of a discriminated record is not the best approach. If it is
> an OO design, create an OO implementation with the correct Ada idiom for
> that - the tagged record and its surrounding package components.

Tagged types are one tool among many.  Use the tool that makes sense for
your problem.  If it's appropriate to use a tagged type, then by all means
do so.

Re: XML DOM Binding for Ada 95 - matter of style

[Ed Falis]

On Sat, 02 Aug 2003 14:46:36 GMT
"Matthew Heaney" <matthewjheaney@earthlink.net> wrote:

> Except for the private derivation needed to get controlledness,
> Charles manages to be "object-oriented" without using inheritance. 
> There is no brutal flogging.
> 

This is an interesting discussion.  I think part of it depends on how
extensively one uses inheritance to deal with variation.  For instance,
using Eiffel, with its (IMO) very expressive facilities for multiple
inheritance, one is likely to use inheritance more than one would in
Ada, which tends to leave a lot of plumbing hanging out to use the same
kind of style.

I had a very interesting experience in this regard only recently.  I
wanted to develop some test suites for a restricted Ada runtime system,
intended for DO-178B Level B applications.  I wanted to use AUnit for
it.  But when I wrote AUnit, I used an Eiffel-style lists package that
was implemented over tagged types: no way was it going to run in that
environment. I decided to try out Charles for the same purpose, and it
worked admirably.  No changes necessary.

- Ed

Re: XML DOM Binding for Ada 95 - matter of style

[Matthew Heaney]

"Marin David Condic" <nobody@noplace.com> wrote in message
news:3F2BA9C8.9030700@noplace.com...
>
> I see tagged types as the way to fully implement the Object Oriented
> paradigm in Ada.

To help convince you that inheritance-oriented programming is not the
solution to all problems, I suggest you read this interview with Stepanov:

http://www.stlport.org/resources/StepanovUSA.html

Here are the money quotes:

"I find OOP technically unsound. It attempts to decompose the world in terms
of interfaces that vary on a single type. To deal with the real problems you
need multisorted algebras - families of interfaces that span multiple types.
I find OOP philosophically unsound. It claims that everything is an object.
Even if it is true it is not very interesting - saying that everything is an
object is saying nothing at all. I find OOP methodologically wrong."

Asked what he thought of Java, he replied that "...It keeps all the stuff
that I never use in C++ - inheritance, virtuals - OO gook - and removes the
stuff that I find useful."

He says later that "...I spent years trying to find some use for inheritance
and virtuals, before I understood why that mechanism was fundamentally
flawed and should not be used."

Re: XML DOM Binding for Ada 95 - matter of style

[Dmitry A. Kazakov]

On Sun, 03 Aug 2003 16:42:26 GMT, "Matthew Heaney"
<matthewjheaney@earthlink.net> wrote:

>"Marin David Condic" <nobody@noplace.com> wrote in message
>news:3F2BA9C8.9030700@noplace.com...
>>
>> I see tagged types as the way to fully implement the Object Oriented
>> paradigm in Ada.
>
>To help convince you that inheritance-oriented programming is not the
>solution to all problems, I suggest you read this interview with Stepanov:
>
>http://www.stlport.org/resources/StepanovUSA.html
>
>Here are the money quotes:
>
>"I find OOP technically unsound. It attempts to decompose the world in terms
>of interfaces that vary on a single type. To deal with the real problems you
>need multisorted algebras - families of interfaces that span multiple types.
>I find OOP philosophically unsound. It claims that everything is an object.
>Even if it is true it is not very interesting - saying that everything is an
>object is saying nothing at all. I find OOP methodologically wrong."
>
>Asked what he thought of Java, he replied that "...It keeps all the stuff
>that I never use in C++ - inheritance, virtuals - OO gook - and removes the
>stuff that I find useful."
>
>He says later that "...I spent years trying to find some use for inheritance
>and virtuals, before I understood why that mechanism was fundamentally
>flawed and should not be used."

1. What Stepanov addresses is actually not OO, or better to say not
ADT, but its existing implementations in the languages like C++ and
Ada. 

2. Maybe dynamic polymorphism is flawed, but then the static has to be
as well.

3. To say that everything is object, was indeed silly, but this was
rather a mantra than a concept. I hope that nobody took it seriosly.
(:-)) Fortunately, presently one hears this rubbish not so frequently
as it was pair years ago.

I think that his decision to switch to macros (aka C++ templates) was
caused merely by the state of ADT, which was too underdeveloped then
and remains underdeveloped now. It is easy to see that "families of
interfaces" is again an interface and that "multiple types" constitute
a type [a class-wide type, many thanks to Ada for this clarification].
Anyway, what could be an alternative? An untyped language? Who wants
that again?

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

Re: XML DOM Binding for Ada 95 - matter of style

[Georg Bauhaus]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
: Anyway, what could be an alternative?

Signatures?

Re: XML DOM Binding for Ada 95 - matter of style

[Dmitry A. Kazakov]

On Tue, 5 Aug 2003 08:00:08 +0000 (UTC), Georg Bauhaus
<sb463ba@d2-hrz.uni-duisburg.de> wrote:

>Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>: Anyway, what could be an alternative?
>
>Signatures?

Isn't signature just another word for interface? Does not a set of
subroutines with compatible signatures constitute an interface for
some abstract/real type? One could long for a better way to describe
and manage interfaces, but there is no real alternative to them.

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

Re: XML DOM Binding for Ada 95 - matter of style

[Georg Bauhaus]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
: Isn't signature just another word for interface? Does not a set of
: subroutines with compatible signatures constitute an interface for
: some abstract/real type? One could long for a better way to describe
: and manage interfaces, but there is no real alternative to them.

You don't need to know about them during the design process,
but you can construct "signature instances" like so:

generic
  type X is private;
  function count(thing: X) return Natural;
  procedure stretch(thing: in out X);
...

and then instantiate "..." with whatever actuals seem fit.
This doesn't require that the provider of the units from which
X, count, etc. are taken, has to know beforehand that his/her types,
functions, or whatever will be used this way.

Actually, you can pass operations of a tagged type as actuals.
Can this be done with virtual member functions in C++?


Georg

Re: XML DOM Binding for Ada 95 - matter of style

[Marin David Condic]

You can use type extension without adding anything "dynamic" to a 
system. Its a perfectly good way of adding things to a record type that 
already exists. The "dynamic" part happens only if you are using 
dispatching in some way. AFAIK, you can add subprograms with a type 
extension that can be determined statically. They just can't be used as 
class-wide operations.

People have different styles. I don't object to discriminated records 
totally - it can be made to work and in some cases, it is a reasonable 
reflection of a given design. However, since Ada got tagged records and 
is capable of making classes, I think it has diminished the need for 
things like discriminated records because tagged records are so much 
more powerful and they address the same need. In the case of the XML 
DOM, I thought they were a more natural reflection of the design. You 
may have done it differently and it may work fine, but I don't think it 
lines up well with the intent of the DOM spec - at least not as well as 
tagged records would have.


MDC



Matthew Heaney wrote:
> 
> 
> The type extension exists in order to implement the dynamically bound
> operation.
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

Re: XML DOM Binding for Ada 95 - matter of style

[Marin David Condic]

I don't recall saying that inheritance-oriented programming is the 
solution to all problems. :-)

IIRC I said that I thought it was a better technique for reflecting the 
design of the XML DOM. I regularly work with software that does not use 
OOP and if it had to support inheritance, it would lead to unacceptable 
inefficiencies. That software is not "bad" by any definition of the 
word. I have used discriminated records in a wide variety of 
circumstances - including hard realtime apps. So I'm not a chauvanistic 
supporter of OOP or a total enemy of discriminated records. I just think 
they were the *wrong* implementation choice for the design under discussion.

MDC



Matthew Heaney wrote:
> "Marin David Condic" <nobody@noplace.com> wrote in message
> news:3F2BA9C8.9030700@noplace.com...
> 
>>I see tagged types as the way to fully implement the Object Oriented
>>paradigm in Ada.
> 
> 
> To help convince you that inheritance-oriented programming is not the
> solution to all problems, I suggest you read this interview with Stepanov:
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

Re: XML DOM Binding for Ada 95 - matter of style

[Dmitry A. Kazakov]

On Tue, 5 Aug 2003 13:34:09 +0000 (UTC), Georg Bauhaus
<sb463ba@d2-hrz.uni-duisburg.de> wrote:

>Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>: Isn't signature just another word for interface? Does not a set of
>: subroutines with compatible signatures constitute an interface for
>: some abstract/real type? One could long for a better way to describe
>: and manage interfaces, but there is no real alternative to them.
>
>You don't need to know about them during the design process,

Really?

>but you can construct "signature instances" like so:
>
>generic
>  type X is private;
>  function count(thing: X) return Natural;
>  procedure stretch(thing: in out X);
>...
>
>and then instantiate "..." with whatever actuals seem fit.
>This doesn't require that the provider of the units from which
>X, count, etc. are taken, has to know beforehand that his/her types,
>functions, or whatever will be used this way.

It is an illusion of freedom. In fact, from the specification above,
it is clear that X is private, i.e. has a default constructor, a copy
constructor, an assignment, count, stretch. So it is pretty much said
about possible X, and it is in fact an *interface*. Then when you
instantiate, the actual type is checked against that interface. Now,
how it differs from interface inheritance, except from techical
details? It does not.

Keep in mind, that present implementations of inheritance are very
limited in many aspects. You cannot create supertypes, disallow
methods, have by-value semantics, have multiple dispatch etc. I do not
argue that things like STL can be implemented without templates. What
I am saying is that it will be possible in the future with advantages
of being:

- safer
- clearer
- far more checkable
- as efficient as macros in static cases
- working in dynamic cases (with some bounded memory/time penalty)

>Actually, you can pass operations of a tagged type as actuals.

Yes, this is a great disadvantage of generics. You have to explicitly
specify everything you need. Compare it with inheritance, you just
specify a base type. This is because Ada's generics try to pretend to
have some contract. C++ does not, it openly says that what you become
is your own business. BTW, C++ is consistent in its approach:

int Something;
   // Maybe it has enough range to keep our values, launch and enjoy!

template <class Element>void Sort ...;
   // Guess, what I have used here this week, "<=" or ">="?

>Can this be done with virtual member functions in C++?

You mean to pass a dispatching operation to a template?

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

signature like constructions (was: Re: XML DOM Binding for Ada 95 - matter of style)

[Georg Bauhaus]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
: On Tue, 5 Aug 2003 13:34:09 +0000 (UTC), Georg Bauhaus
: <sb463ba@d2-hrz.uni-duisburg.de> wrote:
: 
:>Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
:>: Isn't signature just another word for interface? Does not a set of
:>: subroutines with compatible signatures constitute an interface for
:>: some abstract/real type? One could long for a better way to describe
:>: and manage interfaces, but there is no real alternative to them.
:>
:>You don't need to know about them during the design process,
 
: Really?

Yes. See below.
 
:>but you can construct "signature instances" like so:
:>
:>generic
:>  type X is private;
:>  function count(thing: X) return Natural;
:>  procedure stretch(thing: in out X);
:>...
:>
:>and then instantiate "..." with whatever actuals seem fit.
:>This doesn't require that the provider of the units from which
:>X, count, etc. are taken, has to know beforehand that his/her types,
:>functions, or whatever will be used this way.
: 
: It is an illusion of freedom. In fact, from the specification above,
: it is clear that X is private, i.e. has a default constructor, a copy
: constructor, an assignment, count, stretch. So it is pretty much said
: about possible X, and it is in fact an *interface*.

Uhm, that says something about the formals, but not everything about
the things you put inside the "signature package". If you have

generic
  type X is private;
  with function count(thing: X) return Natural;
package Foo is

  type Y is record
     nfrob: Natural;
     wrapped: X;
  end record;

  -- ...
  function calculate_mythical_number(item: Y) return Float;
  -- this is the interesting measure of all the incompatible
  -- X items in the world
end Foo;

Then when you instantiate, this package will offer an interface
to Y, in a general sense, because it is a natural thing for a
package to have one ;-). But ...

: instantiate, the actual type is checked against that interface.

Uhm, against that interface is not what I've had in mind, I think
I have failed to explain. So, instead, the interface is the "result"
of the "signature package" instantiation.

: how it differs from interface inheritance, except from techical
: details? It does not.

I think it does, if you think of this kind of interface.
Anything that can be used as actual for X (and count) can
be used without having to fit in some inheritance tree (or graph).
It can, but it _need_ not, which IIRC is the point of this kind
of "signature". You construct items that have some interface
by way of the subprograms of the *instance*. The provider of X
does _not_ have to know this.

:>Actually, you can pass operations of a tagged type as actuals.
: 
: Yes, this is a great disadvantage of generics. You have to explicitly
: specify everything you need.

In view of the above, how is this a disadvantage?

In another view, if you want something, call it T, that can be
compared to another T, or which needs to be hashed, then the
generic actuals for comparison or hashing need not be associated
with T, which I find can be an advantage. The provider of T does not
have to make T "comparable" or "hashable" by adding operations
to T.


:>Can this be done with virtual member functions in C++?
: 
: You mean to pass a dispatching operation to a template?

Exactly. (This way, you get a collection of virtual
"service routines" from actual parameters, which
can be used to provide the functionality needed in the package's
subprograms.)


Georg

Re: signature like constructions (was: Re: XML DOM Binding for Ada 95 - matter of style)

[Dmitry A. Kazakov]

On Wed, 6 Aug 2003 18:15:03 +0000 (UTC), Georg Bauhaus
<sb463ba@d2-hrz.uni-duisburg.de> wrote:

>Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>: On Tue, 5 Aug 2003 13:34:09 +0000 (UTC), Georg Bauhaus
>: <sb463ba@d2-hrz.uni-duisburg.de> wrote:
>: 
>:>Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>:>: Isn't signature just another word for interface? Does not a set of
>:>: subroutines with compatible signatures constitute an interface for
>:>: some abstract/real type? One could long for a better way to describe
>:>: and manage interfaces, but there is no real alternative to them.
>:>
>:>You don't need to know about them during the design process,
> 
>: Really?
>
>Yes. See below.

Iiterally read - no interfaces needed in a design process! Maybe, you
meant a hacking process. (:-)) 

>:>but you can construct "signature instances" like so:
>:>
>:>generic
>:>  type X is private;
>:>  function count(thing: X) return Natural;
>:>  procedure stretch(thing: in out X);
>:>...
>:>
>:>and then instantiate "..." with whatever actuals seem fit.
>:>This doesn't require that the provider of the units from which
>:>X, count, etc. are taken, has to know beforehand that his/her types,
>:>functions, or whatever will be used this way.
>: 
>: It is an illusion of freedom. In fact, from the specification above,
>: it is clear that X is private, i.e. has a default constructor, a copy
>: constructor, an assignment, count, stretch. So it is pretty much said
>: about possible X, and it is in fact an *interface*.
>
>Uhm, that says something about the formals, but not everything about
>the things you put inside the "signature package". If you have
>
>generic
>  type X is private;
>  with function count(thing: X) return Natural;
>package Foo is
>
>  type Y is record
>     nfrob: Natural;
>     wrapped: X;
>  end record;
>
>  -- ...
>  function calculate_mythical_number(item: Y) return Float;
>  -- this is the interesting measure of all the incompatible
>  -- X items in the world
>end Foo;
>
>Then when you instantiate, this package will offer an interface
>to Y, in a general sense, because it is a natural thing for a
>package to have one ;-). But ...

How this is better than (if were possible)

type X is abstract ...;
function count (thing: X) return Natural is abstract;

type Y is record
   nfrob : Natural;
   wrapped : X'Class;
end record;

You claim that different X are incompatible, but have you asked
yourself, to what they are? The interface tells nothing about it. On
the contrary it tells how they *are* compatible, they all are
copyable, have "count" etc. Now the only incompatibility is a
limitation that a class-wide object cannot be a member. But this has
nothing to do with interfaces. It is an implementation detail. And
after all why not:

type Y is new X with record
   nfrob : Natural;
end record;

>: instantiate, the actual type is checked against that interface.
>
>Uhm, against that interface is not what I've had in mind, I think
>I have failed to explain. So, instead, the interface is the "result"
>of the "signature package" instantiation.

I hope you do not propose "write-first" approach. (:-)) Interface is
not a result, it is the starting point when we are thinking about a
program. You can either formalize it in the code if a language helps,
or leave it for a reader to try to figure interface out.

>: how it differs from interface inheritance, except from techical
>: details? It does not.
>
>I think it does, if you think of this kind of interface.
>Anything that can be used as actual for X (and count) can
>be used without having to fit in some inheritance tree (or graph).

If you use it, then it fits. If it does not, then you cannot use it.
It is no matter whether you state it explicitly or implicitly. But it
well matters for a reader.

>It can, but it _need_ not, which IIRC is the point of this kind
>of "signature". You construct items that have some interface
>by way of the subprograms of the *instance*. The provider of X
>does _not_ have to know this.

I do not see any difference. With inheritance the provider does not
know whether you derive or not. Instantiation can be viewed as sort of
inheritance from some implicitly declared abstract type with a
consequent type cloning (to avoid mixing of siblings).

>:>Actually, you can pass operations of a tagged type as actuals.
>: 
>: Yes, this is a great disadvantage of generics. You have to explicitly
>: specify everything you need.
>
>In view of the above, how is this a disadvantage?

My generic package implementing fuzzy numbers has about 30 formal
parameters.

>In another view, if you want something, call it T, that can be
>compared to another T, or which needs to be hashed, then the
>generic actuals for comparison or hashing need not be associated
>with T, which I find can be an advantage. The provider of T does not
>have to make T "comparable" or "hashable" by adding operations
>to T.

My point is, "to provide a function to compare" = "to make
comparable". It is SAME.

You might object, that one should foresee whether a type should be
comparable or that making comparable is "global". This all are just
limitations of ADT implementations we presently have. For example,
with supertyping and multiple inheritance you can always make one
given type a subtype of another given type.

>:>Can this be done with virtual member functions in C++?
>: 
>: You mean to pass a dispatching operation to a template?
>
>Exactly. (This way, you get a collection of virtual
>"service routines" from actual parameters, which
>can be used to provide the functionality needed in the package's
>subprograms.)

But a class-wide parameter already does the trick.

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

Re: XML DOM Binding for Ada 95 - matter of style

[Matthew Heaney]

"Georg Bauhaus" <sb463ba@d2-hrz.uni-duisburg.de> wrote in message
news:bgoboh$pae$1@a1-hrz.uni-duisburg.de...
> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>
> You don't need to know about them during the design process,
> but you can construct "signature instances" like so:
>
> generic
>   type X is private;
>   function count(thing: X) return Natural;
>   procedure stretch(thing: in out X);
> ...
>
> and then instantiate "..." with whatever actuals seem fit.

This is exactly how the generic algorithms in Charles work.  Something like:

generic
   type Iterator_Type is private;
   with function Succ (I : Iterator_Type) return Iterator_Type is <>;
   with function Is_Less (L, R : Iterator_Type) return Boolean is <>;
  ...
function Generic_O (First, Back : Iterator_Type)
  return Iterator_Type;

There are only a few algorithms in there, because I'm still busy working on
the containers.


> This doesn't require that the provider of the units from which
> X, count, etc. are taken, has to know beforehand that his/her types,
> functions, or whatever will be used this way.

To a point.  But often, you design a type anticipating that that type will
the used as a generic actual.  For example, in Charles, all the iterator
types (indeed, all the containers) have an identical interface (meaning that
all the operation names are the same).  This allows you pass "default"
subprogram actuals, e.g.

function Op is new Generic_Op (Iterator_Type);
--This works because Succ and Is_Less are directly
--visible at the point of instantiation.


> Actually, you can pass operations of a tagged type as actuals.
> Can this be done with virtual member functions in C++?

Well, yes and no.  You can dispatch on the operation, which would be the
only point of doing it, e.g.

generic
   type T (<>) is abstract tagged limited private;
   with function Op (O : in T) is <>;
procedure Generic_Dispatch (O : in T'Class);

procedure Generic_Dispatch (O : in T'Class) is
begin
  Op (O);   --illegal
end;

To do generic dispatching, you have to use a trick, um, I mean "technique,"
which involves passing a class-wide operation instead:

generic
   type T (<>) is limited private;
   with procedure Op (O : in T) is <>;
procedure Generic_Dispatch (O : in T) is
begin
   Op (O);
end;

Now suppose we have a tagged type:

package P is
   type T is tagged limited null record;
   procedure Op (O : T); --primitive
end;

Somehow we'd like to pass an object of type T'Class as a parameter to the
instantion, and dispatch Op.  The way to do this is create a little wrapper
subprogram for Op:

procedure P.Call_Op (O : in T'Class) is
begin
   Op (O); --dispatches
end;

Now we have everything we need to instantiation generic op.  The solution to
the problem is to pass type T'Class as the generic actual type:

procedure Dispatch is
   new Generic_Dispatch (T => T'Class, Op => Call_Op);

Now when we do this:

procedure Op2 (O : T'Class) is
begin
   Dispatch (O);
end;

then the primitive operation Op will dispatch according to the tag of O.

Re: XML DOM Binding for Ada 95 - matter of style

[Matthew Heaney]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:egd1jvc6pe888e4ug683tis6a5q5ua12ml@4ax.com...
> On Tue, 5 Aug 2003 13:34:09 +0000 (UTC), Georg Bauhaus
> <sb463ba@d2-hrz.uni-duisburg.de> wrote:
>
> >Actually, you can pass operations of a tagged type as actuals.
>
> Yes, this is a great disadvantage of generics. You have to explicitly
> specify everything you need.

This is a feature, not a flaw.  The Ada generics were deliberately designed
this way, because you get better error checking.


> Compare it with inheritance, you just
> specify a base type.  This is because Ada's generics try to pretend to
> have some contract.

I don't know what you mean by "pretend" to have a contract: Ada generics do
have a contract.  In fact it's called the "generic contract model."

> C++ does not, it openly says that what you become
> is your own business.

Well, yes and no.  You don't just design ex nihilo, but with the expection
that the generic actual type will have a specific set of operations, even if
those operations are only loosely specified.

> template <class Element>void Sort ...;
>    // Guess, what I have used here this week, "<=" or ">="?

No.  Sort will only use operator<.  It will never use operator<= or
operator>=, because those can be derived from the canonical operator<.

You should always define relational operators in terms of the less-than
operatior:

function "<" (L, R : T) return Boolean is ...;

function ">" (L, R : T) return Boolean is
begin
   return R < L;
end;

function ">=" (L, R : T) return Boolean is
begin
   return not (L < R);
end;

function ">=" (L, R : T) return Boolean is
begin
   return R <= L;
end;

In the STL and in Charles, you even use the less-then operator for computing
"equivalence" of keys:

function Is_Equivalent (L, R : T) return Boolean is
begin
   return not (L < R) and not (R < L);
end;

The equality operator "=" for elements is only used to compute the value of
container equality.


> >Can this be done with virtual member functions in C++?
>
> You mean to pass a dispatching operation to a template?

I showed how to do this in Ada in a previous post.

Re: XML DOM Binding for Ada 95 - matter of style

[Dmitry A. Kazakov]

On Thu, 07 Aug 2003 12:52:44 GMT, "Matthew Heaney"
<matthewjheaney@earthlink.net> wrote:

>"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>news:egd1jvc6pe888e4ug683tis6a5q5ua12ml@4ax.com...
>> On Tue, 5 Aug 2003 13:34:09 +0000 (UTC), Georg Bauhaus
>> <sb463ba@d2-hrz.uni-duisburg.de> wrote:
>>
>> >Actually, you can pass operations of a tagged type as actuals.
>>
>> Yes, this is a great disadvantage of generics. You have to explicitly
>> specify everything you need.
>
>This is a feature, not a flaw.  The Ada generics were deliberately designed
>this way, because you get better error checking.

Yes. Better error checking is because of a better contract
specification. Flaw is that with generics one cannot inherit the
contract and extend/modify it. There are actually two ways to make
something close to that:

1. To define a generic package with "interface" functions and pass its
instance as formal parameter to another generic package.

2. To use child generic packages.

Both are far not so flexible and easy to use as classical interface
inheritance.

>> Compare it with inheritance, you just
>> specify a base type.  This is because Ada's generics try to pretend to
>> have some contract.
>
>I don't know what you mean by "pretend" to have a contract: Ada generics do
>have a contract.  In fact it's called the "generic contract model."

A very limited one. There are many things, which cannot be [precisely]
specified in the contract. For example, you cannot have user-defined
type classes, you have to stick to the predefined ones, like "(<>)",
"range <>", "mod <>", "private". There are problems with information
hiding when generics are used. etc

Anyway, if one wish to argue for generics against tagged types, one
should rather consider C++ templates. All (mosty mythical) advantages
over tagged types appear when one departs from the contract model.
Stricter we make contracts lesser difference we will notice. As a
prophecy, in the end, tagged types will completely supersede generics.

>> C++ does not, it openly says that what you become
>> is your own business.
>
>Well, yes and no.  You don't just design ex nihilo, but with the expection
>that the generic actual type will have a specific set of operations, even if
>those operations are only loosely specified.
>
>> template <class Element>void Sort ...;
>>    // Guess, what I have used here this week, "<=" or ">="?
>
>No.  Sort will only use operator<.  It will never use operator<= or
>operator>=, because those can be derived from the canonical operator<.

The contract states neither this nor otherwise. It is a clear flaw.
One could argue that it is an advantage, because "every reasonable
programmer would make so", but then I would argue that one need no
type system at all, because "every reasonable programmer will never
mix incompatible types".

>You should always define relational operators in terms of the less-than
>operatior:
>
>function "<" (L, R : T) return Boolean is ...;
>
>function ">" (L, R : T) return Boolean is
>begin
>   return R < L;
>end;
>
>function ">=" (L, R : T) return Boolean is
>begin
>   return not (L < R);
>end;
>
>function ">=" (L, R : T) return Boolean is
>begin
>   return R <= L;
>end;
>
>In the STL and in Charles, you even use the less-then operator for computing
>"equivalence" of keys:
>
>function Is_Equivalent (L, R : T) return Boolean is
>begin
>   return not (L < R) and not (R < L);
>end;
>
>The equality operator "=" for elements is only used to compute the value of
>container equality.

How does this support templates?

However this is a point for future Ada revisions. If the compiler
derives "/=" from "=", why doesn't it for "<"? Similar thing is
commutative operations like "+" and "*". One could wish to derive
"+"  (Left : Y; Right : X) from "+"  (Left : X; Right : Y) instead of
a geometric explosion of specifications in case of many types.

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

Re: signature like constructions

[Georg Bauhaus]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
Newsgroups: comp.lang.ada
References: <slrnbihv85.4jd.randhol+abuse@kiuk0152.chembio.ntnu.no>   <apGWa.1581$jp.254@newsread4.news.pas.earthlink.net> <3F2BA9C8.9030700@noplace.com> <SXaXa.5251$jg7.4768@newsread3.news.pas.earthlink.net> <ti3sivgstvvmh3j7399j0prvlifsm8j5it@4ax.com> <bgno68$lpd$1@a1-hrz.uni-duisburg.de> <qp5viv8jdbasoc2s83hrrv0f4mtfvp0mnn@4ax.com> <bgoboh$pae$1@a1-hrz.uni-duisburg.de> <egd1jvc6pe888e4ug683tis6a5q5ua12ml@4ax.com> <bgrgj7$38u$1@a1-hrz.uni-duisburg.de> <jr24jv8sdug2s1ru7kf6vkspj8kh9oltvj@4ax.com>
Organization: GMUGHDU
User-Agent: tin/1.5.8-20010221 ("Blue Water") (UNIX) (HP-UX/B.11.00 (9000/831))

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
:>:>You don't need to know about them during the design process,
:> 
:>: Really?
:>
:>Yes. See below.
: 
: Iiterally read - no interfaces needed in a design process! Maybe, you
: meant a hacking process. (:-)) 

Why should I add hash(x: Point) to the interface of a 2D point?
In the generics case, the "interface of the type", and the "interface
of the package instance" need not be too closely coupled.
Hashing can be provided elsewhere.
(Matthew Heaney has explained that you might anticipate possible
uses of your types, but do I have to expect and design my (x, y) pairs
so that they can become part of a data structure that requires a
hash value for them? Just to stay in inheritance land?)

:>generic
:>  type X is private;
:>  with function count(thing: X) return Natural;
:>package Foo is
:>
:>  type Y is record
:>     nfrob: Natural;
:>     wrapped: X;
:>  end record;
:>
:>  -- ...
:>  function calculate_mythical_number(item: Y) return Float;
:>  -- this is the interesting measure of all the incompatible
:>  -- X items in the world
:>end Foo;
:>
:>Then when you instantiate, this package will offer an interface
:>to Y, in a general sense, because it is a natural thing for a
:>package to have one ;-). But ...
: 
: How this is better than (if were possible)

: type X is abstract ...;
: function count (thing: X) return Natural is abstract;

It is better because it is possible :-)

: You claim that different X are incompatible, but have you asked
: yourself, to what they are? The interface tells nothing about it. On
: the contrary it tells how they *are* compatible, they all are
: copyable, have "count" etc.

No. Count need not be an operation of X. It might as well be implemented
elsewhere, for example using two inquiry functions from the "interface"
of the actual for X, or three from another, unrelated actual.

Also,

generic
  type X is private;
  type Y is private;
  with function between(this_one: X; that_one: Y) return Float;
package ...

How do I do this using your next example, and do it in Ada, that is,
not in CLOS, Smalltalk, or Haskell, with MI of interfaces?

: type Y is new X with record
:   nfrob : Natural;
: end record;

:>Uhm, against that interface is not what I've had in mind, I think
:>I have failed to explain. So, instead, the interface is the "result"
:>of the "signature package" instantiation.
: 
: I hope you do not propose "write-first" approach. (:-)) Interface is
: not a result, it is the starting point when we are thinking about a
: program.

I design the "signature package", which has the interface
I want (mostly after the keyword "package"). The focus is not 
necessarily on the formal type's restrictions.

:>Anything that can be used as actual for X (and count) can
:>be used without having to fit in some inheritance tree (or graph).
: 
: If you use it, then it fits.

It need not even be of a tagged type, so why will it fit?
And if you consider X and Y above, they need not be part of the same
type tree.

Say we had full MI. Would you prefer to to have

  type T is new X and Y with private;  -- not Ada
  function between(combined: T) return Float;

and then name clash resolution all over the place?

 
:>:>Actually, you can pass operations of a tagged type as actuals.
:>: 
:>: Yes, this is a great disadvantage of generics. You have to explicitly
:>: specify everything you need.
:>
:>In view of the above, how is this a disadvantage?
: 
: My generic package implementing fuzzy numbers has about 30 formal
: parameters.

Your type will have about 30 things delcared, too, won't it?
(I'm not advocating the replacement of OO with generics BTW,
just trying to point out that you can, conceptually, escape the
type hierarchy using generics, and then use the instance's
subprograms, thinking of them as an interface.)

: My point is, "to provide a function to compare" = "to make
: comparable". It is SAME.
: 
: You might object, that one should foresee whether a type should be
: comparable or that making comparable is "global".

Indeed I will will be forced to foresee this in Ada.

: This all are just
: limitations of ADT implementations we presently have. For example,
: with supertyping and multiple inheritance you can always make one
: given type a subtype of another given type.

Some Questions:

AFAICS, there might be multiple inheritance of interfaces, but not MI
in Ada 200X?

If I don't want to see but three operation of type X, and two of Y,
how can I limit the visibility of the others?
Use export lists like in Eiffel?

How about libraries without the possibility of changing the base types?



Georg

Re: signature like constructions

[Dmitry A. Kazakov]

On Thu, 7 Aug 2003 16:22:34 +0000 (UTC), Georg Bauhaus
<sb463ba@d2-hrz.uni-duisburg.de> wrote:

>Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>Newsgroups: comp.lang.ada
>References: <slrnbihv85.4jd.randhol+abuse@kiuk0152.chembio.ntnu.no>   <apGWa.1581$jp.254@newsread4.news.pas.earthlink.net> <3F2BA9C8.9030700@noplace.com> <SXaXa.5251$jg7.4768@newsread3.news.pas.earthlink.net> <ti3sivgstvvmh3j7399j0prvlifsm8j5it@4ax.com> <bgno68$lpd$1@a1-hrz.uni-duisburg.de> <qp5viv8jdbasoc2s83hrrv0f4mtfvp0mnn@4ax.com> <bgoboh$pae$1@a1-hrz.uni-duisburg.de> <egd1jvc6pe888e4ug683tis6a5q5ua12ml@4ax.com> <bgrgj7$38u$1@a1-hrz.uni-duisburg.de> <jr24jv8sdug2s1ru7kf6vkspj8kh9oltvj@4ax.com>
>Organization: GMUGHDU
>User-Agent: tin/1.5.8-20010221 ("Blue Water") (UNIX) (HP-UX/B.11.00 (9000/831))
>
>Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>:>:>You don't need to know about them during the design process,
>:> 
>:>: Really?
>:>
>:>Yes. See below.
>: 
>: Iiterally read - no interfaces needed in a design process! Maybe, you
>: meant a hacking process. (:-)) 
>
>Why should I add hash(x: Point) to the interface of a 2D point?

You should not.

>In the generics case, the "interface of the type", and the "interface
>of the package instance" need not be too closely coupled.
>Hashing can be provided elsewhere.

No you create a *new* interface derived from one of 2D point. It is
absolutely same as you do with instantiations:

A. Declaration of an interface:

1a. Generics:

generic
   type X is private;
   procedure Hash (Item : X); -- X has Hash
procedure Foo (Item : X); -- Foo uses Hash

This describes an interface or a class of types having Hash. It also
declares a class-wide (works for all class) procedure Foo.

2a. Tagged:

   type X is abstract tagged ...;
   procedure Hash (Item : X) is abstract; -- X has Hash
   procedure Foo (Item : X'Class); -- Foo uses Hash

This also describes an interface. X'Class is a closure of a class of
types having Hash. Foo is a class-wide procedure.

B. Use of an interface:

type Point_2D is ...;

1b. Generics:

procedure Hash (Item : Point_2D);
procedure NewFoo is new Foo (X, Hash);

This makes Point2D an element of the class and instantiates Foo.

2b.  Tagged (non-Ada!)

type Hashed_Point_2D is new subtype X and supertype Point_2D;
procedure Hash (Item : Hashed_Point_2D);

This creates a new interface from two interfaces of Point_2D and of X.
Hashed_Point_2D is both a subtype of X and a supertype of Point_2D, so
Point_2D in effect becomes a subtype of X in the scope of
Hashed_Point_2D. And thus Foo can be called on Point_2D in that scope.

>(Matthew Heaney has explained that you might anticipate possible
>uses of your types, but do I have to expect and design my (x, y) pairs
>so that they can become part of a data structure that requires a
>hash value for them? Just to stay in inheritance land?)

Of course no, it should be dynamic, see above.

>:>generic
>:>  type X is private;
>:>  with function count(thing: X) return Natural;
>:>package Foo is
>:>
>:>  type Y is record
>:>     nfrob: Natural;
>:>     wrapped: X;
>:>  end record;
>:>
>:>  -- ...
>:>  function calculate_mythical_number(item: Y) return Float;
>:>  -- this is the interesting measure of all the incompatible
>:>  -- X items in the world
>:>end Foo;
>:>
>:>Then when you instantiate, this package will offer an interface
>:>to Y, in a general sense, because it is a natural thing for a
>:>package to have one ;-). But ...
>: 
>: How this is better than (if were possible)
>
>: type X is abstract ...;
>: function count (thing: X) return Natural is abstract;
>
>It is better because it is possible :-)

Hey, I have already said that STL is presently impossible with tagged
types! Stepanov's point quoted by Matthew was that ADT is *inherently*
flawed and unsuitable for generic (class-wide) programming. My point
is that generic programming could and should be done without generics
using class-wide types instead.

>: You claim that different X are incompatible, but have you asked
>: yourself, to what they are? The interface tells nothing about it. On
>: the contrary it tells how they *are* compatible, they all are
>: copyable, have "count" etc.
>
>No. Count need not be an operation of X. It might as well be implemented
>elsewhere, for example using two inquiry functions from the "interface"
>of the actual for X, or three from another, unrelated actual.

Count is an operation of X if it takes an argument of X.

>Also,
>
>generic
>  type X is private;
>  type Y is private;
>  with function between(this_one: X; that_one: Y) return Float;
>package ...
>
>How do I do this using your next example, and do it in Ada, that is,
>not in CLOS, Smalltalk, or Haskell, with MI of interfaces?

That is multiple dispatch, it has to be supported.

>: type Y is new X with record
>:   nfrob : Natural;
>: end record;
>
>:>Uhm, against that interface is not what I've had in mind, I think
>:>I have failed to explain. So, instead, the interface is the "result"
>:>of the "signature package" instantiation.
>: 
>: I hope you do not propose "write-first" approach. (:-)) Interface is
>: not a result, it is the starting point when we are thinking about a
>: program.
>
>I design the "signature package", which has the interface
>I want (mostly after the keyword "package"). The focus is not 
>necessarily on the formal type's restrictions.

But you have to have some picture in mind, which types should work
with the package. The set of all those types is a type class. Its
closure is a class-wide type. Description of its root type is an
interface.

>:>Anything that can be used as actual for X (and count) can
>:>be used without having to fit in some inheritance tree (or graph).
>: 
>: If you use it, then it fits.
>
>It need not even be of a tagged type, so why will it fit?

Every specific type has to be a tagged type, even Boolean. Tagged here
means that Boolean'Class has a tag, Boolean itself has no tag.
Embedded tags was a mistake.

>And if you consider X and Y above, they need not be part of the same
>type tree.

With multiple dispatch you can dispatch on type tuples.

>Say we had full MI. Would you prefer to to have
>
>  type T is new X and Y with private;  -- not Ada
>  function between(combined: T) return Float;
>
>and then name clash resolution all over the place?

Generics have more problems with that, because they rely on
overloading, which is far less controllable than overriding [could
be].

>:>:>Actually, you can pass operations of a tagged type as actuals.
>:>: 
>:>: Yes, this is a great disadvantage of generics. You have to explicitly
>:>: specify everything you need.
>:>
>:>In view of the above, how is this a disadvantage?
>: 
>: My generic package implementing fuzzy numbers has about 30 formal
>: parameters.
>
>Your type will have about 30 things delcared, too, won't it?

No, the number comes from a geometric explosion of signatures when
several interfaces are mixed:

1. plain number
2. interval
3. fuzzy set

With proper ADT I could just use that interfaces which exist anyway.
The problem is that generic interfaces cannot be reused in new
interfaces.

>(I'm not advocating the replacement of OO with generics BTW,
>just trying to point out that you can, conceptually, escape the
>type hierarchy using generics, and then use the instance's
>subprograms, thinking of them as an interface.)

This is a traditional vew, which I disagree. Sets of subprograms
constitute type interfaces no matter whether you declare it
explicitly. A type hierarchy also exists independently on our wishes.
Types are related, and a binary relation is a graph.

>: My point is, "to provide a function to compare" = "to make
>: comparable". It is SAME.
>: 
>: You might object, that one should foresee whether a type should be
>: comparable or that making comparable is "global".
>
>Indeed I will will be forced to foresee this in Ada.
>
>: This all are just
>: limitations of ADT implementations we presently have. For example,
>: with supertyping and multiple inheritance you can always make one
>: given type a subtype of another given type.
>
>Some Questions:
>
>AFAICS, there might be multiple inheritance of interfaces, but not MI
>in Ada 200X?

It is difficult to believe in. See below.

>If I don't want to see but three operation of type X, and two of Y,
>how can I limit the visibility of the others?

Operation disallowing.

>Use export lists like in Eiffel?
>
>How about libraries without the possibility of changing the base types?

One could specify that a particular operation cannot be overriden.

---
The actual problem is that we know very little about future ADT.
Before we start to implement MI, MD, supertyping, op-disallowing etc
in Ada, we should clearly understand how it supposed to work. We
cannot just make Ada++ and leave programmers with that. It should be
consistent, easy to understand and efficient.

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

Re: signature like constructions

[Robert I. Eachus]

Dmitry A. Kazakov wrote:

> The actual problem is that we know very little about future ADT.
> Before we start to implement MI, MD, supertyping, op-disallowing etc
> in Ada, we should clearly understand how it supposed to work. We
> cannot just make Ada++ and leave programmers with that. It should be
> consistent, easy to understand and efficient.

I definitely agree, but I think you are heading in the wrong direction. 
  Multiple inheritance of interfaces will probably be a feature of 
Ada0Y, but the issues being discussed in this article will not be 
'fixed' by interface inheritance.  It is the old saw about if all you 
have is a hammer, every problem starts to look like a nail.  But since 
Ada already offers several different fasteners, part of the solution has 
to be educating users.

Let's look at the example from the right perspective.  The problem is 
not "I need to be able to associate hash values with 2D points."  That 
is a solution.  The problem statement/requirement looks something like:

The system shall have a representation of cartesian points with 
assoicated data for...

There shall a method to create sets of cartesian points.

There shall be an efficient method to determine if a particular point is 
a member of a set...

Now we are getting some meat to deal with.  Three issues should 
immediately come to mind, and should be resolved in the requirements stage:

Can the co-ordinates of the cartesian point objects vary?  If so, how do 
you determine the identity of an object?

Can a particular cartesian point be a member of more than one set?  If 
so, is there a limit on how many sets it can be a member of?

Is there any requirement to easily determine whether a point is not a 
member of a particular set?

The answer to the first question leads to two different potential 
solutions.  It should be obvious that if the point's co-ordinates can 
change without losing its identity, the hash value, if that is the 
solution chosen, must be precalculated and stored in the object.  Or the 
hash value has to be based on some other attribute of the object which 
doesn't change, perhaps its address.

The second question deals with a issue going the other direction.  If an 
object can be a member of several different sets, then any solution that 
embeds the links in the cartesian point objects will be at best, a kludge.

The third question is one of assumptions.  If the author of the 
requirements has a hash table implementation in mind, then there may be 
a 'hidden' requirement.  There may be an algorithm where affirmatively 
determining membership is easy but the negation is hard.  For example, 
if you use a small number of hash values pointing at linked lists, then 
the time to determine an element is not there will on average be twice 
what it is to determine that it is there.  Of course, you can maintain 
the lists in sorted order, and the average times will be the same.

In fact you could go the other way.  Have two hash functions.  (For this 
example assume that the 'real' hash function omits the last five bits.) 
  Now the fine grained hash maps to a bit vector.  If the corresponding 
bit is off, the point is not in the set.  If it is set, then you have to 
walk the linked list.  Now the average response to a query is much 
faster when the point is not in the set.  If you don't ask the right 
question, you won't know which implementation is preferred.

Only after you have resolved these requirements issues is it possible to 
decide what are the best data structures and relationships to use.  It 
may be that there is a "better" solution in some language other than Ada.

I got sick 20 years ago of playing the game where someone would design a 
problem to show off the superiority of some language or other.  Then I 
would propose a better solution, usually stated in Ada, and they would 
go back to the drawing board to fix the problem statement.  The people 
who played this game never figured out that I would always win.  Not 
because Ada was a superior programming language, but because I was able 
to look at the problem WITHOUT going through the filter of a particular 
programming language.  Of course, from their point of view, "and it must 
be programmed in C" would be cheating on their part.  But since I and 
others forced to play the game were much better at finding the right 
algorithms and data structures because we didn't limit ourselves to a 
single programming view.

My favorite example involved the LALR parser generator on Multics.  Pat 
Prange was about to go through the gory effort to allow an array of 
Boolean data to span multiple segments.  I asked why he didn't use a 
packed representation, and he answered at length.  But once we got all 
the requirements written down, it turned out that the major operation on 
the array was a search in a particular row for the first set bit.  After 
another half hour of discussion Pat ran off to implement the new 
version.  To make a long story short, it used the translate and test 
instruction in the character string processing unit.  The single 
instruction generated used a 512-element table to look up the first 
non-zero (9-bit) byte detected, and of course the values in the table 
were the index of the first set bit.  Six lines of PL/I carefully 
written so the code generator would emit a single instruction!

The net result was to decrease the running time for the tool by over 
90%, from just over 20 minutes to generate an optimized LALR1 parser for 
Ada, to just under two minutes.  But the point to take away is not that 
PL/I was great for this purpose, or Multics.  I could write the same 
code in COBOL for an IBM mainframe, or C for an x86 or 680x0 chip. (Or 
in Ada, or just about any language that let you get close to the metal 
when necessary.) The expertise required is in first figuring out the 
actual machine code you want generated, then knowing the compiler 
internals well enough to make it happen.

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

Re: signature like constructions

[Dmitry A. Kazakov]

On Fri, 08 Aug 2003 10:12:47 GMT, "Robert I. Eachus"
<rieachus@attbi.com> wrote:

>Dmitry A. Kazakov wrote:
>
>> The actual problem is that we know very little about future ADT.
>> Before we start to implement MI, MD, supertyping, op-disallowing etc
>> in Ada, we should clearly understand how it supposed to work. We
>> cannot just make Ada++ and leave programmers with that. It should be
>> consistent, easy to understand and efficient.
>
>I definitely agree, but I think you are heading in the wrong direction. 

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

>  Multiple inheritance of interfaces will probably be a feature of 
>Ada0Y, but the issues being discussed in this article will not be 
>'fixed' by interface inheritance.  It is the old saw about if all you 
>have is a hammer, every problem starts to look like a nail.  But since 
>Ada already offers several different fasteners, part of the solution has 
>to be educating users.
>
>Let's look at the example from the right perspective.  The problem is 
>not "I need to be able to associate hash values with 2D points."  That 
>is a solution.  The problem statement/requirement looks something like:
>
>The system shall have a representation of cartesian points with 
>assoicated data for...
>
>There shall a method to create sets of cartesian points.
>
>There shall be an efficient method to determine if a particular point is 
>a member of a set...

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. (:-))

>Now we are getting some meat to deal with.  Three issues should 
>immediately come to mind, and should be resolved in the requirements stage:
>
>Can the co-ordinates of the cartesian point objects vary?  If so, how do 
>you determine the identity of an object?

Points as objects usually have no identity. Why should they have any?
One of real problems of OO is overuse of objects with identity.

>Can a particular cartesian point be a member of more than one set?  If 
>so, is there a limit on how many sets it can be a member of?
>
>Is there any requirement to easily determine whether a point is not a 
>member of a particular set?
>
>The answer to the first question leads to two different potential 
>solutions.  It should be obvious that if the point's co-ordinates can 
>change without losing its identity, the hash value, if that is the 
>solution chosen, must be precalculated and stored in the object.  Or the 
>hash value has to be based on some other attribute of the object which 
>doesn't change, perhaps its address.
>
>The second question deals with a issue going the other direction.  If an 
>object can be a member of several different sets, then any solution that 
>embeds the links in the cartesian point objects will be at best, a kludge.
>
>The third question is one of assumptions.  If the author of the 
>requirements has a hash table implementation in mind, then there may be 
>a 'hidden' requirement.  There may be an algorithm where affirmatively 
>determining membership is easy but the negation is hard.  For example, 
>if you use a small number of hash values pointing at linked lists, then 
>the time to determine an element is not there will on average be twice 
>what it is to determine that it is there.  Of course, you can maintain 
>the lists in sorted order, and the average times will be the same.
>
>In fact you could go the other way.  Have two hash functions.  (For this 
>example assume that the 'real' hash function omits the last five bits.) 
>  Now the fine grained hash maps to a bit vector.  If the corresponding 
>bit is off, the point is not in the set.  If it is set, then you have to 
>walk the linked list.  Now the average response to a query is much 
>faster when the point is not in the set.  If you don't ask the right 
>question, you won't know which implementation is preferred.
>
>Only after you have resolved these requirements issues is it possible to 
>decide what are the best data structures and relationships to use.  It 
>may be that there is a "better" solution in some language other than Ada.

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

>I got sick 20 years ago of playing the game where someone would design a 
>problem to show off the superiority of some language or other.  Then I 
>would propose a better solution, usually stated in Ada, and they would 
>go back to the drawing board to fix the problem statement.  The people 
>who played this game never figured out that I would always win.  Not 
>because Ada was a superior programming language, but because I was able 
>to look at the problem WITHOUT going through the filter of a particular 
>programming language.  Of course, from their point of view, "and it must 
>be programmed in C" would be cheating on their part.  But since I and 
>others forced to play the game were much better at finding the right 
>algorithms and data structures because we didn't limit ourselves to a 
>single programming view.
>
>My favorite example involved the LALR parser generator on Multics.  Pat 
>Prange was about to go through the gory effort to allow an array of 
>Boolean data to span multiple segments.  I asked why he didn't use a 
>packed representation, and he answered at length.  But once we got all 
>the requirements written down, it turned out that the major operation on 
>the array was a search in a particular row for the first set bit.  After 
>another half hour of discussion Pat ran off to implement the new 
>version.  To make a long story short, it used the translate and test 
>instruction in the character string processing unit.  The single 
>instruction generated used a 512-element table to look up the first 
>non-zero (9-bit) byte detected, and of course the values in the table 
>were the index of the first set bit.  Six lines of PL/I carefully 
>written so the code generator would emit a single instruction!
>
>The net result was to decrease the running time for the tool by over 
>90%, from just over 20 minutes to generate an optimized LALR1 parser for 
>Ada, to just under two minutes.  But the point to take away is not that 
>PL/I was great for this purpose, or Multics.  I could write the same 
>code in COBOL for an IBM mainframe, or C for an x86 or 680x0 chip. (Or 
>in Ada, or just about any language that let you get close to the metal 
>when necessary.) The expertise required is in first figuring out the 
>actual machine code you want generated, then knowing the compiler 
>internals well enough to make it happen.

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.

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

Re: signature like constructions

[Robert I. Eachus]

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

Re: signature like constructions

[Alexander Kopilovitch]

Dmitry A. Kazakov wrote:

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

And certainly will always prevail. Essentially, by definition: if the software
world becomes more significant than traditional real world -:) then there will
be just new class of the problems - concerning the software world, and no more
than that. So we'll still look at the problems at first.

> allowing to implement "everything [problem] in anything [language]".

No, this is too inexact statement: even 3 decades ago it was not possible
to implement real-time control program in RPG language. So, not in "anything",
but in "any universal language" - and with this more precise wording the
statement becomes trivially true.

> But in a long-term perspective, I am talking about 20-100 years,

20 years ago no one can predict our current power of computing technology and
its presence everywhere in just 2000. Given that the explosion still continues,
how can you guess about 20 and even 100 future years?

> the balance
> will definitely change, otherwise we will be unable to maintain the
> complexity of software [not the algorithms, note].

What we will unable to maintain will certainly crash. And we will not make
such too complex software any more (after several attempts with sound failures).
That's simple. Just the same reasons as for not to build a 100km-high tower.

> It will be a
> virtual reality with its own virtual problems, if you wish. (:-))

Well, virtual reality is not so big challenge actually. Even nanotechnologies
constitute substantially bigger challenge, because they may easily ruin much
more our "axioms of impossible", which may appear vital for our implicit logic.



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

Re: signature like constructions

[Alexander Kopilovitch]

Robert I. Eachus wrote:

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

Do you mean that the "Paradise may be regained"... if not for average programmer
then at least for an average star -:) ? That is, that by training yourself
in that direction, and keeping your nerve, it is possible to follow even
rapidly and rather randomly changing requirements with proper documentation
and analysis in real time, inside a not very friendly environment?

Do you mean that the common defensive strategy against probable but unpredictable
changes of requirements -- that is, keeping yourself not too near to them, and
more relying upon agreed tools (which seem less vulnerable for spontaneuos
customer's or management's dances) -- is not the best strategy, and that it is
really possible to chase a moving/jumping problem, all the time at near distance,
without significant delay?

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

You have seen the miracles being used more that in one or two cases -- so you
are lucky. I think that most of us feel that the miracles, if happen, will be
most probably betrayed. That's why "Adding an understanding of ISAs and machine
architecture to that is very rare" indeed.



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

Re: signature like constructions

[Robert I. Eachus]

Alexander Kopilovitch wrote:

> Do you mean that the "Paradise may be regained"... if not for average programmer
> then at least for an average star -:) ? That is, that by training yourself
> in that direction, and keeping your nerve, it is possible to follow even
> rapidly and rather randomly changing requirements with proper documentation
> and analysis in real time, inside a not very friendly environment?

No, I mean that I have worked directly on projects that could not have 
been completed without rigorous control over the (evolving) 
requirements.  You have to have religion, or something.  One of my 
favorite examples was a project actually written in Ada, but that is 
almost a detail.  The original schedule called for a three year 
development cycle, in C and assembler.  Two years in, that group 
admitted total failure. I'll get back to why in a minute.

Another group volunteered to take over the project and do it in 11 
months to meet the original schedule--if they could use Ada and modern 
software development methods.  They got the go ahead on a plan which 
called for six months of requirements analysis and design, two months of 
detailed design, two months of coding and one of testing.  At the end of 
detailed design, eight months in, they decided that a significant 
portion of the original design need to be scrapped and redone.  They 
finished coding a week behind schedule, but completed the formal testing 
in two days--the test suite has been developed as part of the entire 
process, and coded by a separate test group within the project.

The manager in charge called it management by heart attack.  It is one 
thing to logically accept that starting coding too early will be a 
disaster, but to finally start coding in the ninth month of an eleven 
month project can stress a manager out.  But it works.  In fact the rest 
of the operating system that it was part of slipped three  months, so 
that all of the features that had been postponed to version two were in 
there when it released.  But they actually formally did keep those 
additions as a second version in the configuration management system, 
and tell marketing that they would get it all when release two was ready 
but nothing before then. That allowed the first version kept bug free 
during beta test under version control so they didn't get involved in 
fighting fires.

I said I would get back to why the first group failed.  They actually 
had a "working" system at one point.  But it had some major bugs, and 
every bug fix created more bugs than it fixed.  The system as a whole 
had too much coupling.  In other words this subsystem was too big for 
the project management tools and methods they were using.  As for the 
Ada version?  The interfaces between the various modules and 
sub-components were all defined in less than one thousand lines of Ada 
package specifications.  All of the bodies, except one that got near 650 
lines were under five-hundred lines long.  Each package came with a test 
program for that package, and was unit tested before being put under 
version control.  Is it any wonder that the system ran the first time 
with only minor errors left to fix.  (There were 17 bugs found in system 
testing.  Fourteen of them were misspellings, poor punctuation or 
missing accents in the foreign language messages.  The program had a 
localization package that supported US, British, French, German, 
Spanish, and Italian.  Most of the complaints during the beta testing 
was about Quebecois usage from French testers. Release 2 made French 
Canadian a separate localization file. ;-)

> Do you mean that the common defensive strategy against probable but unpredictable
> changes of requirements -- that is, keeping yourself not too near to them, and
> more relying upon agreed tools (which seem less vulnerable for spontaneuos
> customer's or management's dances) -- is not the best strategy, and that it is
> really possible to chase a moving/jumping problem, all the time at near distance,
> without significant delay?

No.  If you don't understand the real requirements, you will get blind 
sided again and again during development.  But if you do the work to 
"develop" the requirements, you simply won't have that problem.  Another 
project which was actually for the same OS release as the project above, 
resulted in an even better example.  It was a menu subsystem to provide 
a consistent look and feel to all of the office automation packages. 
(This was for the Honeywell DPS6, Mod 400 release 3.)  There was a 
two-day review to decide if the product was ready for release.  This was 
more than just a did it meet the requirements review.  At these reviews, 
marketing could and did on occasion sent the software "back to the 
drawing boards.  Not because it did not meet the agreed requirements but 
because marketing thought they couldn't sell it in the current market 
environment.

During the first day the marketing team realized that it would be nice 
if there was a standard option just for backing out of transactions, as 
well as the key that took you to the top of the current menu hierarchy. 
  This wasn't considered a show stopper, but marketing wanted an 
estimate on the cost of adding the feature.  The review finished early 
on the second day, and they were going over action items.  The manager 
of the project was able to tell them that the changes had been made, a 
new version compiled overnight, and was now on its way to the 
Distribution and Test group for their blessing.  In the meantime, it had 
been installed on one of the test machines if they wanted to check it out.

You might think that the developers had anticipated this change request 
and had it all designed in.  But that wasn't how it worked.  Since the 
main requirement for the subsystem was to present a consistent interface 
to the user, the design of the system was a rule based engine that 
generated the screens.  The change to the code was three lines, because 
the system did model the problem space.  Something like:

      if In_Transaction
      then Bind_Key(F6, Exit_Transaction);
      end if;

(It was only three lines because there was already a "cancel 
transaction" entry in the localization files.  But if the new messages 
had to be added to the localization files, it still would not have been 
a big deal.)

You can see how designing the system from the getgo to model the problem 
space meant that there were not hundreds of different menu templates 
that needed to be changed.  Since the REAL requirement was for a 
consistent user interface, designing the system this way meant that 
consistency was automatic.

> You have seen the miracles being used more that in one or two cases -- so you
> are lucky. I think that most of us feel that the miracles, if happen, will be
> most probably betrayed. That's why "Adding an understanding of ISAs and machine
> architecture to that is very rare" indeed.

And I have also seen disasters where this sort of discipline was 
necessary due to the scope of the project, but was not put in place.  In 
fact I may finally get around to publishing that paper.  (Basically how 
to tell when the project is dead beyond all hope of recovery from 
analyzing the reports in the bug tracking system.  The earlier you can 
determine that a project will fail, the less money you waste.)

As for the miracle approach, on one very large project, I had to 
determine if the money should be spent at all.  Relatively quickly I 
determined that the success or failure of the radar upgrade would depend 
on whether a particular problem could be solved.  We called it the 
formation flight problem, but it could be a lot of airliners on the same 
course between beacons at the same speed, or a dozen other sorts of 
coincidences.  The proposed solution was to partition the target 
detections into clusters then resolve each cluster separately.  Of 
course this would have to be done in real-time in a few milliseconds 
before the next set of pulse doppler data arrived.  At the end of six 
months I couldn't prove that the partitioning could be done in the time 
available, or that it couldn't.  But I did find a way to solve the 
problem without partitioning the data, so the contract was awarded.

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

Re: signature like constructions

[Simon Wright]

"Robert I. Eachus" <rieachus@attbi.com> writes:

> My favorite example involved the LALR parser generator on Multics.
> Pat Prange was about to go through the gory effort to allow an array
> of Boolean data to span multiple segments.  I asked why he didn't
> use a packed representation, and he answered at length.  But once we
> got all the requirements written down, it turned out that the major
> operation on the array was a search in a particular row for the
> first set bit.  After another half hour of discussion Pat ran off to
> implement the new version.  To make a long story short, it used the
> translate and test instruction in the character string processing
> unit.  The single instruction generated used a 512-element table to
> look up the first non-zero (9-bit) byte detected, and of course the
> values in the table were the index of the first set bit.  Six lines
> of PL/I carefully written so the code generator would emit a single
> instruction!
> 
> The net result was to decrease the running time for the tool by over
> 90%, from just over 20 minutes to generate an optimized LALR1 parser
> for Ada, to just under two minutes.  But the point to take away is
> not that PL/I was great for this purpose, or Multics.  I could write
> the same code in COBOL for an IBM mainframe, or C for an x86 or
> 680x0 chip. (Or in Ada, or just about any language that let you get
> close to the metal when necessary.) The expertise required is in
> first figuring out the actual machine code you want generated, then
> knowing the compiler internals well enough to make it happen.

At some point you need (a) a machine-independent solution to the
problem, (b) a machine-dependent optimisation. Clearly it's good if
the machine-independent solution is also efficient, but it seems to me
like overkill to write 6 very clever lines in the hope that the
compiler (and future revisions) will always emit one machine code
instruction. Why not use an assembler insert?

Re: signature like constructions

[Robert I. Eachus]

Simon Wright wrote:

> At some point you need (a) a machine-independent solution to the
> problem, (b) a machine-dependent optimisation. Clearly it's good if
> the machine-independent solution is also efficient, but it seems to me
> like overkill to write 6 very clever lines in the hope that the
> compiler (and future revisions) will always emit one machine code
> instruction. Why not use an assembler insert?

The LALR tool was used by Honeywell to make compiler front ends.  If 
others in the compiler group made a change to the Multics PL/I compiler 
that would break it, it would be regarded as a serious bug that would 
prevent the new compiler version from being installed in the development 
hierarchy, let alone as part of a shipping compiler.

I guess it is just a different way of thinking when you are part of the 
compiler development team.  For example, any changes I make to my code 
that is part of GNAT will only pass the regression tests if it compiles 
and runs correctly on all supported systems.  Similarly, I can count on 
any code that works once and makes it into GNAT working always because 
it will be part of the regression test suite.  It is not a joke that the 
automated regression test  suite, which may take hours to run, is one of 
the most valuable tools a compiler group has.  In many cases it would 
cost less to recreate a compiler from scratch, given the regression 
suite, than to create a new set of regression tests and the tools to run 
them.

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

Re: signature like constructions

[Alexander Kopilovitch]

Robert I. Eachus wrote:

> One of my 
> favorite examples was a project actually written in Ada, but that is 
> almost a detail.  The original schedule called for a three year 
> development cycle, in C and assembler.  Two years in, that group 
> admitted total failure. I'll get back to why in a minute.
>
> Another group volunteered to take over the project and do it in 11 
> months to meet the original schedule--if they could use Ada and modern 
> software development methods.  They got the go ahead on a plan which 
> called for six months of requirements analysis and design, two months of 
> detailed design, two months of coding and one of testing.  At the end of 
> detailed design, eight months in, they decided that a significant 
> portion of the original design need to be scrapped and redone.  They 
> finished coding a week behind schedule, but completed the formal testing 
> in two days--the test suite has been developed as part of the entire 
> process, and coded by a separate test group within the project.
>
> The manager in charge called it management by heart attack.  It is one 
> thing to logically accept that starting coding too early will be a 
> disaster, but to finally start coding in the ninth month of an eleven 
> month project can stress a manager out.  But it works.  In fact the rest 
> of the operating system that it was part of slipped three  months, so 
> that all of the features that had been postponed to version two were in 
> there when it released.  But they actually formally did keep those 
> additions as a second version in the configuration management system, 
> and tell marketing that they would get it all when release two was ready 
> but nothing before then. That allowed the first version kept bug free 
> during beta test under version control so they didn't get involved in 
> fighting fires.

Just curious about the difference or similarity between the cultures: from my
former Soviet experience (I have seen somehow similar cases, although possibly
of lesser scale) I can guess that that too successful group was rewarded,
praised and then dissolved for they could never repeat such unnatural
performances any more. Was the outcome the same (or similar) in the case?
Or this group was permitted to exist for years after that performance?


> During the first day the marketing team realized that it would be nice 
> if there was a standard option just for backing out of transactions, as 
> well as the key that took you to the top of the current menu hierarchy. 
>   This wasn't considered a show stopper, but marketing wanted an 
> estimate on the cost of adding the feature.  The review finished early 
> on the second day, and they were going over action items.  The manager 
> of the project was able to tell them that the changes had been made, a 
> new version compiled overnight, and was now on its way to the 
> Distribution and Test group for their blessing.  In the meantime, it had 
> been installed on one of the test machines if they wanted to check it out.
>
> You might think that the developers had anticipated this change request 
> and had it all designed in.  But that wasn't how it worked.  Since the 
> main requirement for the subsystem was to present a consistent interface 
> to the user, the design of the system was a rule based engine that 
> generated the screens.  The change to the code was three lines, because 
> the system did model the problem space.

Note, though, that relying upon specific tools - such as problem-oriented
languages (SNOBOL, APL, COBOL, Fortran, Prolog etc.) or libraries is actually
a "poor man solution" for the desire to operate in the problem space. I mean
that if you can't obtain (or even "develop") more or less precise and stable
requirements, and even worse, you can't go deep into the real problem (all that
is common case), and therefore you can't develop proper custom representation
of the problem space, the best strategy may be to rely upon the tools already
widely used for that class of problems. With this strategy you have at least
good chance for operating not too far from the proper problem space (because
the tools will bring you there).


> > You have seen the miracles being used more that in one or two cases -- so you
> > are lucky. I think that most of us feel that the miracles, if happen, will be
> > most probably betrayed. That's why "Adding an understanding of ISAs and machine
> > architecture to that is very rare" indeed.
>
> And I have also seen disasters where this sort of discipline was 
> necessary due to the scope of the project, but was not put in place.  In 
> fact I may finally get around to publishing that paper.  (Basically how 
> to tell when the project is dead beyond all hope of recovery from 
> analyzing the reports in the bug tracking system.  The earlier you can 
> determine that a project will fail, the less money you waste.)

Well, if you actually publish that paper then, perhaps, it will be rare case
of a text about programming for which I believe that Russian translation is
desirable -;)



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

Re: signature like constructions

[Robert I. Eachus]

Alexander Kopilovitch wrote:

> Just curious about the difference or similarity between the cultures: from my
> former Soviet experience (I have seen somehow similar cases, although possibly
> of lesser scale) I can guess that that too successful group was rewarded,
> praised and then dissolved for they could never repeat such unnatural
> performances any more. Was the outcome the same (or similar) in the case?
> Or this group was permitted to exist for years after that performance?

After they finished the second version with all the features that were 
postponed out of the first, they were asked to take on another project 
in trouble, but this time write it in C.  The group manager laid 
resignations from all the members of the group on his manager's desk, 
with his on top.  So they got permission to use Ada.

About that time I got a "godfather" offer from another company, so I 
left.  (I while I was saying I'd have to check with my wife, they raised 
the offer by 10% and threw in some additional stock options.)

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

Re: signature like constructions

[Dmitry A. Kazakov]

On 8 Aug 2003 16:44:04 -0700, aek@vib.usr.pu.ru (Alexander
Kopilovitch) wrote:

>Dmitry A. Kazakov wrote:
>
>> 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,
>
>And certainly will always prevail. Essentially, by definition: if the software
>world becomes more significant than traditional real world -:) then there will
>be just new class of the problems - concerning the software world, and no more
>than that. So we'll still look at the problems at first.

OK, but those problems are not ones we presently count for real.

>> allowing to implement "everything [problem] in anything [language]".
>
>No, this is too inexact statement: even 3 decades ago it was not possible
>to implement real-time control program in RPG language. So, not in "anything",
>but in "any universal language" - and with this more precise wording the
>statement becomes trivially true.

What we count for "universal" is changing, depending on which problems
are of "universal" concern.

I give you a funny example. One student was unable to tell me how to
calculate a distance between two points in cartesian co-ordinates! He
naturally knew nothing about Euclidean distance, space etc. Now the
most amazing thing. This student had successfuly modified a
3D-simulation program in OpenGL! (:-))

It is a catastrophe, would you say. Yes, but it is also a triumph of
software developing tools. Let me foretell that new generations of
programmes will even know nothing about arithmetics! (:-))

>> But in a long-term perspective, I am talking about 20-100 years,
>
>20 years ago no one can predict our current power of computing technology and
>its presence everywhere in just 2000. Given that the explosion still continues,
>how can you guess about 20 and even 100 future years?

I can guess the plume of that explosion ...

>> the balance
>> will definitely change, otherwise we will be unable to maintain the
>> complexity of software [not the algorithms, note].
>
>What we will unable to maintain will certainly crash. And we will not make
>such too complex software any more (after several attempts with sound failures).

This will stop nobody. There are much worse things people are doing,
being well aware of the consequences.

>That's simple. Just the same reasons as for not to build a 100km-high tower.

That tower is already built. Its name is internet! (:-))

>> It will be a
>> virtual reality with its own virtual problems, if you wish. (:-))
>
>Well, virtual reality is not so big challenge actually. Even nanotechnologies
>constitute substantially bigger challenge, because they may easily ruin much
>more our "axioms of impossible", which may appear vital for our implicit logic.

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

Re: signature like constructions

[Dmitry A. Kazakov]

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

Re: signature like constructions

[Alexander Kopilovitch]

>>> allowing to implement "everything [problem] in anything [language]".
>>
>>No, this is too inexact statement: even 3 decades ago it was not possible
>>to implement real-time control program in RPG language. So, not in "anything",
>>but in "any universal language" - and with this more precise wording the
>>statement becomes trivially true.
>
>What we count for "universal" is changing, depending on which problems
>are of "universal" concern.

Not so conformistic, I think. Perhaps you underestimate the generality and
deepness of the works of logicians and "founding fathers" of programming
(like Turing and other great names). I can agree that all their stuff may
seem somehow "basic only" at first sight, but this impression will quickly
fade and disappear if you try to make an alternative yourself.

>I give you a funny example. One student was unable to tell me how to
>calculate a distance between two points in cartesian co-ordinates! He
>naturally knew nothing about Euclidean distance, space etc. Now the
>most amazing thing. This student had successfuly modified a
>3D-simulation program in OpenGL! (:-))

No problem with that. Well, for a native English speaker the spoken language
appears before the written language, but for foreigner the sequence is usually
reverse. (For example. because of this I can communicate in written English
-- well, with many errors, but still usually succesfully -- but I can't say so
about my spoken English. So, an "phonetically illiterate" foreigner differs
radically from an illiterate native speaker -:) .

So for that you student. While for us the Euclidean distance appeared before
3D-simulation and OpenGL, for that student the sequence is opposite -- surely,
if he will continue his works with 3D-simulation and OpenGL, he inevitably
will learn about Euclidean distance, sooner or later.

>It is a catastrophe, would you say. Yes, but it is also a triumph of
>software developing tools.

No more than public success of some good book on cooking is a catastrophe for
biochemisrty -:)

> Let me foretell that new generations of
>programmes will even know nothing about arithmetics! (:-))

Well, there was a short novel about exactly that, by famous science fiction
writer Isaac Asimov. In fact, that was probably the first Asimov's novel
published in Soviet Union (in early sixties, I think), and it immediately made
Asimov well-known in Soviet scientific circles (at least among physicists).
In that novel, in far future the Earth is involved in endless war with another
civilization; on both sides humans forgot arithmetics long ago, and the war is
totally computerized; the problem is that the computers on both sides appeared
"synchronized" -- they develop and upgrade themselves at the same speed, so
nobody can win, and the war can't go to the end. The hero of the novel re-invents
arithmetics from scratch, and the President becomes happy with new perspective
-- to escape the deadlock and defeat the enemy using this non-conventional way.

>>What we will unable to maintain will certainly crash. And we will not make
>>such too complex software any more (after several attempts with sound failures).
>
>This will stop nobody. There are much worse things people are doing,
>being well aware of the consequences.

Well, than it will crash. Don't worry -;) , just don't stay under it -:)

>
>>That's simple. Just the same reasons as for not to build a 100km-high tower.
>
>That tower is already built. Its name is internet! (:-))

Why do you think so? Do you think the same about radio, TV, phones? Perhaps
you were too much impressed by unprecedented freedom in Internet... well this
time is almost over, the freedom in Internet will surely decrease to a normal
level quite soon (although not so much as some governments dream now -- thanks
China -:).



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

Re: signature like constructions

[Dmitry A. Kazakov]

On 11 Aug 2003 07:59:12 -0700, aek@vib.usr.pu.ru (Alexander
Kopilovitch) wrote:

>>>> allowing to implement "everything [problem] in anything [language]".
>>>
>>>No, this is too inexact statement: even 3 decades ago it was not possible
>>>to implement real-time control program in RPG language. So, not in "anything",
>>>but in "any universal language" - and with this more precise wording the
>>>statement becomes trivially true.
>>
>>What we count for "universal" is changing, depending on which problems
>>are of "universal" concern.
>
>Not so conformistic, I think. Perhaps you underestimate the generality and
>deepness of the works of logicians and "founding fathers" of programming
>(like Turing and other great names). I can agree that all their stuff may
>seem somehow "basic only" at first sight, but this impression will quickly
>fade and disappear if you try to make an alternative yourself.

These basics are not concern. Compare this with the basics of
mathematics. There are lot of problems with that, yet 99.9% of people
using mathematics just do not care. Not because they are ignorant.
They have other problems to solve.

>>I give you a funny example. One student was unable to tell me how to
>>calculate a distance between two points in cartesian co-ordinates! He
>>naturally knew nothing about Euclidean distance, space etc. Now the
>>most amazing thing. This student had successfuly modified a
>>3D-simulation program in OpenGL! (:-))
>
>No problem with that. Well, for a native English speaker the spoken language
>appears before the written language, but for foreigner the sequence is usually
>reverse. (For example. because of this I can communicate in written English
>-- well, with many errors, but still usually succesfully -- but I can't say so
>about my spoken English. So, an "phonetically illiterate" foreigner differs
>radically from an illiterate native speaker -:) .
>
>So for that you student. While for us the Euclidean distance appeared before
>3D-simulation and OpenGL, for that student the sequence is opposite -- surely,
>if he will continue his works with 3D-simulation and OpenGL, he inevitably
>will learn about Euclidean distance, sooner or later.

I think that the analogy is invalid. OpenGL cannot supersede analytic
geometry. I would say that one can play an electic piano, knowing
nothing about electricity.

>>It is a catastrophe, would you say. Yes, but it is also a triumph of
>>software developing tools.
>
>No more than public success of some good book on cooking is a catastrophe for
>biochemisrty -:)

To me it is a disaster. I understand Rober Eachus, how can someone
write a program without any understanding of the underlying problem?
In fact, one can and will. That's the dawn of an industrial age of
programming. (:-()

>> Let me foretell that new generations of
>>programmes will even know nothing about arithmetics! (:-))
>
>Well, there was a short novel about exactly that, by famous science fiction
>writer Isaac Asimov. In fact, that was probably the first Asimov's novel
>published in Soviet Union (in early sixties, I think), and it immediately made
>Asimov well-known in Soviet scientific circles (at least among physicists).
>In that novel, in far future the Earth is involved in endless war with another
>civilization; on both sides humans forgot arithmetics long ago, and the war is
>totally computerized; the problem is that the computers on both sides appeared
>"synchronized" -- they develop and upgrade themselves at the same speed, so
>nobody can win, and the war can't go to the end. The hero of the novel re-invents
>arithmetics from scratch, and the President becomes happy with new perspective
>-- to escape the deadlock and defeat the enemy using this non-conventional way.

Happy end. (:-)) But the true story is that re-invented arithmetics
did not help them. See Matrix movie paraphrasing the anecdote about
Sergeant and banana - all problems can solved merely by jumping higher
than others could. (:-))

>>>What we will unable to maintain will certainly crash. And we will not make
>>>such too complex software any more (after several attempts with sound failures).
>>
>>This will stop nobody. There are much worse things people are doing,
>>being well aware of the consequences.
>
>Well, than it will crash. Don't worry -;) , just don't stay under it -:)

Exactly! (:-))

>>>That's simple. Just the same reasons as for not to build a 100km-high tower.
>>
>>That tower is already built. Its name is internet! (:-))
>
>Why do you think so?

It is an example of how a very bad technology could serve a great
purpose. Just because of its size it could take years to collapse.
Like in the old Roman empire, generations may come and go and not
notice that it falls.

> Do you think the same about radio, TV, phones? Perhaps
>you were too much impressed by unprecedented freedom in Internet... well this
>time is almost over, the freedom in Internet will surely decrease to a normal
>level quite soon (although not so much as some governments dream now -- thanks
>China -:).

Thanks to RIAA! I can expect communists fighting freedom of speech,
but Mickey Mouse? Indeed, history repeats twice ...

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

Re: signature like constructions

[Alexander Kopilovitch]

Dmitry A. Kazakov wrote:

>>>I give you a funny example. One student was unable to tell me how to
>>>calculate a distance between two points in cartesian co-ordinates! He
>>>naturally knew nothing about Euclidean distance, space etc. Now the
>>>most amazing thing. This student had successfuly modified a
>>>3D-simulation program in OpenGL! (:-))
>>
>>No problem with that. Well, for a native English speaker the spoken language
>>appears before the written language, but for foreigner the sequence is usually
>>reverse. (For example. because of this I can communicate in written English
>>-- well, with many errors, but still usually succesfully -- but I can't say so
>>about my spoken English. So, an "phonetically illiterate" foreigner differs
>>radically from an illiterate native speaker -:) .
>>
>>So for that you student. While for us the Euclidean distance appeared before
>>3D-simulation and OpenGL, for that student the sequence is opposite -- surely,
>>if he will continue his works with 3D-simulation and OpenGL, he inevitably
>>will learn about Euclidean distance, sooner or later.
>
>I think that the analogy is invalid. OpenGL cannot supersede analytic
>geometry.

If you think that written English supersedes spoken English (and even for
those who cannot reproduce proper sounds from written words) then you are
wrong, sad to say. It may be true or almost true for very poor English, but
no more than that.

> I would say that one can play an electic piano, knowing
>nothing about electricity.

If API is comprehensive and needed library functions are supplied as smoothly
as electricity then why not? Well, I'll try to explain why that is not enough:
You may be unaware about electricity and still play an electric piano succesfully,
but for that you must be aware of music. That is, you must somehow understand
your problem domain - music. You must know something about tunes, tones,
durations etc. So for OpenGL applications: your student will recognize that
he must learn Euclidean distance when he discovers that without it he can't
understand enough 3D-something problems he is facing. Very annoying situation,
indeed: you are ready to solve the problem, but you can't get what is needed;
you customer is surely ignorant and idiot for he can't give you problem statement
in proper (suitable for OpenGL) terms, and he is talking all the time about
those damned distances... but money is on his side, and you are facing the
bitter choice: either learn distances or lose opportunity of earning money.


>>> Let me foretell that new generations of
>>>programmes will even know nothing about arithmetics! (:-))
>>
>>Well, there was a short novel about exactly that, by famous science fiction
>>writer Isaac Asimov. In fact, that was probably the first Asimov's novel
>>published in Soviet Union (in early sixties, I think), and it immediately made
>>Asimov well-known in Soviet scientific circles (at least among physicists).
>>In that novel, in far future the Earth is involved in endless war with another
>>civilization; on both sides humans forgot arithmetics long ago, and the war is
>>totally computerized; the problem is that the computers on both sides appeared
>>"synchronized" -- they develop and upgrade themselves at the same speed, so
>>nobody can win, and the war can't go to the end. The hero of the novel re-invents
>>arithmetics from scratch, and the President becomes happy with new perspective
>>-- to escape the deadlock and defeat the enemy using this non-conventional way.
>
>Happy end. (:-))

Not so happy - at the end of the novel the inventor committed suicide when
became aware of that his invention will be used exclusively for military
purposes.

> But the true story is that re-invented arithmetics
>did not help them. See Matrix movie paraphrasing the anecdote about
>Sergeant and banana - all problems can solved merely by jumping higher
>than others could. (:-))

I think that public referencing of the Matrix movie is inappropriate in any
context which isn't related to mass entertainment. Let's differentiate good
science fiction from something like mental beer. (Why such a strong reaction?
Just because you implied that reader should have seen that movie, so you
became an agent of it.)

>>>>That's simple. Just the same reasons as for not to build a 100km-high tower.
>>>
>>>That tower is already built. Its name is internet! (:-))
>>
>>Why do you think so?
>
>It is an example of how a very bad technology could serve a great
>purpose.

Quite strange claim (about "very bad technology"), I think. Certainly, one can
list many drawbacks of current Internet technologies (thus don't do that here.
please -:) , but knowing that the current Internet as a whole could not be
*designed* anyway, I can't understand any blames of this kind.

Besides that, what a strange criteria for "good" and "bad" you must use for
that your claim. The Internet succeeded in many aspects, it was adopted worldwide,
and that its spreading takes effectively less than two decades. Well, I would
understand if someone says that automobile technology is very bad because it
claims hundreds of thousands lives worldwide every year... or that smoking
technology is bad - for similar reasons; but I don't see any great harm directly
caused by that Internet technology.



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