Is the Writing on the Wall for Ada?

Is the Writing on the Wall for Ada?

[Warren W. Gay VE3WWG]

This is not a troll... but I am soliciting some opinion.

I read a disturbing article in the July COTS Journal recently,
and thought I would bounce the controversial aspects off
of the group. The complete article can be read at:

  http://www.cotsjournalonline.com/pdfs/2003/07/COTS07_softside.pdf

I have quoted some of the sections for ease of discussion below:

From Article:

  Softer Side: Java in the Military
  Java Proving Itself Worthy for Defense Apps
  July 2003 COTS Journal [ 27 ]

...

Navy's Open Architecture
========================

**** <highlight> ****

Among the key motivations for the military's interest in Java is a drive
to transition away from Ada.

**** </highlight> ****

The feeling is that Java represents a modern and more commercially
available technology than alternatives. The Navy, for example, is
drafting their Navy Open Architecture Computing Environment (NOACE) to
be the standard for all future software systems on Navy warships. That
includes shipboard weapon systems, such as anti-aircraft cannon controls
as well as avionics systems aboard naval aircraft. The standard calls
for all new software to develop in either C++ or Java, and makes
specific mention of moving away from Ada. They plan to continue to use
Ada only as required to support legacy systems that have already been
developed.

...

Moving Away from Ada
====================

For its part, Boeing has also expressed a clear preference to move
toward Java. Winner of the lead system integrator contract on for U.S.
Army's Future Combat Systems (FCS) program, Boeing is farming out their
FCS requirements and telling suppliers they want to use Java, they don't

  **** <highlight> ****

like C++ and they don't like Ada for any new system development. Many

  **** </highlight> ****

suppliers to FCS are therefore tasked to convert reams of Ada code over
to Java.

There are some basic human resources reasons why Java is a preferred
approach. Today's new graduates from college are 99% more likely to know
Java than any other programming language. And among experienced
programmers out in the workforce, more will tend to highlight Java on
their resume rather than Ada. The ranks of true Ada gurus are probably
comprised more of programmers near retirement than otherwise.

</quote>


SOME OBSERVATIONS:
==================

I have seen many quotes here in comp.lang.ada and other web sources
that only the mandate to use Ada has been dropped. The position that
is usually made is that Ada is still considered on a project by
project basis, where it makes sense.

However, if the above article is accurate, it seems that the U.S.
military (and Boeing) is making a conscious effort to move away from Ada.
The article is suggesting that the only reason to use Ada now would
be for legacy systems. Boeing apparently does not want to use Ada
in any new development.

CONCLUSION:

Whether or not you agree with the reasoning in the article, the
disturbing thing in my mind is the "mindset". If the military and big
industrial companies like Boeing turn their back on Ada, where is Ada
headed for in the future? Is there enough other momentum to keep Ada
(and GNAT) going into the foreseeable future?

I attended a small Real-Time conference last week in Toronto, and I only
heard the name Ada  mentioned once, and in a negative way
(in passing reference WRT Real-Time Java). None of the vendors there
that I talked to were using Ada for their SBC and the one vendor
for flight systems told me they simply do not have the customer
demand for Ada systems.

So: Is the writing on the wall for Ada?

What is your take on the article?
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Is the Writing on the Wall for Ada?

[Wes Groleau]

Warren W. Gay VE3WWG wrote:
> What is your take on the article?

My take is that I'm glad I'm getting out of software.

-- 
Wes Groleau
Genealogical Lookups:  http://groleau.freeshell.org/ref/lookups.html

Re: Is the Writing on the Wall for Ada?

[Russ]

"Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> wrote in message news:<NGs6b.10770$Pa1.519789@read1.cgocable.net>...
> This is not a troll... but I am soliciting some opinion.
> 
> I read a disturbing article in the July COTS Journal recently,
> and thought I would bounce the controversial aspects off
> of the group. The complete article can be read at:
> 
>   http://www.cotsjournalonline.com/pdfs/2003/07/COTS07_softside.pdf

Thanks for posting this link. I've been trying to wake the Ada
community up to this reality for a while. I work in air traffic
management, a "traditional" Ada stronghold, and I sense firsthand that
Ada may even be dying even there. I had taken solace in the fact that
Boeing seemed to be sticking with Ada, but according to the article
even that is evaporating. Also, I have some contact with a high-level
academic consortium called the High Dependability Computing Program
(HDCP), and Ada barely registers on their radar screen. They all seem
to use Java.

Personally, I like Ada, and I think its a shame that it seems to be
getting short shrift. I consider Ada to be fundamentally solid, and I
don't understand why it is not considered young and sexy anymore. Then
again, I am a very independent thinker, and I am willing to ignore
fads.

Here are the main problems I see with Java:

First of all, Java forces everything into the "object-oriented" mold
whether it fits or not. As far as I am concerned, that's just tacky.
Another problem with Java is that it requires that *all* instances of
user-defined types be put on the heap. That's a heap of crap. Java has
no "generics" or "templates" either. The other deficiency of Java
compared to Ada is that it has no separately compiled specification
files, which are invaluable for large system integration, as you all
know.

I have said in the past in this forum that I consider the syntax of
Ada to be unnecessarily awkward and clunky. I have also suggested that
perhaps that is part of the reason Ada is not embraced by the
trend-setters. I got nothing but flack in response. Perhaps its time
to rethink that possibility.

I have written a simple preprocessor in Python that implements a new,
cleaner dialect of Ada that I call MyAda. It requires no semicolons at
the end of lines (but it allows them to separate multiple statements
on a line, as in Python and Fortran 95). Also, it uses "=" in place of
":=" and "=>". I would also make it enforce consistent indentation
like Python, but I haven't done that yet (it will keep the "end"
statements, of course).

I have also written the inverse preprocessor, so you can go back and
forth between Ada and MyAda. I have tested my preprocessors on several
Ada packages (from one of the Ada websites -- can't remember which),
and I have found that I get the same exact Ada code back when I go
from Ada to MyAda and back.

I note also that C, C++, Java, Perl, and Python, the five more popular
general purpose languages around today, all have augmented assignment
operators, and it it is still painfully obvious to me that Ada needs
them too. But it is also painfully obvious to me that most Ada
veterans are blind to this reality. Too bad -- for Ada.

Re: Is the Writing on the Wall for Ada?

[Hyman Rosen]

Russ wrote:
> First of all, Java forces everything into the "object-oriented" mold
> whether it fits or not.

Not true. It's easy enough to make class methods be static, and then
you've got the equivalent of a package with variables and procedures,
if that's what you want. You can also declare your class methods to be
final and accomplish about the same thing. So there's no real forcing
of OOness.

> it has no separately compiled specification files

That can be programmed by using interfaces. Write your specifications
as interface classes, then write the implementations as implementing
the interfaces. Works fine.

Re: Is the Writing on the Wall for Ada?

[David Marceau]

Hyman Rosen wrote:
> 
> Russ wrote:
> > First of all, Java forces everything into the "object-oriented" mold
> > whether it fits or not.
> 
> Not true. It's easy enough to make class methods be static, and then
> you've got the equivalent of a package with variables and procedures,
> if that's what you want. You can also declare your class methods to be
> final and accomplish about the same thing. So there's no real forcing
> of OOness.
> 
> > it has no separately compiled specification files
> 
> That can be programmed by using interfaces. Write your specifications
> as interface classes, then write the implementations as implementing
> the interfaces. Works fine.

I beg to differ that it works fine just as is.

The concept of the keyword "interface" is something that is highly
documented and truly borrowed from the Microsoft COM/OLE methodology and
probably .NET also.
Interfaces are the way to separating the differences between versions of
components.
The suggested programming lifestyle of COM/OLE/.NET is if you need to
change the behaviour of an existing interface for a component, then it
is usually better actually to create a new interface and keep the old
interface intact.  This is very important for runtime compatibility of
different versions of an application.
The impacts of running an old application with new libaries swept
underneith usually leads to havoc when old interfaces are not preserved.
In fact I would imagine this is where the java developers borrowed the
keyword interface because deep down in the Java Native Interface jni.h
you can see remnants of the OLE/COM variant type structures embedded
into the standard all-encompassing JObject.
If you haven't read Inside OLE I suggest you do it for its perspective. 
There is a much good material in there considering versioned binaries
and architecting forward version binary compatibility.  The recipe you
gave above is exactly the recipe for c++.
In ada it is the case that when you build the app usually you have all
the sources to your disposal so this isn't much of a concern is it? ;)
In java however on more than one occasion I have had my infrastructure
crumble underneith me because the RAD spiral development was spiralling
like crazy.
The interfaces and their behaviours were changing left right and center
without prior notice and completely undocumented.  One advantage over
ada is that much deliberation is placed on thinking about the
specification before implementing it.  Lots of docs support the ada
process usually.  Java is somehow more like visual basic and more
freestyle because it encourages you try a bunch of things on the fly
without much consideration about the impact one's code has on other
members in a team when reinserted into the source control system and
also without any documentation to show for these changes.  Changes like
these would never happen if using ada because usually that assume you
are using process/methodology that explicitly forces you to document
what changes you have made.  The way the dependencies are checked and
built against with an ada compiler is still much better when dealing
with lots of source IMHO.  It's much to do with process also.  When
working with java it is almost as if one was encouraging freestyle
methodology and when you write something is compiles successfully too
easily.  That said it doesn't guarantee that the java application will
run...

I must say the successful construction of an application not only lies
on the language used but also on the methodology/process used.
I like to refer to the methodology/process used as the "programming
lifestyle" which all members of the team must adopt in order to the
project to be a success.

IMHO again Ada will probably succeed more because usually more
deliberation is placed in programming lifestyle when using Ada.  Not all
programmers but there are many freestyle java /c++ coders out there but
when they get together in a team IMHO it's just havoc.

I have placed a lot of effort describing this "interface" feature here
because it is among the most important features any language could have
and to make work efficiently among team developers.  Ada has their way
of doing this stuff and IMHO it is again a better way ;>  I won't waste
my breath repeating the oodles of ada rationale docs.

Cheers,
David

Re: Is the Writing on the Wall for Ada?

[Hyman Rosen]

David Marceau wrote:
> Interfaces are the way to separating the differences between versions of
> components.

That is a very interesting point of view. Oh wait, no it isn't. It's just a
wrong point of view. The way interfaces are used in Java, and in C++ for that
matter, is as a specification for the the methods supported by an object.
It doesn't matter how this got that way, so we may as well assume that your
little history lesson is true, since it's uninteresting regardless.

Write an interface, and now you have a specification for how a component may
be invoked, without any code implementing such a component. Write the code
which conforms to the interface, and you're done. The compiler makes sure that
if an interface is expected, it is supplied, and if it's to be implemented,
nothing is missing.

That's your separately compilable specification and implementation. What about
this fails to work?

Re: Is the Writing on the Wall for Ada?

[Jerry van Dijk]

Hyman Rosen <hyrosen@mail.com> writes:

> David Marceau wrote:
> > Interfaces are the way to separating the differences between versions of
> > components.
> 
> That is a very interesting point of view. Oh wait, no it isn't. It's just a
> wrong point of view. The way interfaces are used in Java, and in C++

I think there is overloading problem here, it seems to me that David is
talking about COM interfaces, and Hyman about language interfaces.

BTW only yesterday I was reading on Slashdot about how Java was now a dead
language (on desktop and server, I presume) because of its slow
development, .NET is what everyone should be using... Mmmmm, anyone for Web
enabled traffic control ? :-)

Ahh, well, fortunately for Ada I am nowhere near retirement yet (although it
sometimes feels like it :-)

-- 
--  Jerry van Dijk, Leiden, Holland 
--  Note that email address is invalid

Re: Is the Writing on the Wall for Ada?

[Alex Gibson]

"Jerry van Dijk" <somename@nospam.demon.nl> wrote in message news:m2k78k8ybr.fsf@jvdsys.demon.nl...
> Hyman Rosen <hyrosen@mail.com> writes:
> 
> > David Marceau wrote:
> > > Interfaces are the way to separating the differences between versions of
> > > components.
> > 
> > That is a very interesting point of view. Oh wait, no it isn't. It's just a
> > wrong point of view. The way interfaces are used in Java, and in C++
> 
> I think there is overloading problem here, it seems to me that David is
> talking about COM interfaces, and Hyman about language interfaces.
> 
> BTW only yesterday I was reading on Slashdot about how Java was now a dead
> language (on desktop and server, I presume) because of its slow
> development, .NET is what everyone should be using... Mmmmm, anyone for Web
> enabled traffic control ? :-)

Sure you don't mean web enabled electricity network control ?
Or using windows 2000 to run nuclear power plants ?

Re: Is the Writing on the Wall for Ada?

[olehjalmar kristensen - Sun Microsystems - Trondheim Norway]

>>>>> "HR" == Hyman Rosen <hyrosen@mail.com> writes:

    HR> David Marceau wrote:
    >> Interfaces are the way to separating the differences between versions of
    >> components.

    HR> That is a very interesting point of view. Oh wait, no it isn't. It's just a
    HR> wrong point of view. The way interfaces are used in Java, and in C++ for that
    HR> matter, is as a specification for the the methods supported by an object.
    HR> It doesn't matter how this got that way, so we may as well assume that your
    HR> little history lesson is true, since it's uninteresting regardless.

    HR> Write an interface, and now you have a specification for how a component may
    HR> be invoked, without any code implementing such a component. Write the code
    HR> which conforms to the interface, and you're done. The compiler makes sure that
    HR> if an interface is expected, it is supplied, and if it's to be implemented,
    HR> nothing is missing.

    HR> That's your separately compilable specification and implementation. What about
    HR> this fails to work?

In theory, nothing. But I've actually managed to create instances of
classes with pure virtual functions. Kind of funny when it blows up at
run time with "pure virtual function called". That's a criticism of the
compiler of course, not the language as such.

And then you don't have the compiler forcing you to actually write a
separate interface, of course.

Re: Is the Writing on the Wall for Ada?

[svaa]

> IMHO again Ada will probably succeed more because usually more
> deliberation is placed in programming lifestyle when using Ada. 
> 

That's whay Ada is not used, with deliberation you can get better
programs, but without too much deliberation you can get enough good
programs and quicker, at least at first sight.

The game is "Deliver before than the competence", not "Deliver
thurstly software", even in systems that must be safe. Ada has sticked
on "good software" and not in "fast tools", A team deliberating is not
a nice picture for CEO, a team coding and releasing often is a nicer
picture for a CEO. Deliberation is not a popular word, productivity is
a popular word. No matter they are not opposites, you must highlight
productivity, not deliberation.

Until gnat, Ada compilers were really too expensive for any company,
except really big coporations.

Ada comunity isn't formed of young hackers, nor adolescents. And
companies want to hire cheap coders, there are not cheap Ada coders,
so there are not a lot of companies that use Ada, so Ada is dying.

Ada is pretrified, the need of a central authority that controls the
language is good, it makes it very stantard, but also stops
innovation. And sometimes I think that Ada people believe that it has
reach perfection, any change is bad.

Re: Is the Writing on the Wall for Ada?

[Russ]

Hyman Rosen <hyrosen@mail.com> wrote in message news:<FRz6b.2150$ej1.1502@nwrdny01.gnilink.net>...
> Russ wrote:
> > First of all, Java forces everything into the "object-oriented" mold
> > whether it fits or not.
> 
> Not true. It's easy enough to make class methods be static, and then
> you've got the equivalent of a package with variables and procedures,
> if that's what you want. You can also declare your class methods to be
> final and accomplish about the same thing. So there's no real forcing
> of OOness.

OK, help me out here. I confess that I have never done any real
programming in Java. My main exposure to it was a class at Stanford
that I audited about six years ago. My formal training is in aerospace
engineering, not programming (and I'm very glad about that, by the
way). Get the picture?

OK, now that I've clarified that, here's a simple, straightforward
question for you. I could probably look this up myself, but I'm lazy.
Suppose I want to take the sine of an angle in Java. Can I somehow set
things up so that I can simply write "sin(x)", or must I write
something like "math.sin(x)"? The former is acceptable to me, but the
latter is not.

> > it has no separately compiled specification files
> 
> That can be programmed by using interfaces. Write your specifications
> as interface classes, then write the implementations as implementing
> the interfaces. Works fine.

I remember Java interfaces only vaguely. Are you telling me that they
do everything that Ada spec files do, and that they do it every bit as
well, with no disadvantages? If so, then I am impressed. But that's a
big "if". I would certainly be interested in other opinions here too.

Re: Is the Writing on the Wall for Ada?

[Robert I. Eachus]

Russ wrote:

> I remember Java interfaces only vaguely. Are you telling me that they
> do everything that Ada spec files do, and that they do it every bit as
> well, with no disadvantages? If so, then I am impressed. But that's a
> big "if". I would certainly be interested in other opinions here too.

There is a proposal for Ada 200X to add interfaces to Ada.  It has been 
extensively worked, and will almost surely be added.

Why?  Because intefaces are different from Ada generics and solve other 
problems.  In particular adding interfaces to Ada allows derived types 
where the type inherits one parent type and adds one or more interfaces. 
  The user must then provide explicitly declared subprograms to match 
any subprograms in the interfaces that are not provided by the parent 
type.  (In the proposal you can inherit from only interfaces as well. 
But directly inheriting from only one interface is not that interesting 
a case.)

Back to the original question, I can remember when the challenge to Ada 
was Smalltalk.  Then fifth generation languages like Prolog, then C++, 
then Java.  Now it is C#.  Do you see a pattern here?  There are 
programmers who NEED to use whatever the latest new thing is, and won't 
let considerations like long term maintenance get in their way.  (For 
those who care about using .NET, I see it as orthogonal to using Ada. 
C#, as far as I am concerned is a restricted subset of C++ that 
Microsoft provides a .NET enabled compiler for.  You can, and for some 
projects you must, compile some modules outside the C# environment.

Could someone provide a .NET enabled compiler for Ada?  Sure. Will 
anyone do so?  I don't think so.  As long as .NET is seen as a Microsoft 
Windows only environment, the only advantage to having an Ada .NET 
compiler is to run the same executables on x86 and IA-64 hardware.  But 
as far as I can see, Itanium2 is succeeding only in the heavy number 
crunching environment where most users will want as much optimization as 
possible.  (Someday there may be a .NET compiler that is that good.  I 
don't expect to live that long--and I expect to live a long time.)

As for x86-64/AMD64, whichever you want to call it, if the operating 
system supports 64-bit mode, it also supports running mixed 32-bit and 
64-bit executables simultaneously and with no extra overhead.  Well, 
technically Microsoft has chosen to support 32-bit executables by 
providing a (thin) interface to expand 32-bit OS calls to 64-bit 
addresses on call and return, while Linux provides both "native" 32-bit 
and 64-bit OS interfaces.  However, we are talking a few "extra" 
instructions per call in WoW-64 to allow the (faster) 64-bit 
implementation of the OS to be used.  It is not clear yet which approach 
is better, but the difference is in the 1% of execution time range. And 
both are faster on average than running on a 32-bit OS.

So I see C# and .NET as a solution to a problem that will never occur. 
(Migrating Windows users to IA-64.)

-- 
                                            Robert I. Eachus

"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: Is the Writing on the Wall for Ada?

[Jerry van Dijk]

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

> Could someone provide a .NET enabled compiler for Ada?  Sure. Will anyone do
> so?  I don't think so.

Never underestimate GNAT users :-)
 
www.usafa.af.mil/dfcs/bios/mcc_html/a_sharp.html

-- 
--  Jerry van Dijk, Leiden, Holland 
--  Note that email address is invalid

Re: Is the Writing on the Wall for Ada?

[David C. Hoos]

"Robert I. Eachus" <rieachus@attbi.com> wrote in message
news:3F5B8084.5080705@attbi.com...
<snip>
> Could someone provide a .NET enabled compiler for Ada?  Sure. Will
> anyone do so?  I don't think so.

Dr. Martin Carlisle and company at the Air Force Academy have already done
so.
http://www.usafa.af.mil/dfcs/bios/mcc_html/a_sharp.html

> As long as .NET is seen as a Microsoft
> Windows only environment, the only advantage to having an Ada .NET
> compiler is to run the same executables on x86 and IA-64 hardware.

Work has been underway for some time on more than one implementation of the
.NET
framework and the CLR for (NIX environments -- e.g. http://www.go-mono.com/

<snip>

Re: Is the Writing on the Wall for Ada?

[Russ]

"Robert I. Eachus" <rieachus@attbi.com> wrote in message news:<3F5B8084.5080705@attbi.com>...
> Russ wrote:
> 
> > I remember Java interfaces only vaguely. Are you telling me that they
> > do everything that Ada spec files do, and that they do it every bit as
> > well, with no disadvantages? If so, then I am impressed. But that's a
> > big "if". I would certainly be interested in other opinions here too.
> 
> There is a proposal for Ada 200X to add interfaces to Ada.  It has been 
> extensively worked, and will almost surely be added.
> 
> Why?  Because intefaces are different from Ada generics and solve other 
> problems.  In particular adding interfaces to Ada allows derived types 
> where the type inherits one parent type and adds one or more interfaces. 
>   The user must then provide explicitly declared subprograms to match 
> any subprograms in the interfaces that are not provided by the parent 
> type.  (In the proposal you can inherit from only interfaces as well. 
> But directly inheriting from only one interface is not that interesting 
> a case.)

Thanks for the reply, but now I'm even more confused. Mr. Rosen
claimed that Java interfaces provide all the functionality of Ada spec
files (.ads files). Now you come along and say that Ada is getting
interfaces too because they are "different from Ada generics and solve
other problems."

Well, let's put 2 and 2 together. If Mr. Rosen is correct, then after
Ada gets interfaces, the spec (.ads) files will be redundant and no
longer really needed. I'm just a simple-minded aerospace engineer. Am
I missing something here?

Re: Is the Writing on the Wall for Ada?

[Matthew Heaney]

18k11tm001@sneakemail.com (Russ) writes:

> Well, let's put 2 and 2 together. If Mr. Rosen is correct, then after
> Ada gets interfaces, the spec (.ads) files will be redundant and no
> longer really needed. I'm just a simple-minded aerospace engineer. Am
> I missing something here?

You are conflating module and type.  

An Ada package spec is a module, which is just a namespace with some
extra semantics.  An interface specifies a set of operations for a type.

Modules and types are othogonal language features.  Adding interface
types to Ada will not affect whether modules are necessary.

Re: Is the Writing on the Wall for Ada?

[Alexander Kopilovitch]

Russ wrote:

> now I'm even more confused. Mr. Rosen
> claimed that Java interfaces provide all the functionality of Ada spec
> files (.ads files).

Actually he did not say that much,

> If Mr. Rosen is correct, then after
> Ada gets interfaces, the spec (.ads) files will be redundant and no
> longer really needed. I'm just a simple-minded aerospace engineer. Am
> I missing something here?

Ada specs contains much more than Java interfaces; and proposed Ada interfaces
may be vaguely compared with Java interfaces. It is well-known fact that the
notion of interface is very similar to the notion of (pure) abstract class/type,
which Ada already have; the essence (for user) of proposed addition is that
restricted multiple inheritance will be permitted through these new interfaces:
you still can't use more than one "normal" type as the parent, but you may at
the same time inherit *subroutine specifications* from several abstract types,
providing implementation of those subroutines within implementation of your type.



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

Re: Is the Writing on the Wall for Ada?

[Hyman Rosen]

Alexander Kopilovitch wrote:
> Actually he did not say that much

Right. I just meant that in Java you do not entirely lose the
ability to separate specification from implementation, if you
approach the design in the right way.

Re: Is the Writing on the Wall for Ada?

[Russ]

Hyman Rosen <hyrosen@mail.com> wrote in message news:<4097b.8256$w41.4532@nwrdny02.gnilink.net>...
> Alexander Kopilovitch wrote:
> > Actually he did not say that much
> 
> Right. I just meant that in Java you do not entirely lose the
> ability to separate specification from implementation, if you
> approach the design in the right way.

Oh, so you don't *entirely* lose the ability to separate specification
from implementation. Approximately what percentage do you lose?

Also, that seems like a slight retreat from your earlier statement:

"Write an interface, and now you have a specification for how a
component may be invoked, without any code implementing such a
component. Write the code which conforms to the interface, and you're
done. The compiler makes sure that if an interface is expected, it is
supplied, and if it's to be implemented, nothing is missing."

"That's your separately compilable specification and implementation.
What about this fails to work?"

Don't mind me. I'm just a clueless aerospace engineer trying to figure
out which end is up.

Re: Is the Writing on the Wall for Ada?

[Hyman Rosen]

Russ wrote:
> Oh, so you don't *entirely* lose the ability to separate specification
> from implementation. Approximately what percentage do you lose?

Sigh.

When you write code in Java, you can write it it in a way that allows
you to have the specification of a functional interface separate from
its implementation. Since I have zero interest in waging a language war
between Java and Ada, I don't care about how superior Ada's package
specifications might be. Let's say that Ada is a million times better.
That's of no interest when you're programming in Java.

RE: Is the Writing on the Wall for Ada?

[Robert C. Leif]

I am presently using Martin Carlisle's A# which employs the same ECMA code
base as the Microsoft .Net products. The only problem that I have had is
that Martin' .Net tools only work when the C++ programmer does builds his
OCX, Active X or DLL according to Microsoft's specifications. I now have two
very important software products where this has not occurred. A major
problem with Ada is that the GNU marketing model does not encourage vendors
to support products like A#.
Parenthetically, C# is closer to Objective C than Java and produces usable
code. 
As for Ada, we are now in the same state as SGML was four years ago. After
XML was derived from SGML, all hell has broken loose. SPARK gives us
something to hype! All Ada needs are a few capable capitalists and marketing
people. Simple classic rule of business, if a product stops selling, change
its name, give it a face lift and then do a marketing blitz.
Bob Leif 
Robert C. Leif, Ph.D.
Email rleif@rleif.com

-----Original Message-----
From: Robert I. Eachus [mailto:rieachus@attbi.com] 
Sent: Sunday, September 07, 2003 12:02 PM
To: comp.lang.ada@ada.eu.org
Subject: Re: Is the Writing on the Wall for Ada?

Russ wrote:

> I remember Java interfaces only vaguely. Are you telling me that they
> do everything that Ada spec files do, and that they do it every bit as
> well, with no disadvantages? If so, then I am impressed. But that's a
> big "if". I would certainly be interested in other opinions here too.

There is a proposal for Ada 200X to add interfaces to Ada.  It has been 
extensively worked, and will almost surely be added.

Why?  Because intefaces are different from Ada generics and solve other 
problems.  In particular adding interfaces to Ada allows derived types 
where the type inherits one parent type and adds one or more interfaces. 
  The user must then provide explicitly declared subprograms to match 
any subprograms in the interfaces that are not provided by the parent 
type.  (In the proposal you can inherit from only interfaces as well. 
But directly inheriting from only one interface is not that interesting 
a case.)

Back to the original question, I can remember when the challenge to Ada 
was Smalltalk.  Then fifth generation languages like Prolog, then C++, 
then Java.  Now it is C#.  Do you see a pattern here?  There are 
programmers who NEED to use whatever the latest new thing is, and won't 
let considerations like long term maintenance get in their way.  (For 
those who care about using .NET, I see it as orthogonal to using Ada. 
C#, as far as I am concerned is a restricted subset of C++ that 
Microsoft provides a .NET enabled compiler for.  You can, and for some 
projects you must, compile some modules outside the C# environment.

Could someone provide a .NET enabled compiler for Ada?  Sure. Will 
anyone do so?  I don't think so.  As long as .NET is seen as a Microsoft 
Windows only environment, the only advantage to having an Ada .NET 
compiler is to run the same executables on x86 and IA-64 hardware.  But 
as far as I can see, Itanium2 is succeeding only in the heavy number 
crunching environment where most users will want as much optimization as 
possible.  (Someday there may be a .NET compiler that is that good.  I 
don't expect to live that long--and I expect to live a long time.)

As for x86-64/AMD64, whichever you want to call it, if the operating 
system supports 64-bit mode, it also supports running mixed 32-bit and 
64-bit executables simultaneously and with no extra overhead.  Well, 
technically Microsoft has chosen to support 32-bit executables by 
providing a (thin) interface to expand 32-bit OS calls to 64-bit 
addresses on call and return, while Linux provides both "native" 32-bit 
and 64-bit OS interfaces.  However, we are talking a few "extra" 
instructions per call in WoW-64 to allow the (faster) 64-bit 
implementation of the OS to be used.  It is not clear yet which approach 
is better, but the difference is in the 1% of execution time range. And 
both are faster on average than running on a 32-bit OS.

So I see C# and .NET as a solution to a problem that will never occur. 
(Migrating Windows users to IA-64.)

-- 
                                            Robert I. Eachus

"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: Is the Writing on the Wall for Ada?

[Rod Chapman]

"Robert C. Leif" <rleif@rleif.com> wrote in message news:<mailman.20.1062997816.295.comp.lang.ada@ada.eu.org>...
> SPARK gives us something to hype!

Please feel free to hype SPARK! :-)

(Seriously, we are a small-ish company, and there's only so much
marketing we can do from over here...)

SPARK has several unique properties, and it is a testament to
the strength of Ada that these things can be achieved at all -
something that the Ada community should be justifiably proud of...

We are seeing real resurgence in interest in static analysis now,
and Eiffel has brough DbC to the attention of many people - you 
never know, SPARK might end up being fashionable soon...(just don't
tell 'em it's Ada... :-) )

 - Rod

Re: Is the Writing on the Wall for Ada?

[Hyman Rosen]

Robert C. Leif wrote:
 > In particular adding interfaces to Ada allows derived types
> where the type inherits one parent type and adds one or more interfaces.

Thereby exhibiting the simple lack of courage to add multiple
inheritance. Why should we limit to inheriting from one type?
What is it about one that makes it better than two or more?

Re: Is the Writing on the Wall for Ada?

[Alexander Kopilovitch]

Hyman Rosen wrote:

> Why should we limit to inheriting from one type?
> What is it about one that makes it better than two or more?

Just for better visualization -:) . There are various suitable visual controls
for a tree, but tell me where I can find an affordable ActiveX or Delphi control
or at least Java beam (of good quality) for a DAG (directed acyclic graph) ?


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

Re: Is the Writing on the Wall for Ada?

[Russ]

Hyman Rosen <hyrosen@mail.com> wrote in message news:<q697b.8261$w41.4773@nwrdny02.gnilink.net>...
> Robert C. Leif wrote:
>  > In particular adding interfaces to Ada allows derived types
> > where the type inherits one parent type and adds one or more interfaces.
> 
> Thereby exhibiting the simple lack of courage to add multiple
> inheritance. Why should we limit to inheriting from one type?
> What is it about one that makes it better than two or more?

I'm certainly no expert here, but my impression is that multiple
inheritance is much more difficult to implement (correctly in all
cases) than SI.

I've also read (somewhere long ago) that in the vast majority of cases
in which MI is used it is unnecessary and more complicated than
necessary. If interfaces are a reasonable "workaround" for the few
legitimate cases where MI is needed, than perhaps they are a
reasonable compromise.

Re: Is the Writing on the Wall for Ada?

[Dmitry A. Kazakov]

On 9 Sep 2003 00:33:54 -0700, 18k11tm001@sneakemail.com (Russ) wrote:

>Hyman Rosen <hyrosen@mail.com> wrote in message news:<q697b.8261$w41.4773@nwrdny02.gnilink.net>...
>> Robert C. Leif wrote:
>>  > In particular adding interfaces to Ada allows derived types
>> > where the type inherits one parent type and adds one or more interfaces.
>> 
>> Thereby exhibiting the simple lack of courage to add multiple
>> inheritance. Why should we limit to inheriting from one type?
>> What is it about one that makes it better than two or more?
>
>I'm certainly no expert here, but my impression is that multiple
>inheritance is much more difficult to implement (correctly in all
>cases) than SI.
>
>I've also read (somewhere long ago) that in the vast majority of cases
>in which MI is used it is unnecessary and more complicated than
>necessary.

You can also read what medieval mathematicians thought about negative
numbers ... (:-))

> If interfaces are a reasonable "workaround" for the few
>legitimate cases where MI is needed, than perhaps they are a
>reasonable compromise.

If what you are saying were true, then a reasonable compromise should
be to have no inheritance at all. Which BTW is a wide spread opinion
too.

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

Re: Is the Writing on the Wall for Ada?

[Hyman Rosen]

Russ wrote:
> I'm certainly no expert here, but my impression is that multiple
> inheritance is much more difficult to implement (correctly in all
> cases) than SI.

So what? Is it more complicated than tasking, or the distributed
annex, or custom floating-point types, or the various other things
that are part of Ada? Besides, C++ has already solved the problem.
Just steal the ABI for object layout, and you have it. Since Ada
doesn't do proper construction anyway, you don't even have to deal
with the complexity of multiple constructors and destructors that
C++ needs.

Re: Is the Writing on the Wall for Ada?

[olehjalmar kristensen - Sun Microsystems - Trondheim Norway]

>>>>> "HR" == Hyman Rosen <hyrosen@mail.com> writes:

    HR> Robert C. Leif wrote:
    >> In particular adding interfaces to Ada allows derived types
    >> where the type inherits one parent type and adds one or more interfaces.

    HR> Thereby exhibiting the simple lack of courage to add multiple
    HR> inheritance. Why should we limit to inheriting from one type?
    HR> What is it about one that makes it better than two or more?

Beats me. In fact, one of the *nice* things about the C++ multiple
inheritance is that it allows me to express roles (a la Reenskaug) and
then combine different roles in the same object without jumping
through hoops. In Smalltalk you need an extra tool to do this, in C++
all you need is a little care. I suppose it *could* be done in Ada
with generics, but I have not tried it, and it would certainly be more
obfuscated.

Re: Is the Writing on the Wall for Ada?

[Ed Falis]

On 09 Sep 2003 09:34:29 +0200
olehjalmar kristensen - Sun Microsystems - Trondheim Norway
<ok145024@sun.com> wrote:

> >>>>> "HR" == Hyman Rosen <hyrosen@mail.com> writes:
> 
>     HR> Robert C. Leif wrote:
>     >> In particular adding interfaces to Ada allows derived types
>     >> where the type inherits one parent type and adds one or more
>     >interfaces.
> 
>     HR> Thereby exhibiting the simple lack of courage to add multiple
>     HR> inheritance. Why should we limit to inheriting from one type?
>     HR> What is it about one that makes it better than two or more?
> 
> Beats me. In fact, one of the *nice* things about the C++ multiple
> inheritance is that it allows me to express roles (a la Reenskaug) and
> then combine different roles in the same object without jumping
> through hoops. In Smalltalk you need an extra tool to do this, in C++
> all you need is a little care. I suppose it *could* be done in Ada
> with generics, but I have not tried it, and it would certainly be more
> obfuscated.

I've done it in Ada using access discriminants to implement multiple
inheritance - takes an awful lot of "plumbing" hanging around to do it. 
On the other hand, Eiffel lends itself quite nicely and cleanly to the
role modelling approach, because it explicitly addresses the stickier
issues in MI.

- Ed

RE: Is the Writing on the Wall for Ada?

[Robert C. Leif]

"Robert C. Leif wrote:
>     >> In particular adding interfaces to Ada allows derived types
>     >> where the type inherits one parent type and adds one or more
>     >interfaces."
I do not believe that I wrote this!
Bob Leif
Robert C. Leif, Ph.D.
rleif@rleif.com

-----Original Message-----
From: Ed Falis [mailto:falis@verizon.net] 
Sent: Tuesday, September 09, 2003 6:14 AM
To: comp.lang.ada@ada.eu.org
Subject: Re: Is the Writing on the Wall for Ada?

On 09 Sep 2003 09:34:29 +0200
olehjalmar kristensen - Sun Microsystems - Trondheim Norway
<ok145024@sun.com> wrote:

> >>>>> "HR" == Hyman Rosen <hyrosen@mail.com> writes:
> 
>     HR> Robert C. Leif wrote:
>     >> In particular adding interfaces to Ada allows derived types
>     >> where the type inherits one parent type and adds one or more
>     >interfaces.
> 
>     HR> Thereby exhibiting the simple lack of courage to add multiple
>     HR> inheritance. Why should we limit to inheriting from one type?
>     HR> What is it about one that makes it better than two or more?
> 
> Beats me. In fact, one of the *nice* things about the C++ multiple
> inheritance is that it allows me to express roles (a la Reenskaug) and
> then combine different roles in the same object without jumping
> through hoops. In Smalltalk you need an extra tool to do this, in C++
> all you need is a little care. I suppose it *could* be done in Ada
> with generics, but I have not tried it, and it would certainly be more
> obfuscated.

I've done it in Ada using access discriminants to implement multiple
inheritance - takes an awful lot of "plumbing" hanging around to do it. 
On the other hand, Eiffel lends itself quite nicely and cleanly to the
role modelling approach, because it explicitly addresses the stickier
issues in MI.

- Ed

Re: Is the Writing on the Wall for Ada?

[Ed Falis]

On Tue, 9 Sep 2003 23:09:17 -0700
"Robert C. Leif" <rleif@rleif.com> wrote:

> I do not believe that I wrote this!

I'm sorry, Bob - I must have mixed up the quoting.

- Ed

Re: Is the Writing on the Wall for Ada?

[Alexander Kopilovitch]

olehjalmar kristensen wrote:

> In fact, one of the *nice* things about the C++ multiple
> inheritance is that it allows me to express roles (a la Reenskaug) and
> then combine different roles in the same object without jumping
> through hoops.

Combining different roles in the same object may be a good thing
as far as those roles do not interfere with each other.
But in reality they may interfere by subtle and unforeseen way,
in some singular points of the problem space. Therefore it is
generally important (for the kinds of projects, for which Ada was
primarily designed) to maintain organized responsibility among
the roles, and this naturally leads to strict prioritization of
individual role's authority and responsibility. Single inheritance
ideally provides that prioritization, while full-scale multiple
inheritance symmetrically spreads responsibilty among several
ancestors, and did not provide any guidance for resolving of
apparent conflicts between the roles.

> In Smalltalk you need an extra tool to do this, in C++
> all you need is a little care. I suppose it *could* be done in Ada
> with generics, but I have not tried it, and it would certainly be more
> obfuscated.

Well, sometimes it may be done with generics, but anyway you may
always use straightforward delegation instead of multiple inheritance.
In fact, a delegation adds not so much code, and do not harm readability
(assuming regular attentive reading, not a brief glance).



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

Re: Is the Writing on the Wall for Ada?

[olehjalmar kristensen - Sun Microsystems - Trondheim Norway]

>>>>> "AK" == Alexander Kopilovitch <aek@vib.usr.pu.ru> writes:

    AK> olehjalmar kristensen wrote:
    >> In fact, one of the *nice* things about the C++ multiple
    >> inheritance is that it allows me to express roles (a la Reenskaug) and
    >> then combine different roles in the same object without jumping
    >> through hoops.

    AK> Combining different roles in the same object may be a good thing
    AK> as far as those roles do not interfere with each other.
    AK> But in reality they may interfere by subtle and unforeseen way,
    AK> in some singular points of the problem space. Therefore it is

Of course, that's why I said you needed some care. However, in
practice, there will be little or no overlap, and thus little chance of
interference, precisely because you have modeled the different roles
properly. Also, you will typically use multiple virtual inheritance
via one common base class to allow the different roles to interact.
I'm talking about multiple inheritance as a tool for combining
carefully modeled, largely orthogonal roles in a single object, not as
a tool for grabbing whatever functionality happens to be in some class.

    AK> generally important (for the kinds of projects, for which Ada was
    AK> primarily designed) to maintain organized responsibility among
    AK> the roles, and this naturally leads to strict prioritization of
    AK> individual role's authority and responsibility. Single inheritance
    AK> ideally provides that prioritization, while full-scale multiple
    AK> inheritance symmetrically spreads responsibilty among several
    AK> ancestors, and did not provide any guidance for resolving of
    AK> apparent conflicts between the roles.

    >> In Smalltalk you need an extra tool to do this, in C++
    >> all you need is a little care. I suppose it *could* be done in Ada
    >> with generics, but I have not tried it, and it would certainly be more
    >> obfuscated.

    AK> Well, sometimes it may be done with generics, but anyway you may
    AK> always use straightforward delegation instead of multiple inheritance.
    AK> In fact, a delegation adds not so much code, and do not harm readability
    AK> (assuming regular attentive reading, not a brief glance).

Sure, you can always use delegation, and obtain precisely the same
interface to the object as if you had used multiple inheritance. But
then you are really just implementing it yourself. I can do that in C
too. No need for inheritance at all, really. I actually did this in a
project in the early eighties as we only had C, not Simula or some
other object oriented language available on our Unix system.

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

Re: Is the Writing on the Wall for Ada?

[Alexander Kopilovitch]

olehjalmar kristensen wrote:

>     AK> Combining different roles in the same object may be a good thing
>     AK> as far as those roles do not interfere with each other.
>     AK> But in reality they may interfere by subtle and unforeseen way,
>     AK> in some singular points of the problem space. Therefore it is
> 
> Of course, that's why I said you needed some care. However, in
> practice, there will be little or no overlap, and thus little chance of
> interference, precisely because you have modeled the different roles
> properly. Also, you will typically use multiple virtual inheritance
> via one common base class to allow the different roles to interact.
> I'm talking about multiple inheritance as a tool for combining
> carefully modeled, largely orthogonal roles in a single object, not as
> a tool for grabbing whatever functionality happens to be in some class.

Well, perhaps you are careful enough with these things, and aren't
subjected to temptation "to grab whatever functionality happens to be
in some class". But most programmers and software engineers surely
have insuffiencet resistance to that temptation, and succumbed to it
more or less often (as experience with *real* C++ programs shows quite
clearly).

So, it is important to differentiate both the need for and dangers of
combining roles this way between the primarily modelling/simulation
class of applications and the class of applications that are in close
contact with real world (that is, with real objects and in real time).

What you wanted is *symmetrical* combining roles. That symmetry indeed
often happen in abstract models and may be very useful feature (and even
a fundamental feature of the model); therefore it will be good to express
this symmetry clearly and directly in source code. At the same time
the risks associated with an unforeseen interference between the roles
is relatively low, because the results of computation usually aren't
applied immediately, but will be analyzed and interpreted by trained
people in usually calm environment.

But for the applications that are in close contact with real world,
the situation is opposite. First, symmetry simply *never* exists
in real world. Quite strong statement, isn't? A symmetry may appear
as a satisfactory approximation in some conditions, which may emerge
and disappear occasionally. Nobody can guarantee any symmetry for a
particular small event in real world. Even a strong probablistic
estimate for such a symmetry seems to be very rare possibility.
Furthemore, even if we are able to prove that the conditions for
symmetry (of roles) will be present then the next question is: how
stable are our assumptions? Will they be still in place, say, 5 years
ahead? (If you disagree with all that just said then please provide
a counterexample - a pair of symmetrical real-world roles.)
Now let's observe the risks associated with a conflict bewteen those
"pseudo-symmetrical" roles. I think it is obvious enough that the risks
are generally much higher here, just because our applications can cause
immediate effects in the real world.

So, a feature for (symmetrical) combining roles in Simula-67 was fully
justified, while for Ada it seems undesirable.

> Sure, you can always use delegation, and obtain precisely the same
> interface to the object as if you had used multiple inheritance. But
> then you are really just implementing it yourself. I can do that in C
> too. No need for inheritance at all, really. I actually did this in a
> project in the early eighties as we only had C, not Simula or some
> other object oriented language available on our Unix system.

Well, but basic delegation (and you need not more, if you want multiple
inheritance, but do not expect from a compiler any complex specifics)
may be implemented using canonical way; so you may develop a custom
preprocessing tool (perhaps, using ASIS, if you wish a full-scale tool).
and have Ada-MI (with file extension .ami -:) ... those who are unable
to create such a tool for themselves surely do not deserve multiple
iheritance in Ada -:) . You may also put this tool in public domain,
and if it becomes highly popular then it may eventually convince ARG
to reconsider their view on the subject... not for Ada200Y, but perhaps
for Ada201Z -:) .



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

Re: Is the Writing on the Wall for Ada?

[Dmitry A. Kazakov]

On 9 Sep 2003 16:48:04 -0700, aek@vib.usr.pu.ru (Alexander
Kopilovitch) wrote:

>Combining different roles in the same object may be a good thing
>as far as those roles do not interfere with each other.
>But in reality they may interfere by subtle and unforeseen way,
>in some singular points of the problem space. Therefore it is
>generally important (for the kinds of projects, for which Ada was
>primarily designed) to maintain organized responsibility among
>the roles, and this naturally leads to strict prioritization of
>individual role's authority and responsibility. Single inheritance
>ideally provides that prioritization, while full-scale multiple
>inheritance symmetrically spreads responsibilty among several
>ancestors, and did not provide any guidance for resolving of
>apparent conflicts between the roles.

If you declare two variables with the same name in the same context,
what sort of guidance you need to resolve this conflict? You need no
quidance. The compiler just do not eat the code. Conflicts has to be
disallowed where possible, as simple as that. (*)

In both cases: MI vs. multiple variable declaration everything can be
checked statically. But strangely enough, that the latter is
considered OK and nobody proposes to limit the number of variables per
block by one. I DO! (:-)) How nice and safe it would be. And there is
a wondeful work-around when you need two variables. Make a record
type!

>> In Smalltalk you need an extra tool to do this, in C++
>> all you need is a little care. I suppose it *could* be done in Ada
>> with generics, but I have not tried it, and it would certainly be more
>> obfuscated.
>
>Well, sometimes it may be done with generics, but anyway you may
>always use straightforward delegation instead of multiple inheritance.
>In fact, a delegation adds not so much code, and do not harm readability
>(assuming regular attentive reading, not a brief glance).

Delegation solves nothing. It just offers you to make everything
manually. How nice. But if MI is inheretly wrong, then doing the SAME
thing manually, you will dicover SAME problems. Just consider
inheritance as a delegation with an automatically generated proxy
code. So let MI be infeasible, then delegation has to be also limited
by "single delegation". But likely they both are not. Because, the
problem is not inheritance per se, but the way a proxy code is
generated and the way a programmer might influence this process.

------------------
(*) Unresolved, postponed conflicts are nightmare. This has nothing to
do with MI. We have this nightmare in case of variable declarations
too (use clauses, for example).

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

Re: Is the Writing on the Wall for Ada?

[Matthew Heaney]

olehjalmar kristensen - Sun Microsystems - Trondheim Norway <ok145024@sun.com> writes:

> Beats me. In fact, one of the *nice* things about the C++ multiple
> inheritance is that it allows me to express roles (a la Reenskaug) and
> then combine different roles in the same object without jumping
> through hoops. In Smalltalk you need an extra tool to do this, in C++
> all you need is a little care. I suppose it *could* be done in Ada
> with generics, but I have not tried it, and it would certainly be more
> obfuscated.

The mechanism for implementing roles (what we call "views") in Ada95 is
access discriminants, not MI.

For example, if I want to have a "persistence role," I can do this:

package Persistence_Views is

   type Root_Persistence_Type is
      abstract tagged limited null record;

   type Persistence_Class_Access is
     access all Root_Persistence_Type'Class;

   procedure Write
     (Stream : in out Root_Stream_Type'Class;
      Persistence : access Root_Persistence_Type) is abstract;

   procedure Read
     (Stream : in out Root_Stream_Type'Class;
      Persistence : access Root_Persistence_Type) is abstract;

   procedure Save
     (Persistence : access Root_Persistence_Type'Class);
   
end Persistence_Views;


To add support for persistence to a type, you can do this:

with Persistence_Views;
package P is

   type T is tagged limited private;

   function Persistence (O : access T) 
     return Persistence_Class_Access;

   ...
private

   type Persisence_Type (O : access T) is
     new Root_Persistence_Type with null record;

   procedure Write (...);
   procedure Read (...);

   type T is tagged limited record
     Persistence : aliased Persistence_Type (T'Access);
     ...
   end record;

end P;

 
So now given an object of type T (which supports persistence), you can
oo this:

procedure Op (O : in out T) is
begin
   Save (Persistence (O'Access));
end;


We've shown one role here, but in fact any number of views may be
supported by a type:

procedure Op (O : in out T) is
begin
   View_1_Op (View_1 (O'Access));
   View_2_Op (View_2 (O'Access));
   View_3_Op (View_3 (O'Access));
   ...
end;


Contrary to being "obfuscated," implementing roles in Ada95 is quite
simple and elegant.  And no MI is required.

Re: Is the Writing on the Wall for Ada?

[olehjalmar kristensen - Sun Microsystems - Trondheim Norway]

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

    MH> olehjalmar kristensen - Sun Microsystems - Trondheim Norway <ok145024@sun.com> writes:
    >> Beats me. In fact, one of the *nice* things about the C++ multiple
    >> inheritance is that it allows me to express roles (a la Reenskaug) and
    >> then combine different roles in the same object without jumping
    >> through hoops. In Smalltalk you need an extra tool to do this, in C++
    >> all you need is a little care. I suppose it *could* be done in Ada
    >> with generics, but I have not tried it, and it would certainly be more
    >> obfuscated.

    MH> The mechanism for implementing roles (what we call "views") in Ada95 is
    MH> access discriminants, not MI.

    MH> For example, if I want to have a "persistence role," I can do this:

    MH> package Persistence_Views is

    MH>    type Root_Persistence_Type is
    MH>       abstract tagged limited null record;

    MH>    type Persistence_Class_Access is
    MH>      access all Root_Persistence_Type'Class;

    MH>    procedure Write
    MH>      (Stream : in out Root_Stream_Type'Class;
    MH>       Persistence : access Root_Persistence_Type) is abstract;

    MH>    procedure Read
    MH>      (Stream : in out Root_Stream_Type'Class;
    MH>       Persistence : access Root_Persistence_Type) is abstract;

    MH>    procedure Save
    MH>      (Persistence : access Root_Persistence_Type'Class);
   
    MH> end Persistence_Views;


    MH> To add support for persistence to a type, you can do this:

    MH> with Persistence_Views;
    MH> package P is

    MH>    type T is tagged limited private;

    MH>    function Persistence (O : access T) 
    MH>      return Persistence_Class_Access;

    MH>    ...
    MH> private

    MH>    type Persisence_Type (O : access T) is
    MH>      new Root_Persistence_Type with null record;

    MH>    procedure Write (...);
    MH>    procedure Read (...);

    MH>    type T is tagged limited record
    MH>      Persistence : aliased Persistence_Type (T'Access);
    MH>      ...
    MH>    end record;

    MH> end P;

 
    MH> So now given an object of type T (which supports persistence), you can
    MH> oo this:

    MH> procedure Op (O : in out T) is
    MH> begin
    MH>    Save (Persistence (O'Access));
    MH> end;


    MH> We've shown one role here, but in fact any number of views may be
    MH> supported by a type:

    MH> procedure Op (O : in out T) is
    MH> begin
    MH>    View_1_Op (View_1 (O'Access));
    MH>    View_2_Op (View_2 (O'Access));
    MH>    View_3_Op (View_3 (O'Access));
    MH>    ...
    MH> end;


    MH> Contrary to being "obfuscated," implementing roles in Ada95 is quite
    MH> simple and elegant.  And no MI is required.

But this is not exactly what I was talking about. With MI, you may
inherit both interface and implementation, no need to write new code.
It's all about synthesising new object types from existing ones
without the straightjacket of single inheritance.

Re: Is the Writing on the Wall for Ada?

[Matthew Heaney]

olehjalmar kristensen - Sun Microsystems - Trondheim Norway <ok145024@sun.com> writes:

> But this is not exactly what I was talking about. With MI, you may
> inherit both interface and implementation, no need to write new code.
> It's all about synthesising new object types from existing ones
> without the straightjacket of single inheritance.

The multiple views idiom in Ada95 doesn't preclude that at all.  See my
post on Mon, 15 Sep 2003, in which My_Object type "inherits" from two
existing types.  It inherits both interface and implementation, and the
only new code I wrote was for trivial multiple views infrastructure.

Re: Is the Writing on the Wall for Ada?

[Ed Falis]

On Mon, 15 Sep 2003 23:31:08 GMT
Matthew Heaney <matthewjheaney@earthlink.net> wrote:

> The multiple views idiom in Ada95 doesn't preclude that at all.  See
> my post on Mon, 15 Sep 2003, in which My_Object type "inherits" from
> two existing types.  It inherits both interface and implementation,
> and the only new code I wrote was for trivial multiple views
> infrastructure.

Matt's on the money with this one.  I've used the same idiom to
implement things I've designed using Reenskaug's role synthesis
approach.  The thing I will say, though, is that it takes a lot more
plumbing to do it in Ada than to do it in eg Eiffel.

- Ed

Re: Is the Writing on the Wall for Ada?

[Ole-Hjalmar Kristensen]

>>>>> "EF" == Ed Falis <falis@verizon.net> writes:

    EF> On Mon, 15 Sep 2003 23:31:08 GMT
    EF> Matthew Heaney <matthewjheaney@earthlink.net> wrote:

    >> The multiple views idiom in Ada95 doesn't preclude that at all.  See
    >> my post on Mon, 15 Sep 2003, in which My_Object type "inherits" from
    >> two existing types.  It inherits both interface and implementation,
    >> and the only new code I wrote was for trivial multiple views
    >> infrastructure.

    EF> Matt's on the money with this one.  I've used the same idiom to
    EF> implement things I've designed using Reenskaug's role synthesis
    EF> approach.  The thing I will say, though, is that it takes a lot more
    EF> plumbing to do it in Ada than to do it in eg Eiffel.

    EF> - Ed

Which was my original point, not that it could not be done.

-- 
This page intentionally left blank

Re: Is the Writing on the Wall for Ada?

[Hyman Rosen]

Matthew Heaney wrote:
> The multiple views idiom in Ada95 doesn't preclude that at all.

It's fine, but what's wrong with letting the language handle the
plumbing for you, instead of making you do it yourself? And the
bit about access discriminants getting initialized with the address
of the object containing them seems a little gimmicky to me, compared
to arbitrary constructors.

Re: Is the Writing on the Wall for Ada?

[Matthew Heaney]

Hyman Rosen <hyrosen@mail.com> writes:

> Matthew Heaney wrote:
> > The multiple views idiom in Ada95 doesn't preclude that at all.
> 
> It's fine, but what's wrong with letting the language handle the
> plumbing for you, instead of making you do it yourself? And the
> bit about access discriminants getting initialized with the address
> of the object containing them seems a little gimmicky to me, compared
> to arbitrary constructors.

Ada95 doesn't have MI.  It will never have MI.  So what to do?

The multiple views idiom gets the job done, without MI.  Yes, you have
to build a little bit of infrastructure yourself, that would otherwise
be done for you a language with full-blown MI, but it works.

I happen to think that access disciminants are quite elegant.  They are
quite general and powerful.  Hardly "gimmicky" at all.

In fact you could do something similar in C++, something Tom Cargill
argued 10 years ago, when he was fighting the inclusion of MI into C++.

Re: Is the Writing on the Wall for Ada?

[Hyman Rosen]

Matthew Heaney <matthewjheaney@earthlink.net> wrote in message news:<ud6e178aw.fsf@earthlink.net>...
> Ada95 doesn't have MI.  It will never have MI.  So what to do?

Sure, you do what the language allows to express what you need to do.
And Ada is getting interfaces, after all. Maybe one day it will have
full MI.

> I happen to think that access disciminants are quite elegant.  They are
> quite general and powerful.  Hardly "gimmicky" at all.

Not access discriminants themselves, just the way to get them
initialized with the address of the object they're contained in.
Java does the same thing with nested classes, so it's probably
just me; I'm used to C++, where doing the same thing would require
an explicit pointer member and a constructor to initialize it.

Anyway, one of the things that this approach misses from true MI
is the ability to cross-cast between pointer types without knowing
the name of a common containing class. In my Colorable/Resizable
example, I could take a 'Colorable *' and do a dynamic_cast to
'Resizable *' on it. If the Colorable pointer was actually pointing
to a base Colorable class of a class that also contained a base
Resizable class, the cast would succeed and give me a pointer to that
Resizable class. In the access discriminant case, the best I can do
is to get the containing object and then get its Resizable part, but
that requires knowing about the type of the containing object.

This sort of thing can be useful if you are trying to query an object
to see if it supports a particular interface, for example.

Re: Is the Writing on the Wall for Ada?

[Robert I. Eachus]

Hyman Rosen wrote:

> Anyway, one of the things that this approach misses from true MI
> is the ability to cross-cast between pointer types without knowing
> the name of a common containing class. In my Colorable/Resizable
> example, I could take a 'Colorable *' and do a dynamic_cast to
> 'Resizable *' on it. If the Colorable pointer was actually pointing
> to a base Colorable class of a class that also contained a base
> Resizable class, the cast would succeed and give me a pointer to that
> Resizable class. In the access discriminant case, the best I can do
> is to get the containing object and then get its Resizable part, but
> that requires knowing about the type of the containing object.
> 
> This sort of thing can be useful if you are trying to query an object
> to see if it supports a particular interface, for example.

I don't particularly like or use access discriminants.  As you may have 
noticed, I prefer to use mix-ins.  But as for your assertion above, I 
had to laugh.  If you want you can try to shoot yourself in the foot 
that way in Ada.  If the compiler can't tell at compile time that a 
particular cast will always succeed (or always fail) it will put code in 
to check and raise an exception for the type conversion.

However, you have to go out of your way to have the problem.  In Ada, 
whether you use mix-ins or access discriminants, there is no reason to 
do explicit casting.  If you say (using my code):

     Set(Some_Object, Red);  -- where Red is a value of type Color.

you would get exactly the same result as if you said:

     Set(My_Colors.Colored_Object(Some_Object), Red);

But in most cases where mix-ins are used in Ada, the scope where you CAN 
do the explicit conversion is very small, while the inherited operations 
are visible throughout the scope of the end type.  So who cares?  You 
don't need to do explicit casts, especially explicit casts of pointers 
(ugh!), so why go to the unnecessary effort?

-- 
                                          Robert I. Eachus

"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: Is the Writing on the Wall for Ada?

[Hyman Rosen]

Robert I. Eachus wrote:
 > But as for your assertion above, I had to laugh.

OK. Are you done now?

> If you want you can try to shoot yourself in the foot that way in Ada.

There is no foot shooting involved here, in either C++ or Ada.

> If the compiler can't tell at compile time that a particular cast will
 > always succeed (or always fail) it will put code in to check and raise
 > an exception for the type conversion.

As will the dynamic_cast in C++.

> there is no reason to do explicit casting

Except when there is. These kinds of situations arise when objects are
held in containers, passed around through various pieces of code not
necessarily under your control, and finally handed back to your code.
The object comes in as a pointer to some class, and the situation may
arise when you need to know whether the object is of some other class
type as well. The dynamic_cast will safely tell you, (almost) regardless
of how the two classes are arranged in the inheritance hierarchy of the
most derived type.

This is a moot point in Ada right now, since Ada just has SI. When the
access discriminant style is used, this cross-casting is impossible
unless you go back to the base type first, which means that code which
in C++ would know only about the two interface types must in Ada be aware
of the containing type as well.

Re: Is the Writing on the Wall for Ada?

[Robert I. Eachus]

I said:

> there is no reason to do explicit casting


Hyman Rosen wrote:

> Except when there is. These kinds of situations arise when objects are
> held in containers, passed around through various pieces of code not
> necessarily under your control, and finally handed back to your code.
> The object comes in as a pointer to some class, and the situation may
> arise when you need to know whether the object is of some other class
> type as well. The dynamic_cast will safely tell you, (almost) regardless
> of how the two classes are arranged in the inheritance hierarchy of the
> most derived type.
> 
> This is a moot point in Ada right now, since Ada just has SI. When the
> access discriminant style is used, this cross-casting is impossible
> unless you go back to the base type first, which means that code which
> in C++ would know only about the two interface types must in Ada be aware
> of the containing type as well.

No, it is not a moot point in Ada.  You can create containers for 
classwide types, and you may want to use an operation only valid for a 
subclass of that class.  But as I said:

 > If you say (using my code):

 >    Set(Some_Object, Red);  -- where Red is a value of type Color.

 > you would get exactly the same result as if you said:

 >    Set(My_Colors.Colored_Object(Some_Object), Red);

In this case if say the code was:

declare
    Some_Object: Nothing'Class := Pop(Some_Stack); -- where Nothing is my
    -- original base class and Pop is for some Stack class instantiated
    -- for Nothing'Class.
begin
    Set(Some_Object, Red);
    ...
exception
    when Constraint_Error => Put_Line("Not a member of My_Color'Class.");
    when Program_Error => Put_Line("Oops"); -- there are potential cases.
end;

Again I could do the explicit cast, but why?  The view conversion will 
raise Constraint_Error if it fails.  Actually, there might be a case 
where I wanted to walk a subtree changing colors for objects that had 
them.  Then it would be more appropriate to do:

declare
   Some_Object: Nothing'Class := Next(Some_Tree_Iterator);
begin
   if Some_Object in My_Color'Class
   then
     Set(Some_Object, Red);
   end if;
end;

With the current interface proposal, you could even say "if Some_Object 
in Colored_Object'Class..." and it would do the correct check for 
several different potential instances of Colors that are subclasses of 
Nothing.  The call on Set will work or raise Constraint_Error (or 
Program_Error) for either the interface approach or the mix-in approach.

But notice what is going on here.  In the cases where "true" multiple 
inheritance can't work, Ada resolves the ambiguity based on the 
parameter and result profile, the mix-in order, allows the user to 
directly resolve the overloading, or raises an error.  (Program_Error is 
possible in some cases, such as the call being made where the routine is 
at the wrong accessability level.  Not a problem unless you instantiate 
generics inside subprograms, and aren't careful.)  In many cases where 
other languages that support MI will barf, there is no problem in Ada. 
That was the whole point of my overloading Set and Get.  Since Ada looks 
at the whole profile when doing overload resolution, not just the name, 
you can do this and it will "just work," even though a concrete type can 
inherit dozens of Get and Set operations from different classes.
-- 
                                          Robert I. Eachus

Ryan gunned down the last of his third white wine and told himself it 
would all be over in a few minutes.  One thing he'd learned from 
Operation Beatrix: This field work wasn't for him. -- from Red Rabbit by 
Tom Clancy.

Re: Is the Writing on the Wall for Ada?

[Hyman Rosen]

Robert I. Eachus wrote:
> No, it is not a moot point in Ada.

I still don't think we're talking about the same thing.

Suppose we have the following C++ situation: I have two
class types, IFoo and IBar, that are not under my control
(they come from two separate libraries, perhaps).

I am given a container of pointers to IFoo. Since C++ has
MI, it's possible that some of these IFoo pointers are
actually pointers to objects of a class which inherit both
from IFoo and IBar. Such a class can be created independently
of the definitions of IFoo and IBar. In any case, I do not
have access to the definitions or names of such classes, and
at the time I am given the following task, such classes may
not even exist yet.

I am tasked with finding such IFoo+IBar pointers in the
container and handing them off to a procedure which expects
to get IBar pointers. In C++, the solution is simple - given
an IFoo pointer, I call dynamic_cast<IBar *> on the pointer.
If the result is non-null, then I have a valid IBar pointer,
and I know that the underlying object inherits from both.

So, does Ada have an equivalent to this? Remember, you do not
control IFoo, IBar, the container type, or the implementation
of the type which is trying to be the combination of an IFoo
and an IBar.

Re: Is the Writing on the Wall for Ada?

[Dmitry A. Kazakov]

On Mon, 22 Sep 2003 11:26:39 -0400, Hyman Rosen <hyrosen@mail.com>
wrote:

>Robert I. Eachus wrote:
>> No, it is not a moot point in Ada.
>
>I still don't think we're talking about the same thing.
>
>Suppose we have the following C++ situation: I have two
>class types, IFoo and IBar, that are not under my control
>(they come from two separate libraries, perhaps).
>
>I am given a container of pointers to IFoo. Since C++ has
>MI, it's possible that some of these IFoo pointers are
>actually pointers to objects of a class which inherit both
>from IFoo and IBar. Such a class can be created independently
>of the definitions of IFoo and IBar. In any case, I do not
>have access to the definitions or names of such classes, and
>at the time I am given the following task, such classes may
>not even exist yet.
>
>I am tasked with finding such IFoo+IBar pointers in the
>container and handing them off to a procedure which expects
>to get IBar pointers. In C++, the solution is simple - given
>an IFoo pointer, I call dynamic_cast<IBar *> on the pointer.
>If the result is non-null, then I have a valid IBar pointer,
>and I know that the underlying object inherits from both.
>
>So, does Ada have an equivalent to this? Remember, you do not
>control IFoo, IBar, the container type, or the implementation
>of the type which is trying to be the combination of an IFoo
>and an IBar.

I think it is a good example of bad design. (:-)) It does not prove a
necessity of MI (*)

Returning to the topic, the container of access IFoo'Class (an
equivalent to C++ &IFoo) has the contract to keep objects of IFoo. It
is a bad design if casting to IBar is required. There should be either
a specialized container (**).  Alternatively, the design of the
container should provide some identification methods, i.e. the
container should know something about IBar.

What I wished to say is that your example is bad, because MI is not
supposed to remedy one's design faults.

---
(*) MI need not to be advocated. It is like to prove whether negative
numbers are necessary. Opponents might provide you with a plethora of
work-agounds, they will tell you how unsafe are negative numbers are
(when used to count crows), how difficult to a compiler to support
them (because you need '-' and '+' in the character set), etc (:-))
You will never win this game!

---
(**) BTW a great unsolvable problem in both Ada and C++, both with MI
or without, is to make a container of a subtype a subtype of the
container of the base type. Which highlights present problems with ADT
and *helpless* attempts to solve this using templates.

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

Re: Is the Writing on the Wall for Ada?

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> Returning to the topic, the container of access IFoo'Class (an
> equivalent to C++ &IFoo) has the contract to keep objects of IFoo. It
> is a bad design if casting to IBar is required. There should be either
> a specialized container (**).  Alternatively, the design of the
> container should provide some identification methods, i.e. the
> container should know something about IBar.
> 
> What I wished to say is that your example is bad, because MI is not
> supposed to remedy one's design faults.

If I use a GUI library, I should not be surprised to find that the
library speaks in terms of pointers to and containers of things like
windows, cursors, fonts, and so forth.

If I use a persistence package, say, I should not be surprised that
it speaks of things like Serializable.

I should be able to combine these things into a single object which
has the behavior of both without having to redesign (and reimplement!)
the libraries which I am trying to use. While having lots of type tests
in bad, occasionally you do have to pass your object into the maw of
a third party library and get it back as a base pointer which you have
to turn back into your object.

You are calling this bad design, and in turn you propose that every
library must know about every other one, including those that have not
yet been written.

Re: Is the Writing on the Wall for Ada?

[Dmitry A. Kazakov]

On Tue, 23 Sep 2003 08:24:28 -0400, Hyman Rosen <hyrosen@mail.com>
wrote:

>Dmitry A. Kazakov wrote:
>> Returning to the topic, the container of access IFoo'Class (an
>> equivalent to C++ &IFoo) has the contract to keep objects of IFoo. It
>> is a bad design if casting to IBar is required. There should be either
>> a specialized container (**).  Alternatively, the design of the
>> container should provide some identification methods, i.e. the
>> container should know something about IBar.
>> 
>> What I wished to say is that your example is bad, because MI is not
>> supposed to remedy one's design faults.
>
>If I use a GUI library, I should not be surprised to find that the
>library speaks in terms of pointers to and containers of things like
>windows, cursors, fonts, and so forth.
>
>If I use a persistence package, say, I should not be surprised that
>it speaks of things like Serializable.
>
>I should be able to combine these things into a single object which
>has the behavior of both without having to redesign (and reimplement!)
>the libraries which I am trying to use.

This is again a bad example. A persistent Window will probably have
other implementation. Because, usually it is required to have an
ability to work with persistent objects directly in the data base.
Compare it with hardware and memory-mapped device contexts. Neither
can inherit much from another. This would be interface MI, which is
already accepted (to my utmost amazement (:-)).

>While having lots of type tests
>in bad, occasionally you do have to pass your object into the maw of
>a third party library and get it back as a base pointer which you have
>to turn back into your object.
>
>You are calling this bad design, and in turn you propose that every
>library must know about every other one, including those that have not
>yet been written.

I do not propose that. There are many ways to decouple things. A need
to cast usually indicates a design problem, as a matter of fact. The
source of the problem (either a language deficiency or a programmer's
fault)  is another story. Should I come to the situation you describe,
I'd probably redesign the container to make it more specialized. Doing
so I will have a variety of possibilities not to use MI.

Again your example neither in favour of nor against MI.

Better is to make streams controlled. Me and other have several times
mentioned it, but nobody from the opposite side responded. This is an
indication that the example is good. (:-))

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

Re: Is the Writing on the Wall for Ada?

[Hyman Rosen]

Dmitry A. Kazakov wrote:
 > Should I come to the situation you describe,
> I'd probably redesign the container

You cannot redesign the container because the container
resides within the implementation of the GUI library.
That's the point.

Re: Is the Writing on the Wall for Ada?

[Dmitry A. Kazakov]

On Tue, 23 Sep 2003 09:38:39 -0400, Hyman Rosen <hyrosen@mail.com>
wrote:

>Dmitry A. Kazakov wrote:
> > Should I come to the situation you describe,
>> I'd probably redesign the container
>
>You cannot redesign the container because the container
>resides within the implementation of the GUI library.
>That's the point.

I will probably convert one container to another when passing it to
GUI.

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

Re: Is the Writing on the Wall for Ada?

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> I will probably convert one container to another when passing it to GUI.

We're talking about containers within the GUI, not yours.

Re: Is the Writing on the Wall for Ada?

[Dmitry A. Kazakov]

On Tue, 23 Sep 2003 10:36:05 -0400, Hyman Rosen <hyrosen@mail.com>
wrote:

>Dmitry A. Kazakov wrote:
>> I will probably convert one container to another when passing it to GUI.
>
>We're talking about containers within the GUI, not yours.

This is why I convert mine first.

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

Re: Is the Writing on the Wall for Ada?

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> This is why I convert mine first.

Sigh.

Re: Is the Writing on the Wall for Ada?

[Matthew Heaney]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> writes:

> (**) BTW a great unsolvable problem in both Ada and C++, both with MI
> or without, is to make a container of a subtype a subtype of the
> container of the base type. Which highlights present problems with ADT
> and *helpless* attempts to solve this using templates.

Au contraire.  The *simplest* way to solve that problem is using
templates.

package P is
   type T is tagged null record;
   procedure Op (O : in out T);
end P;

package P.C is
   type NT is new T with null record;
   procedure Op (O : in out T);
end;


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

package T_Sets is
   new Ada.Containers.Sets.Sorted.Unbounded (P.T);

function "<" (L, R : P.C.NT) return Boolean is ...;

package NT_Sets is
   new Ada.Containers.Sets.Sorted.Unbounded (P.C.NT);

  T_Set : T_Sets.Container_Type;
  NT_Set : NT_Sets.Container_Type;

Now let's say you want an algorithm that can operate over the items in
either of the set containers declared above.  After all, that why you
wanted NT_Set to be a subtype of T_Set.  So let's just abstract-away the
container:

   generic
      type Iterator_Type is private;
      with procedure Succ (Iter : Iterator_Type)
         return Iterator_Type is <>;
      function To_T (Iter : Iterator_Type)
         return T_Class_Access;
   procedure Generic_Algorithm
     (First, Back : Iterator_Type);

Now I can do this:

   function To_T is
      new T_Sets.Generic_Element (T_Class_Access);  --check this

   function To_T is
      new NT_Sets.Generic_Element (T_Class_Access); --ditto

And now I do this:

   procedure Algorithm is
     new Generic_Algorithm (T_Sets.Iterator_Type);

   procedure Algorithm is
     new Generic_Algorithm (NT_Sets.Iterator_Type);

And so now I can do this:

   Algorithm (First (T_Set), Back (T_Set));
   Algorithm (First (NT_Set), Back (NT_Set));

Problem solved.  No MI or base types or inheritance or interfaces or any
other crap is needed.  Generics work just fine thank you very much.

Re: Is the Writing on the Wall for Ada?

[Dmitry A. Kazakov]

On Wed, 24 Sep 2003 02:13:15 GMT, Matthew Heaney
<matthewjheaney@earthlink.net> wrote:

>Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> writes:
>
>> (**) BTW a great unsolvable problem in both Ada and C++, both with MI
>> or without, is to make a container of a subtype a subtype of the
>> container of the base type. Which highlights present problems with ADT
>> and *helpless* attempts to solve this using templates.
>
>Au contraire.  The *simplest* way to solve that problem is using
>templates.
>
>package P is
>   type T is tagged null record;
>   procedure Op (O : in out T);
>end P;
>
>package P.C is
>   type NT is new T with null record;
>   procedure Op (O : in out T);
>end;
>
>
>function "<" (L, R : P.T) return Boolean is ...;
>
>package T_Sets is
>   new Ada.Containers.Sets.Sorted.Unbounded (P.T);
>
>function "<" (L, R : P.C.NT) return Boolean is ...;
>
>package NT_Sets is
>   new Ada.Containers.Sets.Sorted.Unbounded (P.C.NT);
>
>  T_Set : T_Sets.Container_Type;
>  NT_Set : NT_Sets.Container_Type;

T_Set and NT_Set are unrelated types. So one cannot be a
subtype/subclass of another. It means that I cannot write a
NON-GENERIC program operating on both.

>Now let's say you want an algorithm that can operate over the items in
>either of the set containers declared above.  After all, that why you
>wanted NT_Set to be a subtype of T_Set.  So let's just abstract-away the
>container:
>
>   generic
>      type Iterator_Type is private;
>      with procedure Succ (Iter : Iterator_Type)
>         return Iterator_Type is <>;
>      function To_T (Iter : Iterator_Type)
>         return T_Class_Access;
>   procedure Generic_Algorithm
>     (First, Back : Iterator_Type);
>
>Now I can do this:
>
>   function To_T is
>      new T_Sets.Generic_Element (T_Class_Access);  --check this
>
>   function To_T is
>      new NT_Sets.Generic_Element (T_Class_Access); --ditto
>
>And now I do this:
>
>   procedure Algorithm is
>     new Generic_Algorithm (T_Sets.Iterator_Type);
>
>   procedure Algorithm is
>     new Generic_Algorithm (NT_Sets.Iterator_Type);
>
>And so now I can do this:
>
>   Algorithm (First (T_Set), Back (T_Set));
>   Algorithm (First (NT_Set), Back (NT_Set));
>
>Problem solved.  No MI or base types or inheritance or interfaces or any
>other crap is needed.  Generics work just fine thank you very much.

No, the problem is not solved. You just pushed it to another place. As
a designer of the container types, you said that it is not your
business, but one of a user. Who have to keep in mind that they are
different types and implement all subprograms working with them
generic.

After all, your method is applicable not only to containers, but also
to any pair of base-descendant tagged types. Why do we have them? We
could keep them unrelated and re-write everything in generics.
Formally it should be possible, just because both generics and
class-wides represent generic programming and thus in much overlap.
But techincally it is absurd.

You should have expected me answering something like this. (:-))
Because my "swan-song" is to do generic programming *exclusively* with
class-wides kicking generics out!

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

Re: Is the Writing on the Wall for Ada?

[Matthew Heaney]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> writes:

> T_Set and NT_Set are unrelated types. So one cannot be a
> subtype/subclass of another. It means that I cannot write a
> NON-GENERIC program operating on both.

Your problem was to have an operation to traverse a container of
Element_Type, and to be able to reuse the same operation over a
container whose element type derives from Element_Type.

The solution I showed does that.  Whether it's generic vs. non-generic
shouldn't matter.

Re: Is the Writing on the Wall for Ada?

[Dmitry A. Kazakov]

On Wed, 24 Sep 2003 11:43:08 GMT, Matthew Heaney
<matthewjheaney@earthlink.net> wrote:

>Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> writes:
>
>> T_Set and NT_Set are unrelated types. So one cannot be a
>> subtype/subclass of another. It means that I cannot write a
>> NON-GENERIC program operating on both.
>
>Your problem was to have an operation to traverse a container of
>Element_Type, and to be able to reuse the same operation over a
>container whose element type derives from Element_Type.
>
>The solution I showed does that.  Whether it's generic vs. non-generic
>shouldn't matter.

It matters, because generics cannot be put into a library, because
they need to be instantiated. The solution is unhandy and too complex.
What I need is a quite simple and understandable thing. I want to take
a container type and put a constraint on it. In terms of
discriminants:

   -- This is not Ada!
type Container (Element_Tag : T_Set'Class'Tag) is ...;
subtype Specialized_Container is Container (NT_Set'Class'Tag);

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

Re: Is the Writing on the Wall for Ada?

[Robert I. Eachus]

Hyman Rosen wrote:

> So, does Ada have an equivalent to this? Remember, you do not
> control IFoo, IBar, the container type, or the implementation
> of the type which is trying to be the combination of an IFoo
> and an IBar.


The equivalent in Ada is:

if Object in IBar'Class then...

More to the point:

if Object in IBar'Class and Object in IFoo'Class then...

may be true.

if Object in IBar and Object in IFoo then...

Will never be true unless IBar is a renaming or subset of IFoo or 
vice-versa.   Every object is a member of exactly one specific (base) 
type, but it may be a member of many classwide types.
-- 
                                         Robert I. Eachus

Ryan gunned down the last of his third white wine and told himself it 
would all be over in a few minutes.  One thing he'd learned from 
Operation Beatrix: This field work wasn't for him. --from Red Rabbit by 
Tom Clancy.

Re: Is the Writing on the Wall for Ada?

[Hyman Rosen]

Robert I. Eachus wrote:
> More to the point:
> if Object in IBar'Class and Object in IFoo'Class then...

Yes, and this will be thing to do once Ada has interfaces.
Until then, one of IBar and IFoo will be a supertype of the
other - they can't be independent.

> if Object in IBar and Object in IFoo then...
> 
> Will never be true unless IBar is a renaming or subset of IFoo or 
> vice-versa.   Every object is a member of exactly one specific (base) 
> type, but it may be a member of many classwide types.

Yes, and as I have been saying, there's no particular reason
for this restriction to exist. At least Ada's interfaces will
allow null implementations of the methods, which is a small
step forward from Java's interfaces.

Oh, by the way, is it true that "virtual" methods of Ada objects
can only be procedures and not functions?

Re: Is the Writing on the Wall for Ada?

[Dmitry A. Kazakov]

On Tue, 23 Sep 2003 08:29:56 -0400, Hyman Rosen <hyrosen@mail.com>
wrote:

>Oh, by the way, is it true that "virtual" methods of Ada objects
>can only be procedures and not functions?

Untrue. "virtual" = dispatching = covariant. Ada supports dispatching
functions. Moreover one can dispatch on the result, one can dispatch
on an anonymous pointer. Actually the oppositive is true. Any
operation is "virtual" except ones of non-tagged or class-wide types
if declared before the freezing point (within {} brackets, in C++
terms).

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

Re: Is the Writing on the Wall for Ada?

[Matthew Heaney]

Hyman Rosen <hyrosen@mail.com> writes:

> Oh, by the way, is it true that "virtual" methods of Ada objects can
> only be procedures and not functions?

Huh?  Of course not:

   type T is abstract tagged null record;

   function Op (O : T) return Integer is abstract;

You might be thinking of functions that return a tagged type:

   function Op2 return T is abstract;

In the cases where there's a primitive op that returns the type, then
you must override the function or the type "goes abstract."  Think about
this:

   O : T'Class := ...;
begin
   O := Op2;  -- I think that will work

Here we dispatch on the return type.  There are also "tag indeterminate"
expressions, where the compiler figures out which function to call based
on context.

Re: Is the Writing on the Wall for Ada?

[Hyman Rosen]

Matthew Heaney wrote:
> Huh?  Of course not:

Yeah, silly me. I think I got confused by reading the MI AI and
seeing that all the examples were procedures and not functions.

Are the functions allowed to modify the state of the object?
I assume no, since functions only take IN parameters.

Re: Is the Writing on the Wall for Ada?

[Matthew Heaney]

Hyman Rosen <hyrosen@mail.com> writes:

> Are the functions allowed to modify the state of the object?  I assume
> no, since functions only take IN parameters.

Never assume.  The answer is, "it depends."

Functions can of course have access parameters:

   type T is record ... end record;

   function Modify (O : access T) return Whatever;

This is a function that can modify its parameter O, because it's passed
an access parameter which is basically the same as inout.

If the type is limited, then you can use the trick discovered by that
other Rosen:

   type T;
   type Rosen_Trick (O : access T) is limited null record;

   type T is limited record
      Jean_Pierre : Rosen_Trick (T'Access);
      ...
   end record;

   function Modify (O : in T) return Whatever is
      Modifiable : T renames O.Jean_Pierre.O.all;
   begin
      ... -- modify Modifiable as desired
   end;

In fact the bounded linked-list containers in my AI-302 proposal are
implemented using the Rosen Trick, precisely because I have in-params
that need to change container state.

If you have a non-limited type that is pass-by-reference, then you can
use address-to-access conversions to get a variable view of the in-param
and then modify it that way.  You have to leave the type system very
briefly so be careful.

Functions in Ada are basically value-returning subprograms that can
modify state just like procedures, but aren't allowed to say that they
modify state.  This is one thing Ada got wrong and C++ got right.
Ideology should never trump reality.

Re: Is the Writing on the Wall for Ada?

[Dmitry A. Kazakov]

On Wed, 24 Sep 2003 03:52:43 GMT, Matthew Heaney
<matthewjheaney@earthlink.net> wrote:

>Functions in Ada are basically value-returning subprograms that can
>modify state just like procedures, but aren't allowed to say that they
>modify state.  This is one thing Ada got wrong and C++ got right.
>Ideology should never trump reality.

Right, but also to have pure functions would be useful (pragma Pure
for functions).

Better if it were the default for any subroutine declared as
"function". And also to allow return values for subroutines declared
as "procedure".

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

Re: Is the Writing on the Wall for Ada?

[Warren W. Gay VE3WWG]

Matthew Heaney wrote:
> Hyman Rosen <hyrosen@mail.com> writes:
>>Matthew Heaney wrote:
>>
>>>The multiple views idiom in Ada95 doesn't preclude that at all.
>>
>>It's fine, but what's wrong with letting the language handle the
>>plumbing for you, instead of making you do it yourself? And the
>>bit about access discriminants getting initialized with the address
>>of the object containing them seems a little gimmicky to me, compared
>>to arbitrary constructors.
> 
> Ada95 doesn't have MI.  It will never have MI.  So what to do?

The point is that a more natural language interface is needed
for MI. Remember that Ada included a more natural interface
to such ideas as tasking and protected objects. MI does not
need to be an orphan. This is what I am hearing in comp.lang.ada,
and sometimes thinking myself ;-)

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Is the Writing on the Wall for Ada?

[Robert I. Eachus]

Hyman Rosen wrote:

> Thereby exhibiting the simple lack of courage to add multiple
> inheritance. Why should we limit to inheriting from one type?
> What is it about one that makes it better than two or more?

Actually with interfaces added, Ada will have two ways of doing multiple 
inheritance, mix-ins and interfaces.  This is fine because each is a 
solution for different design idioms.

Why not add "full" multiple inheritance and be done with it?  Sorry 
there is no such thing.  Or if you prefer, deriving from several 
interface classes with no privileged parent does exactly that.

What having a single parent allows is inheriting both an interface and 
an implementation.  You can't inherit multiple implementations, at least 
not and have a single concrete implementation.  Let me give an example 
so you can see the problems.  Let's say I have two point types, one of 
which uses Cartesian coordinates, one of which uses polar coordinates.

How do I implement multiple inheritance of both representations?  It 
can't be done.  A representation that stored both cartesian and polar 
coordinates would be possible.  But the compiler can't automatically 
generate the code to insure that both representations agree.  In fact if 
you think about the representable points in both representations, they 
are different sets!  Some points are in both sets, for example those on 
the X and Y axis but almost all points in one representation do not have 
exact representations in the other.  In addition, some of the points in 
the cartesian domain will be at least (Sqrt(2)-1) * Element'Last away 
from any point in the polar domain.

Notice that if I do interface inheritance from the two concrete types, I 
can program the underlying routines to do something sensible when say 
adding a polar displacement to a cartesian point.  By the way, notice 
that in Ada if I want I can provide a type with both cartesian and polar 
implementations.  As a programmer, I can go further and add the 
"missing" operations like adding a cartesian point to a polar point.  Do 
everything right and "+" will just work.  That is a kind of multiple 
implementations of a type that I can live with, and I don't know of any 
other language where you can do such overloading.  (It is tricky enough 
to get right in Ada...)

Interface inheritance will make doing this sort of thing easier in Ada.
But even now, Ada is providing more multiple inheritance than many 
languages which are accepted as having "full" multiple inheritance. 
Sorry if that doesn't satisfy you.

--
                                          Robert I. Eachus

"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: Is the Writing on the Wall for Ada?

[Hyman Rosen]

Robert I. Eachus wrote:
 > Let's say I have two point types, one of which uses Cartesian
 > coordinates, one of which uses polar coordinates.

Quite appropriately for an Ada newsgroup, you are setting up a
straw man argument. The most typical use for multiple inheritance
involves inheriting from unrelated classes. And in C++, combining
multiple inheritance and templates is extraordinarily powerful.

In any case, examples of cases where multiple inhertiance is not
appropriate are not arguments against multiple inheritance. If I
gave you an example where tasking was inappropriate, would that be
an argument to remove it from the language?

Re: Is the Writing on the Wall for Ada?

[Robert I. Eachus]

Hyman Rosen wrote:

> Quite appropriately for an Ada newsgroup, you are setting up a
> straw man argument. The most typical use for multiple inheritance
> involves inheriting from unrelated classes. And in C++, combining
> multiple inheritance and templates is extraordinarily powerful.

I used a simple example to make my argument more concrete.  But the 
argument doesn't depend on the example.  If you have two completely 
non-interacting roles that you want to combine in a single type, Ada 
already supports that type of MI very well through mix-ins.  But when 
you want to inherit from two types that have operations in common, it 
doesn't work without additional coding no matter what the language.

> In any case, examples of cases where multiple inhertiance is not
> appropriate are not arguments against multiple inheritance. If I
> gave you an example where tasking was inappropriate, would that be
> an argument to remove it from the language?

But the case I gave is one where multiple inheritance is appropriate. 
It just has to be interface inheritance.  In other words I can take an 
interface that assumes polar representation and an interface that 
assumes cartesian representation, and provide a type/class that supports 
both interfaces.

The point it though, that there is work to be done to convert between 
polar and cartesian representation, and the compiler can't do that 
automatically.  It takes work--and thought--by the programmer creating 
the class.  Ada won't change that, nor will any language that supports 
multiple inheritance.

What Ada 200Y is planning to do is to make it easier to do the makework 
part of that.  You could directly inherit from a cartesian type and add 
the polar functions through an interface, or vice-versa.  Or you could 
bring in both representations through interface inheritance and do more 
implementation work.  What you can't do, in Ada or any language is 
inherit directly from two types/classes with different state and get 
other than junk.

Let me follow through on that, since you didn't seem to get it.  The 
Cartesian implementation might have a representation:

type Cartesian is record X,Y: Float; end record;

and the Polar type:

type Polar is record R, Theta: Float; end record;

we could even have a pair of procedures:

procedure Set_Point(P: Cartesian; X,Y: Float) is
begin P := (X,Y); end Set_Point;

procedure Set_Point(P: Polar; R,Theta: Float) is
begin P := (R, Theta); end Set_Point;

But for the union type, at least one of those implementations has to be 
wrong.  For example, if the ACTUAL representation is cartesian, we need:

procedure Set_Point(P: Union; R, Theta: Float) is
begin P := (R * sin (Theta), R * cos (Theta)); end Set_Point;

(Of course, in an actual implementation I would have different derived 
types for X and Y, R, and Theta, and Theta would probably be a 
fixed-point type.  But let's ignore that for now.)

This is why the new interfaces in Ada will allow direct derivation from 
one type, and adding in as many interfaces as you wish.  Or, if you 
prefer, no direct derivation and lots of interfaces.  But you can only 
directly derive from one parent type, because that is the way the world 
works, not due to any limitations we are building into Ada.

Notice that in my example, which was why I chose it, that the actual 
implementation of the two potential parent types may match.  But the 
MEANINGS of the data fields are different.

Of course, if you want to inherit from types A and B in Ada, and the 
contents of A can be expressed as a subset of the contents of B, you can 
already do that in Ada:

type A is...
...
type B is new A with...;
...
type C is new B...;

-- 
                                       Robert I. Eachus

"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: Is the Writing on the Wall for Ada?

[Stephen Leake]

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

> But the case I gave is one where multiple inheritance is appropriate.
> It just has to be interface inheritance.  In other words I can take an
> interface that assumes polar representation and an interface that
> assumes cartesian representation, and provide a type/class that
> supports both interfaces.

I think to make this argument truly convincing, you need to show how
it currently works in C++, and why that is bad. Showing that Ada is ok
the way it is will not convince anyone who is sure it could be better
if it was more like C++.

-- 
-- Stephe

Re: Is the Writing on the Wall for Ada?

[Robert I. Eachus]

Stephen Leake wrote:

>>But the case I gave is one where multiple inheritance is appropriate.
>>It just has to be interface inheritance.  In other words I can take an
>>interface that assumes polar representation and an interface that
>>assumes cartesian representation, and provide a type/class that
>>supports both interfaces.
> 
> 
> I think to make this argument truly convincing, you need to show how
> it currently works in C++, and why that is bad. Showing that Ada is ok
> the way it is will not convince anyone who is sure it could be better
> if it was more like C++.

No, someone arguing the other side needs to demonstrate what can be done 
in language X that can't be done as well or better in Ada (with or 
without interfaces added).  The examples you say are needed have all 
been thoroughly discussed by the ARG. (And are available on the web see: 
http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-00251.TXT) We are 
adding interfaces to Ada because it allows a different style of multiple 
inheritance than mix-ins, which of course are currently well supported 
and used in Ada.

I have no problem with adding interfaces, since they are a better match 
to some styles and will be useful for interfacing with other languages 
that have interfaces.  But this self-flagellation by the Ada community 
is just not appropriate in this case.  Other languages support MI 
through interfaces, fine.  The exact same code will work in Ada with 
interfaces added.  Or you can change the idiom and mix interfaces and 
mix-ins.  But type inheritance cannot be from two concrete parents, no 
matter what the language--one parent has to be abstract.  So anyone who 
condemns Ada for not adding what cannot be done needs to get a life.

--
                                      Robert I. Eachus

"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: Is the Writing on the Wall for Ada?

[Stephen Leake]

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

> Stephen Leake wrote:
> 
> > I think to make this argument truly convincing, you need to show how
> > it currently works in C++, and why that is bad. Showing that Ada is ok
> > the way it is will not convince anyone who is sure it could be better
> > if it was more like C++.
> 
> No, someone arguing the other side needs to demonstrate what can be
> done in language X that can't be done as well or better in Ada (with
> or without interfaces added).  

Hmm. I'm talking to a mostly reasonable C++ advocate. She says "C++
has multiple inheritance, and it works fine. Why don't you just put
that in Ada?". She doesn't know Ada. To be convincing, I need an
example, _expressed in C++_, that shows that C++ multiple inheritance
does _not_ "work fine". 

I think I remember seeing such an example once, and I could probably
construct one from what you have been saying. It would be nice if
there were such an example in the FAQ or on AdaIC, so we could all
reference it; this comes up often.

> The examples you say are needed have all been thoroughly discussed
> by the ARG. (And are available on the web see:
> http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-00251.TXT) 

Well, there is no C++ there (I didn't really expect to see any). Maybe
I'll find time to convert one of those Ada examples into C++.

> We are adding interfaces to Ada because it allows a different style
> of multiple inheritance than mix-ins, which of course are currently
> well supported and used in Ada.

I agree this is the best way to go. I'm just looking for a concise
counter example for the C++ advocates.

> But type inheritance cannot be from two concrete parents, no matter
> what the language--one parent has to be abstract. 

You and I and many others understand this; still others do not.

> So anyone who condemns Ada for not adding what cannot be done needs
> to get a life.

Or learn from a good example. They have all seen examples of how the
C++ way does work. None of the C++ books say "here's how we do
multiple inheritance, even though it really can't be done this way"!

-- 
-- Stephe

Re: Is the Writing on the Wall for Ada?

[Hyman Rosen]

Stephen Leake wrote:
>>But type inheritance cannot be from two concrete parents, no matter
>>what the language--one parent has to be abstract. 
> 
> You and I and many others understand this; still others do not.

That is an argument which is ridiculous on its face, so perhaps
you can explain the deep meaning that makes it so?

The simple counterargument is that when you choose to implement
more than one interface in a class, it's possible, and even likely,
that there already exist concrete classes which implement all or
part of those interfaces in a way which is suitable for what you
need, and therefore your class can inherit from more than one of
these concrete classes to gain those implementations for free.

One simple example is often found in Java, where "adapter" classes
implement all functions of an interface in a no-op manner, so that
clsses which need only a small number of methods to do something
don't need to define all of the others. I easily see the need for
inheriting from more than one such adapter.

In C++ I can do this, or I can mimic interface-only inheritance.

Re: Is the Writing on the Wall for Ada?

[Robert I. Eachus]

Hyman Rosen wrote:
> Stephen Leake wrote:
> 
>>> But type inheritance cannot be from two concrete parents, no matter
>>> what the language--one parent has to be abstract. 
>>
>>
>> You and I and many others understand this; still others do not.
> 
> 
> That is an argument which is ridiculous on its face, so perhaps
> you can explain the deep meaning that makes it so?
> 
> The simple counterargument is that when you choose to implement
> more than one interface in a class, it's possible, and even likely,
> that there already exist concrete classes which implement all or
> part of those interfaces in a way which is suitable for what you
> need, and therefore your class can inherit from more than one of
> these concrete classes to gain those implementations for free.

I was going to answer your comment above, but this makes it obvious you 
must have some other definition in mind for inheriting from a concrete 
class than direct inheritance.  How about an example of inheriting from 
two concrete classes?  I could suppose you are talking about mix-ins, 
but Ada already supports MI for mix-ins, and since Ada will support 
interface inheritance from more than one interface, it can't be that either.

--
                                          Robert I. Eachus

"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: Is the Writing on the Wall for Ada?

[olehjalmar kristensen - Sun Microsystems - Trondheim Norway]

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

<snip>

    RIE> interfaces  and mix-ins.  But  type inheritance  cannot  be from  two
    RIE> concrete parents,  no matter what  the language--one parent has  to be
    RIE> abstract. So  anyone who condemns Ada  for not adding  what cannot be
    RIE> done needs to get a life.

What do you mean by "concrete parents"?

class a {
public:
  void foo();
};

class b {
public:
  void bar();
};

class c: public a, public b{
};

Works just fine, and there is nothing abstract about a and b. What's
the problem?

    RIE> --
    RIE>                                       Robert I. Eachus

    RIE> "As  far as  I'm  concerned,  war always  means  failure." --  Jacques
    RIE> Chirac, President of France

    RIE> "As far as France is concerned, you're right." -- Rush Limbaugh

Re: Is the Writing on the Wall for Ada?

[Dmytry Lavrov]

olehjalmar kristensen - Sun Microsystems - Trondheim Norway wrote:
> 
> >>>>> "RIE" == Robert I Eachus <rieachus@attbi.com> writes:
> 
> <snip>
> 
>     RIE> interfaces  and mix-ins.  But  type inheritance  cannot  be from  two
>     RIE> concrete parents,  no matter what  the language--one parent has  to be
>     RIE> abstract. So  anyone who condemns Ada  for not adding  what cannot be
>     RIE> done needs to get a life.
> 
> What do you mean by "concrete parents"?
> 
> class a {
> public:
>   void foo();
> };
> 
> class b {
> public:
>   void bar();
> };
> 
> class c: public a, public b{
> };
> 
> Works just fine, and there is nothing abstract about a and b. What's
> the problem?
> 
>     RIE> --
>     RIE>                                       Robert I. Eachus
> 
>     RIE> "As  far as  I'm  concerned,  war always  means  failure." --  Jacques
>     RIE> Chirac, President of France
> 
>     RIE> "As far as France is concerned, you're right." -- Rush Limbaugh


IMO,if there are difference between inheritance and having class inside
other  class(so called delegation),it's problem of bad language design.

Re: Is the Writing on the Wall for Ada?

[Dmitry A. Kazakov]

On Mon, 15 Sep 2003 20:47:03 +0400, Dmytry Lavrov <m31415@mail.ru>
wrote:

>IMO,if there are difference between inheritance and having class inside
>other  class(so called delegation),it's problem of bad language design.

How so? It is an implementation detail. Inheritance means that you
re-use something from the base type. This does not imply that you have
to re-use everything, including the representation of the base.

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

Re: Is the Writing on the Wall for Ada?

[Mark A. Biggar]

Dmytry Lavrov wrote:

> IMO,if there are difference between inheritance and having class inside
> other  class(so called delegation),it's problem of bad language design.

No, this is the central paradox of OO theory.  It is very often the case
that the implementation inheritance relationship and the Lyskov
substitutability (interface) inheritance relationship between two
classes are in direct opposition to each other.  For example, you really
want integer isa float, so that you can use an integer like a float,
but you also really need to use integers (for exponents) in the
implementation of floats.  This means that languages really want to
support both interface and implementation inheritance as explicitly
different features.  There are several ways that two classes can be
related:

1) A isa B   (lyskov substitutability)

2) A is implemented using a B   (delegation)

3) A contains a B as a member    (possibly multiple indexes instances)

4) no relation at all.

And a language needs to support all of these.

-- 
mark@biggar.org
mark.a.biggar@comcast.net

Re: Is the Writing on the Wall for Ada?

[Jacob Sparre Andersen]

Olehjalmar Kristensen wrote:
>>>>>>"RIE" == Robert I Eachus <rieachus@attbi.com> writes:

>     RIE> interfaces  and mix-ins.  But  type inheritance  cannot  be from  two
>     RIE> concrete parents,  no matter what  the language--one parent has  to be
>     RIE> abstract. So  anyone who condemns Ada  for not adding  what cannot be
>     RIE> done needs to get a life.
> 
> What do you mean by "concrete parents"?

Although I agree that "non-abstract parents" is the most obvious 
interpretation of "concrete parents", I understood it as 
"data-containing non-abstract parents".

> class a {
> public:
>   void foo();
> };
> 
> class b {
> public:
>   void bar();
> };
> 
> class c: public a, public b{
> };
> 
> Works just fine,

Looks that way to me too.  But if a and b had contained data, for 
example position data in respectively spherical and rectangular 
coordinates (to reuse an earlier example), then you would most likely 
end up in trouble.

Jacob
-- 
Rent-a-Minion Inc. Because good help is so hard to find.

Re: Is the Writing on the Wall for Ada?

[Ole-Hjalmar Kristensen]

>>>>> "JSA" == Jacob Sparre Andersen <sparre@crs4.it> writes:

    JSA> Olehjalmar Kristensen wrote:
    >>>>>>> "RIE" == Robert I Eachus <rieachus@attbi.com> writes:

    RIE> interfaces  and mix-ins.  But  type inheritance  cannot  be from  two
    RIE> concrete parents,  no matter what  the language--one parent has  to be
    RIE> abstract. So  anyone who condemns Ada  for not adding  what cannot be
    RIE> done needs to get a life.
    >> What do you mean by "concrete parents"?


    JSA> Although  I agree  that  "non-abstract parents"  is  the most  obvious
    JSA> interpretation   of   "concrete   parents",   I   understood   it   as
    JSA> "data-containing non-abstract parents".

I understand now, by see below.

    >> class a {
    >> public:
    >> void foo();
    >> };
    >> class b {

    >> public:
    >> void bar();
    >> };
    >> class c: public a, public b{

    >> };
    >> Works just fine,


    JSA> Looks that  way to me  too. But  if a and  b had contained  data, for
    JSA> example  position  data  in  respectively  spherical  and  rectangular
    JSA> coordinates (to reuse an earlier  example), then you would most likely
    JSA> end up in trouble.


    JSA> Jacob
    JSA> -- 
    JSA> Rent-a-Minion Inc. Because good help is so hard to find.

Depends on what you expect. As you can see, there is no conflict as
such. On the other hand, a and b can not access each others variables
either.
In the general case I agree, there may be problems, but I think that
the compiler rejecting cases it cannot resolve properly is quite acceptable.

file multi.cc:

#include <stdio.h>

class a
{
public:
  int x;
  a() : x(13) {}
  void foo(){printf("%p %d\n",&x,x);};
};

class b
{
public:
  int x;
  b() : x(666) {}
  void bar(){printf("%p %d\n",&x,x);};
};

class c : public a, public b
{
};

main()
{
  c cc;
  cc.foo();
  cc.bar();
}

ok145024@khepri06:~/div> ./multi
8046abc 13
8046ac0 666

To let the two classes use each others functions and data you can do
the following:

file multi2.cc:

#include <stdio.h>

class base
{
public:
  virtual int x1() = 0;
  virtual int x2() = 0;
};

class a : public virtual base
{
public:
  int x;
  a() : x(13) {}
  int x1() {return x;}
  void foo(){printf("%p %d %d\n",&x,x,x2());};
};

class b : public virtual base
{
public:
  int x;
  b() : x(666) {}
  int x2() {return x;}
  void bar(){printf("%p %d %d\n",&x,x,x1());};
};

class c : public a, public b
{
};

main()
{
  c cc;
  cc.foo();
  cc.bar();
}

ok145024@khepri06:~/div> ./multi2
8046ab4 13 666
8046abc 666 13

-- 
This page intentionally left blank

Re: Is the Writing on the Wall for Ada?

[Robert I. Eachus]

Ole-Hjalmar Kristensen wrote:
>>>>>>"JSA" == Jacob Sparre Andersen <sparre@crs4.it> writes:
>>>>>
> 
>     JSA> Olehjalmar Kristensen wrote:
>     >>>>>>> "RIE" == Robert I Eachus <rieachus@attbi.com> writes:
> 
>     RIE> interfaces  and mix-ins.  But  type inheritance  cannot  be from  two
>     RIE> concrete parents,  no matter what  the language--one parent has  to be
>     RIE> abstract. So  anyone who condemns Ada  for not adding  what cannot be
>     RIE> done needs to get a life.
>     >> What do you mean by "concrete parents"?
> 
> 
>     JSA> Although  I agree  that  "non-abstract parents"  is  the most  obvious
>     JSA> interpretation   of   "concrete   parents",   I   understood   it   as
>     JSA> "data-containing non-abstract parents".

I would say that two non-abstract parents without data is a special case 
I was ignoring.  You have a potential problem if two concrete types have 
  different state data, or identical states with different meanings.

> I understand now, by see below.

Exactly.  The Ada "workarounds" for this issue are the same.  If you 
want to inherit from two parents which both access the same state data, 
you can push the state to a common parent.  If the states are 
independent, you can use mix-ins that add state, but only see their own 
state variables.  Or if you need for one class to see the other's state 
but not vice-versa, you can import the methods of one parent class into 
the min-in for the other.  But if you want to inherit from two classes 
with state, and adjust the state of each based on changes to the other, 
the na�ve implementation isn't possible in Ada, and causes indefinite 
recursion in C++.  In C++ you can compile it, but unless you break the 
recursion, you can't run it.  In Ada you can't compile some versions 
without breaking the recursion.  That doesn't say you can't write 
indefinite recursion or infinite loops to implement this "abstraction" 
in Ada.  It is just that there are some implicit cases that are not allowed.


Back to the example of polar and cartesian co-ordinates.  It is possible 
to do things so that the Get operations are all inherited from the 
respective classes, but the Set operations have to be overridden for the 
child class--and carefully so you don't do unintended recursion.  (To do 
it without adding additional operations or state is possible, but left 
as an exercise for the reader, in Ada or C++ whichever you prefer.  And 
please, don't post it.  The practical solution does add extra state and 
uses lazy evaluation of the conversions between types.)

So as usual, the IDEA of multiple inheritance is powerful.  But in any 
case where you try to take advantage of "true" MI, there are 
implementation specific issues to be resolved.  So why is MI theory so 
common?  Because it is such a nice formalism for use in preliminary 
design.  I can say that this dataset is a list and it is a indexed 
array.  During  detailed design, I can choose the actual abstraction 
used to implement the dataset for performance reasons, which could be an 
indexed file, or a B-tree.

-- 
                                        Robert I. Eachus

Ryan gunned down the last of his third white wine and told himself it 
would all be over in a few minutes.  One thing he'd learned from 
Operation Beatrix: This field work wasn't for him. --from Red Rabbit by 
Tom Clancy.

Re: Is the Writing on the Wall for Ada?

[Hyman Rosen]

Robert I. Eachus wrote:
 > If the states are independent, you can use mix-ins that add state,
 > but only see their own state variables.

The problem with the mix-in approach is that you don't have a standalone
"interface" type which represents the abilities granted by the mix-in.

The problem I am formulating here is that you have multiple existing
interface types, with existing concrete implementations.
You would like to make a class which reuses the implementations and
is of the interface types. I am talking of the Colorable+Resizable
case, not the Polar+Cartesian case.

> But if you want to inherit from two classes  with state, and adjust
 > the state of each based on changes to the other, the na�ve implementation
 > isn't possible in Ada, and causes indefinite recursion in C++.

struct A { int a; virtual void set_a(int aa) { a = aa; } };
struct B { int b; virtual void set_b(int bb) { b = bb; } };

struct AB : A, B {
     void set_a(int aa) { A::set_a(aa); B::set_b(aa + 1); }
     void set_b(int bb) { A::set_a(bb - 1); B::set_b(bb); }
};

What indefinite recursion?

Re: Is the Writing on the Wall for Ada?

[Robert I. Eachus]

I said:


> But if you want to inherit from two classes  with state, and adjust 
> the state of each based on changes to the other, the na�ve implementation
> isn't possible in Ada, and causes indefinite recursion in C++.
 >
 > What indefinite recursion?

This na�ve implementation:

struct A { int a; virtual void set_a(int aa) { a = aa; } };
struct B { int b; virtual void set_b(int bb) { b = bb; } };

struct AB : A, B {
      void set_a(int aa) { set_a(aa); set_b(aa + 1); }
      void set_b(int bb) { set_a(bb - 1); set_b(bb); }
  };

In Ada, as in C++ you can break the recursion by specificly calling the
operations for the parent classes.  Actually you only need to call the 
super operation for one to break the recursion, but you know what I 
mean.  The point about Ada was that if you write equivalent code, you 
will get wacked at compile time for the set_b call.  (If you "fix" it by 
declaring the subroutine and then providing a separate body, you will 
get it to compile, but you won't get the results you want.)

-- 
                                                        Robert I. Eachus

Ryan gunned down the last of his third white wine and told himself it 
would all be over in a few minutes.  One thing he'd learned from 
Operation Beatrix: This field work wasn't for him. --from Red Rabbit by 
Tom Clancy.

Re: Is the Writing on the Wall for Ada?

[Jacob Sparre Andersen]

Ole-Hjalmar Kristensen wrote:
>>>>>>"JSA" == Jacob Sparre Andersen <sparre@crs4.it> writes:
>     JSA> Olehjalmar Kristensen wrote:
>     >>>>>>> "RIE" == Robert I Eachus <rieachus@attbi.com> writes:

>     JSA> Looks that  way to me  too. But  if a and  b had contained  data, for
>     JSA> example  position  data  in  respectively  spherical  and  rectangular
>     JSA> coordinates (to reuse an earlier  example), then you would most likely
>     JSA> end up in trouble.

> Depends on what you expect. As you can see, there is no conflict as
> such. On the other hand, a and b can not access each others variables
> either.

That was not really what I was worrying about either.  I couldn't even
imagine that somebody would design a language that would allow a and b
to access each others variables.

It was more the problem of inconsistencies due to duplicated data with
the same interpretation:

     type Complex_Polar is private;
     function Argument (Item : in Complex_Polar) return Scalar;
     [...]

     type Complex_Rectangular is private;
     function Arg (Item : in Complex_Rectangular) return Scalar;
     [...]

private

     type Complex_Polar is record Modulus, Argument : Scalar; end record;
     type Complex_Rectangular is record Im, Re : Scalar; end record;

If we made a new type inheritede from both of these two (yes, I didn't
write that they are tagged), the results of the two functions Argument
and Arg (which I at least would want to be the same) would not
neccessarily be the same.

> In the general case I agree, there may be problems, but I think that
> the compiler rejecting cases it cannot resolve properly is quite acceptable.

I am not sure that is sufficient for me.  But the above case _would_
most likely be resolved properly by the compiler (because I didn't give
both the functions the same name) and thus lead to unneeded confusion.

I may not understand the reasons behind MI completely, because I can't
imagine a good example, where true MI is significantly better (in terms
of the design goals for Ada) than interfaces.  And then I am also
worried that MI might lead to too many maintenance problems equivalent
to my example above.

Jacob
-- 
"Any, sufficiently advanced, technology is indistinguishable from
  magic."

Re: Is the Writing on the Wall for Ada?

[Dmitry A. Kazakov]

On Tue, 23 Sep 2003 12:49:41 +0200, Jacob Sparre Andersen
<sparre@crs4.it> wrote:

>Ole-Hjalmar Kristensen wrote:
>>>>>>>"JSA" == Jacob Sparre Andersen <sparre@crs4.it> writes:
>>     JSA> Olehjalmar Kristensen wrote:
>>     >>>>>>> "RIE" == Robert I Eachus <rieachus@attbi.com> writes:
>
>>     JSA> Looks that  way to me  too. But  if a and  b had contained  data, for
>>     JSA> example  position  data  in  respectively  spherical  and  rectangular
>>     JSA> coordinates (to reuse an earlier  example), then you would most likely
>>     JSA> end up in trouble.
>
>> Depends on what you expect. As you can see, there is no conflict as
>> such. On the other hand, a and b can not access each others variables
>> either.
>
>That was not really what I was worrying about either.  I couldn't even
>imagine that somebody would design a language that would allow a and b
>to access each others variables.
>
>It was more the problem of inconsistencies due to duplicated data with
>the same interpretation:
>
>     type Complex_Polar is private;
>     function Argument (Item : in Complex_Polar) return Scalar;
>     [...]
>
>     type Complex_Rectangular is private;
>     function Arg (Item : in Complex_Rectangular) return Scalar;
>     [...]
>
>private
>
>     type Complex_Polar is record Modulus, Argument : Scalar; end record;
>     type Complex_Rectangular is record Im, Re : Scalar; end record;
>
>If we made a new type inheritede from both of these two (yes, I didn't
>write that they are tagged), the results of the two functions Argument
>and Arg (which I at least would want to be the same) would not
>neccessarily be the same.

You didn't express your wish in langauge terms. So why do you blaim MI
for this? Should both functions be same, you have to show this. For
example:

type Abstract_Complex is abstract ...;
function Arg (Item : Abstract_Complex) return Scalar is abstract;

type Complex_Polar is new Abstract_Complex with ...;
function Arg (Item : Complex_Pola) return Scalar;

type Complex_Rectangular is new Abstract_Complex with ...;
function Arg (Item : Complex_Rectangular) return Scalar;

Now any attempt to derive from both will reveal a conflict in two
implementations of Arg. This conflict is good here. In your example,
it forces you to provide a consistent implementation of Arg for the
new type. If such does not exist, it is not a problem of MI, or?
Alternatively, if you inherit from, say List_Element twice, via
different routes. The conflict is again good. It forces you to choose
whether object of the new type has to be an element of exactly one
list or of two of them. And again, neither the conflict itself nor the
way it is resolved are MI problems.

>> In the general case I agree, there may be problems, but I think that
>> the compiler rejecting cases it cannot resolve properly is quite acceptable.
>
>I am not sure that is sufficient for me.  But the above case _would_
>most likely be resolved properly by the compiler (because I didn't give
>both the functions the same name) and thus lead to unneeded confusion.

If you declare two varaibles which has to be same, how to avoid this
unneeded confusion? Right, one should not allow multiple variable
declarations!

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

Re: Is the Writing on the Wall for Ada?

[Matthew Heaney]

Jacob Sparre Andersen <sparre@crs4.it> writes:

> That was not really what I was worrying about either.  I couldn't even
> imagine that somebody would design a language that would allow a and b
> to access each others variables.

But that's more or less what the multiple views idiom let's you do in
Ada95.  For example given that we want to "inherit" from both of these
types:

   type A_Type is tagged limited record
      X : Integer;
   end record;

   procedure A_Op (A : in out A_Type);


   type B_Type is tagged limited record
      Y : Integer;
   end record;

   procedure B_Op (B : in out B_Type);


We can use our now-familiar idiom to let C_Type "inherit" from both A
and B:

   type C_Type;

   type A_View (C : access C_Type) is
     new A_Type with null record;

   procedure A_Op (A : in out A_View); --override

   type B_View (C : access C_Type) is
     new B_Type with null record;

   procedure B_Op (B : in out B_View); --override

   type C_Type is tagged limited record
      A : aliased A_View (C_Type'Access);
      B : aliased B_View (C_Type'Access);
      Z : Integer;
   end record;


   procedure A_Op (A : in out A_View) is
      X : Integer renames A.X;
      Y : Integer renames A.C.B.Y; -- can see B's data
      Z : Integer renames A.C.Z;
   begin
      null;
   end;

   procedure B_Op (B : in out B_View) is
      X : Integer renames B.C.A.X; -- can see A's data
      Y : Integer renames B.Y;
      Z : Integer renames B.C.Z;
   begin
      null;
   end;
 

Re: Is the Writing on the Wall for Ada?

[Stephane Richard]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2311 bytes --]

"Matthew Heaney" <matthewjheaney@earthlink.net> wrote in message
news:uu173vtv5.fsf@earthlink.net...
> Jacob Sparre Andersen <sparre@crs4.it> writes:
>
> > That was not really what I was worrying about either.  I couldn't even
> > imagine that somebody would design a language that would allow a and b
> > to access each others variables.
>
> But that's more or less what the multiple views idiom let's you do in
> Ada95.  For example given that we want to "inherit" from both of these
> types:
>
>    type A_Type is tagged limited record
>       X : Integer;
>    end record;
>
>    procedure A_Op (A : in out A_Type);
>
>
>    type B_Type is tagged limited record
>       Y : Integer;
>    end record;
>
>    procedure B_Op (B : in out B_Type);
>
>
> We can use our now-familiar idiom to let C_Type "inherit" from both A
> and B:
>
>    type C_Type;
>
>    type A_View (C : access C_Type) is
>      new A_Type with null record;
>
>    procedure A_Op (A : in out A_View); --override
>
>    type B_View (C : access C_Type) is
>      new B_Type with null record;
>
>    procedure B_Op (B : in out B_View); --override
>
>    type C_Type is tagged limited record
>       A : aliased A_View (C_Type'Access);
>       B : aliased B_View (C_Type'Access);
>       Z : Integer;
>    end record;
>
>
>    procedure A_Op (A : in out A_View) is
>       X : Integer renames A.X;
>       Y : Integer renames A.C.B.Y; -- can see B's data
>       Z : Integer renames A.C.Z;
>    begin
>       null;
>    end;
>
>    procedure B_Op (B : in out B_View) is
>       X : Integer renames B.C.A.X; -- can see A's data
>       Y : Integer renames B.Y;
>       Z : Integer renames B.C.Z;
>    begin
>       null;
>    end;
>

I have a question about this idiom.

Taking your example here I'd like to have a classic example of the following
using that idiom:

I have  Bird class that can fly, chirp, eat, hear and build a nest.
I have a Horse class that can eat, run, walk, hear and sleep

How, using your idiom, would I go about creating a Pegasus class ?

From reading your example it seems to me you're create an aggregation of
TypeA and B from type C.  Perhaps the example I state here might make it
clearer on how the idiom works>?

-- 
St�phane Richard
"Ada World" Webmaster
http://www.adaworld.com




>
>
>
>
>
>
>
>
>
>
>

Re: Is the Writing on the Wall for Ada?

[Matthew Heaney]

"Stephane Richard" <stephane.richard@verizon.net> writes:

> I have a question about this idiom.
> 
> Taking your example here I'd like to have a classic example of the following
> using that idiom:
> 
> I have  Bird class that can fly, chirp, eat, hear and build a nest.
> I have a Horse class that can eat, run, walk, hear and sleep
> 
> How, using your idiom, would I go about creating a Pegasus class ?
> 
> From reading your example it seems to me you're create an aggregation
> of type A and B from type C.  Perhaps the example I state here might
> make it clearer on how the idiom works?

Here you go:

package Birds is

   type Root_Bird_Type is
     abstract tagged limited null record;

   type Bird_Class_Access is
     access all Root_Bird_Type'Class;

   procedure Fly (Bird : access Root_Bird_Type) is abstract;

   procedure Eat (Bird : access Root_Bird_Type) is abstract;

end Birds;


package Horses is

   type Root_Horse_Type is
     abstract tagged limited null record;

   type Horse_Class_Access is
     access all Root_Horse_Type'Class;

   procedure Eat (Horse : access Root_Horse_Type) is abstract;

   procedure Run (Horse : access Root_Horse_Type) is abstract;

end Horses;


package Pegasus_Types is

   type Pegasus_Type is limited private;

   function Bird (Pegasus : access Pegasus_Type)
      return Bird_Class_Access;

   function Horse (Pegasus : access Pegasus_Type)
      return Horse_Class_Access;

private

   type Bird_View (Pegasus : access Pegasus_Type) is
      new Root_Bird_Type with null record;

   procedure Fly (Bird : access Bird_View);
   procedure Eat (Bird : access Bird_View);

   type Horse_View (Pegasus : access Pegasus_Type) is
      new Root_Horse_Type with null record;

   procedure Eat (Horse : access Horse_View);
   procedure Run (Horse : access Horse_View);

   type Pegasus_Type is limited record
      Bird : aliased Bird_View (Pegasus_Type'Access);
      Horse : aliased Horse_View (Pegasus_Type'Access);
      ...
   end record;

end Pegasus_Types;


Now I can say:

declare
   Pegasus : aliased Pegasus_Type;
begin
   Fly (Bird (Pegasus'Access));
   Eat (Bird (Pegasus'Access));

   Eat (Horse (Pegasus'Access));
   Run (Horse (Pegasus'Access));
end;


There's no conflict between the Eat operation for Bird and the Eat
operation for Horse, because you can pick the view you need.









  

Re: Is the Writing on the Wall for Ada?

[Stephane Richard]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2810 bytes --]

"Matthew Heaney" <matthewjheaney@earthlink.net> wrote in message
news:ufzimx6mr.fsf@earthlink.net...
> "Stephane Richard" <stephane.richard@verizon.net> writes:
>
> > I have a question about this idiom.
> >
> > Taking your example here I'd like to have a classic example of the
following
> > using that idiom:
> >
> > I have  Bird class that can fly, chirp, eat, hear and build a nest.
> > I have a Horse class that can eat, run, walk, hear and sleep
> >
> > How, using your idiom, would I go about creating a Pegasus class ?
> >
> > From reading your example it seems to me you're create an aggregation
> > of type A and B from type C.  Perhaps the example I state here might
> > make it clearer on how the idiom works?
>
> Here you go:
>
> package Birds is
>
>    type Root_Bird_Type is
>      abstract tagged limited null record;
>
>    type Bird_Class_Access is
>      access all Root_Bird_Type'Class;
>
>    procedure Fly (Bird : access Root_Bird_Type) is abstract;
>
>    procedure Eat (Bird : access Root_Bird_Type) is abstract;
>
> end Birds;
>
>
> package Horses is
>
>    type Root_Horse_Type is
>      abstract tagged limited null record;
>
>    type Horse_Class_Access is
>      access all Root_Horse_Type'Class;
>
>    procedure Eat (Horse : access Root_Horse_Type) is abstract;
>
>    procedure Run (Horse : access Root_Horse_Type) is abstract;
>
> end Horses;
>
>
> package Pegasus_Types is
>
>    type Pegasus_Type is limited private;
>
>    function Bird (Pegasus : access Pegasus_Type)
>       return Bird_Class_Access;
>
>    function Horse (Pegasus : access Pegasus_Type)
>       return Horse_Class_Access;
>
> private
>
>    type Bird_View (Pegasus : access Pegasus_Type) is
>       new Root_Bird_Type with null record;
>
>    procedure Fly (Bird : access Bird_View);
>    procedure Eat (Bird : access Bird_View);
>
>    type Horse_View (Pegasus : access Pegasus_Type) is
>       new Root_Horse_Type with null record;
>
>    procedure Eat (Horse : access Horse_View);
>    procedure Run (Horse : access Horse_View);
>
>    type Pegasus_Type is limited record
>       Bird : aliased Bird_View (Pegasus_Type'Access);
>       Horse : aliased Horse_View (Pegasus_Type'Access);
>       ...
>    end record;
>
> end Pegasus_Types;
>
>
> Now I can say:
>
> declare
>    Pegasus : aliased Pegasus_Type;
> begin
>    Fly (Bird (Pegasus'Access));
>    Eat (Bird (Pegasus'Access));
>
>    Eat (Horse (Pegasus'Access));
>    Run (Horse (Pegasus'Access));
> end;
>
>
> There's no conflict between the Eat operation for Bird and the Eat
> operation for Horse, because you can pick the view you need.
>
>

Ahhh I see now, ok it's not quite what I thought it would be...(as per my
aggregation assumption)..it makes sense now :-)

-- 
St�phane Richard
"Ada World" Webmaster
http://www.adaworld.com

Re: Is the Writing on the Wall for Ada?

[Hyman Rosen]

Stephane Richard wrote:
> How, using your idiom, would I go about creating a Pegasus class ?
> 
> From reading your example it seems to me you're create an aggregation of
> TypeA and B from type C.  Perhaps the example I state here might make it
> clearer on how the idiom works>?

It's really very simple. The A and B types are each augmented with a
pointer which points back to the aggregate object which contains them.
Then methods can use that back pointer to access the containing object,
and then its components, no matter what they are.

The "magic" is that Ada initializaes this back pointer automatically
when it's declared properly, as in the C_type / (C_Type'Access) code
in the previous message.

For the "Pegasus" class, the 'eat' and 'hear' functions of the Bird
and Horse parts can simply call a common method of the overall class.

I'll rewrite Matthew's example in C++, just for fun:

struct A_Type
{
     virtual void A_Op() = 0;
     int X;
};

struct B_Type
{
     virtual void B_Op() = 0;
     int Y;
};

struct C_Type;

struct A_View : A_Type
{
     C_Type *C;
     A_View(C_Type *c) : C(c) { }
     void A_Op();
};

struct B_View : B_Type
{
     C_Type *C;
     B_View(C_Type *c) : C(c) { }
     void B_Op();
};

struct C_Type
{
     A_View A;
     B_View B;
     int Z;
     C_Type() : A(this), B(this) { }    // Ada does this by itself
};

void A_View::A_Op()
{
     int &X = this->X;
     int &Y = C->B.Y;
     int &Z = C->Z;
}

void B_View::B_Op()
{
     int &X = C->A.X;
     int &Y = this->Y;
     int &Z = C->Z;
}

Re: Is the Writing on the Wall for Ada?

[Hyman Rosen]

"Robert I. Eachus" <rieachus@attbi.com> wrote in message news:<3F6079A9.6080108@attbi.com>...
> Let me follow through on that, since you didn't seem to get it.

What's to get? You are demonstrating one case where MI is not
appropriate, and you seem to think that this constitues a proof
that MI is never appropriate.

    Socrates is a man.
    Therefore all men are Socrates.

Re: Is the Writing on the Wall for Ada?

[Chad R. Meiners]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:568ede3c.0309110925.57d07508@posting.google.com...
> "Robert I. Eachus" <rieachus@attbi.com> wrote in message
news:<3F6079A9.6080108@attbi.com>...
> > Let me follow through on that, since you didn't seem to get it.
>
> What's to get? You are demonstrating one case where MI is not
> appropriate, and you seem to think that this constitues a proof
> that MI is never appropriate.

Not at all!  Robert was demonstrating that inheriting from two different
implementations is not a well formed idea in general.  He already stated
that their exist cases (which you consider appropriate) that combining two
implementations is well formed, but he provided an example (which you
consider inappropriate) that demonstrates that MI does not work in general.
It wasn't a straw man argument; it was a counter example. ;-)

Anyway, I hope this demonstrates that people don't lack the courage to add
full MI.  Instead that want to carefully attain the features of MI without
any unnecessary problems.

-CRM

Re: Is the Writing on the Wall for Ada?

[Hyman Rosen]

Chad R. Meiners wrote:
 > but he provided an example (which you consider inappropriate)
 > that demonstrates that MI does not work in general.
> It wasn't a straw man argument; it was a counter example. ;-)

You cannot possibly mean what you are saying. You appear to be
claiming that because multiple inheritance from all sets of bases
is inappropriate, this is a counterexample to the notion that
multiple inheritance from some set of bases is useful.

If I were to paint everything in my house red, the result would
be a hideous and awful mess. This does not prove that red is a
useless color.

I'm smelling "If we don't have it, you don't need it".

Re: Is the Writing on the Wall for Ada?

[Chad R. Meiners]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:eh78b.7499$ej1.4404@nwrdny01.gnilink.net...
> Chad R. Meiners wrote:
>  > but he provided an example (which you consider inappropriate)
>  > that demonstrates that MI does not work in general.
> > It wasn't a straw man argument; it was a counter example. ;-)
>
> You cannot possibly mean what you are saying. You appear to be
> claiming that because multiple inheritance from all sets of bases
> is inappropriate, this is a counterexample to the notion that
> multiple inheritance from some set of bases is useful.

You misunderstand what I wrote

> If I were to paint everything in my house red, the result would
> be a hideous and awful mess. This does not prove that red is a
> useless color.

But painting everything in your house red is well defined it may not look
very good, but there is no confuse what the result of doing so would be.
However lets take mixing paints, mixing two oil based paints in well
defined; however I am not sure what the result of mixing oil and water based
paints together.

> I'm smelling "If we don't have it, you don't need it".

That's because you play the devils advocate too much ;-)

I welcome MI features to Ada as long as the rules about them are consistent
and understandable.

Re: Is the Writing on the Wall for Ada?

[tmoran]

> > that demonstrates that MI does not work in general.
>... this is a counterexample to the notion that
>multiple inheritance from some set of bases is useful.
  "work in general" can mean, and I think was intended to mean, "work in
all cases", and clearly a single counterexample disproves that.  "work in
general" could also take a less formal meaning of "work most of the time",
and I suspect that's the way Hyman took it.  In that interpretation of
course, the statement is not disproved by a single counterexample.

Re: Is the Writing on the Wall for Ada?

[Robert I. Eachus]

tmoran@acm.org wrote:

>   "work in general" can mean, and I think was intended to mean, "work in
> all cases", and clearly a single counterexample disproves that.  "work in
> general" could also take a less formal meaning of "work most of the time",
> and I suspect that's the way Hyman took it.  In that interpretation of
> course, the statement is not disproved by a single counterexample.

And in the Ada community there are very few people who distinguish 
between doesn't work in all cases, and doesn't work.  That doesn't apply 
in this case though.  There is no way to directly inherit from two 
classes, unless one is a subclass of the other.  (And of course, that 
case is not considered multiple inheritance.)  Interfaces do not include 
state, and mix-ins add state, so you can combine any number of mix-ins 
or interfaces, or combine them and even add one direct parent.

Back to my example, just to take this out of the abstract realm.  If I 
inherit from one set of operations where the first state variable is 
interpreted as distance in the X dimension, and another set of 
operations where the first state variable represents the length of the 
vector, you get garbage.  This is not unique to this example.  It 
happens every time you have two different definitions of state.

If you want to directly inherit the polar class, and also inherit the 
cartesian interface, that works.  Well, sort of.  You can't allow the X 
and Y state variables to be set separately. (Well, maybe you could. 
Convert the current value to cartesian, change one of the components and 
convert back.  But I'd much rather choose an interface that only allows 
X and Y to be changed together.)

If you want to directly inherit from a cartesian class and add a polar 
interface, that works too.  Or you can combine a cartesian class with a 
polar mix-in.  (But you had better do a lot of overriding to maintain 
consistancy.)  Or you can inherit from two interfaces, or add two 
mix-ins to a stateless (null) class, with the same caveat about consistancy.

--
                                          Robert I. Eachus

"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: Is the Writing on the Wall for Ada?

[Hyman Rosen]

"Robert I. Eachus" <rieachus@attbi.com> wrote in message news:<3F615341.4000100@attbi.com>...
> There is no way to directly inherit from two 
> classes, unless one is a subclass of the other.

I am well an truly puzzled at this remark.
Let me give a C++ example, and you can tell me why you don't believe it.

struct Colorable
{
    virtual void setColor(int color) = 0;
    virtual int getColor() = 0;
    virtual ~Colorable() { }
};
struct ColorableAdapter : virtual Colorable
{
    void setColor(int color) { m_color = color; }
    int getColor() { return m_color; }
    ColorableAdapter(int color = 0) : m_color(color) { }
private:
    int m_color;
};

struct Resizable
{
    virtual void setSize(double size) = 0;
    virtual double getSize() = 0;
    virtual ~Resizable() { }
};
struct ResizableAdapter : virtual Resizable
{
    void setSize(double size) { m_size = size; }
    double getSize() { return m_size; }
    ResizableAdapter(double size = 1) : m_size(size) { }
private:
    double m_size;
};

struct MyObject : ColorableAdapter, ResizableAdapter
{
    MyObject(int color = 0, double size = 1)
        : ColorableAdapter(color), ResizableAdapter(size)
    { }
    void doSomething();
};

Re: Is the Writing on the Wall for Ada?

[Robert I. Eachus]

Hyman Rosen wrote:
> "Robert I. Eachus" <rieachus@attbi.com> wrote in message news:<3F615341.4000100@attbi.com>...
> 
>>There is no way to directly inherit from two 
>>classes, unless one is a subclass of the other.
> 
> 
> I am well an truly puzzled at this remark.
> Let me give a C++ example, and you can tell me why you don't believe it.
> 
> struct Colorable
> {
>     virtual void setColor(int color) = 0;
>     virtual int getColor() = 0;
>     virtual ~Colorable() { }
> };
> struct ColorableAdapter : virtual Colorable
> {
>     void setColor(int color) { m_color = color; }
>     int getColor() { return m_color; }
>     ColorableAdapter(int color = 0) : m_color(color) { }
> private:
>     int m_color;
> };
> 
> struct Resizable
> {
>     virtual void setSize(double size) = 0;
>     virtual double getSize() = 0;
>     virtual ~Resizable() { }
> };
> struct ResizableAdapter : virtual Resizable
> {
>     void setSize(double size) { m_size = size; }
>     double getSize() { return m_size; }
>     ResizableAdapter(double size = 1) : m_size(size) { }
> private:
>     double m_size;
> };
> 
> struct MyObject : ColorableAdapter, ResizableAdapter
> {
>     MyObject(int color = 0, double size = 1)
>         : ColorableAdapter(color), ResizableAdapter(size)
>     { }
>     void doSomething();
> };

You inherit from two virtual classes, then use concrete mix-ins to 
implement the classes.  In Ada I would do this without the virtual clases:

with Ada.Text_IO; use Ada.Text_IO;
procedure Multiple is -- an example of multiple inheritance in Ada.

   type Color is new Integer; -- not normal Ada, but I am trying to
                              -- match the original example.
   generic
     type Object is tagged private;
   package Colors is
     type Colored_Object is new Object with private;
     procedure Set(Obj: in out Colored_Object; To: in Color := 0);
     function  Get(Obj: in Colored_Object) return Color;
   private
     type Colored_Object is new Object with record
       Color_Value: Color := 0;
     end record;
   end Colors;

   package body Colors is
     procedure Set(Obj: in out Colored_Object; To: in Color := 0) is
     begin Obj.Color_Value := To; end Set;

     function Get(Obj: in Colored_Object) return Color is
     begin return Obj.Color_Value; end Get;
   end Colors;

   type Size is new Long_Float; -- see comment above.

   generic
     type Object is tagged private;
   package Resize is
     type Resizeable_Object is new Object with private;
     procedure Set(Obj: in out Resizeable_Object; To: Size := 1.0);
     function  Get(Obj: in Resizeable_Object) return Size;
   private
     type Resizeable_Object is new Object with record
       Current_Size: Size := 1.0;
     end record;
   end Resize;

   package body Resize is
     procedure Set(Obj: in out Resizeable_Object; To: Size := 1.0) is
     begin Obj.Current_Size := To; end Set;

     function  Get(Obj: in Resizeable_Object) return Size is
     begin return Obj.Current_Size; end Get;
   end Resize;

   type Nothing is tagged null record;
   package My_Color is new Colors(Nothing);
   package My_Resize is new Resize(My_Color.Colored_Object);
   type Inherited is new My_Resize.Resizeable_Object with null record;
   -- all the MI magic occurs in these four lines  Nothing is the direct
   -- parent, there are two mix-ins, and the final type is just to make
   -- all the inherited operations visible without qualification.

   procedure Do_Something(Obj: in Inherited) is
     package Color_IO is new Integer_IO(Color);
     package Size_IO is new Float_IO(Size);
   begin
     Put(" Color is: ");
     Color_IO.Put(Get(Obj),1);
     Put(" Size is: ");
     Size_IO.Put(Get(Obj),1,2,0);
     New_Line;
   end Do_Something;

   MI: Inherited;

begin
   New_Line;
   Do_Something(MI);
   Set(MI, 42); -- Color.
   Set(MI, 9.43); -- Size.
   Do_Something(MI);
end Multiple;

I put this all in a single procedure to make it easy for anyone who 
wants to compile it.  The program goes to a lot of work to print a few 
lines, but it is an example of multiple inheritance using mix-ins in Ada.

E:\Ada\Misc>multiple
multiple

  Color is: 0 Size is: 1.00
  Color is: 42 Size is: 9.43

Notice that if Colors and Resize were library packages, they could be 
mixed in to any tagged type, including Controlled types.  I could have 
made the generic parameters limited so you could use them with limited 
types as well, but that was outside the bounds of the problem.

Incidently when you use mix-in style multiple inheritance in Ada, it is 
much more ususal for the stack of mix-ins to be in the private part of a 
package.  Then to use renaming to export only the operations that the 
author of the package thinks should be visible for the final type.  For 
example, if you built my example of Polar and Cartesian co-ordinates 
this way, you might export the Get functions directly, but implement 
only Set operations that take co-ordinate pairs, and immediately convert 
from Polar to Cartesian or vice-versa so that both sets of stored 
co-ordinates are always valid.  Or you might derive directly from a 
Cartesian type, mix-in the polar co-ordinates, and only compute the 
polor co-ordinates when necessary.  (So you would also need a valid bit.)

The real point is that multiple inheritance is alive and well in Ada 95. 
  We will probably add a second style of MI (interface inheritance) that 
will mix and match with the mix-in style seamlessly, and with one 
instance of direct inheritance.  Personally I prefer to use mix-ins, but 
there are some situations where interface inheritance is a better fit 
for the problem.

--
                                             Robert I. Eachus

"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: Is the Writing on the Wall for Ada?

[Stephane Richard]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 6524 bytes --]

When is the new Ada 200X to come out?  or are they talking about it's
changes right now?  Where can I get the details of this Ada 200X proposal?

-- 
St�phane Richard
Senior Software and Technology Supervisor
http://www.totalweb-inc.com
For all your hosting and related needs
"Robert I. Eachus" <rieachus@attbi.com> wrote in message
news:3F634E58.4080803@attbi.com...
> Hyman Rosen wrote:
> > "Robert I. Eachus" <rieachus@attbi.com> wrote in message
news:<3F615341.4000100@attbi.com>...
> >
> >>There is no way to directly inherit from two
> >>classes, unless one is a subclass of the other.
> >
> >
> > I am well an truly puzzled at this remark.
> > Let me give a C++ example, and you can tell me why you don't believe it.
> >
> > struct Colorable
> > {
> >     virtual void setColor(int color) = 0;
> >     virtual int getColor() = 0;
> >     virtual ~Colorable() { }
> > };
> > struct ColorableAdapter : virtual Colorable
> > {
> >     void setColor(int color) { m_color = color; }
> >     int getColor() { return m_color; }
> >     ColorableAdapter(int color = 0) : m_color(color) { }
> > private:
> >     int m_color;
> > };
> >
> > struct Resizable
> > {
> >     virtual void setSize(double size) = 0;
> >     virtual double getSize() = 0;
> >     virtual ~Resizable() { }
> > };
> > struct ResizableAdapter : virtual Resizable
> > {
> >     void setSize(double size) { m_size = size; }
> >     double getSize() { return m_size; }
> >     ResizableAdapter(double size = 1) : m_size(size) { }
> > private:
> >     double m_size;
> > };
> >
> > struct MyObject : ColorableAdapter, ResizableAdapter
> > {
> >     MyObject(int color = 0, double size = 1)
> >         : ColorableAdapter(color), ResizableAdapter(size)
> >     { }
> >     void doSomething();
> > };
>
> You inherit from two virtual classes, then use concrete mix-ins to
> implement the classes.  In Ada I would do this without the virtual clases:
>
> with Ada.Text_IO; use Ada.Text_IO;
> procedure Multiple is -- an example of multiple inheritance in Ada.
>
>    type Color is new Integer; -- not normal Ada, but I am trying to
>                               -- match the original example.
>    generic
>      type Object is tagged private;
>    package Colors is
>      type Colored_Object is new Object with private;
>      procedure Set(Obj: in out Colored_Object; To: in Color := 0);
>      function  Get(Obj: in Colored_Object) return Color;
>    private
>      type Colored_Object is new Object with record
>        Color_Value: Color := 0;
>      end record;
>    end Colors;
>
>    package body Colors is
>      procedure Set(Obj: in out Colored_Object; To: in Color := 0) is
>      begin Obj.Color_Value := To; end Set;
>
>      function Get(Obj: in Colored_Object) return Color is
>      begin return Obj.Color_Value; end Get;
>    end Colors;
>
>    type Size is new Long_Float; -- see comment above.
>
>    generic
>      type Object is tagged private;
>    package Resize is
>      type Resizeable_Object is new Object with private;
>      procedure Set(Obj: in out Resizeable_Object; To: Size := 1.0);
>      function  Get(Obj: in Resizeable_Object) return Size;
>    private
>      type Resizeable_Object is new Object with record
>        Current_Size: Size := 1.0;
>      end record;
>    end Resize;
>
>    package body Resize is
>      procedure Set(Obj: in out Resizeable_Object; To: Size := 1.0) is
>      begin Obj.Current_Size := To; end Set;
>
>      function  Get(Obj: in Resizeable_Object) return Size is
>      begin return Obj.Current_Size; end Get;
>    end Resize;
>
>    type Nothing is tagged null record;
>    package My_Color is new Colors(Nothing);
>    package My_Resize is new Resize(My_Color.Colored_Object);
>    type Inherited is new My_Resize.Resizeable_Object with null record;
>    -- all the MI magic occurs in these four lines  Nothing is the direct
>    -- parent, there are two mix-ins, and the final type is just to make
>    -- all the inherited operations visible without qualification.
>
>    procedure Do_Something(Obj: in Inherited) is
>      package Color_IO is new Integer_IO(Color);
>      package Size_IO is new Float_IO(Size);
>    begin
>      Put(" Color is: ");
>      Color_IO.Put(Get(Obj),1);
>      Put(" Size is: ");
>      Size_IO.Put(Get(Obj),1,2,0);
>      New_Line;
>    end Do_Something;
>
>    MI: Inherited;
>
> begin
>    New_Line;
>    Do_Something(MI);
>    Set(MI, 42); -- Color.
>    Set(MI, 9.43); -- Size.
>    Do_Something(MI);
> end Multiple;
>
> I put this all in a single procedure to make it easy for anyone who
> wants to compile it.  The program goes to a lot of work to print a few
> lines, but it is an example of multiple inheritance using mix-ins in Ada.
>
> E:\Ada\Misc>multiple
> multiple
>
>   Color is: 0 Size is: 1.00
>   Color is: 42 Size is: 9.43
>
> Notice that if Colors and Resize were library packages, they could be
> mixed in to any tagged type, including Controlled types.  I could have
> made the generic parameters limited so you could use them with limited
> types as well, but that was outside the bounds of the problem.
>
> Incidently when you use mix-in style multiple inheritance in Ada, it is
> much more ususal for the stack of mix-ins to be in the private part of a
> package.  Then to use renaming to export only the operations that the
> author of the package thinks should be visible for the final type.  For
> example, if you built my example of Polar and Cartesian co-ordinates
> this way, you might export the Get functions directly, but implement
> only Set operations that take co-ordinate pairs, and immediately convert
> from Polar to Cartesian or vice-versa so that both sets of stored
> co-ordinates are always valid.  Or you might derive directly from a
> Cartesian type, mix-in the polar co-ordinates, and only compute the
> polor co-ordinates when necessary.  (So you would also need a valid bit.)
>
> The real point is that multiple inheritance is alive and well in Ada 95.
>   We will probably add a second style of MI (interface inheritance) that
> will mix and match with the mix-in style seamlessly, and with one
> instance of direct inheritance.  Personally I prefer to use mix-ins, but
> there are some situations where interface inheritance is a better fit
> for the problem.
>
> --
>                                              Robert I. Eachus
>
> "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: Is the Writing on the Wall for Ada?

[Robert I. Eachus]

Stephane Richard wrote:
> When is the new Ada 200X to come out?  or are they talking about it's
> changes right now?  Where can I get the details of this Ada 200X proposal?

Ada 200X (or Ada 200Y depending on who you ask) will be ready when it is 
ready.  The end of this month is the closing date for unsolicited 
proposed changes.  I think that the probable date is 2005 or 2006, but 
it will be ready when it is ready, and most compilers will probably 
implement the exentsions well before the standard is official. 
(Obviously there is no reason not to implement proposed added packages 
once they are stable.  The interface proposal will probably take longer.)

All of the existing extension/change proposals have been written up as 
AIs: http://www.ada-auth.org/ais.html  At some point there will be an 
"official" list of the proposals being considered but I don't think that 
will happen before early 2004.

-- 
                                         Robert I. Eachus

"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: Is the Writing on the Wall for Ada?

[Hyman Rosen]

Robert I. Eachus wrote:
> You inherit from two virtual classes, then use concrete mix-ins to 
> implement the classes.

I still feel like we're talking past each other. I am showing you why
one might want to inherit from two different concrete classes. In my
example, you want an object which is Colorable and Resizable, and you
want to reuse the concrete implementations of the adapter classes.

Are you saying that this example is somehow invalid? You can't do it
in Ada, so you have to use the mixin style if you want something like
this, but that's just a deficiency of Ada.

You can use the mixin style in C++ too, of course, but if you have
constructors the mixin style forces you to pass the constructor
parameters around somewhat inconveniently; it's easier to do the
direct multiple inheritance. Notice that your mixin example didn't
have the initializing parameters that my C++ example did.

Re: Is the Writing on the Wall for Ada?

[Robert I. Eachus]

Hyman Rosen wrote:
> Robert I. Eachus wrote:
> 
>> You inherit from two virtual classes, then use concrete mix-ins to 
>> implement the classes.
> 
> 
> I still feel like we're talking past each other. I am showing you why
> one might want to inherit from two different concrete classes. In my
> example, you want an object which is Colorable and Resizable, and you
> want to reuse the concrete implementations of the adapter classes.

There is no problem inheriting from two concrete classes.  I showed how 
it is done in Ada.  What I have been saying is that you can't have 
direct inheritance (with the isa relationship) from two unrelated 
classes.  This paper by Bertrand Meyer: 
http://archive.eiffel.com/doc/manuals/technology/bmarticles/joop/multiple.html
  has a humorous example of the problem.  It is wrong to create a class 
Apple Pie by inheriting from Apple and Pie.  An apple pie isa pie, but 
it isn't an apple.  The article by Bertrand Meyer describes what is 
going on in terms of subtyping and extension.

But let's go back to the apple pie example.  An apple isa pie, but a pie 
is not necessarily an apple pie.  In other words, apple pies are a 
proper subset of pies.  What about the situation where you only want to 
extend a class, but not subset it.  That is direct inheritance.  Let's 
say I want to extend the class integer by adding a routine which will 
convert the integer to an English character string:

function English_Name(I: Integer) return String;

So English_Name(123) will return "one hundred and fortythree".  Now lets 
add an operations that returns the German Name, so German_Name(143) will 
return "einhundert drei und vierzig".  So far so good.  But let's say I 
don't want to name the language.  In Ada I can say:

package English is

   type Number is new Integer;

   function Name return String;

end English;

And do the same for French, German, Italian, and so on.  Now 
English.Number isa Integer, and the relationship is transitive.  An 
Integer isa English.Number, but without the extension provided by the 
name function.  That is direct inheritance.  Notice that due to the 
transitive nature of the isa relationship, an English.Number isa Integer 
and an Integer isa German.Number, therefore an English.Number isa 
German.Number.

Mix-ins in Ada typically provide this type of direct inheritance.  In 
Ada derived types can do subtyping:

     type Small_Numer is Integer range -256..255;

As can subtypes:

     subtype Small_Integer is Integer range -256..255;

So in Ada it is typical to split subtyping and type extension.  Now what 
is wrong with multiple direct inheritance?  It is either wrong, or 
useless.  If you want to inherit from two classes that are identical, 
why bother?  If you want to directly inherit from two classes that are 
different, the new subclass can't force the two parent classes to be 
identical.  But the child class has to be identical to both parents (in 
terms of state, not operations).  Can't be done.

If you use mix-in style inheritance, the new class is a subclass 
(perhaps a non-proper subclass) of the parent with added state.  No 
problem.  There is an isa relationship from the new class to its parent, 
but not from parent to child.  An apple pie isa pie, but a pie may or 
may not be an apple pie.

> Are you saying that this example is somehow invalid? You can't do it
> in Ada, so you have to use the mixin style if you want something like
> this, but that's just a deficiency of Ada.

There are several types of inheritance. Direct inheritance copies the 
state. Interface inheritance does not copy the state, but provides added 
operations.  Mix-in inheritance augments the state. In the normal 
notation for these things, your example took a type with state = color, 
and a type with state = size and created a type with state = color x 
size.  So that is what my example did as well.

The reason for the product notation is that the number of possible 
states for the final type is the product of all the valid color states 
and all the valid size states.  It is impossible in Ada--or any other 
language--to create a new type with the number of possible states equal 
to the number of possible colors and also equal to the number of 
possible sizes.  (Assuming those numbers are different.)

> You can use the mixin style in C++ too, of course, but if you have
> constructors the mixin style forces you to pass the constructor
> parameters around somewhat inconveniently; it's easier to do the
> direct multiple inheritance.   Notice that your mixin example didn't
> have the initializing parameters that my C++ example did.

AFAIK, I copied that exactly. The initial color was = 0, and the initial 
size was = 1.0. I did not copy the destructors because they weren't 
required in Ada.

--
                                       Robert I. Eachus

"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: Is the Writing on the Wall for Ada?

[olehjalmar kristensen - Sun Microsystems - Trondheim Norway]

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

    RIE> Hyman Rosen wrote:
    >> Robert I. Eachus wrote:
    >> 

    >>> You inherit from two virtual  classes, then use concrete mix-ins to
    >>> implement the classes.

    >> I still  feel like we're talking  past each other. I  am showing you
    >> why

    >> one might want to inherit from two different concrete classes. In my
    >> example, you want an object which is Colorable and Resizable, and you
    >> want to reuse the concrete implementations of the adapter classes.

    RIE> There is  no problem inheriting  from two concrete classes.  I showed
    RIE> how it is done in Ada.  What I have been saying is that you can't have
    RIE> direct  inheritance (with  the  isa relationship)  from two  unrelated
    RIE> classes.       This        paper       by       Bertrand       Meyer:
    RIE> http://archive.eiffel.com/doc/manuals/technology/bmarticles/joop/multiple.html

Of course you can, provided that you don't expect them to magically
react to form something entirely new, like apple pie. To do that, you
would probably use mixins.

RE: Is the Writing on the Wall for Ada?

[Robert C. Leif]

Returning to the original subject: Is the Writing on the Wall for Ada?
There is hope. An example of a very successful resurrection has occurred
during the last few years. SGML, Standard Generalized Markup Language,
illustrates how the fortunes of a technology can change from approaching
legacy status to market leader. XML evolved from SGML. The change in name
and improvement in technology was sufficient for this very successful
resurrection. SPARK provides a similar solution for Ada. 
Actually, the change for Ada is much less than that required for SGML. I
believe that a very significant part of SPARK technology is to be inserted
into Ada'0Y and it should be possible with Pragma Restrictions to subset
Ada'0Y to SPARK. It would then be allowable to refer to the language as
Ada.SPARK. 
new name + new technology = new game

Bob
Robert C. Leif, Ph.D.
Email rleif@rleif.com

Re: Is the Writing on the Wall for Ada?

[Matthew Heaney]

hyrosen@mail.com (Hyman Rosen) wrote in message news:<568ede3c.0309121211.743a8da2@posting.google.com>...
> "Robert I. Eachus" <rieachus@attbi.com> wrote in message news:<3F615341.4000100@attbi.com>...
> > There is no way to directly inherit from two 
> > classes, unless one is a subclass of the other.
> 
> I am well an truly puzzled at this remark.
> Let me give a C++ example, and you can tell me why you don't believe it.

Here's the Ada95 version of your example:

package Colorable_Types is
   
   type Root_Colorable_Type is
      abstract tagged limited null record;
      
   type Colorable_Class_Access is
      access all Root_Colorable_Type'Class;
      
   procedure Set_Color 
     (Colorable : access Root_Colorable_Type;
      Color     : in     Integer) is abstract;
   
   function Get_Color (Colorable : access Root_Colorable_Type)
      return Integer is abstract;
      
end Colorable_Types;


package Colorable_Types.Adapters is

   type Colorable_Adapter_Type is
      new Root_Colorable_Type with private;
      
   procedure Set_Color 
     (Colorable : access Colorable_Adapter_Type;
      Color     : in     Integer);
   
   function Get_Color (Colorable : access Colorable_Adapter_Type)
      return Integer;
      
private


   type Colorable_Adapter_Type is
      new Root_Colorable_Type with record
         Color : Integer;
      end record;
      
end Colorable_Types.Adapters;


package Resizable_Types is

   type Root_Resizable_Type is
      abstract tagged limited null record;
      
   type Resizable_Class_Access is
      access all Root_Resizable_Type'Class;
      
   procedure Set_Size
     (Resizable : access Root_Resizable_Type;
      Size      : in     Float) is abstract;
      
   function Get_Size (Resizable : access Root_Resizable_Type) 
     return Float is abstract;
     
end Resizable_Types;


package Resizable_Types.Adapters is

   type Resizable_Adapter_Type is
      new Root_Resizable_Type with private;
      
   procedure Set_Size
     (Resizable : access Resizable_Adapter_Type;
      Size      : in     Float);
      
   function Get_Size (Resizable : access Resizable_Adapter_Type) 
     return Float;
     
private

   type Resizable_Adapter_Type is
      new Root_Resizable_Type with record
         Size : Float;
      end record;
     
end Resizable_Types.Adapters;

with Colorable_Types.Adapters; use Colorable_Types;
with Resizable_Types.Adapters; use Resizable_Types;

package My_Objects is

   type My_Object is limited private;
   
   function Colorable (Object : access My_Object)
      return Colorable_Class_Access;
      
   function Resizable (Object : access My_Object)
      return Resizable_Class_Access;
      
   procedure Do_Something (Object : in out My_Object);
   
private

   use Colorable_Types.Adapters;
   use Resizable_Types.Adapters;

   type Colorable_View (Object : access My_Object) is
      new Colorable_Adapter_Type with null record;
      
   type Resizable_View (Ojbect : access My_Object) is
      new Resizable_Adapter_Type with null record;
 
   type My_Object is limited record
      Colorable : aliased Colorable_View (My_Object'Access);
      Resizable : aliased Resizable_View (My_Object'Access);
   end record;
   
end My_Objects;

Now you can do this:

procedure Test_MI is

   Obj : aliased My_Object;
   
begin

   Set_Color (Colorable (Obj'Access), Color => 0);
   Set_Size (Resizable (Obj'Access), Size => 1.0);

   Do_Something (Obj);
   
end Test_MI;

The type My_Object "inherits" from both Colorable and Resizable. 
Anywhere you have subprogram that accepts a Colorable or Resizable,
you can use a My_Object.

Re: Is the Writing on the Wall for Ada?

[Amir Yantimirov]

mheaney@on2.com (Matthew Heaney) wrote in message news:<1ec946d1.0309150709.4a7daa12@posting.google.com>...
> hyrosen@mail.com (Hyman Rosen) wrote in message news:<568ede3c.0309121211.743a8da2@posting.google.com>...
> > Let me give a C++ example, and you can tell me why you don't believe it.
> 
> Here's the Ada95 version of your example:
> 
> package Colorable_Types is
>    
>    type Root_Colorable_Type is
>       abstract tagged limited null record;
>       
>    type Colorable_Class_Access is
>       access all Root_Colorable_Type'Class;
>       
>    procedure Set_Color 
>      (Colorable : access Root_Colorable_Type;
>       Color     : in     Integer) is abstract;
>    
>    function Get_Color (Colorable : access Root_Colorable_Type)
>       return Integer is abstract;
>       
> end Colorable_Types;
> 
> 
> package Colorable_Types.Adapters is
> 
>    type Colorable_Adapter_Type is
>       new Root_Colorable_Type with private;
>       
>    procedure Set_Color 
>      (Colorable : access Colorable_Adapter_Type;
>       Color     : in     Integer);
>    
>    function Get_Color (Colorable : access Colorable_Adapter_Type)
>       return Integer;
>       
> private
> 
> 
>    type Colorable_Adapter_Type is
>       new Root_Colorable_Type with record
>          Color : Integer;
>       end record;
>       
> end Colorable_Types.Adapters;
> 
> 
> package Resizable_Types is
> 
>    type Root_Resizable_Type is
>       abstract tagged limited null record;
>       
>    type Resizable_Class_Access is
>       access all Root_Resizable_Type'Class;
>       
>    procedure Set_Size
>      (Resizable : access Root_Resizable_Type;
>       Size      : in     Float) is abstract;
>       
>    function Get_Size (Resizable : access Root_Resizable_Type) 
>      return Float is abstract;
>      
> end Resizable_Types;
> 
> 
> package Resizable_Types.Adapters is
> 
>    type Resizable_Adapter_Type is
>       new Root_Resizable_Type with private;
>       
>    procedure Set_Size
>      (Resizable : access Resizable_Adapter_Type;
>       Size      : in     Float);
>       
>    function Get_Size (Resizable : access Resizable_Adapter_Type) 
>      return Float;
>      
> private
> 
>    type Resizable_Adapter_Type is
>       new Root_Resizable_Type with record
>          Size : Float;
>       end record;
>      
> end Resizable_Types.Adapters;
> 
> with Colorable_Types.Adapters; use Colorable_Types;
> with Resizable_Types.Adapters; use Resizable_Types;
> 
> package My_Objects is
> 
>    type My_Object is limited private;
>    
>    function Colorable (Object : access My_Object)
>       return Colorable_Class_Access;
>       
>    function Resizable (Object : access My_Object)
>       return Resizable_Class_Access;
>       
>    procedure Do_Something (Object : in out My_Object);
>    
> private
> 
>    use Colorable_Types.Adapters;
>    use Resizable_Types.Adapters;
> 
>    type Colorable_View (Object : access My_Object) is
>       new Colorable_Adapter_Type with null record;
>       
>    type Resizable_View (Ojbect : access My_Object) is
>       new Resizable_Adapter_Type with null record;
>  
>    type My_Object is limited record
>       Colorable : aliased Colorable_View (My_Object'Access);
>       Resizable : aliased Resizable_View (My_Object'Access);
>    end record;
>    
> end My_Objects;
> 
> Now you can do this:
> 
> procedure Test_MI is
> 
>    Obj : aliased My_Object;
>    
> begin
> 
>    Set_Color (Colorable (Obj'Access), Color => 0);
>    Set_Size (Resizable (Obj'Access), Size => 1.0);
> 
>    Do_Something (Obj);
>    
> end Test_MI;
> 
> The type My_Object "inherits" from both Colorable and Resizable. 
> Anywhere you have subprogram that accepts a Colorable or Resizable,
> you can use a My_Object.

And here is how I wish it should be written (in hypotetical language).

Types {
  type Color = Integer;
  type Size = Float;
}

type GradientBar {
  data {
    Color1,Color2: Types.Color;
    Size: Types.Size;
  }
  procedure Draw;
}

interface Colorable {
  property Color : Types.Color;
}

interface Sizeable {
  property Size : Types.Size;
}

procedure EditColor(string Title, interface Colorable)...
procedure EditSize(string Title, interface Sizeable)...

procedure EditGradientBar(ref Bar: GradientBar) {
  with GradientBar {
    interface Color1 : Colorable {
      get { Color := data.Color1; }
      set { data.Color1 := Color; Draw; }
    }
    interface Color2: Colorable {
      get { Color := data.Color2; }
      set { data.Color2 := Color; Draw; }
    }
    interface : Sizeable {
      get { Size := data.Size; }
      set { data.Size := Size; Draw; }
    }
  }

  EditColor("Color1", Bar.Color1);
  EditColor("Color2", Bar.Color2);
  EditSize("Size", Bar);
}

Note, what interfaces are added outside of type definition.
I think that from Ada point of view its even more naturally than from
other languages.

http://www174.pair.com/yamir/programming/interfaces.htm
Amir Yantimirov

Re: Is the Writing on the Wall for Ada?

[Stephen Leake]

tmoran@acm.org writes:

> > > that demonstrates that MI does not work in general.
> >... this is a counterexample to the notion that
> >multiple inheritance from some set of bases is useful.
>   "work in general" can mean, and I think was intended to mean, "work in
> all cases", and clearly a single counterexample disproves that.  "work in
> general" could also take a less formal meaning of "work most of the time",
> and I suspect that's the way Hyman took it.  In that interpretation of
> course, the statement is not disproved by a single counterexample.

And that, I think, is a key difference between the C++ design
philosophy and the Ada philosophy.

I think we can all agree on this statement:

C++ style multiple inheritance is useful in some situations, and gives
surprising results in others.

The C++ design philosophy says "Since it's sometimes useful, let's do
it; user beware of the surprising stuff".

The Ada design philosophy says "Since it's sometimes surprising, we
can't do it; let's find another way to provide the useful
functionality".

kind of a glass half full / half empty thing.

-- 
-- Stephe

Re: Is the Writing on the Wall for Ada?

[Ed Falis]

On 12 Sep 2003 12:02:05 -0400
Stephen Leake <Stephe.Leake@nasa.gov> wrote:

> I think we can all agree on this statement:
> 
> C++ style multiple inheritance is useful in some situations, and gives
> surprising results in others.

So why take the C++ implementation of MI as the benchmark?  Consider the
Eiffel implementation, which provides much more control, and IMO, a much
cleaner resolution of the issues. (Not to mention that Eiffel's
aesthetic is much closer to Ada's).

- Ed

Re: Is the Writing on the Wall for Ada?

[Hyman Rosen]

Stephen Leake wrote:
> And that, I think, is a key difference between the C++ design
> philosophy and the Ada philosophy.

This is preposterous. Your argument is exactly the equivalent of
saying that since stringing together a sequence of arbitrary
procedure calls is going to produce a garbage program then
procedure calls should be banned.

Really, such desperation.

Re: Is the Writing on the Wall for Ada?

[Stephen Leake]

Hyman Rosen <hyrosen@mail.com> writes:

> Stephen Leake wrote:
> > And that, I think, is a key difference between the C++ design
> > philosophy and the Ada philosophy.
> 
> This is preposterous. Your argument is exactly the equivalent of
> saying that since stringing together a sequence of arbitrary
> procedure calls is going to produce a garbage program then
> procedure calls should be banned.

Hmm. I don't see how that conclusion follows from what I said. I
simply said that Ada takes a much more cautious approach to
implementing stuff than C++ does, which is partly why they have
different features.

> Really, such desperation.

Surely you agree there can be different levels of caution in language
design?

-- 
-- Stephe

Re: Is the Writing on the Wall for Ada?

[Alexander Kopilovitch]

Hyman Rosen wrote:

>You are demonstrating one case where MI is not
> appropriate, and you seem to think that this constitues a proof
> that MI is never appropriate.

Well, perhaps, you (or someone else) will set an example of proper
argumentation by providing an full case (that is, not only piece of program
code, but also sufficient information about surrounding application, its
operational enviroment and expected lifecycle), showing the situation when MI
is 1) appropriate, and 2) can't be implemented conveniently in Ada95, and even
with the interfaces proposed for Ada200Y. Then we all can analyze that example
in depth.

>     Socrates is a man.
>     Therefore all men are Socrates.

Perhaps yes, while no one can (or will) show me at least one man, who is
not Socrates (or at least looks like Socrates -:) .



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

Re: Is the Writing on the Wall for Ada?

[Hyman Rosen]

Alexander Kopilovitch wrote:
> proper argumentation

No need. The argument for single inheritance, whatever that was,
carries over directly to multiple inheritance. The argument for
interfaces carries over to bringing along some implementation.

Re: Is the Writing on the Wall for Ada?

[Matthew Heaney]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> writes:

> I remember my discussion with Rober Dewar 5 years ago. He said that MI
> will never come. Now, lo and behold! There is almost accepted ARG for
> multiple interface inheritance.

There is a huge difference between "multiple inheritance" and "multiple
interface inheritance."

Adding "interfaces" to Ada doesn't gainsay Robert's original comment,
because interface types aren't the same as MI.

Re: Is the Writing on the Wall for Ada?

[Dmitry A. Kazakov]

On Mon, 15 Sep 2003 09:33:27 GMT, Matthew Heaney
<matthewjheaney@earthlink.net> wrote:

>Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> writes:
>
>> I remember my discussion with Rober Dewar 5 years ago. He said that MI
>> will never come. Now, lo and behold! There is almost accepted ARG for
>> multiple interface inheritance.
>
>There is a huge difference between "multiple inheritance" and "multiple
>interface inheritance."

>Adding "interfaces" to Ada doesn't gainsay Robert's original comment,
>because interface types aren't the same as MI.

MII suffers same problems as full MI. When you add an interface it may
conflict with other interfaces. Adding an interface several times you
have the diamond problem: whether same interfaces are mapped to one
interface of the new type or to different cloned interfaces.

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

Re: Is the Writing on the Wall for Ada?

[Robert I. Eachus]

Dmitry A. Kazakov wrote:

> MII suffers same problems as full MI. When you add an interface it may
> conflict with other interfaces. Adding an interface several times you
> have the diamond problem: whether same interfaces are mapped to one
> interface of the new type or to different cloned interfaces.

The current write-up deals with the diamond problem as follows:

If you inherit operations from two types with the signature, if one is 
from the (direct) parent, that is the one used.  If the two are from 
different interfaces, then calling that operation is ambiguous.

So you can get around the diamond problem by directly inheriting from 
one interface and only inheriting the interface of the other.  Yes, it 
isn't perfect, but there is one full solution to the problem.  (With 
mix-ins, the order of inheritance determines which operation is visible 
for the final type, but you can alway either use renaming to make the 
hidden operation visible, or call it directly using type conversions.)

-- 
                                            Robert I. Eachus

"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: Is the Writing on the Wall for Ada?

[Dmitry A. Kazakov]

On Wed, 17 Sep 2003 01:00:46 GMT, "Robert I. Eachus"
<rieachus@attbi.com> wrote:

>Dmitry A. Kazakov wrote:
>
>> MII suffers same problems as full MI. When you add an interface it may
>> conflict with other interfaces. Adding an interface several times you
>> have the diamond problem: whether same interfaces are mapped to one
>> interface of the new type or to different cloned interfaces.
>
>The current write-up deals with the diamond problem as follows:
>
>If you inherit operations from two types with the signature, if one is 
>from the (direct) parent, that is the one used.  If the two are from 
>different interfaces, then calling that operation is ambiguous.

But actually one need all possible mappings 2->1 and 2->2, and in case
of n-th inheritance n->m. The diamond problem is a fundamental one,
which cannot be eliminated.

>So you can get around the diamond problem by directly inheriting from 
>one interface and only inheriting the interface of the other.  Yes, it 
>isn't perfect, but there is one full solution to the problem.  (With 
>mix-ins, the order of inheritance determines which operation is visible 
>for the final type, but you can alway either use renaming to make the 
>hidden operation visible, or call it directly using type conversions.)

Yes, but renaming + optional type conversions would be an universal
solution for full MI too.

BTW, one could require to name the bases as we are doing in case of
subroutine parameters:

type T_1 is ...;
type T_2 is new T_1 with ...;
type T_3 is new T_1 with ...;
type Diamond is new A : T_1,  B : T_2, C : T_3 with ...;
for Diamond.B.T_1 use Diamond.A;  -- All instances of T_1 are
for Diamond.C.T_1 use Diamond.A;  -- same

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

Re: Is the Writing on the Wall for Ada?

[Amir Yantimirov]

"Robert I. Eachus" <rieachus@attbi.com> wrote in message news:<3F6079A9.6080108@attbi.com>...
... 
> type Cartesian is record X,Y: Float; end record;
> 
> and the Polar type:
> 
> type Polar is record R, Theta: Float; end record;
> 
> we could even have a pair of procedures:
> 
> procedure Set_Point(P: Cartesian; X,Y: Float) is
> begin P := (X,Y); end Set_Point;
> 
> procedure Set_Point(P: Polar; R,Theta: Float) is
> begin P := (R, Theta); end Set_Point;
> 
> But for the union type, at least one of those implementations has to be 
> wrong.  For example, if the ACTUAL representation is cartesian, we need:
> 
> procedure Set_Point(P: Union; R, Theta: Float) is
> begin P := (R * sin (Theta), R * cos (Theta)); end Set_Point;
> 
> (Of course, in an actual implementation I would have different derived 
> types for X and Y, R, and Theta, and Theta would probably be a 
> fixed-point type.  But let's ignore that for now.)
> 
> This is why the new interfaces in Ada will allow direct derivation from 
> one type, and adding in as many interfaces as you wish.  Or, if you 
> prefer, no direct derivation and lots of interfaces.  But you can only 
> directly derive from one parent type, because that is the way the world 
> works, not due to any limitations we are building into Ada.
> 
> Notice that in my example, which was why I chose it, that the actual 
> implementation of the two potential parent types may match.  But the 
> MEANINGS of the data fields are different.

I think it is a good example that interfaces should be purely functional:

interface Cartesian is set X,Y: property Float; end set;
interface Polar is set R, Theta: property Float; end set;

Alas, without object.method notation this impossible.

http://www174.pair.com/yamir/programming/interfaces.htm
Amir Yantimirov

Re: Is the Writing on the Wall for Ada?

[Dmitry A. Kazakov]

On 11 Sep 2003 21:00:18 -0700, amir@iae.nsk.su (Amir Yantimirov)
wrote:

>I think it is a good example that interfaces should be purely functional:
>
>interface Cartesian is set X,Y: property Float; end set;
>interface Polar is set R, Theta: property Float; end set;

Note that Ada does not distinguish values and functions with no
arguments. Therefore, whether a cartesian point has a field X or a
"method" X is absolutely no matter. With true ADT you will never know
whether some field really exists or is just some proxy "methods".

>Alas, without object.method notation this impossible.

Why?

X (Cartesian_Object) is as good as Cartesian_Object.X

This is just syntax suggar. One could allow a renaming clause to
provide dot-notation.

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

Re: Is the Writing on the Wall for Ada?

[Dmitry A. Kazakov]

On Wed, 10 Sep 2003 19:47:46 GMT, "Robert I. Eachus"
<rieachus@attbi.com> wrote:

>Hyman Rosen wrote:
>
>> Thereby exhibiting the simple lack of courage to add multiple
>> inheritance. Why should we limit to inheriting from one type?
>> What is it about one that makes it better than two or more?
>
>Actually with interfaces added, Ada will have two ways of doing multiple 
>inheritance, mix-ins and interfaces.  This is fine because each is a 
>solution for different design idioms.
>
>Why not add "full" multiple inheritance and be done with it?  Sorry 
>there is no such thing.  Or if you prefer, deriving from several 
>interface classes with no privileged parent does exactly that.
>
>What having a single parent allows is inheriting both an interface and 
>an implementation.  You can't inherit multiple implementations, at least 
>not and have a single concrete implementation.  Let me give an example 
>so you can see the problems.  Let's say I have two point types, one of 
>which uses Cartesian coordinates, one of which uses polar coordinates.
>
>How do I implement multiple inheritance of both representations?  It 
>can't be done.  A representation that stored both cartesian and polar 
>coordinates would be possible.  But the compiler can't automatically 
>generate the code to insure that both representations agree.

Ada is not PL/1, if the compiler finds a problem it should not invent
a work-around, but just spit an error message. (:-))

> In fact if 
>you think about the representable points in both representations, they 
>are different sets!  Some points are in both sets, for example those on 
>the X and Y axis but almost all points in one representation do not have 
>exact representations in the other.  In addition, some of the points in 
>the cartesian domain will be at least (Sqrt(2)-1) * Element'Last away 
>from any point in the polar domain.
>
>Notice that if I do interface inheritance from the two concrete types, I 
>can program the underlying routines to do something sensible when say 
>adding a polar displacement to a cartesian point.  By the way, notice 
>that in Ada if I want I can provide a type with both cartesian and polar 
>implementations.  As a programmer, I can go further and add the 
>"missing" operations like adding a cartesian point to a polar point.  Do 
>everything right and "+" will just work.  That is a kind of multiple 
>implementations of a type that I can live with, and I don't know of any 
>other language where you can do such overloading.  (It is tricky enough 
>to get right in Ada...)

It is a good example and it shows that there should be both
implementation and interface inheritance. Then for interface
inheritance, it should be possible to inherit from concrete
(non-abstract) types.

In the case of multiple views on the SAME point object, it is clear
that implementation x 2 inheritance would be a wrong solution, because
it would define a 4D point! A right solution is either:

1. implementation inheritance from either Cartesian or Polar point and
interface inheritance from another.

2. interface inheritance from both.

But this does not prove that multiple implementation inheritance has
no place.

>Interface inheritance will make doing this sort of thing easier in Ada.
>But even now, Ada is providing more multiple inheritance than many 
>languages which are accepted as having "full" multiple inheritance. 
>Sorry if that doesn't satisfy you.

Absolutely. Interface inheritance opens a way to true ADT. Just allow
to inherit from an access type and you will have the user-defined
ones. Allow to inherit from an array and you will have array-looking
containers, user-defined unbounded strings etc.

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

Re: Can MI be supported? (Was: Is the Writing on the Wall for Ada?)

[Warren W. Gay VE3WWG]

Dmitry A. Kazakov wrote:
> On Wed, 10 Sep 2003 19:47:46 GMT, "Robert I. Eachus"
> <rieachus@attbi.com> wrote:
>>Hyman Rosen wrote:
...
>>Notice that if I do interface inheritance from the two concrete types, I 
>>can program the underlying routines to do something sensible when say 
>>adding a polar displacement to a cartesian point.  By the way, notice 
>>that in Ada if I want I can provide a type with both cartesian and polar 
>>implementations.  As a programmer, I can go further and add the 
>>"missing" operations like adding a cartesian point to a polar point.  Do 
>>everything right and "+" will just work.  That is a kind of multiple 
>>implementations of a type that I can live with, and I don't know of any 
>>other language where you can do such overloading.  (It is tricky enough 
>>to get right in Ada...)
> 
> It is a good example and it shows that there should be both
> implementation and interface inheritance. Then for interface
> inheritance, it should be possible to inherit from concrete
> (non-abstract) types.
> 
> In the case of multiple views on the SAME point object, it is clear
> that implementation x 2 inheritance would be a wrong solution, because
> it would define a 4D point! A right solution is either:
> 
> 1. implementation inheritance from either Cartesian or Polar point and
> interface inheritance from another.
> 
> 2. interface inheritance from both.
> 
> But this does not prove that multiple implementation inheritance has
> no place.

I have tried to stay out of this fray, and probably should ;-)

But I would add that it doesn't really matter that the MI example
makes no sense, or is poor design. I think what is being suggested
is that the language should allow the programmer to model anything
he can conceive of - even poorly formulated models!


The whole crux of the MI issue is about resolving the clashes of
method and attribute names that MI provokes (or leads to the
possibility of). Certainly, eliminating MI is one way to solve
the problem! Interfaces is another way to hand-wire it
for yourself (ie. working around the problem).

But I can't help but think that MI is "usable" with the correct
amount of care given to it.

Other language(s) allow you special syntax to either:

  - resolve the ambiguity in the declaration
    and
  - resolve the ambiguity in the reference(s)
    (methods and attributes)

I have forgotten the specific language(s) that make
these allowances.  Was it Eiffle?  No matter..


What follows is _just_ discussion, _NOT_ a proposal 8-)  so
don't flame me and the group for its ugliness ;-)


One conceptually ugly way to handle a given MI clash,
is to number them (the inherited from objects).  In
fact, I am sure that many have suggested something
along this line before.... Someone
said something earlier about couching the MI members in
records for example: but take that idea and reference them
by number (for this discussion): 1, for the first inherited
object, 2 for the next etc.  Methods could work along the
same idea.

Again, I am not in favour of using numbers in real
programs for all of the obvious reasons, so just bear with
me here, for discussion's sake.

Once this is done, then clashing members (attributes) and
methods can be qualified in the new objects internals and for
general applicatoin use (let's call these "MI qualifiers"):

    -- Inside some method of Combo_Point which inherits from
    -- a cartesian point and a polar point object:

    1:X := 0;
    2:R := 0;

Object methods could be resolved (in an ugly fashion) as follows:

    procedure My_App
       P : Combo_Point;
    begin
       1:Set_Point(P,New_X,New_Y);


OK, what was my point?  Well all of this is very ugly for
obvious reasons, but the point is that if the ambiguity
for MI is resolved, the whole MI issue goes away. Unless
perhaps I am missing some other related issues like
converting a MI object down to some base class (but again,
the proper qualifiers should be able to help).

You could say that the "MI qualifier" is
unnecessary when no conflicts occur. Certainly
the compiler would be capable of making that determination.
Under those circumstances you could say that this "MI qualification"
then would be illegal. This of course breaks badly, if in
the future a conflict is introduced due to a design change,
causing all clients of the objects to fail to compile
(but maybe that's a good thing?)

In conflicting cases, the compiler would have to insist that
you use "MI qualification" (in whatever elegant form that
someone can come up with -- here we used numbering only
for illustration purposes).

CONCLUSION:

In any case, I think MI _CAN_ be supported, where someone
were to address the "MI qualification" issue in a way that
can be agreed to.

Did I miss other problem(s) with MI that qualification
would not be able to solve? Perhaps there are some
problems within the Ada framework that I have not
anticipated here.

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Can MI be supported? (Was: Is the Writing on the Wall for Ada?)

[Robert I. Eachus]

Warren W. Gay VE3WWG wrote:

> CONCLUSION:
> 
> In any case, I think MI _CAN_ be supported, where someone
> were to address the "MI qualification" issue in a way that
> can be agreed to.

If you look at the mix-in example I just posted you can use the names of 
the intermediate packages to get at the different operations.  For 
example if Size and Color had both been derived from integers, then

    Set(Some_Object,2); --would be ambiguous;
    Set(Some_Object, Color'(2)); -- fine
    Set(Some_Object, Color(2)); -- okay, due to preference rule.
    My_Color.Set(Some_Object, 2); -- also works.
    My_Resize.Set(Some_Object, 2); -- still ambiguous.

> Did I miss other problem(s) with MI that qualification
> would not be able to solve? Perhaps there are some
> problems within the Ada framework that I have not
> anticipated here.

The problem with double direct inheritance has nothing to do with 
ambiguous methods. And as you can see if you look at the example I just 
posted, Ada already HAS multiple inheritance.

The problem with double direct inheritance has to do with membership 
properties.  With direct inheritance, say from types A and B, you need 
to be able to view an object as as if it isa A and isa B.  So where is 
the problem?  It is in the transitivity of isa.  In Ada there are many 
ways to create a new type or subtype which either subset or exend the 
parent type, but only one method of preserving the transitive isa 
relationship:

          subtype A is B;

As you can see, in Ada the transitive isa relationship holds with two 
subtypes of the same type which do not impose a constraint:

    type A is private;
    subtype B is A;
    subtype C is A;
    X: C;

X isa A, and therefore X isa B.

If type C is derived from B and also from A, as can occur with mix-ins 
and interface inheritance:

    type A is ...;
    type B is new A [with ...];
    type C is new B [with ...];
    X: C := ...;
    Y: A := ...;

Then X isa member of C, X isa member of B'Class, and X isa member of 
A'Class, but a Y is not necessarily a member of C'Class, or even 
viewable as a member of A'Class, and all is well in the world.  If 
somehow you added a notation for direct inheritance from two different 
types or classes you would have any C isa A and any C isa B, and 
therefore any A isa B.

The point I was trying to make with the Point example, is that even when 
the state information is identical in size and type (i.e. structural 
equivalence), its MEANING is different.  The first state variable can't 
represent both displacement on the X-axis and the vector length. 
(Although, as it happens, if the second state varible is zero, there is 
no problem. ;-)

In Ada we have gone the extra mile so that you can do view conversions 
on objects to an ancestor type. So even when you derive from a tagged 
type and add state, you can still do a view conversion and look at an 
object of the child type as if it isa member of the parent's class.  The 
tag is still visible, which is why the isa relation is to the parent's 
class, not to the definite type.  For non-tagged types, view conversion 
does satisfy the isa relationship.

Notice that mix-ins take advantage of this.  When you use mix-ins, the 
new type has all of the mix-ins as ancestor types, so if you have a 
generic formal package parameter of the form:

    package Bar is new Foo;

Or a formal derived type parameter of the form:

    type Foobar is new Foob with private;

Then a mix-in type (or the corresponding generic package instance) can 
be used to match the formal.

Could we allow in Ada a new construct:

         subtype A is B with C;

Sure.  In fact the new proposal for interface inheritance looks similar 
to that.  It would mean to directly inherit from B and add the C 
interface.  An A isa B, an A isa C, a B isa A, but an instance of C is 
not necessarily an A.  In practice, that is not all that useful, since 
maintaining the isa relationship would limit what the interfaces could 
add. So the new notation is actually:

         type A is new B with C, D, E;
         X: A := ...;
         Y: B := ...;
         ...
         X := A(Y); -- legal

This way A extends B, there exist views of X as a B, C, D, or E.  Y can 
be converted to an A. The interfaces are part of the type extension of B 
into A, and there are no transitivity problems:

        type F is new G with D;
        Z: F;
        ...
        X := A(D(Z)); -- illegal.

--
                                         Robert I. Eachus

"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: Can MI be supported? (Was: Is the Writing on the Wall for Ada?)

[Hyman Rosen]

Robert I. Eachus wrote:
> If somehow you added a notation for direct inheritance from two different 
> types or classes you would have any C isa A and any C isa B, and 
> therefore any A isa B.

Huh? How does that "therefore" follow from the premises?
My son is derived from an Engelson and a Rosen, but that
hardly means that all Engelsons are Rosens!

In my example, having a class which derives from ColorableAdapter
and ResizableAdapter does not say anything at all about a general
relationship between the two, only that there exists something
which is both.

One of us is really confused, and I don't think it's me.

Re: Can MI be supported? (Was: Is the Writing on the Wall for Ada?)

[Warren W. Gay VE3WWG]

"Robert I. Eachus" <rieachus@attbi.com> wrote in message news:3F636281.7010509@attbi.com...
> Warren W. Gay VE3WWG wrote:
>
> > CONCLUSION:
> >
> > In any case, I think MI _CAN_ be supported, where someone
> > were to address the "MI qualification" issue in a way that
> > can be agreed to.
>
> If you look at the mix-in example I just posted you can use the names of
> the intermediate packages to get at the different operations.  For
> example if Size and Color had both been derived from integers, then
>
>     Set(Some_Object,2); --would be ambiguous;
>     Set(Some_Object, Color'(2)); -- fine
>     Set(Some_Object, Color(2)); -- okay, due to preference rule.
>     My_Color.Set(Some_Object, 2); -- also works.
>     My_Resize.Set(Some_Object, 2); -- still ambiguous.

Although I can't really say that I have ever made use of mixin
inheritance yet, I can see its value.

However, when I look at the example of "Sibling Inheritance (Multiple
classification)", as described in:

http://www.adahome.com/9X/OOP-Ada9X.html#HDR11.2.%20%20Mixin%20Inheritance52

I start to gag on it's messy nature, and like C++ templates,
I am left begging for a simpler, more elegant answer.

> > Did I miss other problem(s) with MI that qualification
...
> The problem with double direct inheritance has to do with membership
> properties.  With direct inheritance, say from types A and B, you need
> to be able to view an object as as if it isa A and isa B.  So where is
> the problem?  It is in the transitivity of isa.  In Ada there are many
> ways to create a new type or subtype which either subset or exend the
> parent type, but only one method of preserving the transitive isa
> relationship:
>
>           subtype A is B;
>
...
> If type C is derived from B and also from A, as can occur with mix-ins
> and interface inheritance:
>
>     type A is ...;
>     type B is new A [with ...];
>     type C is new B [with ...];
>     X: C := ...;
>     Y: A := ...;
>
> Then X isa member of C, X isa member of B'Class, and X isa member of
> A'Class, but a Y is not necessarily a member of C'Class, or even
> viewable as a member of A'Class, and all is well in the world.

Agreed.

> If
> somehow you added a notation for direct inheritance from two different
> types or classes you would have any C isa A and any C isa B, and
> therefore any A isa B.

Hmmm... see comments later..

...
> In Ada we have gone the extra mile so that you can do view conversions
> on objects to an ancestor type. So even when you derive from a tagged
> type and add state, you can still do a view conversion and look at an
> object of the child type as if it isa member of the parent's class.

Right, but where is the conflict in MI in this? If I "convert"
C to B, then why not let me look at the "B" view using MI?
If I convert C to A, then why not allow me the use of the "A" view?

...
> Could we allow in Ada a new construct:
>
>          subtype A is B with C;
>
...
>          type A is new B with C, D, E;
>          X: A := ...;
>          Y: B := ...;
>          ...
>          X := A(Y); -- legal
>
> This way A extends B, there exist views of X as a B, C, D, or E.  Y can
> be converted to an A. The interfaces are part of the type extension of B
> into A, and there are no transitivity problems:

Yes, a little confusing, but I see.

OK, so MI can mess up the "is a" test if I understand correctly
(it leads to "incompatible logical conclusions").

So why not add "has a" test? Then you could test if instance V "has a"
X, Y or Z component. You could also say that V is "not is a" X, Y or Z,
since clearly it is not any one of them by themselves.

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Can MI be supported? (Was: Is the Writing on the Wall for Ada?)

[Robert I. Eachus]

Warren W. Gay VE3WWG wrote:

> So why not add "has a" test? Then you could test if instance V "has a"
> X, Y or Z component. You could also say that V is "not is a" X, Y or Z,
> since clearly it is not any one of them by themselves.

I don't know that I would call it "has a" but that is exactly what 
mix-ins do.  But I have wondered whether we got mix-ins too right in Ada 
95.  I just saw a post by Matt Heaney on access discriminants.  There 
are some roles for which the mix-in needs access to the whole object, 
and his particular example (persistant types) is one of them.  But for 
most roles where a role only needs access to its own state variables, 
mix-ins do the job nicely and much more elegantly than access 
discriminants.  But some programmers miss this easy way because it is 
too easy and too elegant.

In the example I gave (a complete executable example) the mix-ins added 
state variables of type Color and Size to a type, with Get and Set 
operations for each.  I did this deliberately because some people worry 
about view conflicts with multiple inheritance.  But this is Ada!  The 
operations overload each other, and potentially additional operations of 
the same name on the object type, but the strong typing means that 
Set(Some_Object, Red) and Set(Some_Object, Small) will not conflict.

You can even, and I have done this, instantiate the same mix-in twice on 
the same base type.  I was implementing two-dimensional sparse arrays as 
linked lists.  One mix-in added row links, one added column links, and 
if I wanted to add a (non-zero) element to a sparse matrix, I said:

          Add(Entry, Some_Matrix, Row_Number);
          Add(Entry, Some_Matrix, Column_Number);

And overload resolution took care of the rest. Since Rows and Columns 
were separate types derived from Integer, I couldn't even try to mix 
them up.  This may sound like I was doing linear algebra on the sparse 
arrays, and to some extent I was.  But the entries were actually records 
with about 160 bytes of data, and I was doing row and column permutation 
operations and vector operations where this representation was perfect. 
  The linked lists didn't have to be in any particular order.




-- 
"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: Can MI be supported? (Was: Is the Writing on the Wall for Ada?)

[Dmitry A. Kazakov]

On Sun, 14 Sep 2003 19:33:02 -0400, "Warren W. Gay VE3WWG"
<ve3wwg@cogeco.ca> wrote:

>"Robert I. Eachus" <rieachus@attbi.com> wrote in message news:3F636281.7010509@attbi.com...
>> Warren W. Gay VE3WWG wrote:

>> In Ada we have gone the extra mile so that you can do view conversions
>> on objects to an ancestor type. So even when you derive from a tagged
>> type and add state, you can still do a view conversion and look at an
>> object of the child type as if it isa member of the parent's class.
>
>Right, but where is the conflict in MI in this? If I "convert"
>C to B, then why not let me look at the "B" view using MI?
>If I convert C to A, then why not allow me the use of the "A" view?

It is a question of definition. If to view "C" as "B" we need a
conversion, then it is probably rather an interface inheritance than
classical implementation inheritance.

From my point of view, which most people are disagree with (:-)),
there is absolutely no difference, how "view" conversion is achieved,
whether by shifting a reference or by creation a new object. From the
interface point of view, only the fact that this can achived counts.
The rest is just implementation details.

>OK, so MI can mess up the "is a" test if I understand correctly
>(it leads to "incompatible logical conclusions").

No, it is "IS-A" which leads to incompatible logical conclusions!
(:-)) Especially when "substitutable-for" and "interchangeable-with"
are mixed.

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

Re: Can MI be supported? (Was: Is the Writing on the Wall for Ada?)

[Robert I. Eachus]

Dmitry A. Kazakov wrote:

 > No, it is "IS-A" which leads to incompatible logical conclusions!
 > (:-)) Especially when "substitutable-for" and "interchangeable-with"
 > are mixed.

Correct.  I just read an interesting paper on "traits" for Smalltalk. It
of course explained the shortcomings of "true" MI. (It doesn't work
whether you want to call the reason the overriding problem, the diamond
inheritance pattern or whatever.)  It also explained the disadvantages
of mix-in style inheritance.  Of course, the major problems with mix-ins
in other languages don't occur in Ada.  (In Ada you have explicit
control of visibility, and the implementor of the type can always name
and call any methods that might be hidden or overloaded, and even rename
them to make them visible to users of the final concrete type.  And of
course, any methods that don't make sense for the concrete type can be
hidden from users.)

And finally it defined a method of creating and sharing traits.  It
looked like a very interesting design paradigm.  It will be possible to
implement traits in Ada with interfaces.  But even without interfaces
you can implement the pattern using mix-ins.  Of course, mix-ins allow
you to add state, and traits don't, but you can always implement at
trait with generics.

Basically with traits you expect the "base" object to have all the
necessary state, and the traits manage existing state variables.  To use 
the cartesian and polar co-ordinate example, you might have all objects 
with a location attribute as part of its state.  Then the cartesian and 
polar trait addins would manage that part of the state.  The norm would 
be for some objects to have polar co-ordinates and others to have 
cartesian co-ordinates, and the actual trait inherited would determine 
how co-ordinates were managed:

type Location (Polar: Boolean) is record
    case Polar is
      when True => R, Theta: Float;
      when False => X, Y: Float;
    end case;
end record;

type Some_Object is ...
    Where: Location(Polar => True);
    ...
end record;

generic
    type Extended is new Object;
package Polar_Coordinates is
    function Get(Obj: in Extended) return Location;
    procedure Set(Obj: in out Extended R, Theta: in Float);
    ...
end Polar_Coordinates;

and so on...

But I think I'll stick to mix-ins for now.


--
                                      Robert I. Eachus

"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: Is the Writing on the Wall for Ada?

[Ed Falis]

On Sun, 07 Sep 2003 19:01:48 GMT
"Robert I. Eachus" <rieachus@attbi.com> wrote:

> There is a proposal for Ada 200X to add interfaces to Ada.  It has
> been extensively worked, and will almost surely be added.
> 
> Why?  Because intefaces are different from Ada generics and solve
> other problems.  In particular adding interfaces to Ada allows derived
> types where the type inherits one parent type and adds one or more
> interfaces. 
>   The user must then provide explicitly declared subprograms to match 
> any subprograms in the interfaces that are not provided by the parent 
> type.  (In the proposal you can inherit from only interfaces as well. 
> But directly inheriting from only one interface is not that
> interesting a case.)

To get a feel for the real power of interfaces, check out "Working with
Objects" by Trygve Reenskaug.  This is a book from the Smalltalk
community, but the concepts in it are broadly applicable.  In
Reenskaug's approach, interfaces are similar to the "roles" he
describes.

- Ed

Re: Is the Writing on the Wall for Ada?

[olehjalmar kristensen - Sun Microsystems - Trondheim Norway]

>>>>> "EF" == Ed Falis <falis@verizon.net> writes:

    EF> On Sun, 07 Sep 2003 19:01:48 GMT
    EF> "Robert I. Eachus" <rieachus@attbi.com> wrote:

    >> There is a proposal for Ada 200X to add interfaces to Ada.  It has
    >> been extensively worked, and will almost surely be added.
    >> 
    >> Why?  Because intefaces are different from Ada generics and solve
    >> other problems.  In particular adding interfaces to Ada allows derived
    >> types where the type inherits one parent type and adds one or more
    >> interfaces. 
    >> The user must then provide explicitly declared subprograms to match 
    >> any subprograms in the interfaces that are not provided by the parent 
    >> type.  (In the proposal you can inherit from only interfaces as well. 
    >> But directly inheriting from only one interface is not that
    >> interesting a case.)

    EF> To get a feel for the real power of interfaces, check out "Working with
    EF> Objects" by Trygve Reenskaug.  This is a book from the Smalltalk
    EF> community, but the concepts in it are broadly applicable.  In
    EF> Reenskaug's approach, interfaces are similar to the "roles" he
    EF> describes.

    EF> - Ed

The book is now available for download from the authors as a PDF file.

Re: Is the Writing on the Wall for Ada?

[Ed Falis]

On 08 Sep 2003 16:55:42 +0200
olehjalmar kristensen - Sun Microsystems - Trondheim Norway
<ok145024@sun.com> wrote:

> The book is now available for download from the authors as a PDF file.

Definitely one of the best OO design books I've read.

- Ed

Re: Is the Writing on the Wall for Ada?

[Robert Spooner]

olehjalmar kristensen - Sun Microsystems - Trondheim Norway wrote:
> The book is now available for download from the authors as a PDF file.

Can you give us the URL?

Thanks,
Bob
-- 
                             Robert L. Spooner
                      Registered Professional Engineer
                        Associate Research Engineer
                   Intelligent Control Systems Department

          Applied Research Laboratory        Phone: (814) 863-4120
          The Pennsylvania State University  FAX:   (814) 863-7841
          P. O. Box 30
          State College, PA 16804-0030       rls19@psu.edu

Re: Is the Writing on the Wall for Ada?

[olehjalmar kristensen - Sun Microsystems - Trondheim Norway]

You can find a link to it from Trygve Reenskaugs home page:

http://heim.ifi.uio.no/~trygver/topPage.html

>>>>> "RS" == Robert Spooner <rls19@psu.edu> writes:

    RS> olehjalmar kristensen - Sun Microsystems - Trondheim Norway wrote:
    >> The book is now available for download from the authors as a PDF file.

    RS> Can you give us the URL?

    RS> Thanks,
    RS> Bob
    RS> -- 
    RS>                              Robert L. Spooner
    RS>                       Registered Professional Engineer
    RS>                         Associate Research Engineer
    RS>                    Intelligent Control Systems Department

    RS>           Applied Research Laboratory        Phone: (814) 863-4120
    RS>           The Pennsylvania State University  FAX:   (814) 863-7841
    RS>           P. O. Box 30
    RS>           State College, PA 16804-0030       rls19@psu.edu

Re: Is the Writing on the Wall for Ada?

[Hyman Rosen]

Russ wrote:
> Suppose I want to take the sine of an angle in Java. Can I somehow set
> things up so that I can simply write "sin(x)", or must I write
> something like "math.sin(x)"? The former is acceptable to me, but the
> latter is not.

The latter generally. Also for cases like this, 'math' would be a class,
not an object, and 'sin' would be a static method. If that's too odious,
you can always do this:

     class MotherOfAnythingIWouldEverCall
     {
         double sin(double x) { return math.sin(x); }
         // etc.
     }

     class MyClass extends MotherOfAnythingIWouldEverCall
     {
         double f(double x) { return sin(sin(x)); }
     }

But no one would do that. Just pretend you're using Ada in a shop
that has forbidden use clauses.

Re: Is the Writing on the Wall for Ada?

[Russ]

Hyman Rosen <hyrosen@mail.com> wrote in message news:<Mia7b.8477$w41.4485@nwrdny02.gnilink.net>...
> Russ wrote:
> > Suppose I want to take the sine of an angle in Java. Can I somehow set
> > things up so that I can simply write "sin(x)", or must I write
> > something like "math.sin(x)"? The former is acceptable to me, but the
> > latter is not.
> 
> The latter generally. Also for cases like this, 'math' would be a class,
> not an object, and 'sin' would be a static method. If that's too odious,
> you can always do this:
> 
>      class MotherOfAnythingIWouldEverCall
>      {
>          double sin(double x) { return math.sin(x); }
>          // etc.
>      }
> 
>      class MyClass extends MotherOfAnythingIWouldEverCall
>      {
>          double f(double x) { return sin(sin(x)); }
>      }
> 
> But no one would do that. Just pretend you're using Ada in a shop
> that has forbidden use clauses.

Then Java was certainly not designed for elegant implementation of
algorithms.

Let me give you a brief example of some basic greatcircle calculations
based on a spherical model of the earth.

The great circle distance d between two points with coordinates
{lat1,lon1} and {lat2,lon2} is given by:

d = 2 * asin(sqrt((sin((lat1-lat2)/2))^2 +
cos(lat1)*cos(lat2)*(sin((lon1-lon2)/2))^2))

We obtain the initial course, tc1, (at point 1) from point 1 to point
2 by the following. The formula fails if the initial point is a pole.

tc1 = mod(atan2(sin(lon1-lon2)*cos(lat2),
           cos(lat1)*sin(lat2)-sin(lat1)*cos(lat2)*cos(lon1-lon2)),
2*pi)

The corresponding equations for the ellipsoidal model of the earth are
far more complicated, but even these relatively simple equations
demonstrate the awkwardness of using Java for algorithms. The latter
expression has no less than 9 math functions plus a constant (pi), and
you're telling me I must precede each one with "math." (or do some
other nonstandard trick).

You can have it.

Re: Is the Writing on the Wall for Ada?

[Dr. Michael Paus]

Hi

there is no need to discuss this issue here any longer, because the
problem is well known and will be fixed in the upcoming release of
Java (1.5 Tiger).

http://jcp.org/aboutJava/communityprocess/jsr/tiger/static-import.html

Greetings

Michael

Russ wrote:

> Hyman Rosen <hyrosen@mail.com> wrote in message news:<Mia7b.8477$w41.4485@nwrdny02.gnilink.net>...
> 
>>Russ wrote:
>>
>>>Suppose I want to take the sine of an angle in Java. Can I somehow set
>>>things up so that I can simply write "sin(x)", or must I write
>>>something like "math.sin(x)"? The former is acceptable to me, but the
>>>latter is not.
>>
>>The latter generally. Also for cases like this, 'math' would be a class,
>>not an object, and 'sin' would be a static method. If that's too odious,
>>you can always do this:
>>
>>     class MotherOfAnythingIWouldEverCall
>>     {
>>         double sin(double x) { return math.sin(x); }
>>         // etc.
>>     }
>>
>>     class MyClass extends MotherOfAnythingIWouldEverCall
>>     {
>>         double f(double x) { return sin(sin(x)); }
>>     }
>>
>>But no one would do that. Just pretend you're using Ada in a shop
>>that has forbidden use clauses.
> 
> 
> Then Java was certainly not designed for elegant implementation of
> algorithms.
> 
> Let me give you a brief example of some basic greatcircle calculations
> based on a spherical model of the earth.
> 
> The great circle distance d between two points with coordinates
> {lat1,lon1} and {lat2,lon2} is given by:
> 
> d = 2 * asin(sqrt((sin((lat1-lat2)/2))^2 +
> cos(lat1)*cos(lat2)*(sin((lon1-lon2)/2))^2))
> 
> We obtain the initial course, tc1, (at point 1) from point 1 to point
> 2 by the following. The formula fails if the initial point is a pole.
> 
> tc1 = mod(atan2(sin(lon1-lon2)*cos(lat2),
>            cos(lat1)*sin(lat2)-sin(lat1)*cos(lat2)*cos(lon1-lon2)),
> 2*pi)
> 
> The corresponding equations for the ellipsoidal model of the earth are
> far more complicated, but even these relatively simple equations
> demonstrate the awkwardness of using Java for algorithms. The latter
> expression has no less than 9 math functions plus a constant (pi), and
> you're telling me I must precede each one with "math." (or do some
> other nonstandard trick).
> 
> You can have it.

Re: Is the Writing on the Wall for Ada?

[Hyman Rosen]

Dr. Michael Paus wrote:
> there is no need to discuss this issue here any longer, because the
> problem is well known and will be fixed in the upcoming release of
> Java (1.5 Tiger).

I see that Java is marching down the well-trodden path of ad hoc-ery
beaten out by C++. It really does go to show that a language ought to
be well-designed and thought out in the first place.

Re: Is the Writing on the Wall for Ada?

[Wes Groleau]

Russ wrote:
> The corresponding equations for the ellipsoidal model of the earth are
> far more complicated, but even these relatively simple equations
> demonstrate the awkwardness of using Java for algorithms. The latter
> expression has no less than 9 math functions plus a constant (pi), and
> you're telling me I must precede each one with "math." (or do some
> other nonstandard trick).

As much as I prefer Ada over Java,
this particular point is not a good reason.

class whatever
{

    static float sin (float F)
    {
      return Math.sin(F);
    }

    // Now you can use sin() as easily as in Ada.
    // The above maybe a "nonstandard trick" but
    // it's certainly not painful.

}

-- 
Wes Groleau
When all you have is a perl, everything looks like a string.

Re: Is the Writing on the Wall for Ada?

[Matthew Heaney]

18k11tm001@sneakemail.com (Russ) writes:

> I note also that C, C++, Java, Perl, and Python, the five more popular
> general purpose languages around today, all have augmented assignment
> operators, and it it is still painfully obvious to me that Ada needs
> them too. But it is also painfully obvious to me that most Ada
> veterans are blind to this reality. Too bad -- for Ada.

What kind of "augmented" assignment operator did you have in mind?

Re: Is the Writing on the Wall for Ada?

[Frank J. Lhota]

"Matthew Heaney" <matthewjheaney@earthlink.net> wrote in message
news:uvfrvanu3.fsf@earthlink.net...
> 18k11tm001@sneakemail.com (Russ) writes:
> What kind of "augmented" assignment operator did you have in mind?

I'm fairly sure he means the sort of thing where instead of writing

    Item(Number).Inventory.Count := Item(Number).Inventory.Count + 1;

you could write

    Item(Number).Inventory.Count +:= 1;

This was discussed in a thread from earlier this year. Check out the
"proposal for new assignment operators" thread from June 24.

And for the record, I was in favor of augmented assignments.

Re: Is the Writing on the Wall for Ada?

[Matthew Heaney]

"Frank J. Lhota" <NOSPAM.FrankLho@rcn.com> writes:

> "Matthew Heaney" <matthewjheaney@earthlink.net> wrote in message
> news:uvfrvanu3.fsf@earthlink.net...
> > 18k11tm001@sneakemail.com (Russ) writes:
> > What kind of "augmented" assignment operator did you have in mind?
> 
> I'm fairly sure he means the sort of thing where instead of writing
> 
>     Item(Number).Inventory.Count := Item(Number).Inventory.Count + 1;
> 
> you could write
> 
>     Item(Number).Inventory.Count +:= 1;

Well, here's what I do in this case:

declare
   N : Integer renames Item (Number).Inventory.Count;
begin
   N := N + 1;
end;

Re: Is the Writing on the Wall for Ada?

[Russ]

Matthew Heaney <matthewjheaney@earthlink.net> wrote in message news:<u1xuja5zs.fsf@earthlink.net>...
> "Frank J. Lhota" <NOSPAM.FrankLho@rcn.com> writes:
> 
> > "Matthew Heaney" <matthewjheaney@earthlink.net> wrote in message
> > news:uvfrvanu3.fsf@earthlink.net...
> > > 18k11tm001@sneakemail.com (Russ) writes:
> > > What kind of "augmented" assignment operator did you have in mind?
> > 
> > I'm fairly sure he means the sort of thing where instead of writing
> > 
> >     Item(Number).Inventory.Count := Item(Number).Inventory.Count + 1;
> > 
> > you could write
> > 
> >     Item(Number).Inventory.Count +:= 1;
> 
> Well, here's what I do in this case:
> 
> declare
>    N : Integer renames Item (Number).Inventory.Count;
> begin
>    N := N + 1;
> end;

The fact that you need five lines, a new scope, and a new variable to
do what most programmers (C, C++, Java, Perl, and Python) can do in
one simple line should tell you something. If that's what Ada
programmers call "more readable," then I'll take the "less readable"
code, thanks.

I said in an earlier thread that augmented assignment operators should
be added for addition, subtraction, multiplication, and division. They
would be equivalent to the +=, -=, *=, and /= operators of C, C++,
Java, Perl, and Python. Since Ada already uses /=, I suggested that
:+, :-, :*, and :/ could perhaps be used. Others have suggested that
the three-character combinations could be used. I think two-character
combinations are preferable, but the three-character combinations
would be a big step forward too.

Re: Is the Writing on the Wall for Ada?

[Robert I. Eachus]

Russ wrote:

> The fact that you need five lines, a new scope, and a new variable to
> do what most programmers (C, C++, Java, Perl, and Python) can do in
> one simple line should tell you something. If that's what Ada
> programmers call "more readable," then I'll take the "less readable"
> code, thanks.

You are being silly.  Another common approach in Ada is to define a 
procedure to do the work.  Now I might give an example as:

procedure Inc(X: in out Integer) is
begin X := X + 1; end Inc;
pragma Inline(Inc);

And sometimes I have done just that.  But in reality, an operation like 
that is seldom on Integers, because of the almost ironclad style of for 
loops in Ada.  And when it does occur, I am going to think about whether 
overflow can occur, and if it can what should happen on overflow.

So in actual practice I have written lots of "little" Inc subroutines 
that ended up being a package exporting an encapsulated type. Where the 
  package itself was several pages long including comments.  Does this 
mean that Ada is verbose?  No.  Because I only had to define what should 
happen in all the exceptional cases associated with that type in one 
place.  For an example, if this was part of an inventory control system, 
changing the count of items in stock might trigger all sorts of actions. 
  It might be for example that increasing the number might do a check to 
see if some customer had that item on backorder, and if so generate a 
shipping order.

Similarly I have also done exactly what Matt was talking about:

declare
    N : Integer renames Item (Number).Inventory.Count;
begin
    ...
    N := N + 1;
    ...
end;

But I added the elipses to indicate that ususally when you do that, the 
complex name would appear in several other places in that code segment, 
and the declare block makes it clear that that code is operating on one 
particular record.  So the example might really become:

declare
    N : Integer renames Item (Number).Inventory;
begin
    -- some operations on N
    N.Count := N.Count + 1;
    -- more operations on N
end;

In fact, almost always when you use this idiom it is directly inside a loop:

for Number in Item'Range loop
    declare
       N : Integer renames Item (Number).Inventory;
    begin
       -- some operations on N
       N.Count := N.Count + 1;
       -- more operations on N
    end;
end loop;

-- 
                                          Robert I. Eachus

"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: Is the Writing on the Wall for Ada?

[Russ]

"Robert I. Eachus" <rieachus@attbi.com> wrote in message news:<3F650BBE.4080107@attbi.com>...
> Russ wrote:
> 
> > The fact that you need five lines, a new scope, and a new variable to
> > do what most programmers (C, C++, Java, Perl, and Python) can do in
> > one simple line should tell you something. If that's what Ada
> > programmers call "more readable," then I'll take the "less readable"
> > code, thanks.
> 
> You are being silly.  Another common approach in Ada is to define a 
> procedure to do the work.  Now I might give an example as:

Mr. Eachus, you are probably a top-notch programmer and/or software
engineer, but I don't think your example has much bearing on whether
Ada should or should not have augmented assignment operators.

Rather than getting wrapped around the axle explaining why, let me
just point out that, with only slight modification, your example could
have equally been used to argue against the standard arithmetic
operators (+, -, *, and /). Think about it. Do you think Ada shouldn't
have those operators either? I doubt it.

Incrementing a variable with a long name or path is hardly the only
benefit of augmented assignment. As every competent C++ programmer
knows, augmented assignment also allows more efficient vector/matrix
operations (for example) by eliminating the need for temporaries. This
was discussed in detail on a previous thread. I was surprised at how
many comp.lang.ada readers argued with me about that, but they were
and still are wrong. They'll probably argue with me here again, and
they will still be just as wrong. Alas, ignorance is never in short
supply.

It seems to me that this entire debate really boils down to a
fundamental difference in how a programmers view basic arithmetic
operations. If I write a = b + c, I am adding two variables and
putting the result in a third. But if I write a = a + b, I am doing
something different: I am incrementing the value of a and puting the
result right back in the same place. That's why a += b or a :+ b is a
more natural way to express the operation. It's as simple as that.

And that's why the most popular programming languages have augmented
assignment operators. But Ada doesn't want to be popular, I guess.
Don't worry, at this rate it won't be. The question is whether it will
be alive for long.

> procedure Inc(X: in out Integer) is
> begin X := X + 1; end Inc;
> pragma Inline(Inc);
> 
> And sometimes I have done just that.  But in reality, an operation like 
> that is seldom on Integers, because of the almost ironclad style of for 
> loops in Ada.  And when it does occur, I am going to think about whether 
> overflow can occur, and if it can what should happen on overflow.
> 
> So in actual practice I have written lots of "little" Inc subroutines 
> that ended up being a package exporting an encapsulated type. Where the 
>   package itself was several pages long including comments.  Does this 
> mean that Ada is verbose?  No.  Because I only had to define what should 
> happen in all the exceptional cases associated with that type in one 
> place.  For an example, if this was part of an inventory control system, 
> changing the count of items in stock might trigger all sorts of actions. 
>   It might be for example that increasing the number might do a check to 
> see if some customer had that item on backorder, and if so generate a 
> shipping order.
> 
> Similarly I have also done exactly what Matt was talking about:
> 
> declare
>     N : Integer renames Item (Number).Inventory.Count;
> begin
>     ...
>     N := N + 1;
>     ...
> end;
> 
> But I added the elipses to indicate that ususally when you do that, the 
> complex name would appear in several other places in that code segment, 
> and the declare block makes it clear that that code is operating on one 
> particular record.  So the example might really become:
> 
> declare
>     N : Integer renames Item (Number).Inventory;
> begin
>     -- some operations on N
>     N.Count := N.Count + 1;
>     -- more operations on N
> end;
> 
> In fact, almost always when you use this idiom it is directly inside a loop:
> 
> for Number in Item'Range loop
>     declare
>        N : Integer renames Item (Number).Inventory;
>     begin
>        -- some operations on N
>        N.Count := N.Count + 1;
>        -- more operations on N
>     end;
> end loop;

Re: Is the Writing on the Wall for Ada?

[Wes Groleau]

Russ wrote:
> knows, augmented assignment also allows more efficient vector/matrix
> operations (for example) by eliminating the need for temporaries. This
> was discussed in detail on a previous thread. I was surprised at how
> many comp.lang.ada readers argued with me about that, but they were
> and still are wrong. They'll probably argue with me here again, and
> they will still be just as wrong. Alas, ignorance is never in short
> supply.

Interesting how you were not able to persuade
any of us ignoramuses that temporaries are
always needed without it nor that they are
never needed with it.

-- 
Wes Groleau
Genealogical Lookups:  http://groleau.freeshell.org/ref/lookups.html

Re: Is the Writing on the Wall for Ada?

[Robert I. Eachus]

Wes Groleau wrote:

 > Interesting how you were not able to persuade any of us ignoramuses
 > that temporaries are always needed without it nor that they are never
 > needed with it.

Let me tell you a story with names removed because I don't want to seem
to be dissing any company or compiler--because in this case the reality 
was just the opposite.

A woman, who was a fairly well respected compiler expert called me for 
advice.  She was implementing an Ada compiler for a vector machine, and 
was concerned that as she read the rules, Ada required copying the 
arguments in cases where Fortran 90 did not.

I gave her a few lines of Fortran over the phone.  She said, yes, that 
is exactly an example of what I am talking about.  Okay, I said, go 
compile it, run it, and look at the results...

After lunch she called me back.  "As you must have expected, our Fortran 
compiler produced garbage."

"Yep, and I can give you chapter and verse from the Fortran standard 
where it says that case is not erroneous."

"No need, I can do that myself.  Do I need to fix the Fortran compiler 
to make copies of vectors in all the cases that Ada requires them?"

"Nope, if you look at the wording carefully, all that both languages 
require is that you get the right answer.  It is just a little more 
obvious in Ada that sometimes that requires an 'extra' copy."

She fixed her Fortran compiler, and also validated her Ada compiler. 
But let me explain why she had problems.  On a vector machine, the 
hardware can step through an array with a "stride" set to more than one. 
  In other words extract a vector from a 2 dimensional, or even 
n-dimensional array.  But in both Ada and Fortran you can store the 
result of that computation in the same array.  Now imagine a case where 
the vector machine grabs more than one value--this one took 8 byte 
chuncks so a single precison array would do.  But for the code I 
suggested the vector engine wrote back the modified eight-byte value 
with the second half modified, just after writing the first four bytes. 
  The hardware couldn't guarantee that the two writes would occur in any 
particular order, and in practice they didn't.

Both Ada and Fortran were willing to allow her not to use temporaries, 
as long as the compiler could verify that this particular gotcha didn't 
occur.

-- 
                                          Robert I. Eachus

"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: Is the Writing on the Wall for Ada?

[Wes Groleau]

Robert I. Eachus wrote:
> Wes Groleau wrote (to Russ):
>  > Interesting how you were not able to persuade any of us ignoramuses
>  > that temporaries are always needed without it nor that they are never
>  > needed with it.
> 
> Let me tell you a story with names removed [snip interesting story]
> 
> Both Ada and Fortran were willing to allow her not to use temporaries, 
> as long as the compiler could verify that this particular gotcha didn't 
> occur.

The story was interesting, but whether due to my IQ
or the fact it's an hour past my bedtime, I must confess
I do not know whether you were illustrating my point
or agreeing with Russ.

(Russ insists that A += 1 never needs temporaries
and that A := A + 1 always does.)

-- 
Wes Groleau
-----------
I've been framed! ...
http://www.useit.com/alertbox/9612.html

Re: Is the Writing on the Wall for Ada?

[Russ]

Wes Groleau <groleau@freeshell.org> wrote in message news:<RbSdnT6kv7SrdPqiU-KYuQ@gbronline.com>...
> Robert I. Eachus wrote:
> > Wes Groleau wrote (to Russ):
> >  > Interesting how you were not able to persuade any of us ignoramuses
> >  > that temporaries are always needed without it nor that they are never
> >  > needed with it.
> > 
> > Let me tell you a story with names removed [snip interesting story]
> > 
> > Both Ada and Fortran were willing to allow her not to use temporaries, 
> > as long as the compiler could verify that this particular gotcha didn't 
> > occur.
> 
> The story was interesting, but whether due to my IQ
> or the fact it's an hour past my bedtime, I must confess
> I do not know whether you were illustrating my point
> or agreeing with Russ.
> 
> (Russ insists that A += 1 never needs temporaries
> and that A := A + 1 always does.)

That's not *quite* what I insist. What I insist is that, for
vector/matrix operations, "+" is a *function* that must create a
temporary vector/matrix and return it, and it must be *copied* to the
lhs. On the other hand, "+=" is a *procedure* that does not
necessarily need any temporaries because it can do its operations "in
place". No temporaries, no extra copying.

In the previous thread, someone claimed that "+=" needs a temporary
too for some sort of overflow checking (I don't recall the exact
reason given). If that is true, then it is an example of an inherent
inefficiency built in to Ada. For better or worse, C++ has no such
inefficiency. (I'm just stating a fact, I am *not* claiming that C++
did it right.)

Someone else also claimed that a good Ada compiler can make "+" as
efficient as "+=", but I don't see how that could be possible,
considering that I could define "+" and "+=" to do anything I want.
Nothing in the language requires me to define "+" to actually do
matrix addition. I could define it to write poetry if I wish.

And let's not forget that a properly defined "+" should be able to
handle sequential addition, such as A = B + C + D + E. No matter how
you slice it, each of those additions needs a temporary. On the other
hand, you could write

A = B
A += C
A += D
A += E

It's not as elegant, but no temporaries or extra copying are required
(unless the language imposes them for extraneous reasons).

Re: Is the Writing on the Wall for Ada?

[Martin Dowie]

"Russ" <18k11tm001@sneakemail.com> wrote in message
news:bebbba07.0309171110.192b565c@posting.google.com...
> In the previous thread, someone claimed that "+=" needs a temporary
> too for some sort of overflow checking (I don't recall the exact
> reason given). If that is true, then it is an example of an inherent
> inefficiency built in to Ada. For better or worse, C++ has no such
> inefficiency. (I'm just stating a fact, I am *not* claiming that C++
> did it right.)

And Ada will not have this "inefficiency" if _you_ select to remove the
checks. The difference is that you do it _explicitly_ in Ada.

To have equivilent code in C++ if would have to hand-write the
check and then throw the exception.

Re: Is the Writing on the Wall for Ada?

[Mark A. Biggar]

Martin Dowie wrote:
> "Russ" <18k11tm001@sneakemail.com> wrote in message
> news:bebbba07.0309171110.192b565c@posting.google.com...
> 
>>In the previous thread, someone claimed that "+=" needs a temporary
>>too for some sort of overflow checking (I don't recall the exact
>>reason given). If that is true, then it is an example of an inherent
>>inefficiency built in to Ada. For better or worse, C++ has no such
>>inefficiency. (I'm just stating a fact, I am *not* claiming that C++
>>did it right.)
> 
> 
> And Ada will not have this "inefficiency" if _you_ select to remove the
> checks. The difference is that you do it _explicitly_ in Ada.
> 
> To have equivilent code in C++ if would have to hand-write the
> check and then throw the exception.
> 

You may or may not be able to turn this off.  The problem is that the
Ada LRM says that on any assignment if an exception is raised when
evaluating the RHS then the LHS shall be left unchanged.  So unless the
compiler can determine that no such exception is possible it has to use
a temporary.  This of course is yet another instance of solving the
halting problem in the general case.

Now. as Ada doesn't currently have ops like += they could be add to the
language in such a way to not abide by the above rule.  But, that would 
break the semantic equavalence between "A := A + B;" and "A += B;".
It also gets all messed up with issues involving user defined ops and
controlled types.

-- 
mark@biggar.org
mark.a.biggar@comcast.net

Re: Is the Writing on the Wall for Ada?

[Martin Dowie]

"Mark A. Biggar" <mark@biggar.org> wrote in message
news:Iycab.95737$mp.45347@rwcrnsc51.ops.asp.att.net...
> You may or may not be able to turn this off.  The problem is that the
> Ada LRM says that on any assignment if an exception is raised when
> evaluating the RHS then the LHS shall be left unchanged.  So unless the
> compiler can determine that no such exception is possible it has to use
> a temporary.  This of course is yet another instance of solving the
> halting problem in the general case.

Sure, but for the "+ 1" it is simply a case of comparing the appropriate
'Last value for A - no need for a temporary here.


> Now. as Ada doesn't currently have ops like += they could be add to the
> language in such a way to not abide by the above rule.  But, that would
> break the semantic equavalence between "A := A + B;" and "A += B;".
> It also gets all messed up with issues involving user defined ops and
> controlled types.

That I don't like - actually I don't much care for these sorts of ops
anyway.

Re: Is the Writing on the Wall for Ada?

[Wes Groleau]

"Mark A. Biggar" <mark@biggar.org> wrote in message
>>You may or may not be able to turn this off.  The problem is that the
>>Ada LRM says that on any assignment if an exception is raised when
>>evaluating the RHS then the LHS shall be left unchanged.  So unless the
>>compiler can determine that no such exception is possible it has to use
>>a temporary.  This of course is yet another instance of solving the
>>halting problem in the general case.

The LRM does not say anything about what
"short circuit assignment" does because
Ada doesn't have it, so as you say...

>>Now. as Ada doesn't currently have ops like += they could be add to the
>>language in such a way to not abide by the above rule.  But, that would
>>break the semantic equavalence between "A := A + B;" and "A += B;".

1. If no exception raised, semantically equivalent.
2. If exception raised, result undefined.

So Russ gets what he wants--no temporary.
But as you hinted, he's wrong about assignment
always requiring a temporary.  And, as others have
said, Ada already allows you to write a procedure
that meets rules 1 & 2 above.

Add (B, Into => A);

Yes, I know--twelve keystrokes too many!  :-)

-- 
Wes Groleau
Genealogical Lookups:  http://groleau.freeshell.org/ref/lookups.html

Re: Is the Writing on the Wall for Ada?

[Russ]

"Mark A. Biggar" <mark@biggar.org> wrote in message news:<Iycab.95737$mp.45347@rwcrnsc51.ops.asp.att.net>...
> Martin Dowie wrote:
> > "Russ" <18k11tm001@sneakemail.com> wrote in message
> > news:bebbba07.0309171110.192b565c@posting.google.com...
> > 
> >>In the previous thread, someone claimed that "+=" needs a temporary
> >>too for some sort of overflow checking (I don't recall the exact
> >>reason given). If that is true, then it is an example of an inherent
> >>inefficiency built in to Ada. For better or worse, C++ has no such
> >>inefficiency. (I'm just stating a fact, I am *not* claiming that C++
> >>did it right.)
> > 
> > 
> > And Ada will not have this "inefficiency" if _you_ select to remove the
> > checks. The difference is that you do it _explicitly_ in Ada.
> > 
> > To have equivilent code in C++ if would have to hand-write the
> > check and then throw the exception.
> > 
> 
> You may or may not be able to turn this off.  The problem is that the
> Ada LRM says that on any assignment if an exception is raised when
> evaluating the RHS then the LHS shall be left unchanged.  So unless the
> compiler can determine that no such exception is possible it has to use
> a temporary.  This of course is yet another instance of solving the
> halting problem in the general case.

I have been told by a prominent Ada expert on this forum that "+=" is
just "semantic sugar" for a procedure call, and I have no reason to
doubt it. My understanding is that a procedure in Ada involves no LHS.
If that is the case, then I conclude that "+=" involves no LHS either.
Why, then, would this even be an issue?

> Now. as Ada doesn't currently have ops like += they could be add to the
> language in such a way to not abide by the above rule.  But, that would 
> break the semantic equavalence between "A := A + B;" and "A += B;".
> It also gets all messed up with issues involving user defined ops and
> controlled types.

As I wrote above, I don't think the "above rule" even applies. I think
this is just another excuse to keep augmented assignment operators out
of Ada. Unfortunately, I think that will also help keep Ada out of
use.

Re: Is the Writing on the Wall for Ada?

[Robert A Duff]

"Mark A. Biggar" <mark@biggar.org> writes:

> You may or may not be able to turn this off.  The problem is that the
> Ada LRM says that on any assignment if an exception is raised when
> evaluating the RHS then the LHS shall be left unchanged.

No, the Ada RM does *not* say that (for predefined exceptions).
Read 11.6 carefully.  That was true in Ada 83, but not in Ada 95.

- Bob

Re: Is the Writing on the Wall for Ada?

[Jacob Sparre Andersen]

Russ wrote:
> Wes Groleau <groleau@freeshell.org> wrote in message news:<RbSdnT6kv7SrdPqiU-KYuQ@gbronline.com>...

>>(Russ insists that A += 1 never needs temporaries
>>and that A := A + 1 always does.)

Which as far as I know is not quite true.

> That's not *quite* what I insist. What I insist is that, for
> vector/matrix operations, "+" is a *function* that must create a
> temporary vector/matrix and return it, and it must be *copied* to the
> lhs.

I haven't got the LRM right here, but IIRC the compiler just has to
generate code that is _equivalent_ to that, i.e. code that gives the
same result.

And at least for simple cases like matrix operations, it is possible to
make the compiler check if a temporary variable is needed or not.  We
can thus (at least in theory) leave it to the compiler to check if the
temporary variable is needed or not _and_ to consider which of the
solutions - with or without the temporary variable - is actually faster
on the hardware in question.

 > On the other hand, "+=" is a *procedure* that does not
> necessarily need any temporaries because it can do its operations "in
> place". No temporaries, no extra copying.

Yes.  But would you really like to have to mess with writing code that
you just as well could leave it to the compiler to generate _if_ it
actually would make a efficiency difference for the program?

I prefer to leave as much work as possible to the compiler.

> Someone else also claimed that a good Ada compiler can make "+" as
> efficient as "+=", but I don't see how that could be possible,
> considering that I could define "+" and "+=" to do anything I want.

Remember that the compiler has access to the code for your "+" function
and can look at what it actually does.  This is simply a matter of
optimization.  And it is not really on an algorithmic level, so it
should be left to the compiler, unless you can prove that it is strictly
neccessary to improve the code beyond what you compiler manages.

> Nothing in the language requires me to define "+" to actually do
> matrix addition. I could define it to write poetry if I wish.

Yes.  But then the compiler will just notice that and optimize accordingly.

> And let's not forget that a properly defined "+" should be able to
> handle sequential addition, such as A = B + C + D + E. No matter how
> you slice it, each of those additions needs a temporary.

Assuming that we are discussing something nice like simple matrix
addition here, I don't see why.  If your hardware has an "add four
numbers" operation, you don't need any.  And in general should such an
operation be done on a per element basis, which would mean that one
would need one (if the operations are done sequetially) or two (if the
operations are done in parallel) registers in the CPU for storing
intermediate results.  But still: Leave this kind of optimization to the
compiler!

> On the other hand, you could write
> 
> A = B
> A += C
> A += D
> A += E
> 
> It's not as elegant, but no temporaries or extra copying are required
> (unless the language imposes them for extraneous reasons).

I can't see why the resulting code from this should be any faster.  I
would rather say that it makes it more _difficult_ for the compiler to
optimize the operation and for the maintenance programmer to understand it.

Jacob
-- 
"Any, sufficiently advanced, technology is indistinguishable from
  magic."

Re: Is the Writing on the Wall for Ada?

[Russ]

Jacob Sparre Andersen <sparre@crs4.it> wrote in message news:<3F7024F8.1000102@crs4.it>...
> Russ wrote:
> > Wes Groleau <groleau@freeshell.org> wrote in message news:<RbSdnT6kv7SrdPqiU-KYuQ@gbronline.com>...
>  
> >>(Russ insists that A += 1 never needs temporaries
> >>and that A := A + 1 always does.)
> 
> Which as far as I know is not quite true.
> 
> > That's not *quite* what I insist. What I insist is that, for
> > vector/matrix operations, "+" is a *function* that must create a
> > temporary vector/matrix and return it, and it must be *copied* to the
> > lhs.
> 
> I haven't got the LRM right here, but IIRC the compiler just has to
> generate code that is _equivalent_ to that, i.e. code that gives the
> same result.
> 
> And at least for simple cases like matrix operations, it is possible to
> make the compiler check if a temporary variable is needed or not.  We
> can thus (at least in theory) leave it to the compiler to check if the
> temporary variable is needed or not _and_ to consider which of the
> solutions - with or without the temporary variable - is actually faster
> on the hardware in question.
> 
>  > On the other hand, "+=" is a *procedure* that does not
> > necessarily need any temporaries because it can do its operations "in
> > place". No temporaries, no extra copying.
> 
> Yes.  But would you really like to have to mess with writing code that
> you just as well could leave it to the compiler to generate _if_ it
> actually would make a efficiency difference for the program?
> 
> I prefer to leave as much work as possible to the compiler.
> 
> > Someone else also claimed that a good Ada compiler can make "+" as
> > efficient as "+=", but I don't see how that could be possible,
> > considering that I could define "+" and "+=" to do anything I want.
> 
> Remember that the compiler has access to the code for your "+" function
> and can look at what it actually does.  This is simply a matter of
> optimization.  And it is not really on an algorithmic level, so it
> should be left to the compiler, unless you can prove that it is strictly
> neccessary to improve the code beyond what you compiler manages.
> 
> > Nothing in the language requires me to define "+" to actually do
> > matrix addition. I could define it to write poetry if I wish.
> 
> Yes.  But then the compiler will just notice that and optimize accordingly.
> 
> > And let's not forget that a properly defined "+" should be able to
> > handle sequential addition, such as A = B + C + D + E. No matter how
> > you slice it, each of those additions needs a temporary.
> 
> Assuming that we are discussing something nice like simple matrix
> addition here, I don't see why.  If your hardware has an "add four
> numbers" operation, you don't need any.  And in general should such an
> operation be done on a per element basis, which would mean that one
> would need one (if the operations are done sequetially) or two (if the
> operations are done in parallel) registers in the CPU for storing
> intermediate results.  But still: Leave this kind of optimization to the
> compiler!

If the compiler can really do all that, then fine. But how many really
can? Can gnat do that, for example? Or is this just one of those
"maybe someday in the distant future," "pie in the sky" things?

By the way, even if there is no difference in efficiency, I still
prefer

    count += 1
to
    count = count + 1

The latter grates on my minimalist sensibilities like fingernails on a
chalkboard, and I'll bet I'm not alone on this. As I said before, I'll
bet the vast majority of C, C++, Java, Perl, and Python programmers
use the first form. If this low-level deficiency is not corrected in
Ada0x, that will be a big mistake.

Re: Is the Writing on the Wall for Ada?

[Jacob Sparre Andersen]

Russ wrote:
> Jacob Sparre Andersen <sparre@crs4.it> wrote in message news:<3F7024F8.1000102@crs4.it>...
>>Russ wrote:
>>>Wes Groleau <groleau@freeshell.org> wrote in message news:<RbSdnT6kv7SrdPqiU-KYuQ@gbronline.com>...

[ please try to quote more moderately ]

>>And at least for simple cases like matrix operations, it is possible to
>>make the compiler check if a temporary variable is needed or not.  We
>>can thus (at least in theory) leave it to the compiler to check if the
>>temporary variable is needed or not _and_ to consider which of the
>>solutions - with or without the temporary variable - is actually faster
>>on the hardware in question.

> If the compiler can really do all that, then fine.

It can!

 > But how many really
> can? Can gnat do that, for example?

GNAT didn't do it last time I tested it.  I haven't written a patch yet 
that does it, and I haven't heard that anybody else has done it, so GNAT 
does probably not do it yet.

 > Or is this just one of those
> "maybe someday in the distant future," "pie in the sky" things?

It is - like everything else - a "some day when it is needed" things.  I 
don't really need it at the moment, but I might implement it anyway, 
just to get rid of all these tiring claims that we need a ":+" procedure 
because it makes our code faster.  Have you ever thought of all the 
problems it creates, if we make assignment into just another procedure?

> By the way, even if there is no difference in efficiency, I still
> prefer
> 
>     count += 1
> to
>     count = count + 1
> 
> The latter grates on my minimalist sensibilities like fingernails on a
> chalkboard,

Ada is _not_ designed for source code minimalism!  It is designed to 
make safe, trustworthy, and maintainable software.  If you prefer source 
code minimalism to maintainable software, then it is okay with me.  Just 
don't try to change Ada to suit that style.  That is not the idea with Ada.

> If this low-level deficiency is not corrected in
> Ada0x, that will be a big mistake.

It is _not_ a deficiency.  It is an intentional design.

Jacob
-- 
"Nobody writes jokes in base 13."
  Douglas Adams

Re: Is the Writing on the Wall for Ada?

[Russ]

Jacob Sparre Andersen <sparre@crs4.it> wrote in message news:<3F71A78A.5000701@crs4.it>...
> Russ wrote:
> > Jacob Sparre Andersen <sparre@crs4.it> wrote in message news:<3F7024F8.1000102@crs4.it>...
> >>Russ wrote:
> >>>Wes Groleau <groleau@freeshell.org> wrote in message news:<RbSdnT6kv7SrdPqiU-KYuQ@gbronline.com>...
> 
> [ please try to quote more moderately ]
> 
> >>And at least for simple cases like matrix operations, it is possible to
> >>make the compiler check if a temporary variable is needed or not.  We
> >>can thus (at least in theory) leave it to the compiler to check if the
> >>temporary variable is needed or not _and_ to consider which of the
> >>solutions - with or without the temporary variable - is actually faster
> >>on the hardware in question.
>  
> > If the compiler can really do all that, then fine.
> 
> It can!

Great!

>  > But how many really
> > can? Can gnat do that, for example?
> 
> GNAT didn't do it last time I tested it.  I haven't written a patch yet 
> that does it, and I haven't heard that anybody else has done it, so GNAT 
> does probably not do it yet.

What? You wrote above, "It can!", but now you're saying it can't after
all. Perhaps you meant to say, "It could, if someone would implement
it!" That's quite different than "It can!". I don't mean to be a
semantic quibbler, but it sure seems different to me.

>  > Or is this just one of those
> > "maybe someday in the distant future," "pie in the sky" things?
> 
> It is - like everything else - a "some day when it is needed" things.  I 
> don't really need it at the moment, but I might implement it anyway, 
> just to get rid of all these tiring claims that we need a ":+" procedure 
> because it makes our code faster.  Have you ever thought of all the 
> problems it creates, if we make assignment into just another procedure?

Oh, you're going to wait until it's "needed" to implement it? When I
decide I need it, where can I reach you, and how long will it take you
to implement it for me? By the way, I used matrix addition as an
example only, but the principle applies to other cases too. Quaternion
arithmetic, for example. Will your implementation cover that too? Many
other examples could be given as well, of course. If you think that
one example covers the entire matter, you have missed the point.

> > By the way, even if there is no difference in efficiency, I still
> > prefer
> > 
> >     count += 1
> > to
> >     count = count + 1
> > 
> > The latter grates on my minimalist sensibilities like fingernails on a
> > chalkboard,
> 
> Ada is _not_ designed for source code minimalism!  It is designed to 
> make safe, trustworthy, and maintainable software.  If you prefer source 
> code minimalism to maintainable software, then it is okay with me.  Just 
> don't try to change Ada to suit that style.  That is not the idea with Ada.

I agree that minimalism can be taken too far (e.g., Perl). However,
that hardly means that minimalism is inherently antithetical to
safety, readability, and maintainability, and I'm getting tired of the
repeated insinuations on this forum that it is. When properly applied,
minimalism is the very *essence* of readability and maintainability.

When the LHS is a long, convoluted expression, readability is most
certainly *not* enhanced by forcing the reader to verify that the
expression on the left matches the expression on the right. This is
just basic common sense. Let me ask you which of the following is more
readable:

lwienfowowoenfnowoqndfoowopqihjefhnowqoowldvno := 
     lwienfowowoenfnowoqndfoowopqihjefhmowqoowldvno + 1

or 

lwienfowowoenfnowoqndfoowopqihjefhnowqoowldvno += 1

If you said the latter, then pass go and collect $200. Otherwise, I
give up, because you are beyond hope of being convinced of anything
reasonable on this matter.

Yes, I realize that those variable names are ridiculous, but I'm just
trying to make a basic point. Some variable names and data structures
*are* complicated.

By the way, the question above was a trick question. See if you can
figure out why.

> > If this low-level deficiency is not corrected in
> > Ada0x, that will be a big mistake.
> 
> It is _not_ a deficiency.  It is an intentional design.

And a bad one at that.

> Jacob

Re: Is the Writing on the Wall for Ada?

[Preben Randhol]

On 2003-09-25, Russ <18k11tm001@sneakemail.com> wrote:
> just basic common sense. Let me ask you which of the following is more
> readable:
>
> lwienfowowoenfnowoqndfoowopqihjefhnowqoowldvno := 
>      lwienfowowoenfnowoqndfoowopqihjefhmowqoowldvno + 1
>
> or 
>
> lwienfowowoenfnowoqndfoowopqihjefhnowqoowldvno += 1

None of them are readable.

Preben

Re: Is the Writing on the Wall for Ada?

[Vinzent 'Gadget' Hoefler]

Russ wrote:

>just basic common sense. Let me ask you which of the following is more
>readable:
>
>lwienfowowoenfnowoqndfoowopqihjefhnowqoowldvno := 
>     lwienfowowoenfnowoqndfoowopqihjefhmowqoowldvno + 1
>
>or 
>
>lwienfowowoenfnowoqndfoowopqihjefhnowqoowldvno += 1

They are not equivalent.

Using basic common sense, I'd say, the first one assigns the sum of
lwienfowowoenfnowoqndfoowopqihjefhmowqoowldvno and 1 to
lwienfowowoenfnowoqndfoowopqihjefhnowqoowldvno, whilst the second one
just adds 1 to lwienfowowoenfnowoqndfoowopqihjefhnowqoowldvno itself.

One lesson learned: You really should take care of your variable's
names. :)


Vinzent.

Re: Is the Writing on the Wall for Ada? [although this thread changed to something else a long time ago]

[Jeff C,]

"Vinzent 'Gadget' Hoefler" <ada.rocks@jlfencey.com> wrote in message
news:bkubhj$5v7t7$1@ID-175126.news.uni-berlin.de...
Russ wrote:

>just basic common sense. Let me ask you which of the following is more
>readable:
>
>lwienfowowoenfnowoqndfoowopqihjefhnowqoowldvno :=
>     lwienfowowoenfnowoqndfoowopqihjefhmowqoowldvno + 1
>
>or
>
>lwienfowowoenfnowoqndfoowopqihjefhnowqoowldvno += 1

They are not equivalent.

Using basic common sense, I'd say, the first one assigns the sum of
lwienfowowoenfnowoqndfoowopqihjefhmowqoowldvno and 1 to
lwienfowowoenfnowoqndfoowopqihjefhnowqoowldvno, whilst the second one
just adds 1 to lwienfowowoenfnowoqndfoowopqihjefhnowqoowldvno itself.

One lesson learned: You really should take care of your variable's
names. :)


Yipes! I think you just made the point that the C++ syntax is less error
prone...Now this mis-named thread will  never die.

Re: Is the Writing on the Wall for Ada? [although this thread changed to something else a long time ago]

[Vinzent 'Gadget' Hoefler]

Jeff C, wrote:

>>One lesson learned: You really should take care of your variable's
>>names. :)
>
>Yipes! I think you just made the point that the C++ syntax is less error
>prone...

No. :)

I just made the point that the C++ supports encourages bad style. :-P


Vinzent.

Re: Is the Writing on the Wall for Ada? [although this thread changed to something else a long time ago]

[Vinzent 'Gadget' Hoefler]

Jeff C, wrote:

>>One lesson learned: You really should take care of your variable's
>>names. :)
>
>Yipes! I think you just made the point that the C++ syntax is less error
>prone...

No. :)

I just made the point that the C++ syntax encourages bad style. :-P


Vinzent.

Re: Is the Writing on the Wall for Ada? [although this thread changed to something else a long time ago]

[Preben Randhol]

On 2003-09-25, Jeff C, <nolongersafeto@userealemailsniff.com> wrote:
> Yipes! I think you just made the point that the C++ syntax is less error
> prone...Now this mis-named thread will  never die.

No he didn't. The Ada way is less error prone and that is what is
resticting Ada from having the second form. See earlier discussion about
exceptions etc... on this += discussion.

Preben

Re: Is the Writing on the Wall for Ada? [although this thread changed to something else a long time ago]

[Russ]

"Jeff C," <nolongersafeto@userealemailsniff.com> wrote in message news:<BkAcb.579943$uu5.94364@sccrnsc04>...
> "Vinzent 'Gadget' Hoefler" <ada.rocks@jlfencey.com> wrote in message
> news:bkubhj$5v7t7$1@ID-175126.news.uni-berlin.de...
> Russ wrote:
> 
> >just basic common sense. Let me ask you which of the following is more
> >readable:
> >
> >lwienfowowoenfnowoqndfoowopqihjefhnowqoowldvno :=
> >     lwienfowowoenfnowoqndfoowopqihjefhmowqoowldvno + 1
> >
> >or
> >
> >lwienfowowoenfnowoqndfoowopqihjefhnowqoowldvno += 1
> 
> They are not equivalent.

You are very observant. But how long did it take you to determine that
the two statements are not equivalent? My point is that the second
form, using augmented assignment, makes it instantly clear that one
variable is being incremented. That means better readability.

> One lesson learned: You really should take care of your variable's
> names. :)

As I said before, those variable names are obviously ridiculous, but
if I had more time I could come with a reasonable example of a
complicated data structure illustrating the exact same point.

> 
> Yipes! I think you just made the point that the C++ syntax is less error
> prone...Now this mis-named thread will  never die.

Yes, I think I *have* made the point that this particular aspect of
C++ syntax is less error prone and more readable than Ada. And no, I
am not claiming that C++ is less error prone than Ada overall. Of
course not.

Suppose I compare two football teams. One is 6-0, and it dominates the
other, which is 0-6, at almost every position. Now let's say the 0-6
team happens to have a great right tackle, and the 6-0 team has a weak
right tackle. Do you suppose the coach of the 6-0 team will say, "Hey,
we don't need to worry about our weak right tackle because we dominate
at every other position." Not if he wants to win the Super Bowl.

The same principle applies here. If Ada enthusiasts are too blind to
see the obvious deficiency of the lack of augmented assignment
operators, then what hope is there for Ada when it has so much else
going against it?

Re: Is the Writing on the Wall for Ada? [although this thread changed to something else a long time ago]

[Preben Randhol]

On 2003-09-25, Russ <18k11tm001@sneakemail.com> wrote:
> You are very observant. But how long did it take you to determine that
> the two statements are not equivalent? My point is that the second
                                         ^^^^^^^^^^^
                                         Exactly
                                         
> form, using augmented assignment, makes it instantly clear that one
> variable is being incremented. That means better readability.

I don't agree. :-)

Preben

Re: Is the Writing on the Wall for Ada? [although this thread changed to something else a long time ago]

[Vinzent 'Gadget' Hoefler]

Russ wrote:

>"Jeff C," <nolongersafeto@userealemailsniff.com> wrote in message news:<BkAcb.579943$uu5.94364@sccrnsc04>...
>> "Vinzent 'Gadget' Hoefler" <ada.rocks@jlfencey.com> wrote in message
>> news:bkubhj$5v7t7$1@ID-175126.news.uni-berlin.de...
>> Russ wrote:
>> 
>> >just basic common sense. Let me ask you which of the following is more
>> >readable:
>> >
>> >lwienfowowoenfnowoqndfoowopqihjefhnowqoowldvno :=
>> >     lwienfowowoenfnowoqndfoowopqihjefhmowqoowldvno + 1
>> >
>> >or
>> >
>> >lwienfowowoenfnowoqndfoowopqihjefhnowqoowldvno += 1
>> 
>> They are not equivalent.
>
>You are very observant.

Well. I have to admit, I was - of course - expecting something like
this.

>But how long did it take you to determine that
>the two statements are not equivalent?

How long it took to compare the characters, three seconds, five
seconds.

Obviously, such a thing is not done at a first glance like you usually
do when you look over some code to find relevant places when you are
scanning it for errors.

>My point is that the second
>form, using augmented assignment, makes it instantly clear that one
>variable is being incremented.

It does make it clear if and only if you know what this weird operator
+= means (I know, this is not a strong argument).

Well, perhaps it even does not, speaking for myself, I still find this
one one of the most cryptic parts in C-like languages (together with
the funny and unspeakable names of all the C-library functions and the
hyper-cryptic boolean/logical operators, the latter being my
"favourites", I still don't get them and probably I'll never will).

>That means better readability.

I don't like it, but in this particular case I probably should agree.
But...

>> One lesson learned: You really should take care of your variable's
>> names. :)
>
>As I said before, those variable names are obviously ridiculous, but
>if I had more time I could come with a reasonable example of a
>complicated data structure illustrating the exact same point.

Yes, I know, we did that before. And I will come against it with a
simple renaming declaration that makes everything so much easier. ;)

>> Yipes! I think you just made the point that the C++ syntax is less error
>> prone...Now this mis-named thread will  never die.
>
>Yes, I think I *have* made the point that this particular aspect of
>C++ syntax is less error prone and more readable than Ada.

The problem I have with this syntax is that it at first it is not
clear what it means, it breaks at least my normal reading flow. And
like you mixed up variable names that might be not detectable at the
first glance, you also could mix it up with a normal assignment
operation. Yes, I consider "+=" and ":=" as looking not very
different.

So the result is still not better in terms of safety and readable
code, we would just exchange the possibility of mixing up something
with the possibility to mix up something else. What would we gain from
that? The acceptance of some idiotic kids who like to code one buffer
overflow after another? ;->

The second thing: If we introduce such a syntax in Ada, this means it
*will* be used even in simple cases like

|Count := Count + 1;

that converts to

|Count += 1;

(because programmers *are* lazy) and IMO this *would* definitely have
a large impact on general readability. I'd say, the general effect on
readability would be worse than that what we would get back from
adding something like the "+="-operator syntax to the language.

>The same principle applies here. If Ada enthusiasts are too blind to
>see the obvious deficiency of the lack of augmented assignment
>operators, then what hope is there for Ada when it has so much else
>going against it?

Well, I still consider

|Add (lwienfowowoenfnowoqndfoowopqihjefhnowqoowldvno, 1);

(with a "pragma Inline (Add);" if you want so)

a good alternative. Call it a compromise. Well, I know the
C++-community wouldn't accept it, because "+=" is so much "nicer", but
I don't care about them. They don't care about me, so we're even. :)


Vinzent.

Re: Is the Writing on the Wall for Ada? [although this thread changed to something else a long time ago]

[Russ]

Vinzent 'Gadget' Hoefler <ada.rocks@jlfencey.com> wrote in message news:<bkvhb0$6ih3f$1@ID-175126.news.uni-berlin.de>...

> The second thing: If we introduce such a syntax in Ada, this means it
> *will* be used even in simple cases like
> 
> |Count := Count + 1;
> 
> that converts to
> 
> |Count += 1;
> 
> (because programmers *are* lazy) and IMO this *would* definitely have
> a large impact on general readability. I'd say, the general effect on
> readability would be worse than that what we would get back from
> adding something like the "+="-operator syntax to the language.

I happen to think they *should* use the shorter form even for simple
cases. When Python added augmented assignment operators (2.1?), I went
through my Python scripts and changed the incrementation operations to
"+=". My Python scripts are very clean and readable, by the way.

Let me pose a question. Suppose you were picking apples and putting
them into a bushel basket. Each time you pick an apple, would you dump
the contents of the basket on the ground, add the new apple, then
reload them all into the basket? Or would you just add the new apple
to the basket?

In other words, would you do

    basket := basket + 1;
or
    basket += 1; -- or basket :+ 1

Re: Is the Writing on the Wall for Ada? [although this thread changed to something else a long time ago]

[Ludovic Brenta]

18k11tm001@sneakemail.com (Russ) writes:
> In other words, would you do
> 
>     basket := basket + 1;
> or
>     basket += 1; -- or basket :+ 1

I would:

Increment (Basket, By => 1);

-- 
Ludovic Brenta.

Re: Is the Writing on the Wall for Ada? [although this thread changed to something else a long time ago]

[Vinzent 'Gadget' Hoefler]

Russ wrote:

>Vinzent 'Gadget' Hoefler <ada.rocks@jlfencey.com> wrote in message news:<bkvhb0$6ih3f$1@ID-175126.news.uni-berlin.de>...
>
>Let me pose a question. Suppose you were picking apples and putting
>them into a bushel basket. Each time you pick an apple, would you dump
>the contents of the basket on the ground, add the new apple, then
>reload them all into the basket? Or would you just add the new apple
>to the basket?

The latter. But I wouldn't expect to let the basket operate on the
single apple like

|Basket += 1;

would apply, I would do something like:

|Put (Into => Basket, What => Apple, Amount => 1);

;-P

As I said, I consider the procedural version a good compromise.


Vinzent.

Re: Is the Writing on the Wall for Ada? [although this thread changed to something else a long time ago]

[Pascal Obry]

18k11tm001@sneakemail.com (Russ) writes:

> "Jeff C," <nolongersafeto@userealemailsniff.com> wrote in message news:<BkAcb.579943$uu5.94364@sccrnsc04>...
> > "Vinzent 'Gadget' Hoefler" <ada.rocks@jlfencey.com> wrote in message
> > news:bkubhj$5v7t7$1@ID-175126.news.uni-berlin.de...
> > Russ wrote:
> > 
> > >just basic common sense. Let me ask you which of the following is more
> > >readable:
> > >
> > >lwienfowowoenfnowoqndfoowopqihjefhnowqoowldvno :=
> > >     lwienfowowoenfnowoqndfoowopqihjefhmowqoowldvno + 1
> > >
> > >or
> > >
> > >lwienfowowoenfnowoqndfoowopqihjefhnowqoowldvno += 1
> > 
> > They are not equivalent.

What about 

   lwienfowowoenfnowoqnd += 1

and

   lwienfowowoenfnowoqnd := 1

How many chances there is to misread one for another in a real-world
application ?

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Is the Writing on the Wall for Ada? [although this thread changed to something else a long time ago]

[Randy Brukardt]

"Pascal Obry" <p.obry@wanadoo.fr> wrote in message
news:uwubvie8a.fsf@wanadoo.fr...
> What about
>
>    lwienfowowoenfnowoqnd += 1
>
> and
>
>    lwienfowowoenfnowoqnd := 1
>
> How many chances there is to misread one for another in a real-world
> application ?

Exactly. An important part of Ada is that its syntax was designed (as much
as possible) to make one character errors generate something illegal. For
most constructs, it takes several characters of change to create something
else legal. This is definitely not true of C-family syntax. And this is the
root of Ada's philosphy, that small changes do not change the meaning of a
program, they simply make it illegal.

(Yes, Ada does allow arithmetic operators, for the obvious reason that it
would have too weird to say "Add" instead of "+". And it certainly is clear
that you can't get rid of all one character errors, at least as long as you
allow numbers. But that doesn't eliminate the basic point.)

                    Randy.

Re: Is the Writing on the Wall for Ada? [although this thread changed to something else a long time ago]

[Russ]

"Randy Brukardt" <randy@rrsoftware.com> wrote in message news:<vn96gc8urk7s58@corp.supernews.com>...
> "Pascal Obry" <p.obry@wanadoo.fr> wrote in message
> news:uwubvie8a.fsf@wanadoo.fr...
> > What about
> >
> >    lwienfowowoenfnowoqnd += 1
> >
> > and
> >
> >    lwienfowowoenfnowoqnd := 1

or     lwienfowowoenfnowoqnd :+ 1  -- my suggested syntax

> > How many chances there is to misread one for another in a real-world
> > application ?
> 
> Exactly. An important part of Ada is that its syntax was designed (as much
> as possible) to make one character errors generate something illegal. For
> most constructs, it takes several characters of change to create something
> else legal. This is definitely not true of C-family syntax. And this is the
> root of Ada's philosphy, that small changes do not change the meaning of a
> program, they simply make it illegal.
> 
> (Yes, Ada does allow arithmetic operators, for the obvious reason that it
> would have too weird to say "Add" instead of "+". And it certainly is clear
> that you can't get rid of all one character errors, at least as long as you
> allow numbers. But that doesn't eliminate the basic point.)

Hmmm... that's funny. I see that Ada has :=, /=, >=, and <=, all of
which differ by one character. With sloppiness like that, Ada must be
driving airplanes into buildings on a regular basis. Then again,
there's <=, <<, and <>, not to mention =>.

An apparently you disagree with the original design of Ada, which as
you concede allows +, -, *, and /. I guess you think it should have
used a:=Plus(a,b).

I point out, furthermore, that a "one-character" difference is *much*
easier to detect in an operator than it is in a complex variable
name/reference, which was the point of my message that was quoted in
part above.

I've seen some weak arguments here, and this one is typical. What is
increasingly apparent to me is that Ada veterans are set in their
ways, and no amount of reason will budge them on the basic syntax of
Ada, even when if is deficient compared to the existing languages that
98% of programmers use.

I'm sorry if I'm not showing you enough respect. I am not questioning
your intelligence or even your judgment on more complex matters that I
would have no clue about, but only on this low-level matter. Everyone
has a blind spot somewhere, and I think you have one here.

Just so you know a bit about me, I am an aerospace research engineer,
and I work at a major government research lab with the leading experts
in the world on the future of air traffic management. I try to
maintain some level of anonymity on this forum because I am in a
position of some influence, though certainly not great power. I think
Ada will be indispensible for the increasing level of automation that
will be needed in the future. However, I am the *only* one here who
thinks that, and I am considered something of a pariah on the subject.
Apparently even the FAA is abandoning Ada. I don't want to exaggerate
my influence, but I can tell you that I may be literally one of the
last hopes for Ada in air traffic control in the US. Scary, eh?

Re: Is the Writing on the Wall for Ada? [although this thread changed to something else a long time ago]

[Randy Brukardt]

"Russ" <18k11tm001@sneakemail.com> wrote in message
news:bebbba07.0309271109.47069497@posting.google.com...
> > Exactly. An important part of Ada is that its syntax was designed (as
much
> > as possible) to make one character errors generate something illegal.
For
> > most constructs, it takes several characters of change to create
something
> > else legal. This is definitely not true of C-family syntax. And this is
the
> > root of Ada's philosphy, that small changes do not change the meaning of
a
> > program, they simply make it illegal.
> >
> > (Yes, Ada does allow arithmetic operators, for the obvious reason that
it
> > would have too weird to say "Add" instead of "+". And it certainly is
clear
> > that you can't get rid of all one character errors, at least as long as
you
> > allow numbers. But that doesn't eliminate the basic point.)
>
> Hmmm... that's funny. I see that Ada has :=, /=, >=, and <=, all of
> which differ by one character. With sloppiness like that, Ada must be
> driving airplanes into buildings on a regular basis. Then again,
> there's <=, <<, and <>, not to mention =>.
>
> An apparently you disagree with the original design of Ada, which as
> you concede allows +, -, *, and /. I guess you think it should have
> used a:=Plus(a,b).

No, not at all. Using the conventional operators was the right choice,
otherwise no one would have considered it at all. And note that all of the
things you mention above are conventional operators.

> I point out, furthermore, that a "one-character" difference is *much*
> easier to detect in an operator than it is in a complex variable
> name/reference, which was the point of my message that was quoted in
> part above.

I totally argee, but you have to be an idiot to declare variables that are
one character apart. And without that, the program has an error and probably
is relatively easy to find.

In any case, I'm sympathic to the issue, but (a) I don't like this syntax,
and there are other solutions, and (b) there are a hundred issues more
important. I note that you didn't answer my note asking what you'd give up
for this rather substantial change.

> I've seen some weak arguments here, and this one is typical. What is
> increasingly apparent to me is that Ada veterans are set in their
> ways, and no amount of reason will budge them on the basic syntax of
> Ada, even when if is deficient compared to the existing languages that
> 98% of programmers use.

99.7% of Americans voted for an idiot in the last election (myself
included). What does that prove? Most of them aren't even aware that better
choices are available, and in many cases, they have no choice in the matter
anyway (as in the election).

Ada has real technical issues that need fixing, and that is where we need to
put our limited energy. Copying everyone's pet ideas from other languages
isn't it. (Indeed, MY pet ideas have long since been killed for this very
reason.)

                    Randy.

Re: Is the Writing on the Wall for Ada? [although this thread changed to something else a long time ago]

[Frank J. Lhota]

"Randy Brukardt" <randy@rrsoftware.com> wrote in message
news:vnc4gs4llm53a3@corp.supernews.com...
> I totally argee, but you have to be an idiot to declare variables that are
> one character apart. And without that, the program has an error and
probably
> is relatively easy to find.

But even if you make your identifiers quite distinct, the expressions
"Foo(1)" and "Foo(2)" differ by only one character.

Re: Is the Writing on the Wall for Ada? [although this thread changed to something else a long time ago]

[Preben Randhol]

On 2003-09-27, Randy Brukardt <randy@rrsoftware.com> wrote:
> 99.7% of Americans voted for an idiot in the last election (myself
> included). What does that prove? Most of them aren't even aware that better
> choices are available, and in many cases, they have no choice in the matter
> anyway (as in the election).

99.7% ? I thought the attendance was only 40-50% or less in the election?

> Ada has real technical issues that need fixing, and that is where we need to
> put our limited energy. Copying everyone's pet ideas from other languages
> isn't it. (Indeed, MY pet ideas have long since been killed for this very
> reason.)

Exactly.

Preben

Re: Is the Writing on the Wall for Ada? [although this thread changed to something else a long time ago]

[Randy Brukardt]

"Preben Randhol" <randhol+abuse@pvv.org> wrote in message
news:slrnbndfj8.n2.randhol+abuse@kiuk0152.chembio.ntnu.no...
> On 2003-09-27, Randy Brukardt <randy@rrsoftware.com> wrote:
> > 99.7% of Americans voted for an idiot in the last election (myself
> > included). What does that prove? Most of them aren't even aware that
better
> > choices are available, and in many cases, they have no choice in the
matter
> > anyway (as in the election).
>
> 99.7% ? I thought the attendance was only 40-50% or less in the election?

I meant of the people that voted. Who can tell what people that didn't vote
would have done ot thought.

                        Randy.

Re: Is the Writing on the Wall for Ada? [although this thread changed to something else a long time ago]

[Pascal Obry]

18k11tm001@sneakemail.com (Russ) writes:

> Hmmm... that's funny. I see that Ada has :=, /=, >=, and <=, all of

You missed the important point.

Try changing := by /= in a valid program and try to compile it.
Idem for := and >=, idem for := and <=.

As Randy said all those cases can't be avoided but Ada tried hard to have less
of those them. Of course it is possible to change < with > and <= with >=...

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Is the Writing on the Wall for Ada? [although this thread changed to something else a long time ago]

[Larry Kilgallen]

In article <vnc4gs4llm53a3@corp.supernews.com>, "Randy Brukardt" <randy@rrsoftware.com> writes:

> 99.7% of Americans voted for an idiot in the last election (myself
> included).

Actually, considerably fewer that 99.7 percent of US citizens voted at
all in the last election, even if by "last election" you restrict what
you mean to presidential elections.

Re: Is the Writing on the Wall for Ada?

[Wes Groleau]

Vinzent 'Gadget' Hoefler wrote:
> They are not equivalent.

The results are equivalent if an error does not occur.
Russ's case is based on the false claim that the
implementation MUST always be different.

-- 
Wes Groleau
   ----
   The man who reads nothing at all is better educated
   than the man who reads nothing but newspapers.
                             -- Thomas Jefferson

Re: Is the Writing on the Wall for Ada?

[Vinzent 'Gadget' Hoefler]

Wes Groleau wrote:

>Vinzent 'Gadget' Hoefler wrote:
>> They are not equivalent.
>
>The results are equivalent if an error does not occur.

No, ARM 2.3(5) explicitely states:

|All characters of an identifier are significant, including any
|underline character. Identifiers differing only in the use of
|corresponding upper and lower case letters are considered the same.

I consider

|lwienfowowoenfnowoqndfoowopqihjefhmowqoowldvno
|lwienfowowoenfnowoqndfoowopqihjefhnowqoowldvno

as different at the 35th place.


Vinzent.

Re: Is the Writing on the Wall for Ada?

[Stephen Leake]

Wes Groleau <groleau@freeshell.org> writes:

> Vinzent 'Gadget' Hoefler wrote:
> > They are not equivalent.
> 
> The results are equivalent if an error does not occur.
> Russ's case is based on the false claim that the
> implementation MUST always be different.

You (and others) missed the fact that the two names are _not_
identical (one has an 'm' where the other has an 'n'). Which (I
suspect) was the point; repeated long names are hard to verify.

Of course, this example would be thrown out at any real code review,
and a compiler would catch a simple misspelling. But the point
remains:

foo.bar.blah (2).barf (anything) += 1; 

is easier to get right, and easier to review, than

foo.bar.blah (2).barf (anything) := 
    foo.bar.blah (2).barf (anything) + 1; 

This would also be thrown out at any real code review; the recommended
approach in Ada is to use a local renames declaration to simplify the
repeated name, or to declare an Inc operator.

But I think we should simply acknowledge the fact that C and C++ have
a slight edge here, that we are willing to live with because of the
other consequences of trying to define and implement "+=" in Ada.

-- 
-- Stephe

Re: Is the Writing on the Wall for Ada?

[Russ]

Stephen Leake <Stephe.Leake@nasa.gov> wrote in message news:<uu170lt9a.fsf@nasa.gov>...
> Wes Groleau <groleau@freeshell.org> writes:
> 
> > Vinzent 'Gadget' Hoefler wrote:
> > > They are not equivalent.
> > 
> > The results are equivalent if an error does not occur.
> > Russ's case is based on the false claim that the
> > implementation MUST always be different.
> 
> You (and others) missed the fact that the two names are _not_
> identical (one has an 'm' where the other has an 'n'). Which (I
> suspect) was the point; repeated long names are hard to verify.

Yes, that was the point.

> Of course, this example would be thrown out at any real code review,
> and a compiler would catch a simple misspelling. But the point
> remains:
> 
> foo.bar.blah (2).barf (anything) += 1; 
> 
> is easier to get right, and easier to review, than
> 
> foo.bar.blah (2).barf (anything) := 
>     foo.bar.blah (2).barf (anything) + 1; 

That's right, and other even better examples could be found, I'm sure.
In fact, someone gave one on an earlier thread. It was a long nested
data structure in which one of the indices was m in one case and n in
the other, or something like that.

> This would also be thrown out at any real code review; the recommended
> approach in Ada is to use a local renames declaration to simplify the
> repeated name, or to declare an Inc operator.

That's true too, but I think simply using "+=" (or ":+", or "+:=") is
considerably simpler and cleaner than a local renaming declaration.
It's literally one line vs. four or five.

> But I think we should simply acknowledge the fact that C and C++ have
> a slight edge here, that we are willing to live with because of the
> other consequences of trying to define and implement "+=" in Ada.

Thank you for that acknowledgment. Yes, I mean it sincerely.

As you might have anticipated, however, I don't agree with you about
the "other consequences of trying to define and implement "+=" in
Ada". As far as I am concerned, the "other consequences" are
potentially improved efficiency for vector/matrix arithmetic and other
applications, but as you know I've already beaten that one to death. I
think it will take a friggin' nuclear device to get anyone here to
budge on that one.

Re: Is the Writing on the Wall for Ada?

[Randy Brukardt]

"Russ" <18k11tm001@sneakemail.com> wrote in message
news:bebbba07.0309251541.63ef4f7d@posting.google.com...
> As you might have anticipated, however, I don't agree with you about
> the "other consequences of trying to define and implement "+=" in
> Ada". As far as I am concerned, the "other consequences" are
> potentially improved efficiency for vector/matrix arithmetic and other
> applications, but as you know I've already beaten that one to death. I
> think it will take a friggin' nuclear device to get anyone here to
> budge on that one.

More than a nuclear device, for the simple reason that there are a limited
number of changes to the standard that can be made. The effort to write and
edit the standard, the effort to update implementations and tools, the
effort to create new books and training are all limited. (This isn't the
early 80's when Ada had a virtually unlimited budget.)

So possible features have to be compared to other possible features, and
only the most important ones chosen. (An obvious example: several people
here have said that interface inheritance will be in the next Ada. That's
far from a done deal, because it takes up such a large part of the 'budget'.
I personally would trade it for the inclusion of a number of other important
improvements. The ARG has not yet determined what will be in or out.)

So the question is not whether or not an idea is a good one, or workable, or
whatever, but does it bring enough additional to the table to merit
including it over others. I would hope that you realize that purely
syntactic changes (like this one) don't buy as much for their effort as real
new features (like limited with or interface inheritance).

There are some changes contemplated (particularly the prefix call notation)
which are very much in the category of "making Ada seem more familar to
outsiders". And many others aimed at making Ada more consistent. But clearly
there can only be a very limited number of such things. Can you honestly say
that :=+ is more important than prefix calls or "not null" modifiers or
anonymous access-to-constant types?

                                 Randy.

Re: Is the Writing on the Wall for Ada?

[Russ]

"Randy Brukardt" <randy@rrsoftware.com> wrote in message news:<vn95m5dj01aa29@corp.supernews.com>...
> "Russ" <18k11tm001@sneakemail.com> wrote in message
> news:bebbba07.0309251541.63ef4f7d@posting.google.com...
> > As you might have anticipated, however, I don't agree with you about
> > the "other consequences of trying to define and implement "+=" in
> > Ada". As far as I am concerned, the "other consequences" are
> > potentially improved efficiency for vector/matrix arithmetic and other
> > applications, but as you know I've already beaten that one to death. I
> > think it will take a friggin' nuclear device to get anyone here to
> > budge on that one.
> 
> More than a nuclear device, for the simple reason that there are a limited
> number of changes to the standard that can be made. The effort to write and
> edit the standard, the effort to update implementations and tools, the
> effort to create new books and training are all limited. (This isn't the
> early 80's when Ada had a virtually unlimited budget.)

<cut>

> There are some changes contemplated (particularly the prefix call notation)
> which are very much in the category of "making Ada seem more familar to
> outsiders". And many others aimed at making Ada more consistent. But clearly
> there can only be a very limited number of such things. Can you honestly say
> that :=+ is more important than prefix calls or "not null" modifiers or
> anonymous access-to-constant types?

Fair enough, but let me just try one more angle on this.

I think proposed new features should be evaluated in terms of
cost/benefit. The augmented assignment operators may not provide a
huge benefit, but their "cost" is virtually zero. Another Ada expert
on this forum called them "syntactic sugar" for procedure calls. That
being the case, they should be almost trivial to implement. For Pete's
sake, they are simply standard notation for very common standard
procedures! Explaining them to new Ada programmers should be trivial
too. I suspect most of them will be surprised to find out that Ada was
so primitive at one time as to not have such operators.

Also, if I may, I would suggest that this is not the time to be overly
conservative about new features in Ada. Risky ones yes, perhaps, but
not "syntactic sugar." Perhaps Ada *needs* some "syntactic sugar"
about now. Check back to the very first post in this thread, and you
will see that it's getting late in the game for Ada. How late? I'd say
we trail by 13 points with about 4 minutes to go in the fourth
quarter, and we have the ball on the opposing team's 40 yard line with
fourth down and 3 yards to go. If ever there was a time to take a
chance, it's now. If you play it safe and punt now, you are conceding
the game.

Re: Is the Writing on the Wall for Ada?

[Marin David Condic]

I would seriously question the assumption that adding short-circuit 
operators such as += are going to attract much attention and get the C++ 
programmers to abandon their language of choice and come over to Ada. It 
would be *far* more productive to spend effort on Ada 
compilers/environments in ways that add leverage to development efforts. 
I'd even be in favor of leaving all the syntax & semantics of Ada alone 
in exchange for providing things like a big library or standard GUI or 
anything else that made Ada attractive with respect to producing better 
software faster than can be done in some other language. That's the sort 
of thing that can create *real* benefits for most development efforts 
and attract new business away from other languages.

MDC


Russ wrote:
> 
> Also, if I may, I would suggest that this is not the time to be overly
> conservative about new features in Ada. Risky ones yes, perhaps, but
> not "syntactic sugar." Perhaps Ada *needs* some "syntactic sugar"
> about now. Check back to the very first post in this thread, and you
> will see that it's getting late in the game for Ada. How late? I'd say
> we trail by 13 points with about 4 minutes to go in the fourth
> quarter, and we have the ball on the opposing team's 40 yard line with
> fourth down and 3 yards to go. If ever there was a time to take a
> chance, it's now. If you play it safe and punt now, you are conceding
> the game.


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

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

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Is the Writing on the Wall for Ada?

[Russ]

Marin David Condic <nobody@noplace.com> wrote in message news:<3F76F0E4.2090901@noplace.com>...
> I would seriously question the assumption that adding short-circuit 
> operators such as += are going to attract much attention and get the C++ 
> programmers to abandon their language of choice and come over to Ada. It 
> would be *far* more productive to spend effort on Ada 
> compilers/environments in ways that add leverage to development efforts. 
> I'd even be in favor of leaving all the syntax & semantics of Ada alone 
> in exchange for providing things like a big library or standard GUI or 
> anything else that made Ada attractive with respect to producing better 
> software faster than can be done in some other language. That's the sort 
> of thing that can create *real* benefits for most development efforts 
> and attract new business away from other languages.

You have yet to explain why the two are mutually exclusive.

Plus I still think you are missing the point about operators that are
available in C, C++, Java. Perl, and Python. The point is not that
putting augmented assignment operators into Ada is going to draw a
huge new following. Of course not. The point is that *not* having them
may be a *significant* factor in keeping new programmers away. I'll
bet ":=" is a factor too, but let's not get into that now (the fact
that no other popular language uses it might be a clue).

Re: Is the Writing on the Wall for Ada?

[Randy Brukardt]

"Russ" <18k11tm001@sneakemail.com> wrote in message
news:bebbba07.0309280048.327a29a3@posting.google.com...
> I think proposed new features should be evaluated in terms of
> cost/benefit. The augmented assignment operators may not provide a
> huge benefit, but their "cost" is virtually zero. Another Ada expert
> on this forum called them "syntactic sugar" for procedure calls. That
> being the case, they should be almost trivial to implement. For Pete's
> sake, they are simply standard notation for very common standard
> procedures! Explaining them to new Ada programmers should be trivial
> too. I suspect most of them will be surprised to find out that Ada was
> so primitive at one time as to not have such operators.

I think you misunderstand what the cost of a change would be. Other than the
most trivial changes (fixing spelling errors in the RM, changing the title
of Annex H), there is a substantial cost to any change. This one falls in
the middle somewhere.

First of all, it would require substantial RM wording changes. Currently,
operator symbols only are allowed as functions with one or two parameters.
You're suggesting allowing procedures as well. Similarly, defining the
meaning of these operators will also take substantial wording. I compared it
to prefix calls, because the RM changes will be roughly the same.

Similarly, the cost to implementors is also well above zero. Adding new
symbols means changing the lexer (if any part of an Ada compiler is
dust-covered, its that - I don't think anyone has looked at ours since
1993). There is also the resolution code, which will have to handle infix
procedure calls. That could be anything from no work to quite a bit of work.

Finally, some people consider any syntax changes to be expensive, because
they affect tools as well as the compiler. Things like ASIS, compilation
order tools, and the like, need updates when syntax changes. (I personally
don't find this to be a giant deal, but remember that standardization is as
much a polictical process as a technical one.)

So, I'd categorize the cost as "medium-low". Certainly, there are a lot of
proposals with higher costs, but there are plenty with lower costs (such as
the 'Reduce and 'Machine_Rounding attributes). Now, redo your cost-benefit
analysis with a more accurate assessment of the cost.

             Randy.

Re: Is the Writing on the Wall for Ada?

[Robert I. Eachus]

Wes Groleau wrote:

> The story was interesting, but whether due to my IQ
> or the fact it's an hour past my bedtime, I must confess
> I do not know whether you were illustrating my point
> or agreeing with Russ.

Neither, I guess.  The reality is that whether or not a temporary is 
needed may be an artifact of the hardware, and how the type is 
represented.  All that Ada "requires" is that if you do an increment in 
memory, other tasks can never see a value out of range.  This usually 
only applies of course to data visible to more than one task, but my 
example was a "clever" sequence which could trip up vector processing 
hardware--and often occured in practice with vectors of complex values.

> (Russ insists that A += 1 never needs temporaries
> and that A := A + 1 always does.)

In pratice on modern hardware this statement is so far from the truth 
that it isn't even wrong.  For example, at the point where the increment 
is done, the value of A may be in main memory, L3, L2, and L1 cache, and 
in a (virtual) register.  After a successful increment is done, the 
register file will contain both a new and an old copy of A, and the 
processor logic will determine which value is used for other 
instructions in flight.  For example, the code:

A, B: Integer;
...
B := A;
A := A + 1;

may be executed by the processor out of order.  If so, the assignment to 
B will use the old value mentioned above, and if the assignment to A 
cause a trap, the processor will create a state where the first 
assignment has been done before calling the trap handler.  In fact, the 
actual microinstructions executed may look like:

M1: load A to R1
M2: load B to R2
M3: copy R1 to R2
M4: check if R1 = A's subtype'Last
M5: if so cause a trap
M6: increment R1

An OoO processor will then reify this code by assigning register file 
entries to the register names in the code.  This will result in two 
register file entries each for R1 and R2.  (And in practice, the second 
assignment for B will be to the renaming register initially assigned to 
A.  This makes the "move" instruction a no-op, and it will be treated as 
such.)  It will then execute the code in any order that is consistant 
with register file assignments.  This can even result in later 
instructions being "speculatively" executed before instructions they 
depend on.  It would not be at all uncommon for M4 and M6 to be executed 
simutaneously, with M6 "unwound" (in this case the result just ignored) 
if the trap in M5 occurs.

Oh, and if this code is executed often, for example in a loop.  EVERY 
time through the instructions may be executed in a different order than 
the previous time through.

If instead of the A and B being scalars, they are vectors, and the 
intent is to add one to every element (instead of adding a unit vector), 
  the same sort of thing will happen.  But in that case, the increment 
and test instructions for several dozen elements of A may be in flight 
simultaneously, and only if a trap occurs, will the processor have to 
think about generating a consistant state.

To condense the above, into one paragraph, learning assembly code for an 
ISA will result in the programmer thinking in terms of a finite state 
machine.  But modern processors are NOT finite state machines.  In 
particular the processors are only guarenteed to produce an image of a 
state consistant with the ISA implemented when certain instructions are 
executed.  The processor is never in any consistant state.  The most you 
can hope for is that at some points during the execution, you can define 
a subset of the actual hardware registers that corresponds to some 
externally known state. (For example, in an x86 ISA processor, the 
instructions are retired in order.  But two of the measures of goodness 
for an x86 processor are how many instructions can be dispatched at 
once, and how many can be simultaneously retired.)  In particular, 
trying to eliminate copying is often bogus, since in practice the copy 
gets optimized away, either by the compiler, or by the processor front end.

-- 
                                            Robert I. Eachus

Ryan gunned down the last of his third white wine and told himself it 
would all be over in a few minutes.  One thing he'd learned from 
Operation Beatrix: This field work wasn't for him. --from Red Rabbit by 
Tom Clancy.

Re: Is the Writing on the Wall for Ada?

[Russ]

"Robert I. Eachus" <rieachus@attbi.com> wrote in message news:<3F6EF608.7010704@attbi.com>...
> Wes Groleau wrote:

> > (Russ insists that A += 1 never needs temporaries
> > and that A := A + 1 always does.)
> 
> In pratice on modern hardware this statement is so far from the truth 
> that it isn't even wrong.

Whoa! Are you absolutely sure about that?

Are you suggesting perhaps that I'm 360 degrees out of phase with the
truth? If so, I say baloney. I'm sure its at least 720 degrees. But at
least its not 180.

Seriously though, I addressed this matter in an earlier post. 

First of all, when I discussed the issue of temporaries I was
referring to vector/matrix arithmetic, not floats or ints. Secondly, I
claim that "+=" (or whatever you wish to call it for Ada) is
equivalent to a procedure call, and as such it has no "LHS". Oh, yes,
it has a left hand side, but it is not to the left of an assignment
operator. Therefore the entire issue of temporaries is no different
than if I had used Add ( B, into => A) or some such abomination.

I'll say one thing about Ada folks. They're some of the most stubborn
folks I've ever had correspondence with. (Funny, my wife says the same
thing about me.)

Re: Is the Writing on the Wall for Ada?

[Robert I. Eachus]

Russ wrote:

 > First of all, when I discussed the issue of temporaries I was
 > referring to vector/matrix arithmetic, not floats or ints. Secondly,
 > I claim that "+=" (or whatever you wish to call it for Ada) is
 > equivalent to a procedure call, and as such it has no "LHS".

I guess this is just another example of what I mean.  I used scalars in
the first example to make it easy to write, then generalized to vectors:

 > If instead of the A and B being scalars, they are vectors, and the
 > intent is to add one to every element (instead of adding a unit
 > vector),  the same sort of thing will happen.  But in that case, the
 > increment and test instructions for several dozen elements of A may
 > be in flight simultaneously, and only if a trap occurs, will the
 > processor have to think about generating a consistant state.

But what you are still missing is that the whole concept that you as a 
programmer have any idea of the number of temporary copies made--or not 
made by the processor is way off base.  Not just out of the park on 
Yawkey Way, but Commonwealth Ave.--if the game is in Yankee Stadium.

You program for a finite-state machine.  Your code is not run on a 
finite-state machine.  Trying to reason from the FSM representation will 
only lead you astray.

-- 
                                            Robert I. Eachus

Ryan gunned down the last of his third white wine and told himself it
would all be over in a few minutes.  One thing he'd learned from
Operation Beatrix: This field work wasn't for him. --from Red Rabbit by
Tom Clancy.

Re: Is the Writing on the Wall for Ada?

[Jacob Sparre Andersen]

Russ wrote:

> Mr. Eachus, you are probably a top-notch programmer and/or software
> engineer, but I don't think your example has much bearing on whether
> Ada should or should not have augmented assignment operators.

I think Robert made a fairly good explanation of why they aren't needed 
as syntactic sugar.

> As every competent C++ programmer
> knows, augmented assignment also allows more efficient vector/matrix
> operations (for example) by eliminating the need for temporaries.

I think I have already demonstrated here (in some earlier thread on this 
topic) that it is possible, but not completely trivial, to leave this 
optimisation to the compilers.

> And that's why the most popular programming languages have augmented
> assignment operators. But Ada doesn't want to be popular, I guess.

Ada is not designed to be popular.  It is designed to make programs that 
work.  Also after 30 years of system maintenance.

Jacob

PS: I can't find a link to an English language version of the guidelines
     for using quotes on Usenet right now (writing this off-line), but I
     would appreciate it, if people taking part in the discussions here
     on comp.lang.ada took a look at them and tried to follow the advice.
-- 
Rent-a-Minion Inc. Because good help is so hard to find.

Re: Is the Writing on the Wall for Ada?

[Wes Groleau]

Matthew Heaney wrote:
> 18k11tm001@sneakemail.com (Russ) writes:
>>I note also that C, C++, Java, Perl, and Python, the five more popular
>>general purpose languages around today, all have augmented assignment
>>operators, and it it is still painfully obvious to me that Ada needs
>>them too. But it is also painfully obvious to me that most Ada
>>veterans are blind to this reality. Too bad -- for Ada.
> 
> What kind of "augmented" assignment operator did you have in mind?

If this is the same Russ that went on and on and on
about this some time ago, he's talking about stuff like

+=  *=  -=  etc.

On a related subject, I just got a chuckle from the
"job requirements" of an online job posting (note
the third word):

    Experience with modern languages (C/C++, Java, Tcl/Tk, etc)

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau/Wes

Re: Is the Writing on the Wall for Ada?

[Mike Silva]

What about switching to COBOL to take advantage of all the cheap
leftover Y2K talent?

Re: Is the Writing on the Wall for Ada?

[David Marceau]

"Warren W. Gay VE3WWG" wrote:
> 
> This is not a troll... but I am soliciting some opinion.
> 
> I read a disturbing article in the July COTS Journal recently,
> and thought I would bounce the controversial aspects off
> of the group. The complete article can be read at:
> 
>   http://www.cotsjournalonline.com/pdfs/2003/07/COTS07_softside.pdf
> 
> I have quoted some of the sections for ease of discussion below:
> 
> From Article:
> 
>   Softer Side: Java in the Military
>   Java Proving Itself Worthy for Defense Apps
>   July 2003 COTS Journal [ 27 ]
> 
> ...
> 
> Navy's Open Architecture
> ========================
> 
> **** <highlight> ****
> 
> Among the key motivations for the military's interest in Java is a drive
> to transition away from Ada.
> 
> **** </highlight> ****
> 
> The feeling is that Java represents a modern and more commercially
> available technology than alternatives. The Navy, for example, is
> drafting their Navy Open Architecture Computing Environment (NOACE) to
> be the standard for all future software systems on Navy warships. That
> includes shipboard weapon systems, such as anti-aircraft cannon controls
> as well as avionics systems aboard naval aircraft. The standard calls
> for all new software to develop in either C++ or Java, and makes
> specific mention of moving away from Ada. They plan to continue to use
> Ada only as required to support legacy systems that have already been
> developed.
> 
> ...
> 
> Moving Away from Ada
> ====================
> 
> For its part, Boeing has also expressed a clear preference to move
> toward Java. Winner of the lead system integrator contract on for U.S.
> Army's Future Combat Systems (FCS) program, Boeing is farming out their
> FCS requirements and telling suppliers they want to use Java, they don't
> 
>   **** <highlight> ****
> 
> like C++ and they don't like Ada for any new system development. Many
> 
>   **** </highlight> ****
> 
> suppliers to FCS are therefore tasked to convert reams of Ada code over
> to Java.
> 
> There are some basic human resources reasons why Java is a preferred
> approach. Today's new graduates from college are 99% more likely to know
> Java than any other programming language. And among experienced
> programmers out in the workforce, more will tend to highlight Java on
> their resume rather than Ada. The ranks of true Ada gurus are probably
> comprised more of programmers near retirement than otherwise.
> 
> </quote>
> 
> SOME OBSERVATIONS:
> ==================
> 
> I have seen many quotes here in comp.lang.ada and other web sources
> that only the mandate to use Ada has been dropped. The position that
> is usually made is that Ada is still considered on a project by
> project basis, where it makes sense.
> 
> However, if the above article is accurate, it seems that the U.S.
> military (and Boeing) is making a conscious effort to move away from Ada.
> The article is suggesting that the only reason to use Ada now would
> be for legacy systems. Boeing apparently does not want to use Ada
> in any new development.
> 
> CONCLUSION:
> 
> Whether or not you agree with the reasoning in the article, the
> disturbing thing in my mind is the "mindset". If the military and big
> industrial companies like Boeing turn their back on Ada, where is Ada
> headed for in the future? Is there enough other momentum to keep Ada
> (and GNAT) going into the foreseeable future?
> 
> I attended a small Real-Time conference last week in Toronto, and I only
> heard the name Ada  mentioned once, and in a negative way
> (in passing reference WRT Real-Time Java). None of the vendors there
> that I talked to were using Ada for their SBC and the one vendor
> for flight systems told me they simply do not have the customer
> demand for Ada systems.
> 
> So: Is the writing on the wall for Ada?
> 
> What is your take on the article?
> --
> Warren W. Gay VE3WWG
> http://home.cogeco.ca/~ve3wwg
It sounds like a language war being declared again.  If you are saying
if the ada lovers should give up, well here are some alternatives among
others:
-go against the flow and openly defend ada as if it were your religion. 
I was told recently that I consider the Ada language like a religion.   
I may be a language zealot deep inside of me but that's because I don't
want to have to deal with the immense long-term impact of some idiotic
decicion maker choosing the wrong language for building high-integrity
systems.  The key words are "LONG-TERM IMPACT ON SOCIETY".
-go with the flow...take the money and run....develop in java...if you
can't beat em join right?
-if you're really hot, build a chip you coded in ada and give it a
JNI(java native interface) or JVM front end :)  That way everybody's
happy because where it needs to be reliable it is and everything else to
crap out as much as it wants...it's a compromise mind you.  Rumor has it
maybe there are some that already exist with real-time
java/j2me/javacard vm chips running ada inside.
-be a subversive...pretend to be a loyal java developer while coding ada
in some dark corner on your spare time :)  When the right moment comes
the subvervises will come out of the closet and revive ada :)

As it stands there are so many language wars going on that are
pointless.  Currently there is a new wave of web site developers that
are keen on using php/apache/sql on linux boxes....this sounds like a
tangent but its not because eventually some of these developers might
decide to build an embedded system with php in it.  It sounds a lot like
when java started doesn't it?

I think the US DOD did a courageous thing to let other(non-ada)
languages the chance to participate in building many projects.  From
what I understand it was a calculated decision because they took metrics
throughout these projects or at least they were supposed to.

If Ada's time has come, then so be it...but the data from some other
CROSSTALK issues point to other results...results that explicitly show
Ada builds more reliable systems in the long term.   The other feeling
driving me to use ada is my own personal experience with Ada, c,c++,
java, javacard, and j2me.
Let's be honest java is fun to play with and especially on the new
gizmos(pdas,cellphones,smartcards).  That said my gut instinct tells me
it could be better and faster if these devices allowed me to install ada
applets/cardlets/midlets in them instead.

I did read the real time java spec.  The only way it could really
replace ada is if it inherited all of the ada language design.
That isn't going to happen though because real time java is under the
constraint of having-to-look-and-feel like the rest of the java subsets
i.e. javacard, j2me, etc... in order for the language to be easier to
learn and get up to speed.  Yes it is true that java/j2me/javacard on
cell phones/pda's seems adequate but I would bet if these were built
with ada, not only would they be more reliable but they would definitely
run faster.  That said yes a cell phone is not a life-threatening system
and if it bugs/crashes well you just turn it off and then back on.  For
some other people(you know who you are) cell phones/pda's however have
to work all-the-time with no bugs.  Java/j2me/javacard doesn't cut it
for these.  I have another theory maybe there is a double standard being
developed....within a certain number of core devices they still use ada
to have the edge and then for the rest of the industry they give them
the lower quality slower stuff i.e. java just to make sure they keep the
edge :)  I also have another theory...someone wants java to become more
popular in order to make it easier for industry to introduce honeypots
or viruses on anyone's machine in this manner because nobody is using
all the cpu power capacity at 100% all the time.  I remember when my
compiler used to just eat everything the cpu could give me.  That's not
the case with the java compiler tools well not unless you are using a
sophisticated IDE.  Because we are getting used to java's jvm on-the-fly
byte-code compiling/interpreting slowing down performance we just get
used to it being slow all the time when in fact it gives
viruses/honeypots a place to hide because we don't notice them eating
away our cpu cycles.

As you can see it's not black and white...it's just all gray.  I
sincerely think ada and java will both be around with all their
flavours.  I think DOD is not crazy enough to just ditch ada for java. 
They know better than to put all there eggs in one basket which is what
all the above is about right?  What DOD actually wants is to have more
alternatives for doing reliable systems hence the place for
RealTimeJava's existence and encouragement.

My suggestion if you want job security...know both Ada and Java very
well and never admit to your superiors that you like ada more than
java.  Be a diplomat.  I learned this the hard way.  If you want to lose
your job or lose a job opportunity just do like I did...tell them that
you prefer not to use java and explicitly state the technical reasons. 
I have learned from this experience and will never do this again :)  I
do hope that by sharing this with you that it might help someone keep
their job.

Thank you for listening to my delusions :)

Yet another ada wanna-be,
David Marceau

Re: Is the Writing on the Wall for Ada?

[Warren W. Gay VE3WWG]

"David Marceau" <davidmarceau@sympatico.ca> wrote in message news:3F5AD703.24FC6D3E@sympatico.ca...
> "Warren W. Gay VE3WWG" wrote:
> > I read a disturbing article in the July COTS Journal recently,
> > and thought I would bounce the controversial aspects off
> > of the group. The complete article can be read at:
> >
> >   http://www.cotsjournalonline.com/pdfs/2003/07/COTS07_softside.pdf
> > ...

> As it stands there are so many language wars going on that are
> pointless.  Currently there is a new wave of web site developers that
> are keen on using php/apache/sql on linux boxes....this sounds like a
> tangent but its not because eventually some of these developers might
> decide to build an embedded system with php in it.  It sounds a lot like
> when java started doesn't it?

The only "language war" that concerns me, is the one(s) connected
with Ada. Web development is itself, an interesting environment
to code for, so I won't go there in this article..

> I think the US DOD did a courageous thing to let other(non-ada)
> languages the chance to participate in building many projects.  From
> what I understand it was a calculated decision because they took metrics
> throughout these projects or at least they were supposed to.

On the hardware side, I might agree that the certification process
probably left them using less than leading edge stuff, though I
don't know enough about that side of things to say really.

On the software side (Ada), I am not so sure this was a smart thing.

The US military recognized a problem, and have basically "fixed it":
first with Ada83, and now the improved Ada95. Why toss their baby
away now?

> If Ada's time has come, then so be it...but the data from some other
> CROSSTALK issues point to other results...results that explicitly show
> Ada builds more reliable systems in the long term.   The other feeling
> driving me to use ada is my own personal experience with Ada, c,c++,
> java, javacard, and j2me.

I think most here who hang out/lurk in comp.lang.ada recognize
the strengths of Ada.

> I did read the real time java spec.  The only way it could really
> replace ada is if it inherited all of the ada language design.

So you say, but the article suggests that the spec and the intentions
are to help get away from Ada. It is the GOAL that bothers me. Not
whether or not they can do it.

When someone sets a GOAL, the idea generally is that they will
succeed at it someday. What bothers me about this article is
the "who" that is setting this goal.

> As you can see it's not black and white...it's just all gray.  I
> sincerely think ada and java will both be around with all their
> flavours.  I think DOD is not crazy enough to just ditch ada for java.

Define "crazy" ;-)

I don't know that culture very well, but from what I have read
and the impressions I get is that we have a new generation of
people who are thinking differently. It seems that they are
too young to remember the lessons of the past, and are blinded
by the dazzle of the "present".

Here's another example: They have done away with the requirement
to know and use Morse code in radio traffic. They are now more
comfortable with depending upon modern technology. Well, given
a weak signal, morse (CW) will get a message through when all
other forms of communication will fail. Furthermore, if you get
stranded somewhere, it is much easier to build a CW transmitter
and get a message out. You'll never build any other kind of
transmitter out of junk parts in the back woods.

Anyway, I find all of these trends rather disturbing.

> They know better than to put all there eggs in one basket which is what
> all the above is about right?

You are actually better off to put all your eggs in one basket,
if it is a good one. This is generally unwise when you're
investing because it is difficult to identify good investments.
But the success of Ada can be measured and it has been measured,
quite thoroughly.  Hardly an unknown quantity today.

> What DOD actually wants is to have more
> alternatives for doing reliable systems hence the place for
> RealTimeJava's existence and encouragement.

Well, I understand the "alternatives" argument, but I don't
see the "reliability" being in the other scenarios. The mindset
in the other languages just isn't there.

I like the comment that Wes made: "I'm glad I'm getting out
of software."  The current trends make me feel in a similar
vein. I mean who wants to look through reahms of Java code
and try to make sense of it? The new Java generic code looks
like C++ templates all over again. Yuck. Didn't anyone
learn anything from that mess?

> My suggestion if you want job security...know both Ada and Java very

I don't care about job security WRT software anymore, but I
do care about Ada and Open Source. I hate Microsoft because
I cannot write for that platform and expect my application to
still work a few years from now. Maybe things will settle
somewhat now that everything is moving to win32, but I
very much hated the churn that software went through on
that platform.

UNIX/Linux has been much stabler by comparison in that
respect. Ada95 as a language is stable also. I hate this
constant "churn" in software. I hate re-doing everything
every year. Did I say that I hated this? ;-)

Maybe I should be counting my years to retirement instead.

But will the medical equipment they hook me up to someday
be safe?  That thought scares me.

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Is the Writing on the Wall for Ada?

[Marin David Condic]

You neglected one option: Go out and build as many important things as 
you can in Ada and *create* a market for Ada. That works both internally 
and externally. Build tools and other things with Ada internally within 
the company you work for. Build products to sell to the rest of the 
world using Ada. Both will increase the market for Ada and help to make 
Ada viable where the current wisdom says it is not.

MDC



David Marceau wrote:
> 
> Thank you for listening to my delusions :)
> 
> Yet another ada wanna-be,
> David Marceau


-- 
======================================================================
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: Is the Writing on the Wall for Ada?

[chris]

Warren W. Gay VE3WWG wrote:

> So: Is the writing on the wall for Ada?

Perhaps.  Perhaps not.

> What is your take on the article?

Java is attractive even given it's odd bits here and there.  I am not 
involved in SC systems, or real time systems, but I can see why some 
might find Java attractive (in other areas).

Java has a std container library *now*.  Java has a huge developer base. 
  Java has std and thourough documentation.  It is runtime portable and 
compile time portable, as opposed to simply compile time portable.  It 
is funded and advertised by Sun, Borland, IBM and others.  The language 
provides 3d/2d/image processing facilities and a std gui.  It provides 
sound facilities and has support for the 3 major desktop platforms out 
of the box.  Applets run in web browsers so people are aware of it.

It's a complete package!  And it maps easily to the fad of the day, UML. 
   Tools support mapping to UML and are readily available.

A while ago, I stopped programming in Ada 95 after playing with Java.  I 
have since came back to it but for one reason only, performance.  Java 
doesn't cut it for the applications that need speed.  Why stop with Ada 95?

Object Orientation is not easy.  If you want 'protected' access you have 
to use child packages, not always feasible or desirable.  Tasks and 
protected objects aren't oo, you can't extend them.  No reflection. 
Poor library support.  Loads of std container libs, no image processing, 
   etc ..., no applications written to exploit it... and no signs of 
apps appearing.


btw, I have just about finished a binding to linux dynamic loading 
facilities and some examples.  The original was lost but I rewrote it 
this week.  If anyone wants a copy now, email me.  Change spamoff to 
chris.  It doesn't have any documentation yet, but if time permits I 
will write some.

Re: Is the Writing on the Wall for Ada?

[David Marceau]

chris wrote:
> 
> Warren W. Gay VE3WWG wrote:
> 
> > So: Is the writing on the wall for Ada?
> 
> Perhaps.  Perhaps not.
> 
> > What is your take on the article?
> 
> Java is attractive even given it's odd bits here and there.  I am not
> involved in SC systems, or real time systems, but I can see why some
> might find Java attractive (in other areas).
> 
> Java has a std container library *now*.  Java has a huge developer base.
>   Java has std and thourough documentation.  It is runtime portable and
> compile time portable, as opposed to simply compile time portable.  It
> is funded and advertised by Sun, Borland, IBM and others.  The language
> provides 3d/2d/image processing facilities and a std gui.  It provides
> sound facilities and has support for the 3 major desktop platforms out
Essentially all you said here is provided because the JDK provides
wrapper calls to the real fast c/asm-code implementations running on the
destined platform.
In fact if the 2d/3d/image processing libs were completely written in
java they(especially 3d/image processing stuff) would be even more
unusably slow if you're used to ada/c/assembler performance.

>  Why stop with Ada 95?
> 
> Object Orientation is not easy.  If you want 'protected' access you have
> to use child packages, not always feasible or desirable.  Tasks and
> protected objects aren't oo, you can't extend them.  No reflection.
> Poor library support.  Loads of std container libs, no image processing,
>    etc ..., no applications written to exploit it... and no signs of
> apps appearing.
All the things you mentioned here about ada's non-easy OO are actually a
good thing for Ada.  Here are a few reasons:
-parallelism in ada's core language....true parallelism IMHO doesn't
seem to follow OO much IMHO.  It seems more to follow other paradigms.
For example look at java's "synchronized" keyword when used with
"interface" or function in some inheritance hierarchy.  It can actually
stop the gui and then the app because when you have more than one coder
programming a still immature infrastructure that's what actually
happens.  The probability of that happening with many ada developers
even with an immature infrastructure is definitely reduced again because
the language does lots of work for you to make sure things happen really
the way everybody wants.  Let the java developers try to draw the actual
sequence/collaboration diagrams of what actually happened and then
figure out how to fix it :)  Ada developers still need to deliberately
design the sequence/collaborations between the different types(objects
if you must) via their package spec services with parallelism in mind
but they will definitely be at an advantage when implementing it because
of the stronger concurrency capability in the ada language.

Again the fact a language has or doesn't have a bunch of libraries only
means that someone hasn't built them yet.  It's not cast in stone that
ada won't have them.  The other thing I want to say about the
availability of lots of libs for java is that it is smoke and mirrors
because lots of this stuff hasn't been tested/used/left-turned-on for a
very long time.  I never thought I would perceive myself as being
conservative but here I am saying that people should wait and see about
stuff before using it.  I would like to see how long a box running a
java-app will stay on without having to be restarted with all those
popular libs you talked about 2d/3d/image-processing/media sdk....then
come back to me about that.  That's where ada shines because "Ada Memory
Leaks" is more of an oxymoron than "java memory leaks" or "C memory
leaks".  Please correct me if I am wrong about that.

All this to say the writing is not on the wall for ada.  Ditto for
java.  There's room for lots of languages on this planet.  I am just
hoping we'll get better at using the right one at the right time :)

Re: Is the Writing on the Wall for Ada?

[Matthew Heaney]

David Marceau <davidmarceau@sympatico.ca> writes:

> Again the fact a language has or doesn't have a bunch of libraries only
> means that someone hasn't built them yet.  It's not cast in stone that
> ada won't have them.

There is in fact an Ada95 container library available now, modeled on
the STL.

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

I will be submitting a proposal for a standard container library, based
on Charles.

Once the proposal has been submitted (probably another few days), I will
synchronize Charles to match the proposal.

Re: Is the Writing on the Wall for Ada?

[Matthew Heaney]

chris <spamoff.danx@ntlworld.com> writes:

> Java has a std container library *now*.

There is active work on having a standard container library for Ada 0Y.
I will be submitting a proposal soon based on the Charles library.

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

Charles is based on the STL.

Re: Is the Writing on the Wall for Ada?

[Alexander Kopilovitch]

Warren W. Gay wrote:
>Is the writing on the wall for Ada?

This is not a writing on the wall, but just a writing on a fence -:)

(I don't know whether there is an English/American anecdote similar to that
Russian one, but anyway.)



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

Re: Is the Writing on the Wall for Ada?

[Dmytry Lavrov]

Alexander Kopilovitch wrote:
> 
> Warren W. Gay wrote:
> >Is the writing on the wall for Ada?
> 
> This is not a writing on the wall, but just a writing on a fence -:)
> 
> (I don't know whether there is an English/American anecdote similar to that
> Russian one, but anyway.)
ANEKDOTE? 
i don't understand.REally interesting!;-)

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

Re: Is the Writing on the Wall for Ada?

[Ludovic Brenta]

My take at it is that development managers want to hire disposable,
interchangeable developers.  That is why it is so important to them
that "99% of new graduates know Java".  The quality of the language
has nothing to do whatsoever with it.  Furthermore, they deliberately
choose to ignore the fact that by hiring disposable developers, they
end up developing disposable software.  For shops like Boeing where
software just has to work, this means increased costs of development,
which they hope to recoup by lower wages paid to their disposable
developers.

Similarly, consulting firms make their money by selling development
time, therefore it is in their interest to keep development costs as
high as possible.  In fact, the role of a good development manager at
a consulting firm is to keep a project on the verge of being cancelled
(which is the point where costs are as high as the customer is willing
to pay), but to not let it be cancelled (or granted to another
contractor) altogether, so as to milk the cow for as long as possible.

For COTS software vendors, disposable software is in fact the whole
point they want to reach.  Their software, nowadays, is not meant to
be used anymore; it is meant to be sold; so it is a good business
model that produces buggy, ill-designed software that must be replaced
periodically.  The natural consequence of that is a subscription-based
business model.

Sun originally used binary portability as their main argument for
Java.  That was in the days when Java was the language for applets.
At that time, they said it was okay to sacrifice performance for
binary portabiliy.  Now that applets have come and gone, most everyone
is developing server-side software in Java.  On a server, binary
portability is unimportant; what is important is performance
(especially if your servers costs big bucks, you really want to
squeeze performance out of them), so Java should have been ruled out.
But it is in the interest of Sun, IBM and other hardware vendors to
keep selling bigger and bigger servers.  For them, it is a good
business model that produces inefficient software, because they can
sell more hardware to compensate for that.

By the way, why do you think "99% of new graduates know Java"?
Because Java is a simplified language designed for beginners.  The
guys who developed it took C++, removed the really good part of it
(templates), kept a less interesting part of it (inheritance, albeit
simplified), ditched most static type checks in the process, and
designed everything so that errors were detected as late as possible
at run time.  The worst part of it is that most of these graduates are
True Believers in the Java Gospel, and think that "thou shalt use
inheritance everywhere" is the One True Way of Programming.  Most of
them have never even heard of memory management.

By contrast, Ada was designed by and for Real Programmers, and with
low development costs as the main requirement, therefore it took the
exact opposite approach; it had generics before inheritance,
emphasises separation of interfaces from implementation for code
reuse, and tries its best to detect errors as early as possible at
compile time.  Ada is an engineer's dream and a vendor's nightmare.

All in all, I think that the DoD and Boeing are the willing victims of
hardware, software and services vendors, all of which want high
development costs and unreliable software.

:(

-- 
Ludovic Brenta.

Re: Is the Writing on the Wall for Ada?

[Robert I. Eachus]

Ludovic Brenta wrote:

> All in all, I think that the DoD and Boeing are the willing victims of
> hardware, software and services vendors, all of which want high
> development costs and unreliable software.

It is worth remembering that the Boeing of today is not the Boeing that 
was trying to get to Ada for everything.  Due to mergers--the big one 
was Boeing and McDonald-Douglas--the Boeing of a decade ago is less than 
half of today's Boeing.
-- 
                                             Robert I. Eachus

"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: Is the Writing on the Wall for Ada?

[John R. Strohm]

"Ludovic Brenta" <ludovic.brenta@skynet.be> wrote in message
news:m3brtwobby.fsf@insalien.org...
[snip]
> By contrast, Ada was designed by and for Real Programmers, and with
> low development costs as the main requirement, therefore it took the
> exact opposite approach; it had generics before inheritance,
> emphasises separation of interfaces from implementation for code
> reuse, and tries its best to detect errors as early as possible at
> compile time.  Ada is an engineer's dream and a vendor's nightmare.

One quibble.

Ada was not designed for low DEVELOPMENT costs.

Ada was designed for low SOFTWARE LIFECYCLE costs.

The key difference is that NET cost reduction over the entire software
lifecycle MAY require swallowing higher INITIAL costs.

As an extreme example: You can push just about anything through a C
compiler, and the compiler will swallow it and be happy.  Later, the system
will blow bits out the side of the box.  On the other hand, it can take a
lot more effort to get the Ada compiler to accept the equivalent program,
but MANY, MANY Ada programmers have learned, one at a time the old-fashioned
way, that, once you get the Ada compiler to swallow your source code and not
spit it back up, your code is ALMOST certain to work exactly the way you
want it to.

So you have traded increased compilation costs for decreased debugging,
test, and integration costs.  Since debugging, test, and integration
typically costs a LOT more than running the compiler, this is typically a
net win.

Re: Is the Writing on the Wall for Ada?

[Warren W. Gay VE3WWG]

John R. Strohm wrote:
> "Ludovic Brenta" <ludovic.brenta@skynet.be> wrote in message
> news:m3brtwobby.fsf@insalien.org...
> [snip]
> 
>>By contrast, Ada was designed by and for Real Programmers, and with
>>low development costs as the main requirement, therefore it took the
>>exact opposite approach; it had generics before inheritance,
>>emphasises separation of interfaces from implementation for code
>>reuse, and tries its best to detect errors as early as possible at
>>compile time.  Ada is an engineer's dream and a vendor's nightmare.
> 
> One quibble.
> 
> Ada was not designed for low DEVELOPMENT costs.
> 
> Ada was designed for low SOFTWARE LIFECYCLE costs.
> 
> The key difference is that NET cost reduction over the entire software
> lifecycle MAY require swallowing higher INITIAL costs.
> 
> As an extreme example: You can push just about anything through a C
> compiler, and the compiler will swallow it and be happy.  Later, the system
> will blow bits out the side of the box.  On the other hand, it can take a
> lot more effort to get the Ada compiler to accept the equivalent program,
> but MANY, MANY Ada programmers have learned, one at a time the old-fashioned
> way, that, once you get the Ada compiler to swallow your source code and not
> spit it back up, your code is ALMOST certain to work exactly the way you
> want it to.
> 
> So you have traded increased compilation costs for decreased debugging,
> test, and integration costs.  Since debugging, test, and integration
> typically costs a LOT more than running the compiler, this is typically a
> net win.

Those are good points. Limited types for example, severely hamper
what the programmer _wants_ to do, but the "limited" aspect of
the value/object forces them to consider the design aspects (where
C/C++ imposes no such restriction). Another area is of course the
use of access types etc. I am sure that an experienced Ada designer
is not hampered much by these things, but an Ex-C persion sure is!

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Is the Writing on the Wall for Ada?

[Matthew Heaney]

"Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> writes:

> Those are good points. Limited types for example, severely hamper what
> the programmer _wants_ to do, but the "limited" aspect of the
> value/object forces them to consider the design aspects (where C/C++
> imposes no such restriction).

I don't understand this statement.  You have limited types in C++, too.
If you want to take away assignment in C++, then just take away
assignment.  What's the problem?

RE: Is the Writing on the Wall for Ada?

[Robert C. Leif]

This is very interesting because the C language market will eventually go to
C#. The DoD is continuing in its blunders. It would be very interesting to
know if other countries were dumb enough to follow the US DoD's lead.
Bob Leif 
Robert C. Leif, Ph.D.
Email rleif@rleif.com
-----Original Message-----
From: Warren W. Gay VE3WWG [mailto:ve3wwg@cogeco.ca] 
Sent: Saturday, September 06, 2003 2:47 PM
To: comp.lang.ada@ada.eu.org
Subject: Is the Writing on the Wall for Ada?

This is not a troll... but I am soliciting some opinion.

I read a disturbing article in the July COTS Journal recently,
and thought I would bounce the controversial aspects off
of the group. The complete article can be read at:

  http://www.cotsjournalonline.com/pdfs/2003/07/COTS07_softside.pdf

I have quoted some of the sections for ease of discussion below:

>From Article:

  Softer Side: Java in the Military
  Java Proving Itself Worthy for Defense Apps
  July 2003 COTS Journal [ 27 ]

...

Navy's Open Architecture
========================

**** <highlight> ****

Among the key motivations for the military's interest in Java is a drive
to transition away from Ada.

**** </highlight> ****

The feeling is that Java represents a modern and more commercially
available technology than alternatives. The Navy, for example, is
drafting their Navy Open Architecture Computing Environment (NOACE) to
be the standard for all future software systems on Navy warships. That
includes shipboard weapon systems, such as anti-aircraft cannon controls
as well as avionics systems aboard naval aircraft. The standard calls
for all new software to develop in either C++ or Java, and makes
specific mention of moving away from Ada. They plan to continue to use
Ada only as required to support legacy systems that have already been
developed.

...

Moving Away from Ada
====================

For its part, Boeing has also expressed a clear preference to move
toward Java. Winner of the lead system integrator contract on for U.S.
Army's Future Combat Systems (FCS) program, Boeing is farming out their
FCS requirements and telling suppliers they want to use Java, they don't

  **** <highlight> ****

like C++ and they don't like Ada for any new system development. Many

  **** </highlight> ****

suppliers to FCS are therefore tasked to convert reams of Ada code over
to Java.

There are some basic human resources reasons why Java is a preferred
approach. Today's new graduates from college are 99% more likely to know
Java than any other programming language. And among experienced
programmers out in the workforce, more will tend to highlight Java on
their resume rather than Ada. The ranks of true Ada gurus are probably
comprised more of programmers near retirement than otherwise.

</quote>


SOME OBSERVATIONS:
==================

I have seen many quotes here in comp.lang.ada and other web sources
that only the mandate to use Ada has been dropped. The position that
is usually made is that Ada is still considered on a project by
project basis, where it makes sense.

However, if the above article is accurate, it seems that the U.S.
military (and Boeing) is making a conscious effort to move away from Ada.
The article is suggesting that the only reason to use Ada now would
be for legacy systems. Boeing apparently does not want to use Ada
in any new development.

CONCLUSION:

Whether or not you agree with the reasoning in the article, the
disturbing thing in my mind is the "mindset". If the military and big
industrial companies like Boeing turn their back on Ada, where is Ada
headed for in the future? Is there enough other momentum to keep Ada
(and GNAT) going into the foreseeable future?

I attended a small Real-Time conference last week in Toronto, and I only
heard the name Ada  mentioned once, and in a negative way
(in passing reference WRT Real-Time Java). None of the vendors there
that I talked to were using Ada for their SBC and the one vendor
for flight systems told me they simply do not have the customer
demand for Ada systems.

So: Is the writing on the wall for Ada?

What is your take on the article?
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Is the Writing on the Wall for Ada?

[chris]

Robert C. Leif wrote:
> This is very interesting because the C language market will eventually go to
> C#.

Why?  That's what they said about Cpp and Java.  It hasn't happened yet. 
  And C# is constrained to the M$ platform for the moment.  I haven't 
heard of anyone seriously considering developing apps in C# for Linux, 
nor Unix.  That would be interesting.


 > The DoD is continuing in its blunders. It would be very interesting to
> know if other countries were dumb enough to follow the US DoD's lead.

What would you rather have them work with if they wouldn't work in Ada, 
C(++) or Java?

Re: Is the Writing on the Wall for Ada?

[Christopher Browne]

In an attempt to throw the authorities off his trail, chris <spamoff.danx@ntlworld.com> transmitted:
> Robert C. Leif wrote:
>> This is very interesting because the C language market will eventually go to
>> C#.
>
> Why?  That's what they said about Cpp and Java.  It hasn't happened
> yet. And C# is constrained to the M$ platform for the moment.  I
> haven't heard of anyone seriously considering developing apps in C#
> for Linux, nor Unix.  That would be interesting.

Actually, C# _isn't_ so constrained.  There are about three
implementations for other platforms; the most mature being MONO.

I have run sample C# programs, at least, on Linux.

That's a far cry from either:
 - MONO being a total replacement for .NET;
 - C# becoming a popular software implementation language on Linux
   or *BSD.

Mind you, _none_ of that is useful in arguing for the impending
disappearance of C.  

What _would_ be useful arguments would be:

 - That OS kernels were being implemented in C#.  

   Note that neither C#, Java, nor even C++ are heavily used in that
   regard.  C is still pretty much "king."

 - That vital libraries were being implemented in [something other
   than C].

"Don't use C; In my opinion, C is a library programming language not
an app programming language."  -- Owen Taylor (GTK+ and ORBit
developer)
-- 
let name="cbbrowne" and tld="acm.org" in name ^ "@" ^ tld;;
http://www3.sympatico.ca/cbbrowne/x.html
"A man without religion is like a fish without a bicycle."
-- Bertrand Russell

Re: Is the Writing on the Wall for Ada?

[chris]

Christopher Browne wrote:

> Actually, C# _isn't_ so constrained.  There are about three
> implementations for other platforms; the most mature being MONO.
> 
> I have run sample C# programs, at least, on Linux.

Cool.  I was aware of Mono, but thought it was not in a usable state 
yet.  Hmm, A# on Mono and .NET?  Now that would be good.


> That's a far cry from either:
>  - MONO being a total replacement for .NET;
>  - C# becoming a popular software implementation language on Linux
>    or *BSD.

That's a shame.  As much as I dislike the evil empire, .Net helps solve 
a difficult problem and it is *not* migration to 64 bit.  It allows sw 
written in different languages to combine effectively.  That opens up a 
lot of code to languages.  Ada suffers from a lack of libraries for many 
things, and it is not alone.  .Net offers an abundance of such things.

That is what's good about .Net!  The bad part is it seems M$ are intent 
on vendor lock in and .Net is the vehicle through which they seek to 
attain it!


> Mind you, _none_ of that is useful in arguing for the impending
> disappearance of C.  
> 
> What _would_ be useful arguments would be:
> 
>  - That OS kernels were being implemented in C#.  
> 
>    Note that neither C#, Java, nor even C++ are heavily used in that
>    regard.  C is still pretty much "king."

C++ OS development is hampered by RTTI.  Many people posting 
alt.os.development who want to do development with C++ have to turn RTTI 
off and work around it.  If that proves too difficult, some drop to C.

I think Ada 95 would be an excellent tool for an OS and wanted to do one 
in it, still do infact, but an OS is not a trivial application.


>  - That vital libraries were being implemented in [something other
>    than C].
> 
> "Don't use C; In my opinion, C is a library programming language not
> an app programming language."  -- Owen Taylor (GTK+ and ORBit
> developer)

I disagree with that... just don't use C! :)

Seriously, it has some merit but I'd rather not if given the choice.



What I want is a language like Ada 95 without the clunky bits because of 
its' evolution.  Something that has all the good things, but is simpler 
and wiser.


Chris

Re: Is the Writing on the Wall for Ada?

[Christopher Browne]

A long time ago, in a galaxy far, far away, chris <spamoff.danx@ntlworld.com> wrote:
> Christopher Browne wrote:
>> That's a far cry from either:
>>  - MONO being a total replacement for .NET;
>>  - C# becoming a popular software implementation language on Linux
>>    or *BSD.

> That's a shame.  As much as I dislike the evil empire, .Net helps
> solve a difficult problem and it is *not* migration to 64 bit.  It
> allows sw written in different languages to combine effectively.
> That opens up a lot of code to languages.  Ada suffers from a lack
> of libraries for many things, and it is not alone.  .Net offers an
> abundance of such things.

The attendant problem is that what .NET /really/ is (primarily) is a
wannabe alternative to J2EE.  The fact of it supporting languages
aside from C# and Visual BASIC is NOT likely high on the list of
reasons for it being built the way it was.

> That is what's good about .Net!  The bad part is it seems M$ are
> intent on vendor lock in and .Net is the vehicle through which they
> seek to attain it!

For sure.

> I think Ada 95 would be an excellent tool for an OS and wanted to do
> one in it, still do infact, but an OS is not a trivial application.

Indeed.

>>  - That vital libraries were being implemented in [something other
>>    than C].
>> "Don't use C; In my opinion, C is a library programming language not
>> an app programming language."  -- Owen Taylor (GTK+ and ORBit
>> developer)
>
> I disagree with that... just don't use C! :)
>
> Seriously, it has some merit but I'd rather not if given the choice.

I try to avoid it for the most part; the pains of fighting with memory
allocation being the most notable bit...
-- 
"cbbrowne","@","cbbrowne.com"
http://cbbrowne.com/info/emacs.html
He who laughs last thinks slowest. 

RE: Is the Writing on the Wall for Ada?

[Robert C. Leif]

C# is an ECMA standard. There every reason to develop a compiler for other
operating systems. It would be very interesting if an Ada version of the
.Net architecture could be made for Linux. The idea is to be able to produce
binaries that would work on both Windows and Linux. The reliability of Ada
or SPARK would provide a very significant marketing advantage.
Bob Leif
Robert C. Leif, Ph.D.
Email rleif@rleif.com

-----Original Message-----
From: chris [mailto:spamoff.danx@ntlworld.com] 
Sent: Sunday, September 07, 2003 3:22 PM
To: comp.lang.ada@ada.eu.org
Subject: Re: Is the Writing on the Wall for Ada?

Robert C. Leif wrote:
> This is very interesting because the C language market will eventually go
to
> C#.

Why?  That's what they said about Cpp and Java.  It hasn't happened yet. 
  And C# is constrained to the M$ platform for the moment.  I haven't 
heard of anyone seriously considering developing apps in C# for Linux, 
nor Unix.  That would be interesting.


 > The DoD is continuing in its blunders. It would be very interesting to
> know if other countries were dumb enough to follow the US DoD's lead.

What would you rather have them work with if they wouldn't work in Ada, 
C(++) or Java?

Re: Is the Writing on the Wall for Ada?

[chris]

Robert C. Leif wrote:
> C# is an ECMA standard. There every reason to develop a compiler for other
> operating systems. It would be very interesting if an Ada version of the
> .Net architecture could be made for Linux. The idea is to be able to produce
> binaries that would work on both Windows and Linux. The reliability of Ada
> or SPARK would provide a very significant marketing advantage.

So why aren't you building it, then?

RE: Is the Writing on the Wall for Ada?

[Robert C. Leif]

Amongst the readers of Comp.Lang.Ada, there are persons like me, who are Ada
users. When a customer or potential customer tells me how to improve a
product, I do NOT tell him or her to build the product. 
A major problem with Ada is that she has been technology rather than market
driven. I have seen requests for suggestions for Ada projects and therefore
suggested one that I hoped could be an extension of existing Ada technology.
Bob Leif
Robert C. Leif, Ph.D.
rleif@rleif.com
-----Original Message-----
From: chris [mailto:spamoff.danx@ntlworld.com] 
Sent: Monday, September 08, 2003 8:52 AM
To: comp.lang.ada@ada.eu.org
Subject: Re: Is the Writing on the Wall for Ada?

Robert C. Leif wrote:
> C# is an ECMA standard. There every reason to develop a compiler for other
> operating systems. It would be very interesting if an Ada version of the
> .Net architecture could be made for Linux. The idea is to be able to
produce
> binaries that would work on both Windows and Linux. The reliability of Ada
> or SPARK would provide a very significant marketing advantage.

So why aren't you building it, then?

RE: Is the Writing on the Wall for Ada?

[Michael Erdmann]

Robert C. Leif wrote:

........................
> Robert C. Leif wrote:
>> This is very interesting because the C language market will eventually go
> to
>> C#.
> 
> Why?  That's what they said about Cpp and Java.  It hasn't happened yet.
>   And C# is constrained to the M$ platform for the moment.  I haven't
> heard of anyone seriously considering developing apps in C# for Linux,
> nor Unix.  That would be interesting.
> 

Please do not forget the mono project with provides already a C# 
compiler, Gtk Bindings etc.. I think it just a matter of time 
that somebody starts to develop appliccations.

Re: Is the Writing on the Wall for Ada?

[John R. Strohm]

"Robert C. Leif" <rleif@rleif.com> wrote in message
news:mailman.12.1062951277.295.comp.lang.ada@ada.eu.org...
> This is very interesting because the C language market will eventually go
to
> C#. The DoD is continuing in its blunders. It would be very interesting to
> know if other countries were dumb enough to follow the US DoD's lead.

I just saw an announcement somewhere that the People's Republic of China has
some BIG project that is going all in Ada.  I'm not certain, but I think it
is their manned spaceflight work.

Re: Is the Writing on the Wall for Ada?

[Ludovic Brenta]

"John R. Strohm" <strohm@airmail.net> writes:

> I just saw an announcement somewhere that the People's Republic of
> China has some BIG project that is going all in Ada.  I'm not
> certain, but I think it is their manned spaceflight work.

I think that the Chinese are being pretty smart these days.  First,
they kicked Microsoft out of their administration in favour of Linux
and local companies.  Now they use Ada for serious stuff.  It seems to
me that they understand whet is in their best interest as users of
technology : low lifecycle costs, efficient and reliable software.

Unfortunately, most users of technology in the West blindly follow the
advice given to them by vendors of technology.  And, as I explained,
these vendors are interested in selling expensive, unreliable and
inefficient software :(

-- 
Ludovic Brenta.

Re: Is the Writing on the Wall for Ada?

[Warren W. Gay VE3WWG]

Ludovic Brenta wrote:

> "John R. Strohm" <strohm@airmail.net> writes:
>>I just saw an announcement somewhere that the People's Republic of
>>China has some BIG project that is going all in Ada.  I'm not
>>certain, but I think it is their manned spaceflight work.
> 
> I think that the Chinese are being pretty smart these days.  First,
> they kicked Microsoft out of their administration in favour of Linux
> and local companies.  Now they use Ada for serious stuff.  It seems to
> me that they understand whet is in their best interest as users of
> technology : low lifecycle costs, efficient and reliable software.
> 
> Unfortunately, most users of technology in the West blindly follow the
> advice given to them by vendors of technology.  And, as I explained,
> these vendors are interested in selling expensive, unreliable and
> inefficient software :(

Wouldn't it be ironic if the rest of the world uses the technology
that the US military developed and paid for (Ada, with tax dollars),
while they ditch it for inferior tools. Worse, later their own
technology (Ada) could end up being used against them.

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Is the Writing on the Wall for Ada?

[Alexander Kopilovitch]

"Warren W. Gay wrote:

> Wouldn't it be ironic if the rest of the world uses the technology
> that the US military developed and paid for (Ada, with tax dollars),
> while they ditch it for inferior tools. Worse, later their own
> technology (Ada) could end up being used against them.

It's not ironic, it's traditional way (believe me -;) .
It is a big advantage of being well behind the leader: you *know*
what is good and what is bad at your current stage, from the leader's
experience, and you can relatively easily use the leader's past
technological achievements.

But don't worry too much, because there is another effect also:
when a competitor, which uses this tactics extensively, approaches
the leader (that is, the distance to the leader becomes relatively
small) then the competitor loses perspective, and starts to experience
severe burdens, for which he is not prepared. As a consequence his
behaviour becomes essentially random, self-contradictory, and overall
stupid. The probable finale of that behaviour is a crash, which
comes one way or another, and can be softer or harder, depending of
various circumstances.



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

Re: Is the Writing on the Wall for Ada?

[Warren W. Gay VE3WWG]

Alexander Kopilovitch wrote:
> "Warren W. Gay wrote:
...
> But don't worry too much, because there is another effect also:
> when a competitor, which uses this tactics extensively, approaches
> the leader (that is, the distance to the leader becomes relatively
> small) then the competitor loses perspective, and starts to experience
> severe burdens, for which he is not prepared. As a consequence his
> behaviour becomes essentially random, self-contradictory, and overall
> stupid. The probable finale of that behaviour is a crash, ...

So is this your prediction for Linux, as it approaches M$? ;-)

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Is the Writing on the Wall for Ada?

[Jeffrey Creem]

It makes sense that the DoD would really start to switch to C++ or Java now
that
the writing is on the wall that these two technologies are no longer
the ones that will grace the front page of Information Week :)


Is Java Finished?
http://story.news.yahoo.com/news?tmpl=story2&u=/nf/20030904/tc_nf/22216&e=5

Unless you are an Ada vendor and you see your market share drying up, I
would not worry one
way or another.

A few years ago (during the .com boom) there was an engineer who was leaving
because he
was afraid to only have C and Ada experience. While not having a broad
experience base can be
somewhat of an issue it is not nearly as bad as people think.

During the boom times, you could get a job no matter what since people would
hire anyone that had
a pizza stain on their shirt (must be a programmer)..

During the bust times there are so many people available with the "right"
language on their resume that
having it on yours does not really change anything about the equation.


As much as I like Ada and think it can help projects be successful, it has
been my experience that
projects get into trouble for other reasons far more often then they get
into trouble for picking the
wrong language.....(requirements and hidden scope growth being the big two).

Re: Is the Writing on the Wall for Ada?

[David Emery]

Warren W. Gay VE3WWG wrote:
> This is not a troll... but I am soliciting some opinion.
> 
> I read a disturbing article in the July COTS Journal recently,
> and thought I would bounce the controversial aspects off
> of the group. The complete article can be read at:
> 
>   http://www.cotsjournalonline.com/pdfs/2003/07/COTS07_softside.pdf

My take on this article is that much of the information in it is
incorrect.  The language preference for FCS is C++, not Java, although
any JTA-Army approved language is OK (including Ada95).

In many respects, the piece reads as a marketing piece for the RT
Java efforts, applying a combination of truth (occasionally selective),
FUD and wishful thinking about what RT Java -could be- versus what
Ada -has already been.-

But since few langauge decisions are made on facts, this article's
absence of facts just goes with the flow...

I'm firmly convinced that a big part of Java's perceived success or
potential success in the real-time and safety critical area is more as
a response to the disaster that is C++, than to any particular informed
knowledge about Ada.

Certainly, faced with the choice of (only) C++ and Java, I'd generally
prefer Java.  But if I have to do something that must really work, I'd
prefer SPARK, Ada95, Ada83 and C (using one of the 'safe C' dialects).

			dave

Re: Is the Writing on the Wall for Ada?

[Alexander Kopilovitch]

David Emery wrote:

> Certainly, faced with the choice of (only) C++ and Java, I'd generally
> prefer Java.  But if I have to do something that must really work, I'd
> prefer SPARK, Ada95, Ada83 and C (using one of the 'safe C' dialects).

Something is wrong in above paragraph. It seems that in the first sentence
in it you presume that you are faced with the choice of C++ and Java for some
product, which need not really work. But what will be your choice between C++
and Java if the resulting product must really work? I can hardly believe that
you will still choose Java (given, by the way, that all libraries you may use
will be also from Java world in that case).



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

Re: Is the Writing on the Wall for Ada?

[William J. Thomas]

If you read between the lines its all hype. I know I've seen this type of
hype before in the early 80's associated with a language named Ada.

From the article you notice that the Java real time community is already
split into two different camps, and it looks like they are starting up a
third to unite the two. Well, that certainly should fix things! What that
really means is that the Java community is not all on the same page when it
comes to making their "Web Page Safe Language" a real time contender.

Let face it, if you wanted to you could probably make COBOL real-time if you
nailed enough "real-time" specs to it. I mean when Java first came wasn't it
touted as being the "safe" language that you would allow code to be
downloaded onto your system via your web page/http connection?  This was a
language that was not supposed to know about hardware, or addresses, or
interrupts, it also took out the garbage for you, so you could be as sloppy
as you wanted, give me a break. Now they have committees up the wazoo trying
to take the language in the completely opposite direction!!!

And what ever happened to all the concern about standardization? C# is even
an ECMA standard and will most likely end up an ISO standard. Who owns Java,
Sun, well who could ask for more stability than that. If you look on the web
for Java real-time solutions you will soon find yourself swimming in a sea
of incompatibility, and proprietary techonology.

Lets face it, the military (or should I say the individual services or
should I say any organization that pays the bills) could give a rats ass on
what things are coded in, the only thing they want to see are cheap
applications and that translates to cheap software engineers. It's not going
to matter WHAT language its coded in as much as WHERE its coded and by
WHOM!!!

Software Engineers don't come cheap in America, they come cheap in places
like China and India. If you want to know what the software landscape is
going to be like in 10 (make that 7) years just ask those folks, their the
one's that are going to be coding it!!!

William J. Thomas

Re: Is the Writing on the Wall for Ada?

[Alexander Kopilovitch]

William J. Thomas wrote:

> Software Engineers don't come cheap in America, they come cheap in places
> like China and India. If you want to know what the software landscape is
> going to be like in 10 (make that 7) years just ask those folks, their the
> one's that are going to be coding it!!!

Do you think that those software engineers in China and India will be cheap
(and easily available in arbirary quantities) forever? Think about 7-10 years
ahead. Don't forget some projects need quite long maintenance - and Ada is
oriented mainly at those projects.



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

Re: Is the Writing on the Wall for Ada?

[Robert I. Eachus]

Alexander Kopilovitch wrote:

> Do you think that those software engineers in China and India will be cheap
> (and easily available in arbirary quantities) forever? Think about 7-10 years
> ahead. Don't forget some projects need quite long maintenance - and Ada is
> oriented mainly at those projects.

(I am going to say some pretty nasty sounding things, but they all have 
to do with external factors and experience.  I know from experience that 
there are bright, modivated, and well educated people everywhere.  But 
that matters less than you might think.)

The idea of exporting Software Engineering jobs seems great on paper, 
but it never works in practice.  It actually turns out that with low 
enough telecommunications costs, exporting support jobs and other roles 
that require people skills is easier.

The problem is that Software Engineering is not amenable to classroom 
teaching.  No, that is not right.  Programming can be taught in the 
classroom, not well, but since most good programmers are mostly 
self-taught anyway, it is not a big deal.  The classroom provides at 
best certification.

But with true Software Engineering, which is not about programming, you 
have to have three things: easy access to computer hardware while 
learning to program, a mentor, and the experience of working on a large, 
difficult project with competant people early in your career.  This 
environment has not been available in the third world, and in fact most 
of the old second world until recently.  When will there be enough 
software engineers available for mentoring?  I don't know, but in my 
career I have mentored perhaps seven or eight individuals.  Two were 
almost instantly capable of mentoring others on their own.

The others? Some of them did not have the personality for mentoring. 
But for the rest, I have to describe it in the old craft idiom, because 
software engineering should be treated as a craft, since it clearly is 
one.  As I said two of the best who learned software engineering from me 
were clearly going to reach master status soon.  The others were 
journeymen.  Could they eventually become masters?  I think so, but it 
was going to take a decade or more.

So as far as I am concerned, it is possible for someone to become a 
master of software engineering without the gift for teaching.  But it is 
tough, because teaching is really one of the key skills needed for the 
job.  Part of what a software engineer--as opposed to a programmer with 
the same title--does is develop a style which is appropriate for the 
type of job being done, and then teaching that style to the rest of the 
team.  I am not talking about indentation, variable naming and the like. 
  That is just detail.  I am talking about real software architecture, 
designing a system which will satisfy the requirements and also be 
something that humans who maintain or use the system will enjoy. (Enjoy 
is a much higher standard than "be comfortable with."  But it is one of 
the signs of a good system architecture.

Now this doesn't say that someone in India or Pakistan can't develop a 
style which people in the United States will be comfortable with.  It is 
just that the inevitable culture clash between the people on the project 
in the US and the foreign development team will create additional 
problems.  (And if the only people on the project in the US are 
managers, that clash will probably cause insurmountable problems.)  So 
what does work, and I have seen it work, is for a software engineer from 
India or whereever to become Americanized (or Europeanized) and serve as 
a buffer and interface between the two part of the project.

So the net result is that the cases where I have seen the process 
working, you wind up with, say, a joint Indian and American development 
team, and the team members go to the extra? effort to learn one 
another's culture.  Otherwise you can wind up with a system bought and 
paid for, where you literally have to send your staff abroad for 
training in how to use it.  That doesn't save much money.

And yes, when I try to explain this to most managers, it is like 
explaining the color red to a blind man.  You would think that by now 
everyone would have had experience with foreign interfaces to understand 
the issue.  But most managers for some reason seem to accept their 
inability to program their VCRs without understanding why the interface 
is that bad.  (I have used well designed VCRs, but they were designed 
and built as studio equipment by people who had experience working in a 
studio environment...)

-- 
                                            Robert I. Eachus

"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: Is the Writing on the Wall for Ada?

[Alexander Kopilovitch]

Robert I. Eachus wrote:

>But with true Software Engineering, which is not about programming,

Being a programmer, and not a software engineer, I'm very pleased to see this
clear distinction. During about 10 years I often tried to explain for various
people and in various situations that a programmer and a software engineer
aren't the same, that these must have different (although with substantial
intersection) skills and different spirit... different priorities and different
goals. Certainly they are neighbours (say, like a physicist and a chemist -;) ,
and they may be good neighbours and somehow understand and help each other.
They even can emulate each other, but almost always with some degradation in
rank (there are exceptions, though -:) . Only recently (perhaps about 2 years)
I began to meet (occasionally) similar viewpoint.

> as far as I am concerned, it is possible for someone to become a 
> master of software engineering without the gift for teaching.  But it is 
> tough, because teaching is really one of the key skills needed for the 
> job.  Part of what a software engineer--as opposed to a programmer with 
> the same title--does is develop a style which is appropriate for the 
> type of job being done, and then teaching that style to the rest of the 
> team.  I am not talking about indentation, variable naming and the like. 
> That is just detail.  I am talking about real software architecture, 
> designing a system which will satisfy the requirements and also be 
> something that humans who maintain or use the system will enjoy. (Enjoy 
> is a much higher standard than "be comfortable with."  But it is one of 
> the signs of a good system architecture.

Yes, I think that developing of a style and teaching that style the team is
very important for software engineering. The style creates a medium (and/or
"carrier wave") in which internal (within the team) informational protocols
emerge and exist. And which is especially important for maintenance, significant
parts of those mediums and protocols are recoverable afterwards.

> Now this doesn't say that someone in India or Pakistan can't develop a 
> style which people in the United States will be comfortable with.  It is 
> just that the inevitable culture clash between the people on the project 
> in the US and the foreign development team will create additional 
> problems.  (And if the only people on the project in the US are 
> managers, that clash will probably cause insurmountable problems.)  So 
> what does work, and I have seen it work, is for a software engineer from 
> India or whereever to become Americanized (or Europeanized) and serve as 
> a buffer and interface between the two part of the project.

Just for coloring this your statement (which is certainly true) here is a
funny story: an old friend of mine, a true software engineer (despite his
pure mathematical education), who moved to USA 12 years ago and now work for
one of so-called "giants" (which naturally have divisions in India), once wrote
me (I translate from Russian): "Sometimes I receive a mail from one of those
Indians, and after brief reading my first thought is to reply him: guy, first
learn to cut your nails, and only after that try to approach a programming...
but then I recall you, and reread the mail - and discover that the guy is not
so stupid and dirty, in fact he wrote something quite reasonable."



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

Re: Is the Writing on the Wall for Ada?

[Robert I. Eachus]

Alexander Kopilovitch wrote:

> Just for coloring this your statement (which is certainly true) here is a
> funny story: an old friend of mine, a true software engineer (despite his
> pure mathematical education), who moved to USA 12 years ago and now work for
> one of so-called "giants" (which naturally have divisions in India), once wrote
> me (I translate from Russian): "Sometimes I receive a mail from one of those
> Indians, and after brief reading my first thought is to reply him: guy, first
> learn to cut your nails, and only after that try to approach a programming...
> but then I recall you, and reread the mail - and discover that the guy is not
> so stupid and dirty, in fact he wrote something quite reasonable."

Exactly.  It is often the case that I will look at an issue brought to 
the ARG and my software engineering tendancies get in the way.  I have 
to turn that off, and reread everything ignoring style and other 
cultural values.  And this is in Ada, where there is a fairly homogenous 
programming style.

The problem is when you run into managers who are not used to abstract 
domains, and have to try to explain why a common culture is important to 
a project.  (Again, this has nothing to do, as such, with ethnic 
background.)  I worked on one project where we had a very eclectic 
group, one person from Nigeria, one from China, a third from England, 
and a fourth was from Russia.  The rest of the team was from America. 
We all had problems with the Russian that had nothing to do with his 
background AFAIK.

We has rules for checking in software, and he would on a fairly regular 
basis run the full regression suite on some revision he made, and find a 
bug.  He would then fix the bug and check the software in without 
re-running the regression suite.

This was a serious problem, especially once we had real users for the 
compiler we were creating.  Fortunately the RCS would allow us to back 
out his changes when the bug fix didn't work or created new problems. 
The problem was not that he made mistakes, we all did.  But that 
particular repeated mistake on several occasions led to other team 
members bypassing the RCS and using a "known good" version of the 
semantic analysis code.

-- 
                                              Robert I. Eachus

"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: Is the Writing on the Wall for Ada?

[Alexander Kopilovitch]

Robert I. Eachus wrote:

> I worked on one project where we had a very eclectic 
> group, one person from Nigeria, one from China, a third from England, 
> and a fourth was from Russia.  The rest of the team was from America. 
> We all had problems with the Russian that had nothing to do with his 
> background AFAIK.
>
> We has rules for checking in software, and he would on a fairly regular 
> basis run the full regression suite on some revision he made, and find a 
> bug.  He would then fix the bug and check the software in without 
> re-running the regression suite.
>
> This was a serious problem, especially once we had real users for the 
> compiler we were creating.  Fortunately the RCS would allow us to back 
> out his changes when the bug fix didn't work or created new problems. 
> The problem was not that he made mistakes, we all did.  But that 
> particular repeated mistake on several occasions led to other team 
> members bypassing the RCS and using a "known good" version of the 
> semantic analysis code.

It was not me! -:)  Just because I never been in America and never
participated in construction of a compiler. -;) And after all, I usually
do not make the same procedural mistake more then twice, one repetition
usually is enough for me, after it the mistake typically is recognized,
analyzed, generalized and eliminated or suppressed -;) .

Seriously, I am absolutely not surprised with that you story, and with
the behaviour of the Russian character in it - I saw similar patterns
very many times in former Soviet Union, and I certainly was myself
subjected to many such things until recently. Now, after acquiring
some experience of working with Americans, I'm much more careful about
the procedural aspects of joint work... not because I believe in their
importance *for my part of work*, but just for not annoying my partner
or customer.

Well, a culture, and in particular, software culture, reflects the
real circumstances. You will not invest your efforts in building and
maintenance of an infrastructure and working procedures if all that
may and will be easily destroyed by overwhelming and wild external
forces at any moment. And what is even worse, those things easily may
be taken from you and went under hostile control. So, in generally
unprotected and sometimes even hostile enviroment many good and skilled
people (who were raised in that environment) naturally use only minimal
infrastructure and minimize formal procedures... and sometimes even
add random elements to their "procedural behaviour". And that strategy
proves itself one of the best *in that enviroment* - it protects the
work by making real progress almost invisible until the results
become too solid and significant and therefore it is too late for
attempts to harm or stop the project. (Another good strategy, which
was possible occasionally, was "lightning"; with this strategy you
simply make all the work in very short period of time, say, one month
instead of 6 months or a year... but it worked only if the results
were badly needed by high management of the enterprise.)

But all above mostly sank in the past (rather quickly, during recent
decade). The Western software engineering *popular* methods, procedures
and working environment become widely known in Russia, and many people
here acquired some experience with all that. Moreover the general
working environment changes radically, and it does not reproduce
anymore a negligence for working infrastructure and working procedures...
partly because many companies here are owned (at least partially) by
Westerners (or are divisions of American or Europian companies), partly
because new generation of native managers everywhere here tries to
imitate Western practices.

Needless to say, all that is still acquired and not native culture.
So, the formalities and tools came first, while the essence largely
still did not arrive here... and those procedural issues are, perhaps,
still more like a fashionable and required game then a way of life.
But nevertheless, a significant part of a cultural adaptation is
already done here.



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

Re: Is the Writing on the Wall for Ada?

[Robert I. Eachus]

Alexander Kopilovitch wrote:

> It was not me! -:)  Just because I never been in America and never
> participated in construction of a compiler. -;) And after all, I usually
> do not make the same procedural mistake more then twice, one repetition
> usually is enough for me, after it the mistake typically is recognized,
> analyzed, generalized and eliminated or suppressed -;) .
> 
> Seriously, I am absolutely not surprised with that you story, and with
> the behaviour of the Russian character in it - I saw similar patterns
> very many times in former Soviet Union, and I certainly was myself
> subjected to many such things until recently. Now, after acquiring
> some experience of working with Americans, I'm much more careful about
> the procedural aspects of joint work... not because I believe in their
> importance *for my part of work*, but just for not annoying my partner
> or customer.

I know it wasn't you, but I didn't want to name the individual.  And as 
you say, his original style of work was very typical for Russians.  Not 
a problem--if you can adapt to the actual culture of the current 
project.  If you can't, eventually your conflict with the project style 
will outweigh the contributions you can and do make.

Incidently what Alexander was explaining as typical Russian style is not 
necessarily Russian.  At MITRE we found that there was a significant 
change in culture among development teams when the computer resources 
reached one MIPS per person.  Of course, that was ten years ago, today 
the requirement for an open culture is probably just a network connected 
computer on every desk.

It turns out that the advantage of the RCS (revision control system) and 
open--everyone has access to the latest versions of everyone else's 
code--comes from minimizing the number of versions of a single module 
floating around.  The best situation is when there is only one "checked 
out" version of any source file outside the RCS.  This means that 
programmers need to share access to their working directories.  That is 
a real culture change for many programmers, and it doesn't come easy.

--
                                           Robert I. Eachus

"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: Is the Writing on the Wall for Ada?

[Alexander Kopilovitch]

Robert I. Eachus wrote:

> > ... I am absolutely not surprised with that you story, and with
> > the behaviour of the Russian character in it - I saw similar patterns
> > very many times in former Soviet Union, and I certainly was myself
> > subjected to many such things until recently. Now, after acquiring
> > some experience of working with Americans, I'm much more careful about
> > the procedural aspects of joint work... not because I believe in their
> > importance *for my part of work*, but just for not annoying my partner
> > or customer.
>
> ... as you say, his original style of work was very typical for Russians.

Just one addition: I forgot to mention that although those elements of style
was indeed widespread among Russian programmers, but that pertains to *male*
programmers only. Female programmers very rarely exhibited those characteristics
- usually they followed all required procedures quite strictly.

I think that explanation of this difference is that female programmers,
as a rule, are *emotionally* distracted from the essence of their current
programming work. They easily may be emotionally engaged in the details, but
usually not in the essence.

That correlation (between the emotional engagement in the essence of current
programming work and negligence for *externally established* procedures)
is general, I think, and it surely does not depend on gender.

So, that past trend in behaviour of male Russian programmers probably should
be considered as a consequence as their (statistically) relatively higher
emotional engagement in the essence of current programming work. That was not
depend on skills, and only slightly depended on experience - that was true
cultural phenomena.

And in turn, that higher emotional engagement in the essence of current job,
may be explained, at least partially, by the fact that better working performance
in Soviet Union usually did not cause significant difference in one's material
life. Therefore it seems quite natural that many (more or less) intellectually
developed males used the essence of their work as emotionally charged value.

> Not a problem--if you can adapt to the actual culture of the current 
> project.  If you can't, eventually your conflict with the project style 
> will outweigh the contributions you can and do make.

That's it. 4 years ago I observed that process myself, in all details.
I joined a local division of one Danish company. Naturally, they tried to
immerse me in their project culture. I must admit, they tried hard. And as
I was that time in quite desperate financial position, I also tried hard.
But nevertheless we all failed, the cultures appeared totally incompatible,
and after 5 months all that nightmare came to the end. Not that I violated
their procedures - no, I was very accurate with all that, but the fatal
incompatibility emerged another way.

That even was not programming as such, it was design stage, and my job was
to design a part of the system and write the design documents. I wrote the
documents, and then nightmare began. They said that they like my writing
style but disagree with the design approach. Well, we discussed the issues,
and then I reworked the design. With the same result. After 3rd or 4th
iteration I began to hate them (first time in my life... I never knew what is
a true personal hate before that).

When all that unpleasant adventure ended and I relaxed, I concluded that
they really have no need in any particular design, they wanted some process,
not a result (at least at that stage). My fault was that I did not recognize
that (rather usual) thing. And that was exactly the cultural difference
that made me blind - I misinterpeted obvious symptoms, and went into
false interpretation quite deeply. For example, I took many of their phrases
at face value (or almost that way) just because those phrases were said in
foreign language and by good-looking persons... I could never make such
mistakes with the people that belong to my native culture.



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

Re: Is the Writing on the Wall for Ada?

[Dmytry Lavrov]

Alexander Kopilovitch wrote:
> 
> Robert I. Eachus wrote:
> 
> > > ... I am absolutely not surprised with that you story, and with
> > > the behaviour of the Russian character in it - I saw similar patterns
> > > very many times in former Soviet Union, and I certainly was myself
> > > subjected to many such things until recently. Now, after acquiring
> > > some experience of working with Americans, I'm much more careful about
> > > the procedural aspects of joint work... not because I believe in their
> > > importance *for my part of work*, but just for not annoying my partner
> > > or customer.
> >
> > ... as you say, his original style of work was very typical for Russians.
> 
> Just one addition: I forgot to mention that although those elements of style
> was indeed widespread among Russian programmers, but that pertains to *male*
> programmers only. Female programmers very rarely exhibited those characteristics
> - usually they followed all required procedures quite strictly.
> 
> I think that explanation of this difference is that female programmers,
> as a rule, are *emotionally* distracted from the essence of their current
> programming work. They easily may be emotionally engaged in the details, but
> usually not in the essence.
> 
> That correlation (between the emotional engagement in the essence of current
> programming work and negligence for *externally established* procedures)
> is general, I think, and it surely does not depend on gender.
> 
> So, that past trend in behaviour of male Russian programmers probably should
> be considered as a consequence as their (statistically) relatively higher
> emotional engagement in the essence of current programming work. That was not
> depend on skills, and only slightly depended on experience - that was true
> cultural phenomena.
> 
> And in turn, that higher emotional engagement in the essence of current job,
> may be explained, at least partially, by the fact that better working performance
> in Soviet Union usually did not cause significant difference in one's material
> life. Therefore it seems quite natural that many (more or less) intellectually
> developed males used the essence of their work as emotionally charged value.
> 
> > Not a problem--if you can adapt to the actual culture of the current
> > project.  If you can't, eventually your conflict with the project style
> > will outweigh the contributions you can and do make.
> 
> That's it. 4 years ago I observed that process myself, in all details.
> I joined a local division of one Danish company. Naturally, they tried to
> immerse me in their project culture. I must admit, they tried hard. And as
> I was that time in quite desperate financial position,
like i'm now.

 I also tried hard.
> But nevertheless we all failed, the cultures appeared totally incompatible,
> and after 5 months all that nightmare came to the end. Not that I violated
> their procedures - no, I was very accurate with all that, but the fatal
> incompatibility emerged another way.
> 
> That even was not programming as such, it was design stage, and my job was
> to design a part of the system and write the design documents. I wrote the
> documents, and then nightmare began. They said that they like my writing
> style but disagree with the design approach. Well, we discussed the issues,
> and then I reworked the design. With the same result. After 3rd or 4th
> iteration I began to hate them (first time in my life... I never knew what is
> a true personal hate before that).
> 
> When all that unpleasant adventure ended and I relaxed, I concluded that
> they really have no need in any particular design, they wanted some process,
> not a result (at least at that stage). My fault was that I did not recognize
> that (rather usual) thing. And that was exactly the cultural difference
> that made me blind - I misinterpeted obvious symptoms, and went into
> false interpretation quite deeply. For example, I took many of their phrases
> at face value (or almost that way) just because those phrases were said in
> foreign language and by good-looking persons... I could never make such
> mistakes with the people that belong to my native culture.
> 
> Alexander Kopilovitch                      aek@vib.usr.pu.ru
> Saint-Petersburg
> Russia

Main problem that ANYWHERE development are "same" as in russia:sometimes
absolutely no need in some work,but you should _simulate_ the working
process(it does not happen only in really small companies,ex. 5
persons).Result of incorrect management.
And "escaped" Russian think that in Danish company there are something
different.

Re: Is the Writing on the Wall for Ada?

[Dmitry A. Kazakov]

On 12 Sep 2003 19:23:11 -0700, aek@vib.usr.pu.ru (Alexander
Kopilovitch) wrote:

>That even was not programming as such, it was design stage, and my job was
>to design a part of the system and write the design documents. I wrote the
>documents, and then nightmare began. They said that they like my writing
>style but disagree with the design approach. Well, we discussed the issues,
>and then I reworked the design. With the same result. After 3rd or 4th
>iteration I began to hate them (first time in my life... I never knew what is
>a true personal hate before that).

You have rammed at "consensus culture" wide spread in the northern
areas of EU. The idea is that all problems have to solved through a
consensus, but of course in the way the leading persons decide. (:-))
So they never tell you what and how, otherwise it would violate the
consensus rules! You have to *guess* the boss' idea and
enthusiastically roll it up and thus reach the consensus.

>When all that unpleasant adventure ended and I relaxed, I concluded that
>they really have no need in any particular design, they wanted some process,
>not a result (at least at that stage). My fault was that I did not recognize
>that (rather usual) thing. And that was exactly the cultural difference
>that made me blind - I misinterpeted obvious symptoms, and went into
>false interpretation quite deeply. For example, I took many of their phrases
>at face value (or almost that way) just because those phrases were said in
>foreign language and by good-looking persons... I could never make such
>mistakes with the people that belong to my native culture.

Which is an army-like one. The boss does not care about any consensus:
"Ich bin der Boss, du bist nix!". Russian equivalent is "I am the boss
you are a fool". It makes things much easier, but it is so awfully
undemocratic... (:-))

Alas to EU and Russia, neither of the mentioned "cultures" work good
in science and software developing. I cannot tell which one Americans
or Asians use.

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

Re: Is the Writing on the Wall for Ada?

[Dmitry A. Kazakov]

On Sat, 6 Sep 2003 17:47:06 -0400, "Warren W. Gay VE3WWG"
<ve3wwg@cogeco.ca> wrote:

>I read a disturbing article in the July COTS Journal recently,

[...]

No comments, but a question to the news group.

What is the status of JGNAT? Is there any activity to revive it, on a
volunteer basis perhaps. IMO it was a mistake to abadon it. The reason
is that though JVM is close to useless, it could be a great lever to
persuade customers to switch to Ada. The main obstacle with our
customers is unavailability of Ada compilers for many platforms. They
will not appear without customer demands. And there will be no such
demands, I know my customers. At the same time many of these potential
platforms have JVM. The rest is clear, I suppose.

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

Re: Is the Writing on the Wall for Ada?

[Alexander Kopilovitch]

Dmitry A. Kazakov wrote:

> though JVM is close to useless, it could be a great lever to
> persuade customers to switch to Ada. The main obstacle with our
> customers is unavailability of Ada compilers for many platforms. They
> will not appear without customer demands. And there will be no such
> demands, I know my customers. At the same time many of these potential
> platforms have JVM. The rest is clear, I suppose.

Why take all the mess and inefficiency of that JVM? Why not use Ada-to-C
translation step? As far as I understand, the SofCheck has and can supply
you that technology/toolset. And you may tell your customers that this is
simply a great way to achive both goodies in one bottle: good high-level OO
language for development and maintenance, and at the same time fashionable
restricted C for deployment on targets.



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

Re: Is the Writing on the Wall for Ada?

[Peter Amey]

Alexander Kopilovitch wrote:
> Dmitry A. Kazakov wrote:
[snip]
> 
> Why take all the mess and inefficiency of that JVM? Why not use Ada-to-C
> translation step? As far as I understand, the SofCheck has and can supply
> you that technology/toolset. And you may tell your customers that this is
> simply a great way to achive both goodies in one bottle: good high-level OO
> language for development and maintenance, and at the same time fashionable
> restricted C for deployment on targets.

Yes! And if the source is SPARK, and you have done a proof of exception 
freedom you get the added bonus that the mapping from Ada (the design 
language) to C (the portable intermediate language) is extremely 
transparent and reviewable.  The two step process makes object code 
verfication much simpler as well.

Peter

Re: Is the Writing on the Wall for Ada?

[Dmitry A. Kazakov]

On 8 Sep 2003 12:50:45 -0700, aek@vib.usr.pu.ru (Alexander
Kopilovitch) wrote:

>> though JVM is close to useless, it could be a great lever to
>> persuade customers to switch to Ada. The main obstacle with our
>> customers is unavailability of Ada compilers for many platforms. They
>> will not appear without customer demands. And there will be no such
>> demands, I know my customers. At the same time many of these potential
>> platforms have JVM. The rest is clear, I suppose.
>
>Why take all the mess and inefficiency of that JVM? Why not use Ada-to-C
>translation step? As far as I understand, the SofCheck has and can supply
>you that technology/toolset. And you may tell your customers that this is
>simply a great way to achive both goodies in one bottle: good high-level OO
>language for development and maintenance, and at the same time fashionable
>restricted C for deployment on targets.

They are managers, you know. Sometimes talking with them I am thinking
that all stoies about Martians capturing humans, washing them brains
and then returning them back are true. Managers are those returned! Or
maybe dressed Martians. (:-)) Today they keep on wanting Java. That's
it.

Seriosly, one good thing about JVM has is a large library of widgets
and communication protocols. To convince a manager your demo
application should have all that and works on his PDA. Once you get a
contract, you can slowly drag them into the right direction. But only
then.

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

Re: Is the Writing on the Wall for Ada?

[Alexander Kopilovitch]

Dmitry A. Kazakov wrote:

> >Why take all the mess and inefficiency of that JVM? Why not use Ada-to-C
> >translation step? As far as I understand, the SofCheck has and can supply
> >you that technology/toolset. And you may tell your customers that this is
> >simply a great way to achive both goodies in one bottle: good high-level OO
> >language for development and maintenance, and at the same time fashionable
> >restricted C for deployment on targets.
> 
> They are managers, you know. Sometimes talking with them I am thinking
> that all stoies about Martians capturing humans, washing them brains
> and then returning them back are true. Managers are those returned! Or
> maybe dressed Martians. (:-)) Today they keep on wanting Java. That's
> it.

Well, even if they are Martians that doesn't matter - why not export our
products to Mars, or via Mars? They still will pay in a currency, which
is valid here on Earth. And Mars do not pose an immediate threat.

Actually, they do not want specifically Java - they want fashionable
things, and no more. And furthemore, they want fashionable things just
because they consider them as relatively safe things. They are responsible
for decisions (or at least for propositions, which may lead to decisions),
so they feel themselves liable for future failures. And they know well,
that the punishment for a failure probably will be heavier if the
decision resulted in the failure somehow deviated from a perceived
"industry standard". They know that probably nobody will investigate
the details and motives, but instead the manager will be found guilty
for failure to maintain the industry standart (or state-of-art).
So, a manager will agree to deviate from a fashionable thing only if
he thinks that the *weighted" risk for him will be lower with this
deviation. Alternatively, you may provide him a solid argumentation
(which he find satisfactory for the possible future self-defence)
for that you propose is not a deviation, but actually the true
industry standard for the case.

> Seriosly, one good thing about JVM has is a large library of widgets
> and communication protocols. To convince a manager your demo
> application should have all that and works on his PDA. Once you get a
> contract, you can slowly drag them into the right direction. But only
> then.

Well, so you, perhaps, should separate application's "front-end"
from the application's "engine" in your overall design, and then
give that "front-end" to some cheap subcontractors, giving then
your specifications *in Ada* (they will quickly learn some Ada
for that, because that will be part of their work, and you know
that this is not difficult for cheap subcontractors -:), and
monitoring them with your QA. Those subcontractors will provide
you that "front-end" in Java for demo and prototyping purposes,
while you will be free from all that mess. And for those customer's
managers you may explain that your technology is a great combination
of a solid software engineering methods and technique for fundamental
issues of the project and a modern, state-of-art (Java) technology
for data communication and data presentation.



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

Re: Is the Writing on the Wall for Ada?

[Dmitry A. Kazakov]

On 9 Sep 2003 17:53:33 -0700, aek@vib.usr.pu.ru (Alexander
Kopilovitch) wrote:

>> >Why take all the mess and inefficiency of that JVM? Why not use Ada-to-C
>> >translation step? As far as I understand, the SofCheck has and can supply
>> >you that technology/toolset. And you may tell your customers that this is
>> >simply a great way to achive both goodies in one bottle: good high-level OO
>> >language for development and maintenance, and at the same time fashionable
>> >restricted C for deployment on targets.
>> 
>> They are managers, you know. Sometimes talking with them I am thinking
>> that all stoies about Martians capturing humans, washing them brains
>> and then returning them back are true. Managers are those returned! Or
>> maybe dressed Martians. (:-)) Today they keep on wanting Java. That's
>> it.
>
>Well, even if they are Martians that doesn't matter - why not export our
>products to Mars, or via Mars? They still will pay in a currency, which
>is valid here on Earth.

Yep.

>And Mars do not pose an immediate threat.

Enron, Worldcom, Deutsche Telecom, uncounted DOT-COM companies;
Mission critical software in Visual Basic; even NASA have admitted
problems with management. Isn't that a threat?

>Actually, they do not want specifically Java - they want fashionable
>things, and no more.

It was partially true three years ago, but presently there is too
little resources to spend them on bells and whistles.

>And furthemore, they want fashionable things just
>because they consider them as relatively safe things. They are responsible
>for decisions (or at least for propositions, which may lead to decisions),
>so they feel themselves liable for future failures. And they know well,
>that the punishment for a failure probably will be heavier if the
>decision resulted in the failure somehow deviated from a perceived
>"industry standard". They know that probably nobody will investigate
>the details and motives, but instead the manager will be found guilty
>for failure to maintain the industry standart (or state-of-art).

In most cases they do want a real and necessary thing. And they want
this thing for less money and yesterday. For what ever reason, they
are convinced that a funny technology X will save the money and time.
So either you have to come with this technology, or to present
something already working in a way they understand as "working". The
best way to do both.

This is why in my view Ada-to-JVM and Ada-to-DOT-NET should be on the
top of priority list to make Ada popular. An alternative could be Ada
virtual machine and Ada OS, but they are out of sight.

>So, a manager will agree to deviate from a fashionable thing only if
>he thinks that the *weighted" risk for him will be lower with this
>deviation.

He will never agree. "Never try to convince a manager." This is the
first law of management. (:-))

>Alternatively, you may provide him a solid argumentation
>(which he find satisfactory for the possible future self-defence)
>for that you propose is not a deviation, but actually the true
>industry standard for the case.

The second law is "Do whatever you have to".
And the third law is "Things you are doing should convince a manager
that he had convinced you"

>> Seriosly, one good thing about JVM has is a large library of widgets
>> and communication protocols. To convince a manager your demo
>> application should have all that and works on his PDA. Once you get a
>> contract, you can slowly drag them into the right direction. But only
>> then.
>
>Well, so you, perhaps, should separate application's "front-end"
>from the application's "engine" in your overall design, and then
>give that "front-end" to some cheap subcontractors, giving then
>your specifications *in Ada* (they will quickly learn some Ada
>for that, because that will be part of their work, and you know
>that this is not difficult for cheap subcontractors -:), and
>monitoring them with your QA. Those subcontractors will provide
>you that "front-end" in Java for demo and prototyping purposes,
>while you will be free from all that mess.

Where you saw cheap subcontractors? (:-))

>And for those customer's
>managers you may explain that your technology is a great combination
>of a solid software engineering methods and technique for fundamental
>issues of the project and a modern, state-of-art (Java) technology
>for data communication and data presentation.

Nobody will allow you to do same thing twice. The customer will fire
you if he discover how you spend his money. In most cases they wish a
precise control over how many people are working on the project and
what exactly they are doing. I never saw a customer, who would say,
here is NN bucks and X is the deadline. That would be an end of the
world we live in. (:-))

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

Re: Is the Writing on the Wall for Ada?

[Marin David Condic]

Anyone wishing to bitch about management ought to be required to show 
credentials as having had a turn in the driver's seat. ;-) Its really 
easy to sit back and criticize while not being the one who has the 
responsibility for schedule, budget, personnel, etc. Every decision can 
be second-guessed and the guy who works for you always knows that it is 
intuitively obvious to even the most casual observer that whatever 
decision you made, it is wrong. You don't have control over much of what 
goes on around you but you have full resopnsibility for the ultimate 
outcome.

If one wants to understand why bureaucracies and large organizations do 
stupid things from time to time, one need look no further than the 
Bible. Try the part about the Tower of Babel. The universe seems to be 
structured such that large groups of people aren't capable of working 
efficiently towards a common objective. Probably this is a good thing - 
or tyrants would be unstopable.

As for the languages being selected for a lot of these projects? There 
are probably lots of factors (technical and business) that are figuring 
into the decisions that are not obvious from the outside. Ultimately, 
you can build good software in any language - if you're willing to incur 
the costs associated with shoring up the weaknesses of the given 
language. So its possible that for a given mission critical piece of 
software, Visual Basic may have been the right choice. Its impossible to 
say without knowing all the surrounding factors.

MDC


Dmitry A. Kazakov wrote:
> 
> 
> Enron, Worldcom, Deutsche Telecom, uncounted DOT-COM companies;
> Mission critical software in Visual Basic; even NASA have admitted
> problems with management. Isn't that a threat?
> 
> 



-- 
======================================================================
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: Is the Writing on the Wall for Ada?

[Dmitry A. Kazakov]

On Wed, 10 Sep 2003 12:36:50 GMT, Marin David Condic
<nobody@noplace.com> wrote:

>As for the languages being selected for a lot of these projects? There 
>are probably lots of factors (technical and business) that are figuring 
>into the decisions that are not obvious from the outside.

Which in effect would indulge any decision made. Who are the outsiders
to judge us? etc. After all the outsiders are the tax payers. Maybe,
if a politician, manager, programmer is unable to explain his
decisions without references to astral bodies he/she should better
find another job.

>Ultimately, 
>you can build good software in any language - if you're willing to incur 
>the costs associated with shoring up the weaknesses of the given 
>language.

I think it is a delusion. You cannot build a rocket using a stone axe.
What you can is to invest a huge amount of work in more advanced
tools, which in the end will allow you to build the rocket. Though,
you had started with an axe, the work was actually done using other
tools.

And again, who pays for the banquet?

> So its possible that for a given mission critical piece of 
>software, Visual Basic may have been the right choice. Its impossible to 
>say without knowing all the surrounding factors.

I think it is clear to everybody that the present state of software
developing is not very good. Knowing the surrounding factors one might
explain this sorrowful fact, but this would not change it. And isn't
the paper in COTS magazine caused this dicussion also a "surrounding
factor"?

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

Re: Is the Writing on the Wall for Ada?

[Warren W. Gay VE3WWG]

Marin David Condic wrote:

..
> As for the languages being selected for a lot of these projects? There 
> are probably lots of factors (technical and business) that are figuring 
> into the decisions that are not obvious from the outside. Ultimately, 
> you can build good software in any language - if you're willing to incur 
> the costs associated with shoring up the weaknesses of the given 
> language. 

It usally involves more than cost. You need the right people
along side the mindset to succeed. Some people just plain
succeed with less "influence" using some tools than others.

Progressive I.T. shops try to do the "leadership" thing, while
others use "management" (big stick) approach instead. With either
approach, it still is a lot like herding cats.

Ada however, can enforce certain things more easily
without involving the politics of design concepts
(limited types, access type restrictions, visibility
rules etc.)  Trying to enforce good software design
in wide open environments like assembly language,
C or BASIC is difficult for large teams. Team members
will always rebell against guidelines in the name of
deadlines, efficiency or their own concept of design
principles.

I suppose your point still holds that it still comes
down to costs of dealing with the people issues, in
addition to the other factors.

But I do like the aspect that Ada removes the politic
of certain design concepts. You don't have to tell
your programmers to avoid assignment of limited types
for example. Getting them to use limited types however,
may be a different story ;-)

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Is the Writing on the Wall for Ada?

[Robert I. Eachus]

Marin David Condic wrote:
> Anyone wishing to bitch about management ought to be required to show 
> credentials as having had a turn in the driver's seat. ;-)

My parents ran a family-owned manufacturing company which was started in 
1907.  I have three sisters and a brother.  We all worked at least one 
summer during high-school and college at the family company.

When I was about 35, my mother told me:  "You know, you kids all 
complained about the archaic way Macbeth was run when you worked here. 
Now every one of you has had experience working in management of a large 
company, and every one of you has told me how poorly they are run 
compared to Macbeth."

It was true.  Macbeth Arc Lamp Company was run very conservatively.  But 
when my father took over, he worked with the CPA who audited the company 
books to come up with a bookkeeping system that let him know today as 
much as could be known about the few things that were important in 
managing the company.  (Cash, Cash flow, P&L, receivables, liabilities, 
and open orders divided into in manufacturing and awaiting materials.)

That adoption of standard accounting methods to provide a one page 
summary of the health of the company, and what needed to be done was a 
very engineering oriented approach to accounting.  But it worked very 
well.  I've thought on occasion about trying to sell companies on 
keeping books that way.  But you have to have someone at the top with an 
engineering background to understand why instantaneous state is so much 
better than quarterly or monthly numbers.

And in every case, the biggest complaint we had was "mushroom 
management."  Managers not knowing what the state of their department 
was from one month to the next trying to tell their subordinates what to do.

-- 
                                             Robert I. Eachus

"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: Is the Writing on the Wall for Ada?

[Marin David Condic]

It just goes to show that its *hard* to run any large endeavor and 
experience with trying to do so can be very enlightening. You tend to 
learn that there is more going into decisions than you might have been 
aware of when you're the non-management guy. Decisions are often 
compromises between technical factors, budgets, schedules, personel 
factors, customer demands, etc. And you have to optimize "profit" - not 
"technical superiority". That's something that most engineers have a 
hard time grasping.

MDC


Robert I. Eachus wrote:
> 
> When I was about 35, my mother told me:  "You know, you kids all 
> complained about the archaic way Macbeth was run when you worked here. 
> Now every one of you has had experience working in management of a large 
> company, and every one of you has told me how poorly they are run 
> compared to Macbeth."
> 

-- 
======================================================================
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: Is the Writing on the Wall for Ada?

[Robert I. Eachus]

Marin David Condic wrote:
 > And you have to optimize "profit" - not  "technical superiority". 
That's something
 > that most engineers have a hard time grasping.

No!  And that is an even harder lesson.  What you want to do is to 
maximize the long-term survival of the company.  That is the hard lesson 
for non-engineering types to learn.

An airplane can fly higher if the wheels fall off at take-off.  But an 
engineer knows he has to design for the entire flight.  This doesn't say 
you can't design for the wheels to fall off, just you have to figure out 
the landing strategy when you do.  (WW2 assault gliders, the U-2, and 
some UAVs have all used variations on this approach.)

In corporate terms, you need to do R&D so you have products to sell when 
the demand for current products dries up.  And a company can stay in 
business for twenty years or more with a 'book' loss as long as the cash 
flow is positive.  (For example, if you depreciate the factory but 
maintain it, at the end of the ammortization period you will still own 
the factory, and it will still be useful, even if depreciated to zero on 
the books.  The land you don't depreciate, but at the end of the 
amortization period, the land plus building may be worth much more than 
the book value.  Some REITs (real-estate investment trusts) are 
structured this way.  They allow you to take a loss every year you own 
them, then sell and take the capital gain. ;-)

-- 
                                                  Robert I. Eachus

"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

Management, was:Is the Writing on the Wall for Ada?

[Anders Wirzenius]

"Robert I. Eachus" <rieachus@attbi.com> wrote in message
news:3F607DC5.5070408@attbi.com...
> Marin David Condic wrote:
>  > And you have to optimize "profit" - not  "technical superiority".
> That's something
>  > that most engineers have a hard time grasping.
>
> No!  And that is an even harder lesson.  What you want to do is to
> maximize the long-term survival of the company.  That is the hard
lesson
> for non-engineering types to learn.
>

It also depends on what you mean by "profit": short term profit or
long term profit (which is much the same as long-term survival). I
experience in many businesses a slip against short time span
management where you focus your attention on end_of_this_year or, even
worse, end_of_next_quarter. Why bother about a longer time period if
your career plan is to move on to your next life (company) latest
within, say, three years?

Another thing that is a hard lesson for some managers:
The higher up in the organization you are, the longer time span it is
between your decision and the result of the decision.
I see often impatient managers who bypasses lower level managers and
who go directly to sub-sub-sub-ordinates and give orders. The only
reason is that the sup-sup-superior doesn't have the patience to wait
for the organization to carry out his decision properly. This leads
easily to low motivation among lower level managers and complaining
about lack of time among higher level managers. :(

Anders

Re: Management, was:Is the Writing on the Wall for Ada?

[Dmitry A. Kazakov]

On Fri, 12 Sep 2003 05:45:50 GMT, "Anders Wirzenius"
<anders.wirzenius@pp.qnet.fi> wrote:

>Another thing that is a hard lesson for some managers:
>The higher up in the organization you are, the longer time span it is
>between your decision and the result of the decision.
>I see often impatient managers who bypasses lower level managers and
>who go directly to sub-sub-sub-ordinates and give orders. The only
>reason is that the sup-sup-superior doesn't have the patience to wait
>for the organization to carry out his decision properly. This leads
>easily to low motivation among lower level managers and complaining
>about lack of time among higher level managers. :(

"Vassal of my vassal is not my vassal!" (:-))

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

Re: Is the Writing on the Wall for Ada?

[Marin David Condic]

Robert I. Eachus wrote:
> Marin David Condic wrote:
>  > And you have to optimize "profit" - not  "technical superiority". 
> That's something
>  > that most engineers have a hard time grasping.
> 
> No!  And that is an even harder lesson.  What you want to do is to 
> maximize the long-term survival of the company.  That is the hard lesson 
> for non-engineering types to learn.
> 
And how is that not "Maximizing Profit"? :-) Would you rather earn one 
dollar a day for a thousand years or ten dolars a day for a week? Long 
term survival of a company *is* maximizing profits - and without some 
focus on the bottom line, investors withdrawal their money from the 
enterprise and... No long term survival. A corporation exists for only 
one reason - to make money. The instant it stops doing that, the 
employees all lose their jobs, the investors lose their retirement funds 
and the managers are all out hoping some other company won't look 
unfavorably on their track record. If you don't keep your eye on *that* 
particular mission, all the good engineering and better mousetraps and 
R&D in the world won't do the company any good.


> 
> In corporate terms, you need to do R&D so you have products to sell when 
> the demand for current products dries up.  And a company can stay in 

Not necessarily. There are lots of companies that turn a nice profit 
over long periods of time and do not invest in R&D. The pizzaria down on 
the corner has been making the same pizza for the last fifteen years 
that I know of and they've been doing just fine.

Mind you, I'm not against R&D. Just that it is a typical engineer's 
focus to think that without it a company is going to hell in a handcart. 
I fall prey to this focus myself sometimes. (I am, after all, an 
engineer.) Its just that I've seen engineers complain about a lack of 
funding for R&D when a company might actually be in the middle of an 
economic crisis and fighting for its very survival. Sometimes you have 
to focus on all those alligators chomping at your butt rather than on 
draining the swamp. ;-)



> business for twenty years or more with a 'book' loss as long as the cash 
> flow is positive.  (For example, if you depreciate the factory but 
> maintain it, at the end of the ammortization period you will still own 
> the factory, and it will still be useful, even if depreciated to zero on 
> the books.  The land you don't depreciate, but at the end of the 
> amortization period, the land plus building may be worth much more than 
> the book value.  Some REITs (real-estate investment trusts) are 
> structured this way.  They allow you to take a loss every year you own 
> them, then sell and take the capital gain. ;-)
> 
Yes, I understand how you can have a paper loss and still be on the right
course. Here we're simply looking at a company that has positive cash flow
and is focused in on its long term strategy rather than worrying about 
optimizing next quarter's reports. That's a good thing to do so long as 
your investors understand what the strategy is and agree with it. But if 
that cash flow goes negative for too long, you don't have a business. 
What you have is a hobby. Few investors will stick around and keep 
pitching bails of money at you so you can play with a hobby.

I recall going through a business course that dealt specifically with 
the jet engine industry and after all the lectures we got on the 
importance to survival of the business of bringing down the 
manufacturing costs over time, we still had engineers who didn't get it. 
A jet engine program might go on for thirty or more years. (Is that 
sufficiently long term focus? ;-) Over that time, you probably are going 
to lose money on the engine for the first ten years or more. The sooner 
you can "learn down" the cost of making those engines, the sooner it 
starts generating profit. When we got to running the business 
simulations, we still had engineers who kept trying to throw massive 
amounts of their budget into R&D well before they had made the last 
engine program pay for itself and had the whole business in a shambles 
within five years.

Of course, one can always argue that it was the "business" guys who 
created the model, so naturally they can make it fit their view of 
reality. But it seemed intuitively obvious to *this* engineer that given 
limited resources and a limited market, you can't R&D every cool jet 
engine product you can imagine - sooner or later you have to make and 
sell the ones you already R&D'd and if you make too many products that 
fit the same market, you're just canibalizing your own business.

Its all a delicate ballancing act. Maybe someone will one day come up 
with a good multi-variable control system that will totally eliminate 
the need for human judgement in matters of running a business, but I 
won't hold my breath. ;-)

MDC

-- 
======================================================================
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: Is the Writing on the Wall for Ada?

[tmoran]

> Long term survival of a company *is* maximizing profits - and without
>some focus on the bottom line, investors withdrawal their money from the
>enterprise and...  No long term survival.
  Profitability is a constraint.  As long as it's satisfied, management,
employees, shareholders, community, etc can fight about the exact function
to be optimized.

Re: Is the Writing on the Wall for Ada?

[Robert I. Eachus]

Marin David Condic wrote:

> Not necessarily. There are lots of companies that turn a nice profit 
> over long periods of time and do not invest in R&D. The pizzaria down on 
> the corner has been making the same pizza for the last fifteen years 
> that I know of and they've been doing just fine.

Other pizzerias have not been so fortunate.  I understand your point 
that for some companies there are periods where "time stands still." 
Others in the same business may have to constantly evolve their product 
line to satisfy a changing customer base.  For example one pizzeria near 
here still makes the best pizzias in town. (IMHO)  But three-quarters of 
their business or more is in grinders, cheese steaks, etc.  And almost 
all of their lunchtime pizza business is now pizza by the slice.

They will continue to move with the times, even if the demand for pizza 
disappears entirely.

-- 
                                           Robert I. Eachus

"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: Is the Writing on the Wall for Ada?

[Marin David Condic]

Oh sure. Businesses have to adapt to the market. I don't think that was 
my point. My point was that the local pizzaria didn't need to dedicate 
10% of its budget trying to develop a "better" pizza. They may spend 
some of their budget on market research, advertising, etc., trying to 
determine how to better serve their customers, but that's different than 
what most people mean by "R&D". Possibly there *is* some "R&D" - they 
maybe from time to time try some new vendor's sausage or cheese to see 
if they can get better flavor at a lower price, etc., but I'd suspect 
that this is *really* small in terms of their budget. So the point is 
that not all businesses have to invest heavily in R&D in order to insure 
long-term survival. Its not the "Magic Wand" that us techies would like 
to think it is.

MDC


Robert I. Eachus wrote:
> 
> They will continue to move with the times, even if the demand for pizza 
> disappears entirely.
> 


-- 
======================================================================
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: Is the Writing on the Wall for Ada?

[Robert I. Eachus]

Marin David Condic wrote:
> Oh sure. Businesses have to adapt to the market. I don't think that was 
> my point. My point was that the local pizzaria didn't need to dedicate 
> 10% of its budget trying to develop a "better" pizza. They may spend 
> some of their budget on market research, advertising, etc., trying to 
> determine how to better serve their customers, but that's different than 
> what most people mean by "R&D". Possibly there *is* some "R&D" - they 
> maybe from time to time try some new vendor's sausage or cheese to see 
> if they can get better flavor at a lower price, etc., but I'd suspect 
> that this is *really* small in terms of their budget. So the point is 
> that not all businesses have to invest heavily in R&D in order to insure 
> long-term survival. Its not the "Magic Wand" that us techies would like 
> to think it is.

Of course, my point was that if a company is too "conservative" they 
will find themselves out of business someday.  On the other hand, 
sometimes change is not good.  (I'd use New Coke as an example, except 
that when Coca Cola listened to their customers and switched back to the 
old formula, they gained marketshare. ;-)

So our hypothetical pizzeria might spend a few hundred dollars a year on 
new ingredients, ingrediants from new suppliers, etc.  (And all the 
pizzas made for research purposes may be eaten by the staff.)

But then it may be relocating to a new site, or refurnishing, or an 
advertising campaign, or any of a dozen other possibilities that results 
in a temporary loss.  As long as it helps keep long term cash flow 
positive, not a problem.

-- 
                                          Robert I. Eachus

"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: Is the Writing on the Wall for Ada?

[Russ]

Marin David Condic <nobody@noplace.com> wrote in message news:<3F61BE5F.2010204@noplace.com>...
> Robert I. Eachus wrote:
> > Marin David Condic wrote:

> > In corporate terms, you need to do R&D so you have products to sell when 
> > the demand for current products dries up.  And a company can stay in 
> 
> Not necessarily. There are lots of companies that turn a nice profit 
> over long periods of time and do not invest in R&D. The pizzaria down on 
> the corner has been making the same pizza for the last fifteen years 
> that I know of and they've been doing just fine.

This is off topic, but I feel compelled to reply. Good pizza tastes
great, but all those carbs in the crust are terrible for your health.
The doe turns to sugar in your system so fast that you might as well
be eating bags of candy.

When I eat pizza, I can't stop until I've eaten 3/4 of a g**-d****
large pizza. I excercize regularly and I'm in good shape, so I can
tolerate it, more or less. My wife is absolutely gorgeous, but tends a
bit to the heavy side. Whenever she suggests we eat pizza, I cringe.
Sometimes it starts an argument.

Whenever I see a pizza parlor, I think to myself that those bastards
are capitalizing on the human proclivity for self-destruction. No,
self-destruction shouldn't be illegal (all drugs should be legal, for
example), but the bastards who promote it should get a conscience and
take account of the death and misery (not to mention obesity) they are
promoting in the long run.

So if some pizzaria is making a profit, I'm not impressed.

Re: Is the Writing on the Wall for Ada?

[Marin David Condic]

I'm in shape. "Round" is a shape.

MDC


Russ wrote:

> large pizza. I excercize regularly and I'm in good shape, so I can
> tolerate it, more or less. My wife is absolutely gorgeous, but tends a


-- 
======================================================================
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: Is the Writing on the Wall for Ada?

[Robert C. Leif]

Firstly as the only trained biochemist in this group, I most vigorously
protest any suggestion that the pizza industry can have a decent future
without R & D. The entire pasta and baking business needs to increase its
fiber content, decrease its fast carbohydrates and fats. On this part, I am
not kidding. McDonald's and other fast-food operations have started to see
the effects of consumer resistance to unhealthy products. 
I write this to illustrate that short term a company and an industry can
flourish with minimal R & D expenditures. However, either technological
progress will result in very strong competitive pressures; or if the
operation can be moved off-shore, it will leave. Fortunately for our local
pizzerias, there products can not be made in India.
Bob
Robert C. Leif, Ph.D.
Email rleif@rleif.com

-----Original Message-----
From: Marin David Condic [mailto:nobody@noplace.com] 
Sent: Saturday, September 13, 2003 5:28 AM
To: comp.lang.ada@ada.eu.org
Subject: Re: Is the Writing on the Wall for Ada?

I'm in shape. "Round" is a shape.

MDC


Russ wrote:

> large pizza. I excercize regularly and I'm in good shape, so I can
> tolerate it, more or less. My wife is absolutely gorgeous, but tends a


-- 
======================================================================
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: Is the Writing on the Wall for Ada?

[Warren W. Gay VE3WWG]

Robert C. Leif wrote:

> Firstly as the only trained biochemist in this group, I most vigorously
> protest any suggestion that the pizza industry can have a decent future
> without R & D. The entire pasta and baking business needs to increase its
> fiber content, decrease its fast carbohydrates and fats. On this part, I am
> not kidding. McDonald's and other fast-food operations have started to see
> the effects of consumer resistance to unhealthy products. 
> I write this to illustrate that short term a company and an industry can
> flourish with minimal R & D expenditures. However, either technological
> progress will result in very strong competitive pressures; or if the
> operation can be moved off-shore, it will leave. Fortunately for our local
> pizzerias, there products can not be made in India.
> Bob
> Robert C. Leif, Ph.D.
> Email rleif@rleif.com

Well, all that aside, I still preferred the unhealthy Harvey's fries!
If I wanna eat healthy fries, I'll order them where they makes them!

I want my unhealthy Harvey's Fries back. >:-(
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Is the Writing on the Wall for Ada?

[Marin David Condic]

Investors are only interested in making money - and there's nothing 
wrong with that. Why does one put his money in a bank instead of 
stuffing it in a matress at home? Why does one buy into a pension fund 
rather than stick the money in a cookie jar at home? There are different 
levels of risk tolerance and different timeframes in which investors 
expect to reap their profits, but the motives are all basically the 
same: Make Money.

And its important to note, in the long-term, I'll be dead. So if you 
want me to invest in your company, you need a plan to show me some 
profits before that eventuality takes place. :-)

MDC



olehjalmar kristensen - Sun Microsystems - Trondheim Norway wrote:
> 
> But many investors are *NOT* interested in the long-term survival of
> the company.....


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

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

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Is the Writing on the Wall for Ada?

[Stephane Richard]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1685 bytes --]

And what your explaining here is yet another plus for Ada, with it's design
it's made to bring your results (returns on your investment(s)) faster than
other languages.

-- 
St�phane Richard
Senior Software and Technology Supervisor
http://www.totalweb-inc.com
For all your hosting and related needs
"Marin David Condic" <nobody@noplace.com> wrote in message
news:3F672A29.1010604@noplace.com...
> Investors are only interested in making money - and there's nothing
> wrong with that. Why does one put his money in a bank instead of
> stuffing it in a matress at home? Why does one buy into a pension fund
> rather than stick the money in a cookie jar at home? There are different
> levels of risk tolerance and different timeframes in which investors
> expect to reap their profits, but the motives are all basically the
> same: Make Money.
>
> And its important to note, in the long-term, I'll be dead. So if you
> want me to invest in your company, you need a plan to show me some
> profits before that eventuality takes place. :-)
>
> MDC
>
>
>
> olehjalmar kristensen - Sun Microsystems - Trondheim Norway wrote:
> >
> > But many investors are *NOT* interested in the long-term survival of
> > the company.....
>
>
> -- 
> ======================================================================
> Marin David Condic
> I work for: http://www.belcan.com/
> My project is: http://www.jsf.mil/
>
> Send Replies To: m c o n d i c @ a c m . o r g
>
>      "All reformers, however strict their social conscience,
>       live in houses just as big as they can pay for."
>
>           --Logan Pearsall Smith
> ======================================================================
>

Re: Is the Writing on the Wall for Ada?

[Marin David Condic]

Very true - and bringing the thread back on topic, I might add. However, 
as I've noted before, that truth depends on the ever nebulous "all other 
things being equal" quality that we seldom ever have in the real world. 
In a given company you have existing bodies of code, existing tools, 
existing programmer skills, requirements to interface with other 
software, etc. You have compilers for other languages that provide 
development tools, libraries, etc that add leverage. You have available 
subsystems, operating systems or other libraries you might utilize 
available from all sorts of places. Someone looking at Ada as a possible 
technology for a new project has to consider a lot more than just the 
technical merits of the language.

And its worth observing that this "inertia" is currently helping Ada. 
With the DoD's current philosophy of trying to ditch Ada, its only the 
inertia of prior history in existing systems that is keeping Ada afloat 
in that market. That can't last forever, so Ada better find a way to 
start adding more value and increasing its market share.

MDC


Stephane Richard wrote:
> And what your explaining here is yet another plus for Ada, with it's design
> it's made to bring your results (returns on your investment(s)) faster than
> other languages.
> 


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

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

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Is the Writing on the Wall for Ada?

[Stephane Richard]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4414 bytes --]

"Marin David Condic" <nobody@noplace.com> wrote in message
news:3F6852EC.4000907@noplace.com...
> Very true - and bringing the thread back on topic, I might add. However,
> as I've noted before, that truth depends on the ever nebulous "all other
> things being equal" quality that we seldom ever have in the real world.
> In a given company you have existing bodies of code, existing tools,
> existing programmer skills, requirements to interface with other
> software, etc. You have compilers for other languages that provide
> development tools, libraries, etc that add leverage. You have available
> subsystems, operating systems or other libraries you might utilize
> available from all sorts of places. Someone looking at Ada as a possible
> technology for a new project has to consider a lot more than just the
> technical merits of the language.
>
> And its worth observing that this "inertia" is currently helping Ada.
> With the DoD's current philosophy of trying to ditch Ada, its only the
> inertia of prior history in existing systems that is keeping Ada afloat
> in that market. That can't last forever, so Ada better find a way to
> start adding more value and increasing its market share.
>
> MDC
>
>
> Stephane Richard wrote:
> > And what your explaining here is yet another plus for Ada, with it's
design
> > it's made to bring your results (returns on your investment(s)) faster
than
> > other languages.
> >
>
>
> -- 
> ======================================================================
> Marin David Condic
> I work for: http://www.belcan.com/
> My project is: http://www.jsf.mil/NSFrames.htm
>
> Send Replies To: m c o n d i c @ a c m . o r g
>
>      "All reformers, however strict their social conscience,
>       live in houses just as big as they can pay for."
>
>           --Logan Pearsall Smith
> ======================================================================
>

You're right, Hopefully the upcoming revision Ada 200X will help put into th
e Ada Standard at least part of what's missing to make it a good complete
development system as far as Ada itself goes.  As in integrated tools, like
the other languages, to gfive it the leverage it needs.  (I know it's a
development process, not a standarisation process) but as a standard
language.  What can a programmer expect out of Ada?   The language has no
arguments against it (except for a little bit of addons that should be
covered in Ada 200X.

althought I dont like to brag about microsoft in General.  What gave
VisualBasic it's popularity?  the integration of everything that is needed,
in a very visual way, to develop a full fledged applications from GUI
designers, to control development, to databases, to reporting, and the
likes.  Althought Aonix, ACT and other seem to offer some good set of tools
(some of which have a good base of integration), seems to me that more
integration of these tools, so they all work together to accomplish Ada's
ultimate goal would be a good approach to it.  I dont mean, by that, to try
to give users wizards to do everything either.  Where applicable might be
nice.  Integrated Code generators and semi project management (at the
code/design) level for instance might be nice.

Take the GNADE project, with more tools, that is an Ideal project to me as
integrates SQL right into Ada (there's something not given to every
programming language :-).  perhaps more efforts into the achievement of
projects such as these mgith be good for Ada in general too.  there are many
ideas as for as IDE, the language etc etc.....but like you said, we're also
talking market shares....and as such, there's not many things to compare Ada
to the rest....perhaps a bit fo competition thrown in the programming
industry might excite people and companies.  for instances, making
applications that rival other existing applications, in select fields....see
if we can do it better (which we probably can in ada) faster and have
somekind of comparison charts to give to project managers or anyone
responsible to select the "proper" development environment for a given
project.

There's many, unexplored, situations and projects that still need to be done
to give Ada a leading edge....The language speaks for itself, now it's tiem
we use it for something new :-).

-- 
St�phane Richard
Senior Software and Technology Supervisor
http://www.totalweb-inc.com
For all your hosting and related needs

Re: Is the Writing on the Wall for Ada?

[Warren W. Gay VE3WWG]

Dmitry A. Kazakov wrote:

> On 9 Sep 2003 17:53:33 -0700, aek@vib.usr.pu.ru (Alexander
> Kopilovitch) wrote:
...
>>And Mars do not pose an immediate threat.
> 
> Enron, Worldcom, Deutsche Telecom, uncounted DOT-COM companies;
> Mission critical software in Visual Basic; even NASA have admitted
> problems with management. Isn't that a threat?

I thought that Visual Basic was the information
shredder that they used ;-)

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Is the Writing on the Wall for Ada?

[Alexander Kopilovitch]

Dmitry A. Kazakov wrote:

> >And Mars do not pose an immediate threat.
>
> Enron, Worldcom, Deutsche Telecom, uncounted DOT-COM companies;

Do you see anything unusual in all that? If so then you surely read neither
history nor classical literature... or forgot all that stuff. Well, forgotten
past do not remain in the past -;) . For me, all those Enrons etc. are (as a
general system phenomena) an attempt to perform soft landing, in other words
- to discharge situation, which was gradually becoming dangerous. If you think
that this not soft but hard landing then look, for example, at the end of 1920th
(and observe worldwide consequences of those events).

Generally, world/civilization recently entered into new major stage of global
technological trasformation (the most visible part of which is certainly
Internet with all its direct consequences, but there are other, no less
significant technological changes), and it would be far too stupid to expect
that such a major system transformation will proceed smoothly everywhere
at the micro-level (where we live -;) . Moreover, it is improbable that even
richest and strongest countries will be able to push all (or almost all) the
burdens of that transformation somewhere outside.

> Mission critical software in Visual Basic;

I must confess that I'm sick and tired of those words "mission critical".
What a mission? For which or for whom it is critical? Is it a calculation
of optimal credit policy for some bank? Ah, perhaps you will say that you
mean medical equipment. so which part of it and for which particular purposes
it serve? As you mention Visual Basic then probably it runs under Windows -
so what you have against Visual Basic if you run Windows - do you think that
Visual Basic is less safe/reliable than average part of Windows machinery?
Probably you associate incompetent programming with Visual Basic, but most
probably you only guess that is the case, an do not know the actual
programmer's skills. Imagine that you are offered lucrative contract, which
you think you can easily done... but it is non-negotiable requirement that
all must be done in Visual Basic. Will you reject that offer? Or, if you
accept it, will you develop bad/unsafe/unreliable software, excusing yourself
by inherent inferiority of Visual Basic?

> even NASA have admitted
> problems with management. Isn't that a threat?

On the contrary, I was pleasantly surprised with some formulations in the
investigation board's report. You know, while your investigation facilities
are generally healthy, your cause isn't lost beyond repair.

> >Actually, they do not want specifically Java - they want fashionable
> >things, and no more.
>
> It was partially true three years ago, but presently there is too
> little resources to spend them on bells and whistles.

You didn't get me right - I didn't mean bells and whistles, I meant exactly
what I said - they want fashionable things, no matter what is fashionable
at this moment. They perceive Java as fashionable - so they want Java, and
it doesn't matter whether they speak about good GUI or about economy of resources.

> In most cases they do want a real and necessary thing.

Perhaps, but still very often they can't describe that real and necessary
thing adequately. They even often have no firm understanding what they want:
they surely understand their *problem*, but not a solution. In other words,
they have good "negative" understanding, but not a "positive" one.

> And they want this thing for less money and yesterday.

It always been (and will be) so. Just because they are elements of the market,
and play their roles in the game.

> For what ever reason, they
> are convinced that a funny technology X will save the money and time.

They aren't convinced in anything of that sort. Don't keep them so stupid.
They just are keeping the current fashion when they have no special arguments
in their terms), which justify anothey way.

> So either you have to come with this technology, or to present
> something already working in a way they understand as "working". The
> best way to do both.
>
>This is why in my view Ada-to-JVM and Ada-to-DOT-NET should be on the
>top of priority list to make Ada popular.

I wonder how can you think that Ada ever can be popular in the sense you
implied. Any popular and massively used thing will necessarily and quickly
degrade to some average level (at best). A popular Ada can't be generally
better than, say, C++. 

> Where you saw cheap subcontractors? (:-))

Did you mean that you for some reason can't use individuals as subcontractors?
(Otherwise I can't get this your question.)

> > And for those customer's
> > managers you may explain that your technology is a great combination
> > of a solid software engineering methods and technique for fundamental
> > issues of the project and a modern, state-of-art (Java) technology
> > for data communication and data presentation.
>
> Nobody will allow you to do same thing twice.

Why "same thing"? Do you mean, for example, that a prototype demo, which must
be presented at some early stage of a project and the final release of the
product are now regarded as the same thing, for economy of resources?

> The customer will fire you if he discover how you spend his money.

Don't permit him to discover anything of this soft - just expose all that
explicitly in you plan, along with appropriate explanations.

> In most cases they wish a
> precise control over how many people are working on the project and
> what exactly they are doing. I never saw a customer, who would say,
> here is NN bucks and X is the deadline. That would be an end of the
> world we live in. (:-))

Hm. Try to do with Americans -:) For my (as well as some my friends here) 
experience, Americans are generally much smarter and much more flexible
than Europeans in that matters. It is often no problem with Americans to see
a customer who says: $NNN for X at mm/dd/yy (and wonderfully, they keep their
word, as a rule). Although I agree that Europeans tend to pay more for less,
and therefore they may seem more attractive as customers -;) .



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

Re: Is the Writing on the Wall for Ada?

[Dmitry A. Kazakov]

On 12 Sep 2003 11:55:50 -0700, aek@vib.usr.pu.ru (Alexander
Kopilovitch) wrote:

>> >And Mars do not pose an immediate threat.
>>
>> Enron, Worldcom, Deutsche Telecom, uncounted DOT-COM companies;
>
>Do you see anything unusual in all that?

Not at all.

>Generally, world/civilization recently entered into new major stage of global
>technological trasformation (the most visible part of which is certainly
>Internet with all its direct consequences, but there are other, no less
>significant technological changes), and it would be far too stupid to expect
>that such a major system transformation will proceed smoothly everywhere
>at the micro-level (where we live -;).

It cannot especially, because an overwhelming despise to science and
knowledge. Look at the picture of a scientist in Hollywood films and
cartoons!

The major problem of bad management is a lack of any desire to hear
opinons which differs from your own.

>> Mission critical software in Visual Basic;
>
>I must confess that I'm sick and tired of those words "mission critical".
>What a mission?

One of the program.

> For which or for whom it is critical? Is it a calculation
>of optimal credit policy for some bank? Ah, perhaps you will say that you
>mean medical equipment. so which part of it and for which particular purposes
>it serve? As you mention Visual Basic then probably it runs under Windows -
>so what you have against Visual Basic if you run Windows - do you think that
>Visual Basic is less safe/reliable than average part of Windows machinery?

These are two sides of the same coin.

>Probably you associate incompetent programming with Visual Basic, but most
>probably you only guess that is the case, an do not know the actual
>programmer's skills. Imagine that you are offered lucrative contract, which
>you think you can easily done... but it is non-negotiable requirement that
>all must be done in Visual Basic. Will you reject that offer? Or, if you
>accept it, will you develop bad/unsafe/unreliable software, excusing yourself
>by inherent inferiority of Visual Basic?

This is the situation we usually have. The question is why these
requirements are considered absolute? Who are those decided that
Windows and Basic has to be there? Why they decided so. If you dig
just a bit deeper you will find that in 90% cases these decisions are
absolutely ungrounded and caused by sheer incompetence. It could be no
problem if and only if the people having the right to impose
non-negotiable requirements would be also resposible for all
consequences of that. Unfortunately, it is others who are paying for
this.

>> even NASA have admitted
>> problems with management. Isn't that a threat?
>
>On the contrary, I was pleasantly surprised with some formulations in the
>investigation board's report. You know, while your investigation facilities
>are generally healthy, your cause isn't lost beyond repair.

True, but also think about those lost lives.

>> In most cases they do want a real and necessary thing.
>
>Perhaps, but still very often they can't describe that real and necessary
>thing adequately. They even often have no firm understanding what they want:
>they surely understand their *problem*, but not a solution. In other words,
>they have good "negative" understanding, but not a "positive" one.
>
>> And they want this thing for less money and yesterday.
>
>It always been (and will be) so. Just because they are elements of the market,
>and play their roles in the game.
>
>> For what ever reason, they
>> are convinced that a funny technology X will save the money and time.
>
>They aren't convinced in anything of that sort. Don't keep them so stupid.
>They just are keeping the current fashion when they have no special arguments
>in their terms), which justify anothey way.

Call it so if you want, but the result is same. They are not ready and
not willing to have any techincal discussion. As you said, the
requirements are non-negotiable.

>> So either you have to come with this technology, or to present
>> something already working in a way they understand as "working". The
>> best way to do both.
>>
>>This is why in my view Ada-to-JVM and Ada-to-DOT-NET should be on the
>>top of priority list to make Ada popular.
>
>I wonder how can you think that Ada ever can be popular in the sense you
>implied. Any popular and massively used thing will necessarily and quickly
>degrade to some average level (at best). A popular Ada can't be generally
>better than, say, C++. 

You mean that any popularity would make Ada worse? (:-))

>> Where you saw cheap subcontractors? (:-))
>
>Did you mean that you for some reason can't use individuals as subcontractors?
>(Otherwise I can't get this your question.)

We cannot use cheap individuals! (:-)) To find a skilled programmer
with a permission to work in EU and to pay him/her a salary of a
supermarket cashier ...

>> > And for those customer's
>> > managers you may explain that your technology is a great combination
>> > of a solid software engineering methods and technique for fundamental
>> > issues of the project and a modern, state-of-art (Java) technology
>> > for data communication and data presentation.
>>
>> Nobody will allow you to do same thing twice.
>
>Why "same thing"? Do you mean, for example, that a prototype demo, which must
>be presented at some early stage of a project and the final release of the
>product are now regarded as the same thing, for economy of resources?

This is the advantage of Ada-to-Java compiler. The prototype could be
compiled into a native code saving much work.

>> The customer will fire you if he discover how you spend his money.
>
>Don't permit him to discover anything of this soft - just expose all that
>explicitly in you plan, along with appropriate explanations.

Which would be uttely naive. You won't get the contract at all!

>> In most cases they wish a
>> precise control over how many people are working on the project and
>> what exactly they are doing. I never saw a customer, who would say,
>> here is NN bucks and X is the deadline. That would be an end of the
>> world we live in. (:-))
>
>Hm. Try to do with Americans -:) For my (as well as some my friends here) 
>experience, Americans are generally much smarter and much more flexible
>than Europeans in that matters. It is often no problem with Americans to see
>a customer who says: $NNN for X at mm/dd/yy (and wonderfully, they keep their
>word, as a rule). Although I agree that Europeans tend to pay more for less,
>and therefore they may seem more attractive as customers -;) .

It again depends on which money are being spent. In bureaucratic
Europe with its "solidarity" system you can be paid for nothing
(however it is not so easy to find a sinecure). Perhaps, many
Americans are *still* spending money of their own.

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

Re: Is the Writing on the Wall for Ada?

[Alexander Kopilovitch]

Dmitry A. Kazakov wrote:

> > it would be far too stupid to expect
> > that such a major system transformation will proceed smoothly everywhere
> > at the micro-level (where we live -;).
>
> It cannot especially, because an overwhelming despise to science and
> knowledge. Look at the picture of a scientist in Hollywood films and
> cartoons!

Well, people are right in that despise (which is actually only partial, not
overwhelming). It was caused by pseudo-scientists of all flavors, which are
multiplied in increasing rate (like pseudo-engineers in former Soviet Union,
if you remember) A pseudo-scientist is not necessary a parasite or unskilled
or stupid or dishonest person - he (or she, these times -;) is just not a
scientist, but with all visual attributes of one - diploma, degrees,
vocabulary, workplace, duties and lifestyle. It became possible when the
numbers of "licensed" scientists increased greatly - number of real scientists
increased substantially, but at the same time number of pseudo-scientists
skyrocketed much higher. After several decades of such proliferation of
pseudo-scientists (and even quasi-sciences), common people became aware of this
effect... and I don't think that it is Hollywood to be blamed - it was 
behaviour of those pseudo-scientists in real life that disclosed their presence
and their numbers.

> The major problem of bad management is a lack of any desire to hear
> opinons which differs from your own.

I think that almost everyone would like to hear seriously and skillfully
considered, beautifully expressed and responsible (that is, backed by some
form of signing or by reference to external support) opinion, which is offered
for free -:) . So the question is whether a manager expects these qualities
from an opinion of another person. Given real circumstances I do not always
blame the manager if his (or her -:) expectations are low.

>>> Mission critical software in Visual Basic;
>>
>>I must confess that I'm sick and tired of those words "mission critical".
>>What a mission?
>
>One of the program.

It is not always clear which mission has a program. I think I saw more than
one case where different people have different opinions about the program's
mission. But anyway, I asked about particular mission - just curious to hear
concrete enough example of this kind of a blame.

> > Imagine that you are offered lucrative contract, which
> > you think you can easily done... but it is non-negotiable requirement that
> > all must be done in Visual Basic. Will you reject that offer? Or, if you
> > accept it, will you develop bad/unsafe/unreliable software, excusing 
> > yourself by inherent inferiority of Visual Basic?
>
> This is the situation we usually have. The question is why these
> requirements are considered absolute?

There may be trivial reasons. For example, your customer wants to have an 
opportunity to modify some pieces of the software in some future, without your
assistance; and he reasonably thinks that it will be some support for Visual
Basic in the future, and there will be non-expensive workforce for that; at the
same time he is not sure that there will be comparable conditions for any other
language, which is equally affordable now. It's enough, isn't it? Notice, that
is is *his* territory - manager's, and not yours, programmer's. He may or may
not take consequences from that his decision, but you, as a contractor, most 
probably will not.

And let me remind you that not too much ago in some places exactly Ada was
considered as absolute requirement; and there were some reasons for that.

> Who are those decided that
> Windows and Basic has to be there? Why they decided so. If you dig
> just a bit deeper you will find that in 90% cases these decisions are
> absolutely ungrounded and caused by sheer incompetence.

Perhaps. So what? All people's activities suffered, suffer, and will suffer
from that, not only programming. Medieval theologists believed that this is
one of the major consequences of original sin.

> You mean that any popularity would make Ada worse? (:-))

If you mean popularity among professional programmers than perhaps, almost Yes
(replacing "any" by "radical raise of"). But if you mean popularity among
scientists and engineers - than No.

> > > Where you saw cheap subcontractors? (:-))
> >
> >Did you mean that you for some reason can't use individuals as subcontractors?
> >(Otherwise I can't get this your question.)
>
> We cannot use cheap individuals! (:-)) To find a skilled programmer
> with a permission to work in EU and to pay him/her a salary of a
> supermarket cashier ...

I can't believe that you aren't aware of "virtual contractors".



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

Re: Is the Writing on the Wall for Ada?

[Dmitry A. Kazakov]

On 15 Sep 2003 18:36:02 -0700, aek@vib.usr.pu.ru (Alexander
Kopilovitch) wrote:

>Dmitry A. Kazakov wrote:
>
>> > it would be far too stupid to expect
>> > that such a major system transformation will proceed smoothly everywhere
>> > at the micro-level (where we live -;).
>>
>> It cannot especially, because an overwhelming despise to science and
>> knowledge. Look at the picture of a scientist in Hollywood films and
>> cartoons!
>
>Well, people are right in that despise (which is actually only partial, not
>overwhelming). It was caused by pseudo-scientists of all flavors, which are
>multiplied in increasing rate (like pseudo-engineers in former Soviet Union,
>if you remember) A pseudo-scientist is not necessary a parasite or unskilled
>or stupid or dishonest person - he (or she, these times -;) is just not a
>scientist, but with all visual attributes of one - diploma, degrees,
>vocabulary, workplace, duties and lifestyle. It became possible when the
>numbers of "licensed" scientists increased greatly - number of real scientists
>increased substantially, but at the same time number of pseudo-scientists
>skyrocketed much higher. After several decades of such proliferation of
>pseudo-scientists (and even quasi-sciences), common people became aware of this
>effect... and I don't think that it is Hollywood to be blamed - it was 
>behaviour of those pseudo-scientists in real life that disclosed their presence
>and their numbers.

Actually a typical Hollywood scientist is rather opposite to what you
describe. He is very skilled. He concentrates exclusively on his work.
He is absolutely amoral and often asexual. He wears dirty clothes and
spectacles. His activity could lead the humankind to a catastophe, if
there were no main hero, who crushes scientists's lower jaw in a final
apotheosis.

>> The major problem of bad management is a lack of any desire to hear
>> opinons which differs from your own.
>
>I think that almost everyone would like to hear seriously and skillfully
>considered, beautifully expressed and responsible (that is, backed by some
>form of signing or by reference to external support) opinion, which is offered
>for free -:) .

OK, I suppose the smiley refers the whole sentence (:-))

>>>> Mission critical software in Visual Basic;
>>>
>>>I must confess that I'm sick and tired of those words "mission critical".
>>>What a mission?
>>
>>One of the program.
>
>It is not always clear which mission has a program. I think I saw more than
>one case where different people have different opinions about the program's
>mission.

Such programs should not be even developed. That's a part of the
problem, developing whithout an understanding what the program should
do.

> But anyway, I asked about particular mission - just curious to hear
>concrete enough example of this kind of a blame.

Consider MS-Word. Its mission to help in writting documents. Does it?
(:-))

>> > Imagine that you are offered lucrative contract, which
>> > you think you can easily done... but it is non-negotiable requirement that
>> > all must be done in Visual Basic. Will you reject that offer? Or, if you
>> > accept it, will you develop bad/unsafe/unreliable software, excusing 
>> > yourself by inherent inferiority of Visual Basic?
>>
>> This is the situation we usually have. The question is why these
>> requirements are considered absolute?
>
>There may be trivial reasons. For example, your customer wants to have an 
>opportunity to modify some pieces of the software in some future, without your
>assistance; and he reasonably thinks that it will be some support for Visual
>Basic in the future, and there will be non-expensive workforce for that; at the
>same time he is not sure that there will be comparable conditions for any other
>language, which is equally affordable now. It's enough, isn't it? Notice, that
>is is *his* territory - manager's, and not yours, programmer's. He may or may
>not take consequences from that his decision, but you, as a contractor, most 
>probably will not.

Neither of the reasons you mentioned are absolute. And the language of
implementation is *my* territory. *His* territory is to write the
requrements of *what* the program should do. The common problem is
that this part of work is never done, while *how* to write programs
will be proclaimed on each corner, by people, having qualification and
knowledge of a bath-house attendant!

>And let me remind you that not too much ago in some places exactly Ada was
>considered as absolute requirement; and there were some reasons for that.

Know what, the Mandate was a good thing! The bad thing was, that it
was never enforced.

If the government reguates the speed limit on a high way, it should
also regulate the way the software is developed in the fields of
common interest.

>> Who are those decided that
>> Windows and Basic has to be there? Why they decided so. If you dig
>> just a bit deeper you will find that in 90% cases these decisions are
>> absolutely ungrounded and caused by sheer incompetence.
>
>Perhaps. So what? All people's activities suffered, suffer, and will suffer
>from that, not only programming. Medieval theologists believed that this is
>one of the major consequences of original sin.

True, I too consider Windows as a punishment for our sins!

>> You mean that any popularity would make Ada worse? (:-))
>
>If you mean popularity among professional programmers than perhaps, almost Yes
>(replacing "any" by "radical raise of"). But if you mean popularity among
>scientists and engineers - than No.

Well, didn't Jesus save us? (:-))

>> > > Where you saw cheap subcontractors? (:-))
>> >
>> >Did you mean that you for some reason can't use individuals as subcontractors?
>> >(Otherwise I can't get this your question.)
>>
>> We cannot use cheap individuals! (:-)) To find a skilled programmer
>> with a permission to work in EU and to pay him/her a salary of a
>> supermarket cashier ...
>
>I can't believe that you aren't aware of "virtual contractors".

Actually, I am not.

How virtual is the software written by virtual contractors? (:-))

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

Re: Is the Writing on the Wall for Ada?

[Alexander Kopilovitch]

Dmitry A. Kazakov wrote:

> > numbers of "licensed" scientists increased greatly - number of real scientists
> > increased substantially, but at the same time number of pseudo-scientists
> > skyrocketed much higher. After several decades of such proliferation of
> > pseudo-scientists (and even quasi-sciences), common people became aware of this
> > effect... and I don't think that it is Hollywood to be blamed - it was
> > behaviour of those pseudo-scientists in real life that disclosed their presence
> > and their numbers.
>
> Actually a typical Hollywood scientist is rather opposite to what you
> describe. He is very skilled. He concentrates exclusively on his work.
> He is absolutely amoral and often asexual. He wears dirty clothes and
> spectacles. His activity could lead the humankind to a catastophe, if
> there were no main hero, who crushes scientists's lower jaw in a final
> apotheosis.

It isn't opposite at all. That Hollywood's type you described is not for
a human character, it's simply a personification of "bad part" of science.
I didn't see that Hollywood's production myself, but from what you said
I may conclude that except of dirty clothes (which probably does not belong
to the image, but is a form of direct message, that is, label "BAD"), this
image is an acceptable popular presentation of the prototype. And I can't
blame Hollywood for not representing a "good part" of science - just because
it is an impossible job: you can show a good guy who incidentally is a scientist,
but you can't show an image of good science on movie; common people can't see
good science directly, without a mediation of an engineering.

> >>>> Mission critical software in Visual Basic;
> >>>
> >>>I must confess that I'm sick and tired of those words "mission critical".
> >>>What a mission?
> >>
> >>One of the program.
> >
> >It is not always clear which mission has a program. I think I saw more than
> >one case where different people have different opinions about the program's
> >mission.

> Such programs should not be even developed. That's a part of the
> problem, developing whithout an understanding what the program should
> do.

Hm. Suppose we both agree to go to a bar and continue discussion there. And I
want coffee, while you want beer (I don't know your preferences, but your
e-mail is in German domain -:) . What is our joint mission? My view is that
the mission is to get coffee for me, your beer is not significant, but only
acceptable; your view is exactly opposite - for you the mission is to get beer
for you, and my coffee is not significant, but only acceptable. Should we
delay our move until we can reach consensus about the mission? It depends
on our expectations about the probability of a conflict, which may emerge if
it appears that particular bar can provide coffee, but not beer, or vice versa.

> > But anyway, I asked about particular mission - just curious to hear
> >concrete enough example of this kind of a blame.
>
> Consider MS-Word. Its mission to help in writting documents. Does it?
> (:-))

Certainly does, I have huge experimental data for that statement. Consider
Russian picture: practically all existed word processors were available there
practically for free, so competition among them was as honest as one can dream.
And MS Word got clear and undoubtful victory.

But I don't agree with you about the MS Word's mission -;) . For me, its
mission is to help in writing, printing and exchanging documents. And the
latter is very valuable. I think that without RTF there would be much less
chances for MS Word to succeed.


> > There may be trivial reasons. For example, your customer wants to have an
> > opportunity to modify some pieces of the software in some future, without your
> > assistance; and he reasonably thinks that it will be some support for Visual
> > Basic in the future, and there will be non-expensive workforce for that; at the
> > same time he is not sure that there will be comparable conditions for any other
> > language, which is equally affordable now. It's enough, isn't it? Notice, that
> > is is *his* territory - manager's, and not yours, programmer's. He may or may
> > not take consequences from that his decision, but you, as a contractor, most
> > probably will not.
>
> Neither of the reasons you mentioned are absolute.

Yes. But nevertheless they are reasons.

> And the language of implementation is *my* territory.

Not necessary. Here is more strong argument for this (as you aren't convinced
by previous ones): the manager sees an opportunity to sell the software to 
some third parties, and he thinks that it will be much easier to do if the
software will be in Visual Basic. He may be wrong, but how can you know that,
as you do not know perspective buyers and there preferences?

> *His* territory is to write the
> requrements of *what* the program should do.

There may be requirements that aren't in your competence as a contract programmer
- for example, perspective for maintenance 5 years ahead... unless your contract
explicitly includes your responsibility for that (which is improbable for
too small contractors).

All after all, it is usually much harder to say what exactly the program
should do than actually write that program.

> The common problem is
> that this part of work is never done, while *how* to write programs
> will be proclaimed on each corner, by people, having qualification and
> knowledge of a bath-house attendant!

Well, both parties want more freedom for themselves and are willing to impose
restrictions on the partner. Quite usual, isn't it?

Generally, I don't think that fraction of competent and responsible professionals
is much higher for programmers than for managers... these times.

> If the government reguates the speed limit on a high way, it should
> also regulate the way the software is developed in the fields of
> common interest.

Poor, poor government -:)

> >> You mean that any popularity would make Ada worse? (:-))
> >
> >If you mean popularity among professional programmers than perhaps, almost Yes
> >(replacing "any" by "radical raise of"). But if you mean popularity among
> >scientists and engineers - than No.
>
> Well, didn't Jesus save us? (:-))

I must disappoint you - you are too optimistic in this issue -:) . Salvage of
mankind as a whole did not include particular implications, for which you are
apparently hoping -:) .

> >> > > Where you saw cheap subcontractors? (:-))
> >> >
> >> >Did you mean that you for some reason can't use individuals as subcontractors?
> >> >(Otherwise I can't get this your question.)
> >>
> >> We cannot use cheap individuals! (:-)) To find a skilled programmer
> >> with a permission to work in EU and to pay him/her a salary of a
> >> supermarket cashier ...
> >
> >I can't believe that you aren't aware of "virtual contractors".
>
> Actually, I am not.

So, you have an unaccounted resource.

> How virtual is the software written by virtual contractors? (:-))

Virtual contractors typically do not write software at all (for their functionality
as virtual contractors) - just because of that they are cheap. Sometimes they
participate in writing the software, but only some smaller part of it,



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

Re: Is the Writing on the Wall for Ada?

[Dmitry A. Kazakov]

On 16 Sep 2003 20:15:52 -0700, aek@vib.usr.pu.ru (Alexander
Kopilovitch) wrote:

>Dmitry A. Kazakov wrote:
>
>> > numbers of "licensed" scientists increased greatly - number of real scientists
>> > increased substantially, but at the same time number of pseudo-scientists
>> > skyrocketed much higher. After several decades of such proliferation of
>> > pseudo-scientists (and even quasi-sciences), common people became aware of this
>> > effect... and I don't think that it is Hollywood to be blamed - it was
>> > behaviour of those pseudo-scientists in real life that disclosed their presence
>> > and their numbers.
>>
>> Actually a typical Hollywood scientist is rather opposite to what you
>> describe. He is very skilled. He concentrates exclusively on his work.
>> He is absolutely amoral and often asexual. He wears dirty clothes and
>> spectacles. His activity could lead the humankind to a catastophe, if
>> there were no main hero, who crushes scientists's lower jaw in a final
>> apotheosis.
>
>It isn't opposite at all. That Hollywood's type you described is not for
>a human character, it's simply a personification of "bad part" of science.
>I didn't see that Hollywood's production myself, but from what you said
>I may conclude that except of dirty clothes (which probably does not belong
>to the image, but is a form of direct message, that is, label "BAD"), this
>image is an acceptable popular presentation of the prototype. And I can't
>blame Hollywood for not representing a "good part" of science - just because
>it is an impossible job: you can show a good guy who incidentally is a scientist,
>but you can't show an image of good science on movie; common people can't see
>good science directly, without a mediation of an engineering.

Can common people see angels? (well, before they get too much beer)
Nevertheless, do not even try to attack a religion and its priests?
All religion? This is no, no. Because, public would not accept this.
Hollywood is just a mirror.

>> Such programs should not be even developed. That's a part of the
>> problem, developing whithout an understanding what the program should
>> do.
>
>Hm. Suppose we both agree to go to a bar and continue discussion there. And I
>want coffee, while you want beer (I don't know your preferences, but your
>e-mail is in German domain -:) . What is our joint mission? My view is that
>the mission is to get coffee for me, your beer is not significant, but only
>acceptable; your view is exactly opposite - for you the mission is to get beer
>for you, and my coffee is not significant, but only acceptable. Should we
>delay our move until we can reach consensus about the mission? It depends
>on our expectations about the probability of a conflict, which may emerge if
>it appears that particular bar can provide coffee, but not beer, or vice versa.

It depends on who will pay! (:-))

>> > But anyway, I asked about particular mission - just curious to hear
>> >concrete enough example of this kind of a blame.
>>
>> Consider MS-Word. Its mission to help in writting documents. Does it?
>> (:-))
>
>Certainly does, I have huge experimental data for that statement. Consider
>Russian picture: practically all existed word processors were available there
>practically for free, so competition among them was as honest as one can dream.
>And MS Word got clear and undoubtful victory.

Which does not imply that it fulfills the mission. It is comparable
with choosing a medicine against baldness.

>> And the language of implementation is *my* territory.
>
>Not necessary. Here is more strong argument for this (as you aren't convinced
>by previous ones): the manager sees an opportunity to sell the software to 
>some third parties, and he thinks that it will be much easier to do if the
>software will be in Visual Basic. He may be wrong, but how can you know that,
>as you do not know perspective buyers and there preferences?

Because I *know* that highly likely the buyers' preferences are as
ungrounded as the manager's opinon.

>> *His* territory is to write the
>> requrements of *what* the program should do.
>
>There may be requirements that aren't in your competence as a contract programmer
>- for example, perspective for maintenance 5 years ahead... unless your contract
>explicitly includes your responsibility for that (which is improbable for
>too small contractors).

Unfortunate example, in 5 years, MS will ship a new version of Visual
Basic, fully incompatible with the present one. So far, the goal of MS
is to maximize the maintenace costs of those who are using MS
software.

>All after all, it is usually much harder to say what exactly the program
>should do than actually write that program.

Right! (:-))

>> If the government reguates the speed limit on a high way, it should
>> also regulate the way the software is developed in the fields of
>> common interest.
>
>Poor, poor government -:)

A rich one, because it will suck more taxes from us, to produce more
regulations! (:-))

>> >> You mean that any popularity would make Ada worse? (:-))
>> >
>> >If you mean popularity among professional programmers than perhaps, almost Yes
>> >(replacing "any" by "radical raise of"). But if you mean popularity among
>> >scientists and engineers - than No.
>>
>> Well, didn't Jesus save us? (:-))
>
>I must disappoint you - you are too optimistic in this issue -:) . Salvage of
>mankind as a whole did not include particular implications, for which you are
>apparently hoping -:) .

Alas

>> How virtual is the software written by virtual contractors? (:-))
>
>Virtual contractors typically do not write software at all (for their functionality
>as virtual contractors) - just because of that they are cheap. Sometimes they
>participate in writing the software, but only some smaller part of it,

Sounds like money-laundering! (:-))

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

Re: Is the Writing on the Wall for Ada?

[Alexander Kopilovitch]

Dmitry A. Kazakov wrote:

> > you can't show an image of good science on movie; common people can't see
> > good science directly, without a mediation of an engineering.

> Can common people see angels? (well, before they get too much beer)
> Nevertheless, do not even try to attack a religion and its priests?

First, there was various states of that in different times - just recall how
the Protestant Churches emerged. Second, Christian religion generally accepts
that common people (that is, not priest or monks) can feel God's direct influence
to some degree and in various forms, even in the form of visions.

> >> *His* territory is to write the
> >> requrements of *what* the program should do.
> >
> >There may be requirements that aren't in your competence as a contract programmer
> >- for example, perspective for maintenance 5 years ahead... unless your contract
> >explicitly includes your responsibility for that (which is improbable for
> >too small contractors).
>
> Unfortunate example, in 5 years, MS will ship a new version of Visual
> Basic, fully incompatible with the present one.

I don't know what you call "fully incompatible", but a typical program in
Visual Basic surely may be converted from old to new compiler without much
effort. And if it appears inconvenient for conversion, it may be simply
rewrote from old source code. No big deal usually, even for average Basic
programmer.

> >> How virtual is the software written by virtual contractors? (:-))
> >
> >Virtual contractors typically do not write software at all (for their functionality
> >as virtual contractors) - just because of that they are cheap. Sometimes they
> >participate in writing the software, but only some smaller part of it,

> Sounds like money-laundering! (:-))

I see you have a taste for risky jokes -:(



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

Re: Is the Writing on the Wall for Ada?

[Dmitry A. Kazakov]

On 17 Sep 2003 15:16:40 -0700, aek@vib.usr.pu.ru (Alexander
Kopilovitch) wrote:

>Dmitry A. Kazakov wrote:
>
>> > you can't show an image of good science on movie; common people can't see
>> > good science directly, without a mediation of an engineering.
>
>> Can common people see angels? (well, before they get too much beer)
>> Nevertheless, do not even try to attack a religion and its priests?
>
>First, there was various states of that in different times - just recall how
>the Protestant Churches emerged. Second, Christian religion generally accepts
>that common people (that is, not priest or monks) can feel God's direct influence
>to some degree and in various forms, even in the form of visions.

Can't common people perceive scientifical concepts in the form of a
vision? So the reason why religion is respected and science is not
lies somewhere else than in a possibility to perceive the fruits of
both. And fruits of science are far more visible than ones of anything
other.

>> >> *His* territory is to write the
>> >> requrements of *what* the program should do.
>> >
>> >There may be requirements that aren't in your competence as a contract programmer
>> >- for example, perspective for maintenance 5 years ahead... unless your contract
>> >explicitly includes your responsibility for that (which is improbable for
>> >too small contractors).
>>
>> Unfortunate example, in 5 years, MS will ship a new version of Visual
>> Basic, fully incompatible with the present one.
>
>I don't know what you call "fully incompatible",

"fully incompatible" = not "full compatible" (:-))

> but a typical program in
>Visual Basic surely may be converted from old to new compiler without much
>effort. And if it appears inconvenient for conversion, it may be simply
>rewrote from old source code. No big deal usually, even for average Basic
>programmer.

Which would be indeed an excellent maintenance perspective ...

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

Re: Is the Writing on the Wall for Ada?

[Alexander Kopilovitch]

Dmitry A. Kazakov wrote:

> Can't common people perceive scientifical concepts in the form of a
> vision?

Sad to say, they can't. Their recognition facilities aren't trained for that.
Science fiction literature in its best efforts tried to make a bridge for that,
but even the best authors - Isaac Asimov, John Wyndham, Stanislav Lem, Boris
and Arkady Strugatsky - fell short of that; they mostly provided glimpses of
only human part of scientific environment, that is, human logic, human decision
mechanism etc. ... although some novels of them (especially of Asimov) may be
useful for an intermediate level, as it pertains to the scientific concepts.

> So the reason why religion is respected and science is not
> lies somewhere else than in a possibility to perceive the fruits of
> both. And fruits of science are far more visible than ones of anything
> other.

Fruits of science can't be directly visible. All good (or arguably good) fruits
of science must first pass through engineering, and only after that they become
visible (so the role of science becomes vague). Only bad/poisonous fruits of
science  occasionally can be visible directly.

> > but a typical program in
> >Visual Basic surely may be converted from old to new compiler without much
> >effort. And if it appears inconvenient for conversion, it may be simply
> >rewrote from old source code. No big deal usually, even for average Basic
> >programmer.
> 
> Which would be indeed an excellent maintenance perspective ...

Not so bad, really. Probably you will have some burden, but for that you have
vast pool of resources. and most probably you'll never have to hire a costly
expert. At least it is honest, without any hype; with that you have some sort
of upper estimate: the cost of maintanance (per month) most probably will not
exceed the cost of development (per month); probably it will be much less, but
this will depend on external factors.



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

Re: Is the Writing on the Wall for Ada?

[Dmitry A. Kazakov]

On 18 Sep 2003 11:46:43 -0700, aek@vib.usr.pu.ru (Alexander
Kopilovitch) wrote:

>Dmitry A. Kazakov wrote:
>
>> Can't common people perceive scientifical concepts in the form of a
>> vision?
>
>Sad to say, they can't.

Come on! Everybody had a vision of a TV set.

>Their recognition facilities aren't trained for that.

Rather, they are well trained not to recognize it.

>Science fiction literature in its best efforts tried to make a bridge for that,
>but even the best authors - Isaac Asimov, John Wyndham, Stanislav Lem, Boris
>and Arkady Strugatsky

Hal Clement

> - fell short of that; they mostly provided glimpses of
>only human part of scientific environment, that is, human logic, human decision
>mechanism etc. ... although some novels of them (especially of Asimov) may be
>useful for an intermediate level, as it pertains to the scientific concepts.

Honestly speaking, among these writers only Clement and maybe
Strugatsky tried to show a science-oriented society, where knowledge,
rather than money, is a measure of success. All others are considering
space ships as granted.

>> So the reason why religion is respected and science is not
>> lies somewhere else than in a possibility to perceive the fruits of
>> both. And fruits of science are far more visible than ones of anything
>> other.
>
>Fruits of science can't be directly visible. All good (or arguably good) fruits
>of science must first pass through engineering,

It is no matter. Cash must also pass through a money access machine. 

Similarly as with science, people grown in rich families often despise
money and become anarchists, socialists, anti-globalists, greens etc.
They just take wealth [created by others] for granted.

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

Re: Is the Writing on the Wall for Ada?

[Alexander Kopilovitch]

Dmitry A. Kazakov wrote:

> >> Can't common people perceive scientifical concepts in the form of a
> >> vision?
> >
> >Sad to say, they can't.
>
> Come on! Everybody had a vision of a TV set.

Well, and which scientific concepts are represented by this wooden or plastic
box with a glass screen showing dynamic images and something inside producing
speech and music?

> >Their recognition facilities aren't trained for that.
>
> Rather, they are well trained not to recognize it.

It's impossible - to train not to recognize - at least at current state-of-art
and not a single person, but a big part of population. You can (with big and
very costly effort) block a particular way of recognition, but no more.

> >Science fiction literature in its best efforts tried to make a bridge for that,
> >but even the best authors - Isaac Asimov, John Wyndham, Stanislav Lem, Boris
> >and Arkady Strugatsky
>
> Hal Clement

Hm, I never heard of him. Well, these days it isn't too hard, probably I'll
try to see what other people said about this author.

> > - fell short of that; they mostly provided glimpses of
> >only human part of scientific environment, that is, human logic, human decision
> >mechanism etc. ... although some novels of them (especially of Asimov) may be
> >useful for an intermediate level, as it pertains to the scientific concepts.
>
> Honestly speaking, among these writers only Clement and maybe
> Strugatsky tried to show a science-oriented society, where knowledge,
> rather than money, is a measure of success.

Given current circumstances regarding intellectual property, I can't resist
to ask question: if knowledge, rather than money, is a measure of success,
doesn't this mean that knowledge became a property in that science-oriented
society? -;)

> All others are considering space ships as granted.

I see no problem with it, they just extrapolate from already established tendency;
nevertheless, Asimov's spaceships are still evolving (after 20+K years), for
example in "Foundation and Earth", where this is significant for a plot.

> >Fruits of science can't be directly visible. All good (or arguably good) fruits
> >of science must first pass through engineering,
>
>It is no matter. Cash must also pass through a money access machine. 

But money access machine doesn't change the money, and you get exactly what
you expect, you know the thing in advance. I think you will be much surprised
(and quite unpleasantly), if you get from something you never seen before
(and of unknown value and of entirely unfamiliar form) from a money access
machine.

> Similarly as with science, people grown in rich families often despise
> money and become anarchists, socialists, anti-globalists, greens etc.
> They just take wealth [created by others] for granted.

I don't know how often it happens (I never meet such persons, and I strongly
suspect that you also have no reliable sources for statistics about this
phenomena), but anyway I do not count those, almost always young people being
so stupid - I think they just are trying other values... rich families provide
them possibility for an experiment without too much danger for their present
and future status - so why not to use this opportunity (sometimes)... ?



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

Re: Is the Writing on the Wall for Ada?

[Dmitry A. Kazakov]

On 19 Sep 2003 18:44:33 -0700, aek@vib.usr.pu.ru (Alexander
Kopilovitch) wrote:

>Dmitry A. Kazakov wrote:
>
>> >> Can't common people perceive scientifical concepts in the form of a
>> >> vision?
>> >
>> >Sad to say, they can't.
>>
>> Come on! Everybody had a vision of a TV set.
>
>Well, and which scientific concepts are represented by this wooden or plastic
>box with a glass screen showing dynamic images and something inside producing
>speech and music?

To peceive and to understand are well different things. For example, I
percevie chancellor Schroeder, but beat me, I cannot undersand him!
(:-))

>> >Their recognition facilities aren't trained for that.
>>
>> Rather, they are well trained not to recognize it.
>
>It's impossible - to train not to recognize - at least at current state-of-art
>and not a single person, but a big part of population. You can (with big and
>very costly effort) block a particular way of recognition, but no more.

Oh, this is very possible. For example, people trained to eat
McDonald's food will not accept any decent dish. People permanently
watching MTV are unable to recognize virtually any music. Wirth wrote
that students once exposed to Basic are beyond any hope...

>> >Science fiction literature in its best efforts tried to make a bridge for that,
>> >but even the best authors - Isaac Asimov, John Wyndham, Stanislav Lem, Boris
>> >and Arkady Strugatsky
>>
>> Hal Clement
>
>Hm, I never heard of him. Well, these days it isn't too hard, probably I'll
>try to see what other people said about this author.

Strugatsky called him Jules Verne of XX century. They translated his
Mission of Gravity - one of the best science fiction novels.

>> > - fell short of that; they mostly provided glimpses of
>> >only human part of scientific environment, that is, human logic, human decision
>> >mechanism etc. ... although some novels of them (especially of Asimov) may be
>> >useful for an intermediate level, as it pertains to the scientific concepts.
>>
>> Honestly speaking, among these writers only Clement and maybe
>> Strugatsky tried to show a science-oriented society, where knowledge,
>> rather than money, is a measure of success.
>
>Given current circumstances regarding intellectual property, I can't resist
>to ask question: if knowledge, rather than money, is a measure of success,
>doesn't this mean that knowledge became a property in that science-oriented
>society? -;)

In my dilettantish opinion, there is a difference, knowledge is
difficult to separate from its carrier. The-Mickey-Mouse-movement
against freedom of speech was so successfull because in case of
recorded music and movies it was relatively easy to do.

>> All others are considering space ships as granted.
>
>I see no problem with it, they just extrapolate from already established tendency;
>nevertheless, Asimov's spaceships are still evolving (after 20+K years), for
>example in "Foundation and Earth", where this is significant for a plot.
>
>> >Fruits of science can't be directly visible. All good (or arguably good) fruits
>> >of science must first pass through engineering,
>>
>>It is no matter. Cash must also pass through a money access machine. 
>
>But money access machine doesn't change the money, and you get exactly what
>you expect, you know the thing in advance. I think you will be much surprised
>(and quite unpleasantly), if you get from something you never seen before
>(and of unknown value and of entirely unfamiliar form) from a money access
>machine.
>
>> Similarly as with science, people grown in rich families often despise
>> money and become anarchists, socialists, anti-globalists, greens etc.
>> They just take wealth [created by others] for granted.
>
>I don't know how often it happens (I never meet such persons, and I strongly
>suspect that you also have no reliable sources for statistics about this
>phenomena), but anyway I do not count those, almost always young people being
>so stupid - I think they just are trying other values... rich families provide
>them possibility for an experiment without too much danger for their present
>and future status - so why not to use this opportunity (sometimes)... ?

This is what I meant. This is the pattern. It is like a believer,
visiting shrines of all possible gods, church, mosque and not
forgetting to buy a horoscope and a herbalife course, just in case.
(:-))

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

Re: Is the Writing on the Wall for Ada?

[Frank J. Lhota]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:j5itmvchgijlria6a9q1m7hsloopveo20d@4ax.com...
> Oh, this is very possible. For example, people trained to eat
> McDonald's food will not accept any decent dish.

Where do people get TRAINED to eat McDonald's food? And if there are so many
McDonald's "trainees" out there, what accounts for the drop in McDonald's
business over the last few years?

> People permanently
> watching MTV are unable to recognize virtually any music. Wirth wrote
> that students once exposed to Basic are beyond any hope...

Yeah, poor Bill Gates will never amount to anything...

> ...
>
> In my dilettantish opinion, there is a difference, knowledge is
> difficult to separate from its carrier. The-Mickey-Mouse-movement
> against freedom of speech was so successfull because in case of
> recorded music and movies it was relatively easy to do.

What success? The recording industry attempts to reign in file sharing has
been inept and ineffective. Universal has finally seen the light and taken
the right course of action on recorded music. Instead of threatening their
customer base with legal action, Universal announced that they are reducing
the price of their CD's to $10 tops.

Re: Is the Writing on the Wall for Ada?

[Dmitry A. Kazakov]

On Mon, 22 Sep 2003 13:38:08 GMT, "Frank J. Lhota"
<NOSPAM.lhota.adarose@verizon.net> wrote:

>"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>news:j5itmvchgijlria6a9q1m7hsloopveo20d@4ax.com...
>> Oh, this is very possible. For example, people trained to eat
>> McDonald's food will not accept any decent dish.
>
>Where do people get TRAINED to eat McDonald's food?

In McDonald's restaurant, I guess. Here in Germany, there is a
tradition to go in all family each weekend to a McDonald. Not to a
theatre or museum, note.

>And if there are so many
>McDonald's "trainees" out there, what accounts for the drop in McDonald's
>business over the last few years?

Because of Pizza restaurants? (:-)) Is that much better?

>> People permanently
>> watching MTV are unable to recognize virtually any music. Wirth wrote
>> that students once exposed to Basic are beyond any hope...
>
>Yeah, poor Bill Gates will never amount to anything...

Sorry, that was not Wirth, but Edsger W. Dijkstra:

"It is practically impossible to teach good programming style to
students that have had prior exposure to BASIC: as potential
programmers they are mentally mutilated beyond hope of regeneration." 

Maybe Bill is also a Nobel Prize nominee for this year, or Dijkstra
had missed something. Well, reading the list of Nobel Peace Awards,
maybe, maybe...

>> In my dilettantish opinion, there is a difference, knowledge is
>> difficult to separate from its carrier. The-Mickey-Mouse-movement
>> against freedom of speech was so successfull because in case of
>> recorded music and movies it was relatively easy to do.
>
>What success?

They'd got that DMCA through. They switched attention of law makers
from software safety to software use. From the liability of software
developers to the liability of the software users. Maybe it is
unpatriotic, all we here are developers, but I find it scandalous.

>The recording industry attempts to reign in file sharing has
>been inept and ineffective.

Freedom always wins, after all.

>Universal has finally seen the light and taken
>the right course of action on recorded music. Instead of threatening their
>customer base with legal action, Universal announced that they are reducing
>the price of their CD's to $10 tops.

[sobbing] Children of Universal's top managers will hunger! (:-))

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

Re: Is the Writing on the Wall for Ada?

[Steffen Huber]

"Dmitry A. Kazakov" wrote:
> 
> On Mon, 22 Sep 2003 13:38:08 GMT, "Frank J. Lhota"
> <NOSPAM.lhota.adarose@verizon.net> wrote:
> 
> >"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> >news:j5itmvchgijlria6a9q1m7hsloopveo20d@4ax.com...
> >> Oh, this is very possible. For example, people trained to eat
> >> McDonald's food will not accept any decent dish.
> >
> >Where do people get TRAINED to eat McDonald's food?
> 
> In McDonald's restaurant, I guess. Here in Germany, there is a
> tradition to go in all family each weekend to a McDonald. Not to a
> theatre or museum, note.

<off-topic mode>

You must be living in a different Germany.

</off-topic mode>

Steffen

-- 
steffen.huber@gmx.de               steffen@huber-net.de
GCC for RISC OS  - http://www.arcsite.de/hp/gcc/
Private homepage - http://www.huber-net.de/

Re: Is the Writing on the Wall for Ada?

[Dmitry A. Kazakov]

On Mon, 22 Sep 2003 18:45:13 +0200, Steffen Huber <spam@huber-net.de>
wrote:

>"Dmitry A. Kazakov" wrote:
>> 
>> On Mon, 22 Sep 2003 13:38:08 GMT, "Frank J. Lhota"
>> <NOSPAM.lhota.adarose@verizon.net> wrote:
>> 
>> >"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> >news:j5itmvchgijlria6a9q1m7hsloopveo20d@4ax.com...
>> >> Oh, this is very possible. For example, people trained to eat
>> >> McDonald's food will not accept any decent dish.
>> >
>> >Where do people get TRAINED to eat McDonald's food?
>> 
>> In McDonald's restaurant, I guess. Here in Germany, there is a
>> tradition to go in all family each weekend to a McDonald. Not to a
>> theatre or museum, note.
>
><off-topic mode>
>
>You must be living in a different Germany.
>
></off-topic mode>

Just being afraid of the recent wave of attempts to close orchestras
and theatres all over the country.

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

Re: Is the Writing on the Wall for Ada?

[Steffen Huber]

"Dmitry A. Kazakov" wrote:
> On Mon, 22 Sep 2003 18:45:13 +0200, Steffen Huber <spam@huber-net.de>
> wrote:
> 
> >"Dmitry A. Kazakov" wrote:
[snip]
> >> In McDonald's restaurant, I guess. Here in Germany, there is a
> >> tradition to go in all family each weekend to a McDonald. Not to a
> >> theatre or museum, note.
> >
> ><off-topic mode>
> >
> >You must be living in a different Germany.
> >
> ></off-topic mode>
> 
> Just being afraid of the recent wave of attempts to close orchestras
> and theatres all over the country.

*Hopefully* a lot of that redundant stuff gets closed as soon as possible.
While I love going to to theatre, visiting museums and listen to
classical music, I hate the idea that to provide me with a low enough
entry price, other people's money gets spent.

Look at Berlin. 300 million Euros are paid year by year for their
numerous operas, museums, orchestras, theatres etc.

Nobody has the right to decide that a museum is worth more than a
McDonald's or a Rolling Stones concert if it costs other people's
money to subsidise the "worthy" stuff.

Steffen

-- 
steffen.huber@gmx.de               steffen@huber-net.de
GCC for RISC OS  - http://www.arcsite.de/hp/gcc/
Private homepage - http://www.huber-net.de/

Re: Is the Writing on the Wall for Ada?

[Dmitry A. Kazakov]

On Tue, 23 Sep 2003 18:00:04 +0200, Steffen Huber <spam@huber-net.de>
wrote:

>"Dmitry A. Kazakov" wrote:
>> On Mon, 22 Sep 2003 18:45:13 +0200, Steffen Huber <spam@huber-net.de>
>> wrote:
>> 
>> >"Dmitry A. Kazakov" wrote:
>[snip]
>> >> In McDonald's restaurant, I guess. Here in Germany, there is a
>> >> tradition to go in all family each weekend to a McDonald. Not to a
>> >> theatre or museum, note.
>> >
>> ><off-topic mode>
>> >
>> >You must be living in a different Germany.
>> >
>> ></off-topic mode>
>> 
>> Just being afraid of the recent wave of attempts to close orchestras
>> and theatres all over the country.
>
>*Hopefully* a lot of that redundant stuff gets closed as soon as possible.
>While I love going to to theatre, visiting museums and listen to
>classical music, I hate the idea that to provide me with a low enough
>entry price, other people's money gets spent.

Come on, do you really believe that all our taxes go to keep tickets
cheap?

>Look at Berlin. 300 million Euros are paid year by year for their
>numerous operas, museums, orchestras, theatres etc.
>
>Nobody has the right to decide that a museum is worth more than a
>McDonald's or a Rolling Stones concert if it costs other people's
>money to subsidise the "worthy" stuff.

So, we return back to the proposition: people prefer McDonald's to
museum.

BTW, I agree that subventions in any form is a medicine worse than the
disease.

Now, why science, literatue (except Harry Potter), culture and arts
cannot exist without subventions in our precious society?

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

Re: Is the Writing on the Wall for Ada?

[Steffen Huber]

"Dmitry A. Kazakov" wrote:
[snip]

Taken to email because of incredible off-topicness.

Steffen

-- 
steffen.huber@gmx.de               steffen@huber-net.de
GCC for RISC OS  - http://www.arcsite.de/hp/gcc/
Private homepage - http://www.huber-net.de/

Re: Is the Writing on the Wall for Ada?

[Frank J. Lhota]

WARNING: Complete Off-topic.

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:dsvtmvge015p2toc3d921hc81sc6orrtnl@4ax.com...
> On Mon, 22 Sep 2003 13:38:08 GMT, "Frank J. Lhota"
> >Where do people get TRAINED to eat McDonald's food?
>
> In McDonald's restaurant, I guess. Here in Germany, there is a
> tradition to go in all family each weekend to a McDonald. Not to a
> theatre or museum, note.

Tradition? Not is my family. And I hope that plenty of German families take
advantage of their country's many excellent museums.

> >And if there are so many
> >McDonald's "trainees" out there, what accounts for the drop in McDonald's
> >business over the last few years?
>
> Because of Pizza restaurants? (:-)) Is that much better?

No, the only fast food chain that has not experienced a drop in business
over the past few years is Subway, a chain that serves low-fat sandwiches.

> >The recording industry attempts to reign in file sharing has
> >been inept and ineffective.
>
> Freedom always wins, after all.

I've always thought so.

> >Universal has finally seen the light and taken
> >the right course of action on recorded music. Instead of threatening
their
> >customer base with legal action, Universal announced that they are
reducing
> >the price of their CD's to $10 tops.
>
> [sobbing] Children of Universal's top managers will hunger! (:-))

Actually, Universal music may very well end up making more money than ever.
The drop in per-disk profit could be made up in increased volume.

Re: Is the Writing on the Wall for Ada?

[Amir Yantimirov]

"Frank J. Lhota" <NOSPAM.lhota.adarose@verizon.net> wrote in message news:<x7Hbb.13496$Uv2.10006@nwrdny02.gnilink.net>...
> WARNING: Complete Off-topic.

Back to topic, :)

Is I correct that "Writing on the Wall" means "Mene teckel fares" by
firing letters from Bible?

Amir Yantimirov

Re: Is the Writing on the Wall for Ada?

[Warren W. Gay VE3WWG]

Amir Yantimirov wrote:
> "Frank J. Lhota" <NOSPAM.lhota.adarose@verizon.net> wrote in message news:<x7Hbb.13496$Uv2.10006@nwrdny02.gnilink.net>...
> 
>>WARNING: Complete Off-topic.
> Back to topic, :)
> 
> Is I correct that "Writing on the Wall" means "Mene teckel fares" by
> firing letters from Bible?
> 
> Amir Yantimirov

Yes, that is what I was thinking when I started the thread. I had
no idea that it would carry on like this ;-)

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Is the Writing on the Wall for Ada?

[Dmitry A. Kazakov]

On Mon, 22 Sep 2003 18:24:29 GMT, "Frank J. Lhota"
<NOSPAM.lhota.adarose@verizon.net> wrote:

>WARNING: Complete Off-topic.
>
>"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>news:dsvtmvge015p2toc3d921hc81sc6orrtnl@4ax.com...
>> On Mon, 22 Sep 2003 13:38:08 GMT, "Frank J. Lhota"
>> >Where do people get TRAINED to eat McDonald's food?
>>
>> In McDonald's restaurant, I guess. Here in Germany, there is a
>> tradition to go in all family each weekend to a McDonald. Not to a
>> theatre or museum, note.
>
>Tradition? Not is my family.

Alone using Ada makes all of us statistically irrelevant! (:-))

> And I hope that plenty of German families take
>advantage of their country's many excellent museums.

I hope that you are right.

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

Re: Is the Writing on the Wall for Ada?

[Russ]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote in message news:<dsvtmvge015p2toc3d921hc81sc6orrtnl@4ax.com>...
> On Mon, 22 Sep 2003 13:38:08 GMT, "Frank J. Lhota"
> <NOSPAM.lhota.adarose@verizon.net> wrote:

> >Where do people get TRAINED to eat McDonald's food?
> 
> In McDonald's restaurant, I guess. Here in Germany, there is a
> tradition to go in all family each weekend to a McDonald. Not to a
> theatre or museum, note.

Speaking of McDonald's, I remember reading several years ago that when
the first McDonald's "restaurants" were built in Russia, many Russians
assumed that the food being served was considered fine American
cuisine. Perhaps one of you Russians out there can tell me if that is
true.

Perhaps the French think that too, which would explain their attitude
toward us.

Just to set the record straight, I am an American, and I hope I never
find out how hungry I would have to be to actually *want* to eat at
McDonald's.

My seven-year-old boy loves it though, of course. There's no
accounting for the taste. Come to think of it, I probably did too when
I was seven years old.

Re: Is the Writing on the Wall for Ada?

[Alexander Kopilovitch]

Russ wrote:

> Speaking of McDonald's, I remember reading several years ago that when
> the first McDonald's "restaurants" were built in Russia, many Russians
> assumed that the food being served was considered fine American
> cuisine. Perhaps one of you Russians out there can tell me if that is
> true.

No, it certainly isn't true, it is just wrong angle of view. In those first
McDonalds Russians didn't care about national character of cuisine, but paid
attention to clean rooms and tables, quick service, good-looking and smiling
boys and girls at all service points (they were common Russians, of course,
but well-trained and well-dressed), modest (although not exacly cheap) prices.
And exactly this environment (and not a cuisine) gained popularity for McDonalds
here.

Just one recent counter-example: about a month ago I was walking near the city's
centre, and saw new "BlinDonalds" - local Russian clone of McDonalds (name from
Russian "blin" = crape, pancake) . I entered there, thinking that, perhaps,
I'm willing to eat such a "blin" now. Well, there were indeed good-looking and
cheap meals, and the similar boys and girls at service points, but they weren't
smiling - they were trained not to abuse a customer, but no more; and the service
was very slow, the kitchen was open and entirely visible, and all the boys and
girls shouted orders to the kitchen from time to time. After observing that
situation for 5 minutes I left, because it became obvious that it will take
minimum 15-20 minutes to get that "blin". I hope that this counter-example is
sufficient for some understanding - why McDonalds became (and still are) quite
popular here.



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

Re: Is the Writing on the Wall for Ada?

[Chad R. Meiners]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:dsvtmvge015p2toc3d921hc81sc6orrtnl@4ax.com...
> Sorry, that was not Wirth, but Edsger W. Dijkstra:
>
> "It is practically impossible to teach good programming style to
> students that have had prior exposure to BASIC: as potential
> programmers they are mentally mutilated beyond hope of regeneration."
>
> Maybe Bill is also a Nobel Prize nominee for this year, or Dijkstra
> had missed something. Well, reading the list of Nobel Peace Awards,
> maybe, maybe...

Well Dijkstra's point about BASIC was wrong.  BASIC was my first language
and I turned out fine.  Furthermore, I know others whose first language was
BASIC, and they turned out fine too.

-CRM

Re: Is the Writing on the Wall for Ada?

[Hyman Rosen]

Chad R. Meiners wrote:
> Well Dijkstra's point about BASIC was wrong.  BASIC was my first language
> and I turned out fine.  Furthermore, I know others whose first language was
> BASIC, and they turned out fine too.

My first language was BASIC as well.
Take that as you will :-)

Re: Is the Writing on the Wall for Ada?

[Warren W. Gay VE3WWG]

Hyman Rosen wrote:

> Chad R. Meiners wrote:
> 
>> Well Dijkstra's point about BASIC was wrong.  BASIC was my first language
>> and I turned out fine.  Furthermore, I know others whose first 
>> language was
>> BASIC, and they turned out fine too.
> 
> My first language was BASIC as well.
> Take that as you will :-)

Well my first language was FORTRAN, and I am still recovering
from it.  What amazes me though, is that they continue to muck
about with it with newer versions of the dialect. It appears to
have an incredible amount of "bags on the sides".
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Is the Writing on the Wall for Ada?

[Alexander Kopilovitch]

Dmitry A. Kazakov wrote: in message 

> >> Come on! Everybody had a vision of a TV set.
> >
> >Well, and which scientific concepts are represented by this wooden or plastic
> >box with a glass screen showing dynamic images and something inside producing
> >speech and music?
> 
> To peceive and to understand are well different things.

If a person was unable to learn that from his/her contacts with other persons
(of opposite sex, for a strong example) than TV box surely will not help.

> >It's impossible - to train not to recognize - at least at current state-of-art
> >and not a single person, but a big part of population. You can (with big and
> >very costly effort) block a particular way of recognition, but no more.
> 
> Oh, this is very possible. For example, people trained to eat
> McDonald's food will not accept any decent dish.

You are certainly wrong. Those habits easily change in several weeks in
appropriate (even not severe) circumstances, for almost every person.

> People permanently
> watching MTV are unable to recognize virtually any music.

This is wrong also. They just may be unable to recognize that this *is called*
music, because they reserved that term to MTV production, but this generally
do not make them deaf to another kinds of music - it just should not be abstract,
and should not require special training.

> Wirth wrote
> that students once exposed to Basic are beyond any hope...

Well, this was true in some sense, but the difference is that programming is
more about creation then about consumption or perception.
 
> >> Hal Clement
> >...
> Strugatsky called him Jules Verne of XX century. They translated his
> Mission of Gravity - one of the best science fiction novels.

Hm, 20th century was not the best time for "Jules Verne" -;) . And the gravity
is not the best subject for manipulation, for many reasons... Well, perhaps
there will be some chance to see...

> >Given current circumstances regarding intellectual property, I can't resist
> >to ask question: if knowledge, rather than money, is a measure of success,
> >doesn't this mean that knowledge became a property in that science-oriented
> >society? -;)
> 
> In my dilettantish opinion, there is a difference, knowledge is
> difficult to separate from its carrier.

But a carrier can be severely restricted (if not imprisoned... or even killed
after he shared his knowledge with another person) - by state or corporate
secrecy/security rules, copyright or patent laws (don't forget that copyright
and patent rights may be sold and bought). In such a situation the real measure
of success is not carrying knowledge, but having rights and/or control of it.
Not much difference from money, I think.

> The-Mickey-Mouse-movement
> against freedom of speech was so successfull

I do not think, that it was successful. On the contrary, I think that its
current choice is between retreat and rout in near future.

> because in case of
> recorded music and movies it was relatively easy to do.

Just as mocking science and irresponsible engineering. It is not easy (and even
relatively easy) to create popular music or movies of high quality (like, say,
Nino Rota... or Webber in JCS and Evita - in music, and, say, Casablanca - for
movie).
 
> >> ...people grown in rich families often despise
> >> money and become anarchists, socialists, anti-globalists, greens etc.
> >> They just take wealth [created by others] for granted.
> >
> >I don't know how often it happens (I never meet such persons, and I strongly
> >suspect that you also have no reliable sources for statistics about this
> >phenomena), but anyway I do not count those, almost always young people being
> >so stupid - I think they just are trying other values... rich families provide
> >them possibility for an experiment without too much danger for their present
> >and future status - so why not to use this opportunity (sometimes)... ?
> 
> This is what I meant. This is the pattern. It is like a believer,
> visiting shrines of all possible gods, church, mosque and not
> forgetting to buy a horoscope and a herbalife course, just in case.
> (:-))

Something of this sort... many young people naturally try to find their own
tastes and places. But as you specifically mentioned rich then don't forget
about one of the major system roles of rich - many of them are just testers
- they test things on themselves - so for some part of young rich this can be
just good training for their future role.



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

Re: Is the Writing on the Wall for Ada?

[Dmitry A. Kazakov]

On 22 Sep 2003 19:05:30 -0700, aek@vib.usr.pu.ru (Alexander
Kopilovitch) wrote:

>Dmitry A. Kazakov wrote: in message 
>
>> >It's impossible - to train not to recognize - at least at current state-of-art
>> >and not a single person, but a big part of population. You can (with big and
>> >very costly effort) block a particular way of recognition, but no more.
>> 
>> Oh, this is very possible. For example, people trained to eat
>> McDonald's food will not accept any decent dish.
>
>You are certainly wrong. Those habits easily change in several weeks in
>appropriate (even not severe) circumstances, for almost every person.

Oh, I observed many children. As a rule, they prefer McDonald's to
normal food, Milka/Snickers to good chocolate, coca-cola to other
drinks. Compare it with software developers, which definetely prefer
C++ and Java to Ada. You can spend all your life trying to explain
them that McDonald's or C++ is bad, but they still will. Reflexes are
stronger than any explanations.

>> People permanently
>> watching MTV are unable to recognize virtually any music.
>
>This is wrong also. They just may be unable to recognize that this *is called*
>music, because they reserved that term to MTV production, but this generally
>do not make them deaf to another kinds of music - it just should not be abstract,
>and should not require special training.

Training is essential in understanding music. More complex it is,
higher the level of training required. As for "MTV music", it also
requires a lot of training, but for other reasons.

>> Wirth wrote
>> that students once exposed to Basic are beyond any hope...
>
>Well, this was true in some sense, but the difference is that programming is
>more about creation then about consumption or perception.

Understanding of good music also requires some creative efforts.

>> >Given current circumstances regarding intellectual property, I can't resist
>> >to ask question: if knowledge, rather than money, is a measure of success,
>> >doesn't this mean that knowledge became a property in that science-oriented
>> >society? -;)
>> 
>> In my dilettantish opinion, there is a difference, knowledge is
>> difficult to separate from its carrier.
>
>But a carrier can be severely restricted (if not imprisoned... or even killed
>after he shared his knowledge with another person)

It would be too expensive. If you mean Stalin's methods, remeber that
he was looting the potential built before him.

> - by state or corporate
>secrecy/security rules, copyright or patent laws (don't forget that copyright
>and patent rights may be sold and bought).

Copyright on knowledge, what is that? You can probably patent 2+2=4,
but how can you prevent me from using this knowledge? I mean to build
an *effective* legal system protecting such patents? How to prove that
i=sqrt(-1) is based on 2+2=4? Imagine a court, where such case could
be brought in!

>In such a situation the real measure
>of success is not carrying knowledge, but having rights and/or control of it.
>Not much difference from money, I think.

There is a difference, you cannot control it without killing it.
Science is rooted in freedom. Church, Communists tried first to
control and then to fight against it, and they lost. There will be
others...

>Just as mocking science and irresponsible engineering. It is not easy (and even
>relatively easy) to create popular music or movies of high quality (like, say,
>Nino Rota... or Webber in JCS and Evita - in music, and, say, Casablanca - for
>movie).

Does recording industry create any music? They sell it!
 
>> >> ...people grown in rich families often despise
>> >> money and become anarchists, socialists, anti-globalists, greens etc.
>> >> They just take wealth [created by others] for granted.
>> >
>> >I don't know how often it happens (I never meet such persons, and I strongly
>> >suspect that you also have no reliable sources for statistics about this
>> >phenomena), but anyway I do not count those, almost always young people being
>> >so stupid - I think they just are trying other values... rich families provide
>> >them possibility for an experiment without too much danger for their present
>> >and future status - so why not to use this opportunity (sometimes)... ?
>> 
>> This is what I meant. This is the pattern. It is like a believer,
>> visiting shrines of all possible gods, church, mosque and not
>> forgetting to buy a horoscope and a herbalife course, just in case.
>> (:-))
>
>Something of this sort... many young people naturally try to find their own
>tastes and places. But as you specifically mentioned rich then don't forget
>about one of the major system roles of rich - many of them are just testers
>- they test things on themselves - so for some part of young rich this can be
>just good training for their future role.

I'd prefer them testing a scientific hypothesis rather than joints.

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

Re: Is the Writing on the Wall for Ada?

[Alexander Kopilovitch]

Dmitry A. Kazakov wrote:

> Oh, I observed many children. As a rule, they prefer McDonald's to
> normal food, Milka/Snickers to good chocolate, coca-cola to other
> drinks.

I guess they have no (or little) choice: the environment matters more
than
a food. Give them to choose between standard McDonals food and normal
food,
but in exactly the same environment, and do that several times - and
then
observe what they choose.

> Compare it with software developers, which definetely prefer
> C++ and Java to Ada. You can spend all your life trying to explain
> them that McDonald's or C++ is bad, but they still will. Reflexes are
> stronger than any explanations.

Reflexes don't matter here. The situation is indeed somehow similar to
the
McDonalds and children: an environment matters more then a food, and
there is
usually little or no choice. Besides all that things like
availability,
familiarity, costs etc., there is a fundamental obstacle: Ada presumes
full
and thorough design, while neither C++ nor Java don't. You can build
some
half-prototype/half-product in C++ or Java, and hope to complete
(somehow)
the rest of design and then the real application later. But it will be
much
more difficult to follow that way in Ada. And very often during
initial stage
of a project any future savings don't matter much, just because it is
quite
unclear whether the project will have any future.

>Training is essential in understanding music.

Generally, no. Good popular music do not (and should not) require any
special
training. Note also, that a part of Mozart's music and even some of
Beethoven's
music do not require any special training for undoubtful appreciation.

> Understanding of good music also requires some creative efforts.

I can't judge for so-called "serious" music, but I believe that those
efforts
should not be called "creative", but just "imaginative". Because those
efforts,
as a rule, do not create anything persistent, but only short-lived
phantoms
or moods.

> >> >Given current circumstances regarding intellectual property, I can't resist
> >> >to ask question: if knowledge, rather than money, is a measure of success,
> >> >doesn't this mean that knowledge became a property in that science-oriented
> >> >society? -;)
> >> 
> >> In my dilettantish opinion, there is a difference, knowledge is
> >> difficult to separate from its carrier.
> >
> >But a carrier can be severely restricted (if not imprisoned... or even killed
> >after he shared his knowledge with another person)
>
> It would be too expensive. If you mean Stalin's methods, remeber that
> he was looting the potential built before him.

So what? You certainly can't say that we have (or will have) too
little potential
for looting. And note that Western (educated) public admired Orwell's
"1984"
not just because of some analogies with Stalinism.

> > - by state or corporate
> >secrecy/security rules, copyright or patent laws (don't forget that copyright
> >and patent rights may be sold and bought).
>
> Copyright on knowledge, what is that? You can probably patent 2+2=4,
> but how can you prevent me from using this knowledge? I mean to build
> an *effective* legal system protecting such patents? How to prove that
> i=sqrt(-1) is based on 2+2=4? Imagine a court, where such case could
> be brought in!

I can easily imagine such a court. All judges will be not only
graduated from
well-known universities, but have Ph.D. also, and perhaps will be
members of
some Academias. No problem with that, and never been. (Yes, certainly
there
will be dissidents also, of both kinds - persecuted and tolerated).

> >In such a situation the real measure
> >of success is not carrying knowledge, but having rights and/or control of it.
> >Not much difference from money, I think.
>
> > There is a difference, you cannot control it without killing it.
> > Science is rooted in freedom.

This is a popular slogan, no more. How much freedom had Copernicus?
Galileo?
Newton? Gauss? Fermat? They all had some, quite little freedom, and
apparently
had no need for much more for their scientific purposes.

Perhaps you mean not individual, but collective scientific efforts.
Well, for
that some extended freedom is actually needed. Well, "Brave New World"
was quite
scientific... Collective activity can be controlled more easily than
individual
one, even some perception of a freedom may be retained without losing
control.

One serious problem of our time is that USA, being the Land of
Engineers,
can't agree with that science and engineering aren't the same, and
consistently
tries to convert science to engineering. And with huge influence from
USA this
becomes influental tendency worldwide. They want to "do math", then
they will
want to "do physics", "do biology" etc, An attempt to achieve harmony
between
"do" and "think" inside an individual, as a standard (for educated
people).
A stupid version of this idea was tried in exUSSR and failed
beautifully, long before
the collapse of USSR (but nevertheless, it contributed to that
collapse).
USA's approach is certainly much cleverer tactically, and much more
cautious -
so, hopefully its future failure will be more graceful. (Just a remark
about
relations between social architecture designs and requirements for
circutry
base, not that much off-topic as it probably seems -;) .



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

Re: Is the Writing on the Wall for Ada?

[Dmitry A. Kazakov]

On 23 Sep 2003 19:52:06 -0700, aek@vib.usr.pu.ru (Alexander
Kopilovitch) wrote:

>Dmitry A. Kazakov wrote:
>
>> Oh, I observed many children. As a rule, they prefer McDonald's to
>> normal food, Milka/Snickers to good chocolate, coca-cola to other
>> drinks.
>
>I guess they have no (or little) choice: the environment matters more
>than a food. Give them to choose between standard McDonals food and normal
>food, but in exactly the same environment, and do that several times - and
>then observe what they choose.

I did. I have many friends with children and most of them tried. Many
of them did it hard. No success.

>> Compare it with software developers, which definetely prefer
>> C++ and Java to Ada. You can spend all your life trying to explain
>> them that McDonald's or C++ is bad, but they still will. Reflexes are
>> stronger than any explanations.
>
>Reflexes don't matter here. The situation is indeed somehow similar to
>the McDonalds and children: an environment matters more then a food, and
>there is usually little or no choice. Besides all that things like
>availability, familiarity, costs etc.,

Children known no such words. They just yell - mum, I want Donald's!

>there is a fundamental obstacle: Ada presumes
>full and thorough design, while neither C++ nor Java don't. You can build
>some half-prototype/half-product in C++ or Java, and hope to complete
>(somehow) the rest of design and then the real application later. But it will be
>much more difficult to follow that way in Ada.

Why? Ada cannot prevent "C++ design". Also C++ does not enforce it
that much.

Half-baked design is a result of half-baked programmes and uneducated
managers. This is mostly because of the amount of projects developed
in C++. Should Ada be used instead, by same programmers led by same
managers, the result would be much same. The adavantages of Ada
appears at a definite level of competence, and only when extensive
methods of software development are replaced by intensive ones.

>>Training is essential in understanding music.
>
>Generally, no. Good popular music do not (and should not) require any
>special training.

I meant rather simple things. For instance, "don't chew, when you hear
music". (:-))

>> >> >Given current circumstances regarding intellectual property, I can't resist
>> >> >to ask question: if knowledge, rather than money, is a measure of success,
>> >> >doesn't this mean that knowledge became a property in that science-oriented
>> >> >society? -;)
>> >> 
>> >> In my dilettantish opinion, there is a difference, knowledge is
>> >> difficult to separate from its carrier.
>> >
>> >But a carrier can be severely restricted (if not imprisoned... or even killed
>> >after he shared his knowledge with another person)
>>
>> It would be too expensive. If you mean Stalin's methods, remeber that
>> he was looting the potential built before him.
>
>So what? You certainly can't say that we have (or will have) too
>little potential for looting.

Yet, it gone and the empire collapsed.

>And note that Western (educated) public admired Orwell's
>"1984" not just because of some analogies with Stalinism.

They welcomed Stalin and recently Saddam. Sort of weakness for tyrants
with moustache ...

>> > - by state or corporate
>> >secrecy/security rules, copyright or patent laws (don't forget that copyright
>> >and patent rights may be sold and bought).
>>
>> Copyright on knowledge, what is that? You can probably patent 2+2=4,
>> but how can you prevent me from using this knowledge? I mean to build
>> an *effective* legal system protecting such patents? How to prove that
>> i=sqrt(-1) is based on 2+2=4? Imagine a court, where such case could
>> be brought in!
>
>I can easily imagine such a court. All judges will be not only
>graduated from well-known universities, but have Ph.D. also, and perhaps will be
>members of some Academias.

Sort of those flourishing now in Russia? If you mean *real* Academias,
remember, that USSR Academia refused to expell Sakharov. True
scientists are hard to manipulate.

>No problem with that, and never been. (Yes, certainly
>there will be dissidents also, of both kinds - persecuted and tolerated).
>
>> >In such a situation the real measure
>> >of success is not carrying knowledge, but having rights and/or control of it.
>> >Not much difference from money, I think.
>>
>> > There is a difference, you cannot control it without killing it.
>> > Science is rooted in freedom.
>
>This is a popular slogan, no more. How much freedom had Copernicus?
>Galileo?
>Newton? Gauss? Fermat? They all had some, quite little freedom, and
>apparently had no need for much more for their scientific purposes.

Their personal freedom was not restricted. And they openly discussed
the issues they wished. Galileo was charged *after* he published a
work revolting the curch. In USSR he would be never able to do so.

>Perhaps you mean not individual, but collective scientific efforts.
>Well, for that some extended freedom is actually needed. Well, "Brave New World"
>was quite scientific...

As scientific as the communist theory was.

>Collective activity can be controlled more easily than
>individual one,

As long as that activity is concetrated on digging ditches...

>even some perception of a freedom may be retained without losing
>control.

I'd recommend you read Feinman memoirs about his work under strict
[army] control in the atomic project. Well, generals didn't lose a
perception of control ...

>One serious problem of our time is that USA, being the Land of Engineers,
>can't agree with that science and engineering aren't the same, and
>consistently tries to convert science to engineering.

Egh? How so. In my view USA is the last hope of humankind.

>And with huge influence from
>USA this becomes influental tendency worldwide. They want to "do math", then
>they will want to "do physics", "do biology" etc, An attempt to achieve harmony
>between "do" and "think" inside an individual, as a standard (for educated
>people).

All is better than "do money".

>A stupid version of this idea was tried in exUSSR and failed
>beautifully, long before the collapse of USSR (but nevertheless, it contributed to that
>collapse). USA's approach is certainly much cleverer tactically, and much more
>cautious - so, hopefully its future failure will be more graceful. (Just a remark
>about relations between social architecture designs and requirements for
>circutry base, not that much off-topic as it probably seems -;) .

So far, it is Russia and EU which fail.

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

Re: Is the Writing on the Wall for Ada?

[Alexander Kopilovitch]

Dmitry A. Kazakov wrote:

> >I guess they have no (or little) choice: the environment matters more
> >than a food. Give them to choose between standard McDonals food and normal
> >food, but in exactly the same environment, and do that several times - and
> >then observe what they choose.
>
> I did. I have many friends with children and most of them tried. Many
> of them did it hard. No success.

Probably they weren't aware of experintation technique. I guess they simply
tried to achieve an aim, not to discover significant factors, relations, and
stable system states. In particular, I suspect that they did not provide
equivalent external (for a food) conditions (spatial, temporal and mindset).

> >> Compare it with software developers, which definetely prefer
> >> C++ and Java to Ada. You can spend all your life trying to explain
> >> them that McDonald's or C++ is bad, but they still will. Reflexes are
> >> stronger than any explanations.
> >
> >Reflexes don't matter here. The situation is indeed somehow similar to
> >the McDonalds and children: an environment matters more then a food, and
> >there is usually little or no choice. Besides all that things like
> >availability, familiarity, costs etc.,
>
>Children known no such words. They just yell - mum, I want Donald's!

But there are parents who should know these words; children's knowledge is
irrelevant for meta-issues, children never operate at meta-level.

> >there is a fundamental obstacle: Ada presumes
> >full and thorough design, while neither C++ nor Java don't. You can build
> >some half-prototype/half-product in C++ or Java, and hope to complete
> >(somehow) the rest of design and then the real application later. But it will be
> >much more difficult to follow that way in Ada.
>
> Why? Ada cannot prevent "C++ design". Also C++ does not enforce it
> that much.

Certainly Ada cannot prevent, and C++ does not enforce anything. The difference
is in what is presumed in language design and to which degree. If you follow
the language design assumptions then the language's design trade-offs will work
for you; otherwise they will work against you, and you will spend much effort
for overcoming various obstacles and will suffer from various inconveniences.

> Half-baked design is a result of half-baked programmes and uneducated
> managers.

I think, no. It is most often a result of substantially incomplete problem
statement and incompetence (of the team) in problem domain.

> This is mostly because of the amount of projects developed
> in C++. Should Ada be used instead, by same programmers led by same
> managers, the result would be much same.

Yes, I agree with that.

> The adavantages of Ada
> appears at a definite level of competence, and only when extensive
> methods of software development are replaced by intensive ones.

I do not think that most of advantages of Ada are related to the skills in
software development. I believe that they are related to compentence in problem
domain. (But if the problem domain itself is the software development then
well, the software development skills are naturally most significant in the case.)

> >>Training is essential in understanding music.
> >
> >Generally, no. Good popular music do not (and should not) require any
> >special training.
>
> I meant rather simple things. For instance, "don't chew, when you hear
> music". (:-))

I tend to disagree with this rule in the form it was presented.  I think that
a proper rule should mention not music in general, but specific circumstances,
which involves other people. Well, I have no habit of chewing, but I certainly
want an opportunity to hear music in my kitchen, drinking coffee and smoking.

> >> >> >Given current circumstances regarding intellectual property, I can't resist
> >> >> >to ask question: if knowledge, rather than money, is a measure of success,
> >> >> >doesn't this mean that knowledge became a property in that science-oriented
> >> >> >society? -;)
> >> >> 
> >> >> In my dilettantish opinion, there is a difference, knowledge is
> >> >> difficult to separate from its carrier.
> >> >
> >> >But a carrier can be severely restricted (if not imprisoned... or even killed
> >> >after he shared his knowledge with another person)
> >>
> >> It would be too expensive. If you mean Stalin's methods, remeber that
> >> he was looting the potential built before him.
> >
> >So what? You certainly can't say that we have (or will have) too
> >little potential for looting.
>
> Yet, it gone and the empire collapsed.

Yes, so what? Why not to repeat? Final collapse doesn't matter, it will be
somewhere in future and perhaps another generation will deal with it.

> >And note that Western (educated) public admired Orwell's
> >"1984" not just because of some analogies with Stalinism.
>
> They welcomed Stalin

What? Are you implying that they also welcomed Franco and Mussolini? Do you
think that they dream that tomorrow Stalin or an equivalent will rule in their
own countries?

> and recently Saddam.

We certainly read different BBCs. I am not aware of those educated Western
people who welcomed Saddam. But at the same time I know that many people
were and are very dissatisfied with obvious lies of their governments about
the reasons for the recent war action. Notice, that the problem is not much
in the war action itself, but in that the possible true and valid reasons were
substitued by obvious lies. Why I use that strong term "obvious" here? Just
because I can *prove* that there were lies about WMD, and could prove that in
the time of preparations for the war action. And I'm quite sure that I was
not alone who understood how to prove that - the proof isn't too difficult,
just some experience in polical observation, and some history (40,,, and even
30 years of depth is enough).

> Sort of weakness for tyrants with moustache ...

Drop that stupid myth about moustache, better view an excellent documentary
film "Triumph of Will" ("Triumph Des Willens", Leni Riefenstahl, 1935). Even
in that film you will see that there was much more than moustache.

> >> > - by state or corporate
> >> >secrecy/security rules, copyright or patent laws (don't forget that copyright
> >> >and patent rights may be sold and bought).
> >>
> >> Copyright on knowledge, what is that? You can probably patent 2+2=4,
> >> but how can you prevent me from using this knowledge? I mean to build
> >> an *effective* legal system protecting such patents? How to prove that
> >> i=sqrt(-1) is based on 2+2=4? Imagine a court, where such case could
> >> be brought in!
> >
> >I can easily imagine such a court. All judges will be not only
> >graduated from well-known universities, but have Ph.D. also, and perhaps will be
> >members of some Academias.
>
> Sort of those flourishing now in Russia?

Sort of those flourishing now in many places/countries, and Russia is just
like many others in that respect, just not yet polished enough. Don't make
much illusions about so-called developed world... although the situation
varies from country to country, potential for resistance is different.

> If you mean *real* Academias,
> remember, that USSR Academia refused to expell Sakharov.

Don't overestimate that story. Remember, that Sakharov was very special case
for Communist authorities because of its supposed role in development of
Soviet nuclear weapon. Those times Communist authorites tried hard to remember
and reward scientists who substantially helped in weapon development, even if
those scientists later deviated from party line and even became dissidents (or
helped dissidents). Recall that even when Sakharov went in open opposition and
was publicly condemned, he was sent neither to trial and prison nor to psychiatric
hospital, but just in Gorky - quite big city and strong scientific center with
many intellectuals, under some sort of house arrest, but not severe. So, the
pressure on academics for expelling Sakharov was not strong, and when they
refused nobody insisted.

> True scientists are hard to manipulate.

Well, perhaps sometimes this true. Although history says nothing definite on
this matter. Anyway, the numbers of true scientists always are rather small,
so it does not help.

> Galileo was charged *after* he published a
> work revolting the curch. In USSR he would be never able to do so.

Generally no - although unlikely. It might happen in USSR that a heresy might
not be recognized in advance, and the book published - and only after a month,
a year (or even several years) the storm exploded and the book went into hiding.

> >even some perception of a freedom may be retained without losing
> >control.
>
> I'd recommend you read Feinman memoirs about his work under strict
> [army] control in the atomic project. Well, generals didn't lose a
> perception of control ...

Well, reading Feynman is almost always a pleasure, so I will read that if I
get it somehow (without spending much money for it). But I think I know that
matter well enough from old Soviet sources... not books, but private communications
- that was my childhood inside a fence, and some people around me were quite
good physisists, of the rank not much lower than Feynman's. I remember attemps
to guess how nuclear bullets are possible, short rumors about neutron bombs -
in early sixties.

> >One serious problem of our time is that USA, being the Land of Engineers,
> >can't agree with that science and engineering aren't the same, and
> >consistently tries to convert science to engineering.
>
> Egh? How so. In my view USA is the last hope of humankind.

Well, there were episodes in recent century when USA was indeed the last hope
of our sort of civilization, and USA fulfilled that hope. And that may be
repeated once more, who knows. But that does not imply that particular serious
problems can't be originated and developed in USA. And that does not imply
that all people outside USA should be hopeful spectators only.

> >And with huge influence from
> >USA this becomes influental tendency worldwide. They want to "do math", then
> >they will want to "do physics", "do biology" etc, An attempt to achieve harmony
> >between "do" and "think" inside an individual, as a standard (for educated
> >people).

> All is better than "do money".

No. It is worse. Because money is just ephemerical criteria, just commonly
agreed abstract notion, just place and role in the social system, and not a
way of perception of fundamental things and processes. Money is entirely human
and even entirely social matter, it exists only inside and because of human
civilization - so, one almost never can just "make money" - as a rule, he must
understand and do something other for that. So, money is just intermediate
entity, which generally doesn't isolate people from reality.



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

Re: Is the Writing on the Wall for Ada?

[Dmitry A. Kazakov]

On 24 Sep 2003 19:51:34 -0700, aek@vib.usr.pu.ru (Alexander
Kopilovitch) wrote:

>Dmitry A. Kazakov wrote:
>
>> >I guess they have no (or little) choice: the environment matters more
>> >than a food. Give them to choose between standard McDonals food and normal
>> >food, but in exactly the same environment, and do that several times - and
>> >then observe what they choose.
>>
>> I did. I have many friends with children and most of them tried. Many
>> of them did it hard. No success.
>
>Probably they weren't aware of experintation technique. I guess they simply
>tried to achieve an aim, not to discover significant factors, relations, and
>stable system states. In particular, I suspect that they did not provide
>equivalent external (for a food) conditions (spatial, temporal and mindset).

And a belt as an external condition (:-))

>> >> Compare it with software developers, which definetely prefer
>> >> C++ and Java to Ada. You can spend all your life trying to explain
>> >> them that McDonald's or C++ is bad, but they still will. Reflexes are
>> >> stronger than any explanations.
>> >
>> >Reflexes don't matter here. The situation is indeed somehow similar to
>> >the McDonalds and children: an environment matters more then a food, and
>> >there is usually little or no choice. Besides all that things like
>> >availability, familiarity, costs etc.,
>>
>>Children known no such words. They just yell - mum, I want Donald's!
>
>But there are parents who should know these words; children's knowledge is
>irrelevant for meta-issues, children never operate at meta-level.

Yep, they operate a reflex basis.

>> >there is a fundamental obstacle: Ada presumes
>> >full and thorough design, while neither C++ nor Java don't. You can build
>> >some half-prototype/half-product in C++ or Java, and hope to complete
>> >(somehow) the rest of design and then the real application later. But it will be
>> >much more difficult to follow that way in Ada.
>>
>> Why? Ada cannot prevent "C++ design". Also C++ does not enforce it
>> that much.
>
>Certainly Ada cannot prevent, and C++ does not enforce anything. The difference
>is in what is presumed in language design and to which degree. If you follow
>the language design assumptions then the language's design trade-offs will work
>for you; otherwise they will work against you, and you will spend much effort
>for overcoming various obstacles and will suffer from various inconveniences.

Right, but the language design assumtions do not influence the
software design approach in a direct way. I do not see why it should
be more difficult to make incomplete products in Ada.

>> Half-baked design is a result of half-baked programmes and uneducated
>> managers.
>
>I think, no. It is most often a result of substantially incomplete problem
>statement and incompetence (of the team) in problem domain.

These are the consequences. An uneducated manager is incompetent in
any problem domain, except for organizing useless meetings. More
uneducated he and his team are, more global problems they challenge.

>> The adavantages of Ada
>> appears at a definite level of competence, and only when extensive
>> methods of software development are replaced by intensive ones.
>
>I do not think that most of advantages of Ada are related to the skills in
>software development. I believe that they are related to compentence in problem
>domain. (But if the problem domain itself is the software development then
>well, the software development skills are naturally most significant in the case.)

The point was that to see any difference beteen an axe and a razor,
one should stop cutting the lawn and try to have a shave ...

>> >>Training is essential in understanding music.
>> >
>> >Generally, no. Good popular music do not (and should not) require any
>> >special training.
>>
>> I meant rather simple things. For instance, "don't chew, when you hear
>> music". (:-))
>
>I tend to disagree with this rule in the form it was presented.  I think that
>a proper rule should mention not music in general, but specific circumstances,
>which involves other people. Well, I have no habit of chewing, but I certainly
>want an opportunity to hear music in my kitchen, drinking coffee and smoking.

There are simple physical reasons of human ear construction behind
this rule. (:-))

>> >> >> >Given current circumstances regarding intellectual property, I can't resist
>> >> >> >to ask question: if knowledge, rather than money, is a measure of success,
>> >> >> >doesn't this mean that knowledge became a property in that science-oriented
>> >> >> >society? -;)
>> >> >> 
>> >> >> In my dilettantish opinion, there is a difference, knowledge is
>> >> >> difficult to separate from its carrier.
>> >> >
>> >> >But a carrier can be severely restricted (if not imprisoned... or even killed
>> >> >after he shared his knowledge with another person)
>> >>
>> >> It would be too expensive. If you mean Stalin's methods, remeber that
>> >> he was looting the potential built before him.
>> >
>> >So what? You certainly can't say that we have (or will have) too
>> >little potential for looting.
>>
>> Yet, it gone and the empire collapsed.
>
>Yes, so what? Why not to repeat? Final collapse doesn't matter, it will be
>somewhere in future and perhaps another generation will deal with it.

Because the stock is empty now.

>> >And note that Western (educated) public admired Orwell's
>> >"1984" not just because of some analogies with Stalinism.
>>
>> They welcomed Stalin
>
>What? Are you implying that they also welcomed Franco and Mussolini?

Mussolini had no moustache.

>Do you think that they dream that tomorrow Stalin or an equivalent will rule in their
>own countries?

Probably yes.

>> and recently Saddam.
>
>We certainly read different BBCs. I am not aware of those educated Western
>people who welcomed Saddam.

Maybe "welcome" was a wrong word. But BBC World always tried to
represent Saddam and US as morally equivalent sides. They promptly
passed Saddam's propaganda without any analysis or comments.

>But at the same time I know that many people
>were and are very dissatisfied with obvious lies of their governments about
>the reasons for the recent war action. Notice, that the problem is not much
>in the war action itself, but in that the possible true and valid reasons were
>substitued by obvious lies.

Which appeared to be the single possible way. Whom to blaim?

>> Sort of weakness for tyrants with moustache ...
>
>Drop that stupid myth about moustache, better view an excellent documentary
>film "Triumph of Will" ("Triumph Des Willens", Leni Riefenstahl, 1935).

I find it neither excellent nor documentary. Yes, Leni influenced the
modern body lotion commercials. This is her place in the history of
art.

>Even in that film you will see that there was much more than moustache.

To be like others, to share everything with others, to vibrate with
others in an extatic "consensus"...

>> If you mean *real* Academias,
>> remember, that USSR Academia refused to expell Sakharov.
>
>Don't overestimate that story. Remember, that Sakharov was very special case
>for Communist authorities because of its supposed role in development of
>Soviet nuclear weapon.

Huh, Trotzky's role in grounding Soviet Army didn't save him from
ice-axe. 

>> True scientists are hard to manipulate.
>
>Well, perhaps sometimes this true. Although history says nothing definite on
>this matter. Anyway, the numbers of true scientists always are rather small,
>so it does not help.

So the court we are talking about were incompetent. That's the point.

>> >One serious problem of our time is that USA, being the Land of Engineers,
>> >can't agree with that science and engineering aren't the same, and
>> >consistently tries to convert science to engineering.
>>
>> Egh? How so. In my view USA is the last hope of humankind.
>
>Well, there were episodes in recent century when USA was indeed the last hope
>of our sort of civilization, and USA fulfilled that hope. And that may be
>repeated once more, who knows. But that does not imply that particular serious
>problems can't be originated and developed in USA. And that does not imply
>that all people outside USA should be hopeful spectators only.

At least, they could stop accusing America in the faults of their own!

>> >And with huge influence from
>> >USA this becomes influental tendency worldwide. They want to "do math", then
>> >they will want to "do physics", "do biology" etc, An attempt to achieve harmony
>> >between "do" and "think" inside an individual, as a standard (for educated
>> >people).
>
>> All is better than "do money".
>
>No. It is worse. Because money is just ephemerical criteria, just commonly
>agreed abstract notion, just place and role in the social system, and not a
>way of perception of fundamental things and processes. Money is entirely human
>and even entirely social matter, it exists only inside and because of human
>civilization - so, one almost never can just "make money" - as a rule, he must
>understand and do something other for that. So, money is just intermediate
>entity, which generally doesn't isolate people from reality.

While doing mathematics isolates? Actually money were invented to
isolate reality. To exchange something real for something having only
an imaginary value.

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

Re: Is the Writing on the Wall for Ada?

[Alexander Kopilovitch]

Dmitry A. Kazakov wrote:

> >> >there is a fundamental obstacle: Ada presumes
> >> >full and thorough design, while neither C++ nor Java don't. You can build
> >> >some half-prototype/half-product in C++ or Java, and hope to complete
> >> >(somehow) the rest of design and then the real application later. But it will be
> >> >much more difficult to follow that way in Ada.
> >>
> >> Why? Ada cannot prevent "C++ design". Also C++ does not enforce it
> >> that much.
> >
> >Certainly Ada cannot prevent, and C++ does not enforce anything. The difference
> >is in what is presumed in language design and to which degree. If you follow
> >the language design assumptions then the language's design trade-offs will work
> >for you; otherwise they will work against you, and you will spend much effort
> >for overcoming various obstacles and will suffer from various inconveniences.
>
> Right, but the language design assumtions do not influence the
> software design approach in a direct way.

In practice there are always expectations about future implementation opportunities
and problems, and those expectations usually influence design substantially.
But what is more significant, if you aren't familiar with the problem domain,
then programming (or software engineering) terminology necessarily becomes your
internal design language; general notions (like List, Queue, etc.) usually
aren't enough, and for the rest part of the design you will use either forms
from a programming language or their imprecise glimpses.

> I do not see why it should
> be more difficult to make incomplete products in Ada.

Because it takes much more expertise in the language for making useful imprecise
glimpses of the language's forms in Ada than in C++. Just becase Ada was designed
primarily for use in environments where competence in the problem domain can
be assumed (and therefore those things should no be needed), while C++ inherits
all its basic OO machinery from universal modelling language (Simula-67).

> >> Half-baked design is a result of half-baked programmes and uneducated
> >> managers.
> >
> >I think, no. It is most often a result of substantially incomplete problem
> >statement and incompetence (of the team) in problem domain.
>
> These are the consequences.

Sometimes, but far from always. Quite often people that are generally educated
and sufficiently competent in some problem domain(s) are throwed to other problem
domains (in which they are incompetent) without any preliminary training. And
those people will have no other choice but to start with some vague model.

> >> I meant rather simple things. For instance, "don't chew, when you hear
> >> music". (:-))
> >
> >I tend to disagree with this rule in the form it was presented.  I think that
> >a proper rule should mention not music in general, but specific circumstances,
> >which involves other people. Well, I have no habit of chewing, but I certainly
> >want an opportunity to hear music in my kitchen, drinking coffee and smoking.
>
> There are simple physical reasons of human ear construction behind
> this rule. (:-))

Being slightly suprised. I consulted a specialist in hearing, and she explained
me that yes, chewing inhibits perception of sound to some degree, but increasing
volume of the sound usually conpensates for that. For example (she told me),
if you are listening radio or TV in foreign language you may need to increase
the volume if you are chewing. So, a proper rule, perhaps, will be: "don't
chew when you are hearing a kind of music, to which you are not accustomed".

> >> >> >> >Given current circumstances regarding intellectual property, I can't resist
> >> >> >> >to ask question: if knowledge, rather than money, is a measure of success,
> >> >> >> >doesn't this mean that knowledge became a property in that science-oriented
> >> >> >> >society? -;)
> >> >> >> 
> >> >> >> In my dilettantish opinion, there is a difference, knowledge is
> >> >> >> difficult to separate from its carrier.
> >> >> >
> >> >> >But a carrier can be severely restricted (if not imprisoned... or even killed
> >> >> >after he shared his knowledge with another person)
> >> >>
> >> >> It would be too expensive. If you mean Stalin's methods, remeber that
> >> >> he was looting the potential built before him.
> >> >
> >> >So what? You certainly can't say that we have (or will have) too
> >> >little potential for looting.
> >>
> >> Yet, it gone and the empire collapsed.
> >
> >Yes, so what? Why not to repeat? Final collapse doesn't matter, it will be
> >somewhere in future and perhaps another generation will deal with it.
>
> Because the stock is empty now.

You certainly mean Russian stock here; but I wrote not about particularly
Russia as it pertains to the current and future situation. I suppose you do
not think that the Western stock and generally worldwide stock is empty.

> >Do you think that they dream that tomorrow Stalin or an equivalent will rule in their
> >own countries?
>
> Probably yes.

So, you think that they all were very stupid.

> BBC World always tried to
> represent Saddam and US as morally equivalent sides. They promptly
> passed Saddam's propaganda without any analysis or comments.

I can only repeat that we certainly read different BBC Worlds. 

> >But at the same time I know that many people
> >were and are very dissatisfied with obvious lies of their governments about
> >the reasons for the recent war action. Notice, that the problem is not much
> >in the war action itself, but in that the possible true and valid reasons were
> >substitued by obvious lies.
>
> Which appeared to be the single possible way. Whom to blaim?

> >film "Triumph of Will" ("Triumph Des Willens", Leni Riefenstahl, 1935).
>...
> >Even in that film you will see that there was much more than moustache.
>
> To be like others, to share everything with others, to vibrate with
> others in an extatic "consensus"...

No, that isn't an interesting part, it is too well-known thing (for that I'd
better recommend American film "Inherit the Wind"). What is really interesting
in "Triumph Des Willens", it is Hitler Youth and Labor Front reviews with
Hitler's speeches on them, and excellent Hitler's and especially Hess's performance
as actors (Hitler's mostly at various reviews and Hess's at the congress).
Hitler's speeches on those (Youth and Labor) reviews are very good public
presentations of important aspects of low-level integration ideology. And Hess
looks as true soul of that version of national-socialism during its takeoff phase.

> >Sakharov was very special case
> >for Communist authorities because of its supposed role in development of
> >Soviet nuclear weapon.
>
> Huh, Trotzky's role in grounding Soviet Army didn't save him from
> ice-axe. 

First, there was another (and very different) phase of regime; second, Trotzky
was not scientist (or otherwise high-ranking specialist), but politician and
once direct competitor; and note that even Trotzky was not killed in USSR -
he was first sent out, and killed after almost decade.

> >> >One serious problem of our time is that USA, being the Land of Engineers,
> >> >can't agree with that science and engineering aren't the same, and
> >> >consistently tries to convert science to engineering.
> >>
> >> Egh? How so. In my view USA is the last hope of humankind.
> >
> >Well, there were episodes in recent century when USA was indeed the last hope
> >of our sort of civilization, and USA fulfilled that hope. And that may be
> >repeated once more, who knows. But that does not imply that particular serious
> >problems can't be originated and developed in USA. And that does not imply
> >that all people outside USA should be hopeful spectators only.
>
> At least, they could stop accusing America in the faults of their own!

What do you mean - which faults, and who is accusing?

> While doing mathematics isolates?

What isolates is losing the sense of abstraction. It is not too harmful while
it isn't overwhelmingly widespread among the educated people - because a link
is usually possible via a neighbour. But if it becomes overwhelmingly widespread
than isolation actually takes effect.

> Actually money were invented to isolate reality.

Not isolate, but rather virtualize somehow. 

> To exchange something real for something having only an imaginary value.

For that there must be some degree of confidence in that value, and people
usually monitor the correspondence one way or another, and adjust that their
confidence accordingly.



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

Re: Is the Writing on the Wall for Ada?

[Dmitry A. Kazakov]

On 25 Sep 2003 14:12:04 -0700, aek@vib.usr.pu.ru (Alexander
Kopilovitch) wrote:

>Dmitry A. Kazakov wrote:
>
>> >> >there is a fundamental obstacle: Ada presumes
>> >> >full and thorough design, while neither C++ nor Java don't. You can build
>> >> >some half-prototype/half-product in C++ or Java, and hope to complete
>> >> >(somehow) the rest of design and then the real application later. But it will be
>> >> >much more difficult to follow that way in Ada.
>> >>
>> >> Why? Ada cannot prevent "C++ design". Also C++ does not enforce it
>> >> that much.
>> >
>> >Certainly Ada cannot prevent, and C++ does not enforce anything. The difference
>> >is in what is presumed in language design and to which degree. If you follow
>> >the language design assumptions then the language's design trade-offs will work
>> >for you; otherwise they will work against you, and you will spend much effort
>> >for overcoming various obstacles and will suffer from various inconveniences.
>>
>> Right, but the language design assumtions do not influence the
>> software design approach in a direct way.
>
>In practice there are always expectations about future implementation opportunities
>and problems, and those expectations usually influence design substantially.

Those are not related to the language design.

>But what is more significant, if you aren't familiar with the problem domain,
>then programming (or software engineering) terminology necessarily becomes your
>internal design language; general notions (like List, Queue, etc.) usually
>aren't enough, and for the rest part of the design you will use either forms
>from a programming language or their imprecise glimpses.

Right, but mostly, because the problem domain issues are very often
minor comparing with the software design issues. Frankenstein is
awaken.

>> I do not see why it should
>> be more difficult to make incomplete products in Ada.
>
>Because it takes much more expertise in the language for making useful imprecise
>glimpses of the language's forms in Ada than in C++. Just becase Ada was designed
>primarily for use in environments where competence in the problem domain can
>be assumed (and therefore those things should no be needed), while C++ inherits
>all its basic OO machinery from universal modelling language (Simula-67).

It is a strange statement. You are comparing design purposes with
heritage. It is apples and oranges. I do not see how C++ OO constructs
make designing incomplete products easier than Ada OO constructs.

>> >> Half-baked design is a result of half-baked programmes and uneducated
>> >> managers.
>> >
>> >I think, no. It is most often a result of substantially incomplete problem
>> >statement and incompetence (of the team) in problem domain.
>>
>> These are the consequences.
>
>Sometimes, but far from always. Quite often people that are generally educated
>and sufficiently competent in some problem domain(s) are throwed to other problem
>domains (in which they are incompetent) without any preliminary training. And
>those people will have no other choice but to start with some vague model.

To be competent, largely *implies* to know the limits of oneself
competence. This is the key point. An incompetent manager is a
universally one. An incompetent programmer always write the same
program no matter which language he uses or what this program should
do.

>> >> >> >> >Given current circumstances regarding intellectual property, I can't resist
>> >> >> >> >to ask question: if knowledge, rather than money, is a measure of success,
>> >> >> >> >doesn't this mean that knowledge became a property in that science-oriented
>> >> >> >> >society? -;)
>> >> >> >> 
>> >> >> >> In my dilettantish opinion, there is a difference, knowledge is
>> >> >> >> difficult to separate from its carrier.
>> >> >> >
>> >> >> >But a carrier can be severely restricted (if not imprisoned... or even killed
>> >> >> >after he shared his knowledge with another person)
>> >> >>
>> >> >> It would be too expensive. If you mean Stalin's methods, remeber that
>> >> >> he was looting the potential built before him.
>> >> >
>> >> >So what? You certainly can't say that we have (or will have) too
>> >> >little potential for looting.
>> >>
>> >> Yet, it gone and the empire collapsed.
>> >
>> >Yes, so what? Why not to repeat? Final collapse doesn't matter, it will be
>> >somewhere in future and perhaps another generation will deal with it.
>>
>> Because the stock is empty now.
>
>You certainly mean Russian stock here; but I wrote not about particularly
>Russia as it pertains to the current and future situation. I suppose you do
>not think that the Western stock and generally worldwide stock is empty.

It is finite.

>> >Do you think that they dream that tomorrow Stalin or an equivalent will rule in their
>> >own countries?
>>
>> Probably yes.
>
>So, you think that they all were very stupid.

Irresponsible blind.

>> >film "Triumph of Will" ("Triumph Des Willens", Leni Riefenstahl, 1935).
>>...
>> >Even in that film you will see that there was much more than moustache.
>>
>> To be like others, to share everything with others, to vibrate with
>> others in an extatic "consensus"...
>
>No, that isn't an interesting part, it is too well-known thing (for that I'd
>better recommend American film "Inherit the Wind"). What is really interesting
>in "Triumph Des Willens", it is Hitler Youth and Labor Front reviews with
>Hitler's speeches on them, and excellent Hitler's and especially Hess's performance
>as actors (Hitler's mostly at various reviews and Hess's at the congress).
>Hitler's speeches on those (Youth and Labor) reviews are very good public
>presentations of important aspects of low-level integration ideology. And Hess
>looks as true soul of that version of national-socialism during its takeoff phase.

Come on, do you really believe that cheap shows might influence
intellectuals? They ain't so stupid. They wished and are wishing to
use circumstances (like Stalin or Saddam) in their own purposes. They
consider these circumstances as a proof of their understanding of the
world, and in the end start to enjoy them.

>> >> >One serious problem of our time is that USA, being the Land of Engineers,
>> >> >can't agree with that science and engineering aren't the same, and
>> >> >consistently tries to convert science to engineering.
>> >>
>> >> Egh? How so. In my view USA is the last hope of humankind.
>> >
>> >Well, there were episodes in recent century when USA was indeed the last hope
>> >of our sort of civilization, and USA fulfilled that hope. And that may be
>> >repeated once more, who knows. But that does not imply that particular serious
>> >problems can't be originated and developed in USA. And that does not imply
>> >that all people outside USA should be hopeful spectators only.
>>
>> At least, they could stop accusing America in the faults of their own!
>
>What do you mean - which faults, and who is accusing?

We are watching different BBC's! (:-))

>> While doing mathematics isolates?
>
>What isolates is losing the sense of abstraction. It is not too harmful while
>it isn't overwhelmingly widespread among the educated people - because a link
>is usually possible via a neighbour. But if it becomes overwhelmingly widespread
>than isolation actually takes effect.

I do not see isolation as a trend. To me it is much simplier,
knowledge is loosing its value in people's view. It is no more a shame
to be uneducated (in all meanings of this word), stupid or even have
no traces common sense.

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

Re: Is the Writing on the Wall for Ada?

[Alexander Kopilovitch]

Dmitry A. Kazakov wrote:

> >> ... the language design assumtions do not influence the
> >> software design approach in a direct way.
> >
> >In practice there are always expectations about future implementation opportunities
> >and problems, and those expectations usually influence design substantially.
>
> Those are not related to the language design.

Sounds strange - implementation opportunities (or expectations about
them)
are not related to the language design?

> >But what is more significant, if you aren't familiar with the problem domain,
> >then programming (or software engineering) terminology necessarily becomes your
> >internal design language; general notions (like List, Queue, etc.) usually
> >aren't enough, and for the rest part of the design you will use either forms
> >from a programming language or their imprecise glimpses.
>
> Right, but mostly, because the problem domain issues are very often
> minor comparing with the software design issues.

I think that this impression is caused exactly by the effect I just
mentioned:
when our (programmers) knowledge about problem domain is only partial
and/or
vague, we naturally try to compensate that at the software design
level (for
example, providing much more flexibility that might be needed if we
knew the
problem domain better).

> >> I do not see why it should
> >> be more difficult to make incomplete products in Ada.
> >
> >Because it takes much more expertise in the language for making useful imprecise
> >glimpses of the language's forms in Ada than in C++. Just becase Ada was designed
> >primarily for use in environments where competence in the problem domain can
> >be assumed (and therefore those things should no be needed), while C++ inherits
> >all its basic OO machinery from universal modelling language (Simula-67).
>
> It is a strange statement. You are comparing design purposes with
> heritage.

But this was the way C++ was originally designed - it more or less
honestly
inherited all its object machinery from Simula-67 (dropping
coroutines). So,
those (original) object features in fact weren't designed for C++,
they were
designed for Simula-67.

> It is apples and oranges.

Do you really think that apples and oranges never can (or should) be
compared? -:)

> I do not see how C++ OO constructs
> make designing incomplete products easier than Ada OO constructs.

For me it is quite obvious. Take, for example, that multiple
inheritance. In
C++ you have it, and therefore you can simply say: "I inherit
Democracy from
Population and Constitution", retaining the details for vague future
(next
phase of design - detailed design, which possibly will never happen).
You can't
say that in Ada - here you'll be forced to give some kind of
preference either
to Population or to Constitution. And if you aren't aware about
relations
between the Population and Constitution, you naturally will feel Ada
less
convenient in the case, because she pushes you to say something about
the
things you don't know... while C++ permits you to be silent about
them.

> >> >> Half-baked design is a result of half-baked programmes and uneducated
> >> >> managers.
> >> >
> >> >I think, no. It is most often a result of substantially incomplete problem
> >> >statement and incompetence (of the team) in problem domain.
> >>
> >> These are the consequences.
> >
> >Sometimes, but far from always. Quite often people that are generally educated
> >and sufficiently competent in some problem domain(s) are throwed to other problem
> >domains (in which they are incompetent) without any preliminary training. And
> >those people will have no other choice but to start with some vague model.
>
> To be competent, largely *implies* to know the limits of oneself
> competence. This is the key point.

The problem here is that the configuration space of skills/competence
is not
so plain, it is not restricted to classical scientific and technical
domains.
So, one easily can consider his competence limited just because it is
concentrated
at some *level*, and not in some real world problem domain.

> An incompetent manager is a universally one.

He may think otherwise - he may be well aware of his level. He may
think that
he can manage a group of, say, 50-100 people, but, perhaps, not 1000.
So, his
competence is quite limited in his view.

After all, methematicians also usually do not restrict their
competence to some
problem domains as far as it pertains to square equations -:) .


> Come on, do you really believe that cheap shows might influence
> intellectuals?

Certainly yes - they influence them in 2 steps: at the first step
those
intellectuals believe that those shows influence masses, and at the
second step
they build their conclusions on the belief created at the first step.

But I also think that those shows weren't cheap. Probably you meant
low quantity
of design features and low structural complexity of those shows, but
these
aren't most important criteria for cost estimates. It is not simple
and not
cheap to organize such shows without too much obvious (for spectators)
blunders.
If you think otherwise then certainly you have no experience in this
area...
probably you even did not try to control a squad of 30 soldiers (or
forgot that -:) .

> They ain't so stupid. They wished and are wishing to
> use circumstances (like Stalin or Saddam) in their own purposes. They
> consider these circumstances as a proof of their understanding of the
> world, and in the end start to enjoy them.

Opportunists were, are, and will be at all levels of education, And
two-step
opportunists aren't particularly interesting. And their fraction isn't
much
differ from fraction of opportunists of all flavors at other levels of
education.

> knowledge is loosing its value in people's view.

People, quite understandably, failed to find much value in Dark Matter
(which
is too dark and too far) and in intermediate boson (which is too
intermediate),
They patiently waited for decades for miracles or at least
explanations, but
finally quit. Well, I mean Western people (in China, India and some
other places
the situation is entirely different, in these places many people still
consider
education as precious aid for personal survival).



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

Re: Is the Writing on the Wall for Ada?

[Dmitry A. Kazakov]

On 26 Sep 2003 10:22:29 -0700, aek@vib.usr.pu.ru (Alexander
Kopilovitch) wrote:

>Dmitry A. Kazakov wrote:
>
>> >> ... the language design assumtions do not influence the
>> >> software design approach in a direct way.
>> >
>> >In practice there are always expectations about future implementation opportunities
>> >and problems, and those expectations usually influence design substantially.
>>
>> Those are not related to the language design.
>
>Sounds strange - implementation opportunities (or expectations about
>them) are not related to the language design?

Because software patterns are more or less universal. You probably
refer programming habits which are different for programmers in C++
and Ada, but again these habits have more to do with a qualification
and backgound than with a particular language.

>> >But what is more significant, if you aren't familiar with the problem domain,
>> >then programming (or software engineering) terminology necessarily becomes your
>> >internal design language; general notions (like List, Queue, etc.) usually
>> >aren't enough, and for the rest part of the design you will use either forms
>> >from a programming language or their imprecise glimpses.
>>
>> Right, but mostly, because the problem domain issues are very often
>> minor comparing with the software design issues.
>
>I think that this impression is caused exactly by the effect I just
>mentioned:
>when our (programmers) knowledge about problem domain is only partial
>and/or
>vague, we naturally try to compensate that at the software design
>level (for
>example, providing much more flexibility that might be needed if we
>knew the
>problem domain better).

No, it is because for real problems, there is usually neither funding
nor interest. See the crux point about making money vs. knowledge? To
make money, you have to avoid real problems.

>> >> I do not see why it should
>> >> be more difficult to make incomplete products in Ada.
>> >
>> >Because it takes much more expertise in the language for making useful imprecise
>> >glimpses of the language's forms in Ada than in C++. Just becase Ada was designed
>> >primarily for use in environments where competence in the problem domain can
>> >be assumed (and therefore those things should no be needed), while C++ inherits
>> >all its basic OO machinery from universal modelling language (Simula-67).
>>
>> It is a strange statement. You are comparing design purposes with
>> heritage.
>
>But this was the way C++ was originally designed - it more or less
>honestly
>inherited all its object machinery from Simula-67 (dropping
>coroutines). So,
>those (original) object features in fact weren't designed for C++,
>they were
>designed for Simula-67.
>
>> It is apples and oranges.
>
>Do you really think that apples and oranges never can (or should) be
>compared? -:)

It is a question of taste! (:-))

>> I do not see how C++ OO constructs
>> make designing incomplete products easier than Ada OO constructs.
>
>For me it is quite obvious. Take, for example, that multiple
>inheritance. In
>C++ you have it, and therefore you can simply say: "I inherit
>Democracy from
>Population and Constitution", retaining the details for vague future
>(next
>phase of design - detailed design, which possibly will never happen).
>You can't
>say that in Ada - here you'll be forced to give some kind of
>preference either
>to Population or to Constitution. And if you aren't aware about
>relations
>between the Population and Constitution, you naturally will feel Ada
>less
>convenient in the case, because she pushes you to say something about
>the
>things you don't know... while C++ permits you to be silent about
>them.

You are overestimating use of MI in C++.

Then any additional work one have to do in Ada as compared with C++,
when MI (no matter interface or implementation) is necessary, actually
pushes for incomplete products.

A deficiency cannot be an advantage. It only could be if a feature,
instead of being incompletely or inconsistently implemented, is
altogether abadoned. This is not the case if we consider inheritance.

>> >> >> Half-baked design is a result of half-baked programmes and uneducated
>> >> >> managers.
>> >> >
>> >> >I think, no. It is most often a result of substantially incomplete problem
>> >> >statement and incompetence (of the team) in problem domain.
>> >>
>> >> These are the consequences.
>> >
>> >Sometimes, but far from always. Quite often people that are generally educated
>> >and sufficiently competent in some problem domain(s) are throwed to other problem
>> >domains (in which they are incompetent) without any preliminary training. And
>> >those people will have no other choice but to start with some vague model.
>>
>> To be competent, largely *implies* to know the limits of oneself
>> competence. This is the key point.
>
>The problem here is that the configuration space of skills/competence
>is not so plain, it is not restricted to classical scientific and technical
>domains.

After all psychiatry is a scientific domain, or what did you mean?
(:-))

>So, one easily can consider his competence limited just because it is
>concentrated
>at some *level*, and not in some real world problem domain.
>
>> An incompetent manager is a universally one.
>
>He may think otherwise -

Surely!

>he may be well aware of his level. He may
>think that he can manage a group of, say, 50-100 people, but, perhaps, not 1000.
>So, his competence is quite limited in his view.

Sort of that. To manage 50-100 people ... what these people are
supposed to do is no matter.

>After all, methematicians also usually do not restrict their
>competence to some
>problem domains as far as it pertains to square equations -:) .

Yep, to think that to lead a 50-men software project is as simple as
to solve a square equation, that sounds familiar!

>> knowledge is loosing its value in people's view.
>
>People, quite understandably, failed to find much value in Dark Matter
>(which is too dark and too far) and in intermediate boson (which is too
>intermediate), They patiently waited for decades for miracles or at least
>explanations, but finally quit.

As long as people are waiting for miracles, there is no place for
knowledge.

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

Re: Is the Writing on the Wall for Ada?

[Marin David Condic]

IMHO, you can't count on the big defense contractors to keep Ada alive 
and well. They're under pressrue to use whatever the rest of the world 
is using for precicely the same reasons: Cost and Schedule. C++ and Java 
are perceived as having a larger user base, bigger/better toolsets, more 
support, etc and Ada is an "Also Ran" that is struggling to provide some 
fraction of the tools/support/staff that other languages have.

But the answer is not to piss-and-moan about what a bunch of stupid 
morons the DoD weenies are (as I'm sure we will see some of here under 
this topic ;-) The answer is to struggle to get Ada into more 
commercialized projects. If more businesses are out there using Ada for 
some important product or internal tool, then there are more Ada 
developers and more commercial demand for Ada-related tools. Then the 
big guys at LockMart and Boeing will not find an incentive to go elsewhere.

Work on making Ada better at Time-To-Market issues by providing tools 
and leverage features (like a library abnd a GUI) Dream up ideas for 
some kind of product that people might want and build it using Ada - 
take it out and find a market. (The problem here is we're all willing to 
work alone developing some kind of "Geek Tools" - but what about working 
together and developing some kind of "Consumer Tools" that have a much 
broader appeal and make Ada a much more important player?) Build some 
successful businesses that utilize Ada as part of their competitive edge 
and maybe we won't have to worry about articles like this.

MDC


Warren W. Gay VE3WWG wrote:
> This is not a troll... but I am soliciting some opinion.
> 
-- 
======================================================================
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: Is the Writing on the Wall for Ada?

[Jacob Sparre Andersen]

Warren W. Gay VE3WWG wrote:

[ begin quote from article ]

> Among the key motivations for the military's interest in Java is a drive
> to transition away from Ada.

[ end quote from article ]

What matters to me is:

  1) that those I pay tax to don't waste money (on bad software)

  2) that there are sufficient resources to continue the development and
     improvement of Ada compilers and libraries

Since I don't pay tax to the USA, I don't care much about 1) in this 
specific case.  But I have been made aware that all recently awarded ESA 
software development contracts have come with clauses that the software 
must be developed in C.  Since I have made it a habit to pay tax in ESA 
member countries this really annoys me (and quite a few of the people, 
who have to write the code).

I don't know where the Ada compiler industry gets its revenues from.  If 
it is mostly from US DoD and ESA subcontractors, then we may have a 
serious problem with respect to 2).  I am sorry to say that the 
available product ranges and prices in the Ada compiler market mean that 
I probably (unwillingly and indirectly) have poured more money into 
unused MS-Windows licenses than into Ada compilers and support 
contracts.  But if all those who currently pay for all the nice Ada 
compilers we can get stop paying, we have to find some other model to 
maintain the availability of the tools we want.

Until now I have been rather lazy, when it comes to active work on GNAT 
and general purpose Ada libraries (I am much too much better at 
complaining).  But I think there are enough knowledgable people, who can 
and are willing to put in a bit of effort to continue to have access to 
good Ada tools.

> So: Is the writing on the wall for Ada?

I don't think so.

Jacob
-- 
Wie "Tippfehler !?" Mein Modem hat doch Fehlerkorrektur...

Re: Is the Writing on the Wall for Ada?

[Warren W. Gay VE3WWG]

Jacob Sparre Andersen wrote:
> Warren W. Gay VE3WWG wrote:
> 
> [ begin quote from article ]
> 
>> Among the key motivations for the military's interest in Java is a drive
>> to transition away from Ada.
> [ end quote from article ]
> 
> What matters to me is:
> 
>  1) that those I pay tax to don't waste money (on bad software)
> 
>  2) that there are sufficient resources to continue the development and
>     improvement of Ada compilers and libraries
> 
> Since I don't pay tax to the USA, I don't care much about 1) in this 
> specific case.  

You and I probably do in an indirect sense: some of the profits
in products we buy from the US, no doubt go towards applicable
taxation.

> I don't know where the Ada compiler industry gets its revenues from.  If 
> it is mostly from US DoD and ESA subcontractors, then we may have a 
> serious problem with respect to 2).  I am sorry to say that the 
> available product ranges and prices in the Ada compiler market mean that 
> I probably (unwillingly and indirectly) have poured more money into 
> unused MS-Windows licenses than into Ada compilers and support 
> contracts.  But if all those who currently pay for all the nice Ada 
> compilers we can get stop paying, we have to find some other model to 
> maintain the availability of the tools we want.

What worries me is the perceived trend of all Ada vendors in
their hedging of their bets into other services and products. What
could happen, is that Ada ends up dropping off of the supported
list at some point, due to general lack of demand.

> Until now I have been rather lazy, when it comes to active work on GNAT 
> and general purpose Ada libraries (I am much too much better at 
> complaining).  But I think there are enough knowledgable people, who can 
> and are willing to put in a bit of effort to continue to have access to 
> good Ada tools.
> 
>> So: Is the writing on the wall for Ada?
> 
> I don't think so.
> 
> Jacob

I hope you're right. Certainly, Ada code will be around
for a long time, but I get concerned when/if new development
stops.

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Is the Writing on the Wall for Ada?

[Ed Falis]

On Tue, 09 Sep 2003 12:48:10 -0400
"Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> wrote:

> What worries me is the perceived trend of all Ada vendors in
> their hedging of their bets into other services and products. What
> could happen, is that Ada ends up dropping off of the supported
> list at some point, due to general lack of demand.

That's certainly _not_ the trend at Ada Core and ACT Europe.  Doesn't
mean that we don't support the use of other languages or provide other
products (all written primarily in Ada); but Ada is clearly our bread
and butter, with no change in our forecast.

- Ed Falis

Ada Core Technologies

Re: Is the Writing on the Wall for Ada?

[Warren W. Gay VE3WWG]

Ed Falis wrote:

> On Tue, 09 Sep 2003 12:48:10 -0400
> "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> wrote:
>>What worries me is the perceived trend of all Ada vendors in
>>their hedging of their bets into other services and products. What
>>could happen, is that Ada ends up dropping off of the supported
>>list at some point, due to general lack of demand.
> 
> That's certainly _not_ the trend at Ada Core and ACT Europe.  Doesn't
> mean that we don't support the use of other languages or provide other
> products (all written primarily in Ada); but Ada is clearly our bread
> and butter, with no change in our forecast.
> 
> - Ed Falis
> 
> Ada Core Technologies

Glad to hear it!
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Is the Writing on the Wall for Ada?

[Marin David Condic]

Can you blame them? They have a payroll to meet and investor's money to 
protect. Unless they're seeing gobs of Ada business coming out of their 
ears, they would be foolish not to diversify some to protect jobs and 
the ongoing business.

If we want to help Ada succeed and thus help insure a market for the 
vendors and a market for those of us wishing to use Ada in our jobs, 
then we need to a) work to give Ada more capabilities/power right out of 
the box and b) build as many important applications as possible in Ada. 
I think a good place to start would be to get a common library 
built/adopted for Ada that is distributed with most implementations. To 
further the second goal, creative Ada fans should look to develop common 
business or home applications in Ada and look to commercialize them. 
(How are you going to create business for the vendors and jobs for the 
techies unless you have some successful business of your own that 
utilizes Ada?) Both of those areas could be addressed and Ada would benefit.

MDC



Warren W. Gay VE3WWG wrote:
> 
> What worries me is the perceived trend of all Ada vendors in
> their hedging of their bets into other services and products. What
> could happen, is that Ada ends up dropping off of the supported
> list at some point, due to general lack of demand.
> 

-- 
======================================================================
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: Is the Writing on the Wall for Ada?

[Gautier Write-only]

It seems to be highly probable that it is "the Writing
on the Wall for Ada" in real-time US military systems.
But is it new ? In 1990 "everybody" said that Ada was
finished (without having quit a very restricted circle),
that "now it is C++". Around 1993 (10 years!) the creators of
GNAT surely felt that it was an unique chance to broaden
the user base of this language by making a free compiler
- and support the more usable Ada 9X language. My gut feeling
is that, for this never well known general-purpose language,
2003 is the best year ever, in terms of geographic and
programming area domains - and it could even improve, while
remaining small in terms of "market share".
The only solid fact to draw from that could be that the US military
are not optimally profiting from "their" investment - hum, or
from the taxpayer's... Is it a surprise ? Funnily they seem
to love Java, just when "everybody" says that Java is finished,
that "now it is C#". Surely in 8-10 years they'll find C#
completely sexy.
________________________________________________________
Gautier  --  http://www.mysunrise.ch/users/gdm/gsoft.htm

NB: For a direct answer, e-mail address on the Web site!

Re: Is the Writing on the Wall for Ada?

[Stephane Richard]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 7315 bytes --]

Here's my perception.  This is from the many messages that exist in this
thread, since I'm responding to many comments that were made, I just decided
to put it here in the hierarchy of messages pertaining to this thread.

If the millitary switches to Java, it will shoot itself in the foot.
Especially if they expect the same kind of:

a.  Performances  (Java is slower than Ada, in many places I consider
essential)
b.  Readability and Udnerstandability of Code
c.  Any kind of standard.  A datatype is NOT an object and Java thinks it
is.  What to make of that?  drop in performances automatically.

Many Java projects I did in the first release of Java I basically gave up on
when the JDK 2 came out....what qbout JDK3, 4 or 5 when they pop up?

I dont think have Ada centralized as it is right now will stopp innovation,
I believe it will rather stop Innovation in the wrong direction which is a
good thing in my book.  We all know what we want in the new Ada.  For a
language to evolve and adapt to new realities, it needs the foundations to
do so and Java and C++ just dont have it....not as far as reliability is
concerned and given methods of controling resource/tasking/memory management
just aren't there in Java or C++ for any truely reliable realtime systems
the boehm Demers Garbage collection model does have it's flaws and is stated
that garbage collections happens when it can, not necessarily when it
should...which defeats the purpose in my book....Although I realize that for
languages such asJava and C++ it's probably the only way to achieve a
somewhat "adequate" garbage collection.   but it's far from perfect and
depending on what it is collecting it can be very irregularly called upon
which makes memory management tricky at best.

What I would like to see in Ada 200X is a true console library...I dont mean
as compared to Text_IO, I'd like simple things such as Text color,
background color, etc etc....as part of the Ada Standard.   there's one
library that implements an interface to the conio C library.  I'd like to
see that as part of Ada in an OS independant manner, of course :-)..

And it is not true, even for a big project, that every is better coded in an
OOP environment.  there are situations that can do without OOP even today.
Ada is capable of both OO and Modular paradigms and that's one thing Java
just doesn't do.   Java Tasking and Ada Tasking are quite similar but again
a few key Ada features simply dont exist in Java and those features, to me,
are what makes Ada's tasking so good.  So Java just doesn't cut it for me.

Likewise, Java "thinks" it solved the multiplatform issues by providing it's
own GUI layer.  That might be good, in it's own context as far as Java is
Concerned.  But there are definite flaws in this architecture.  So to me,
Java is not the way to go for many types of applications, especially
realtime and embedded.

So in my book, there's many reasons why Java and C++ aren't my first choices
when it comes many categories of projects...Granted C/C++ mya be more suited
for a certain range of applications.  but Java isn't even a viable solution
to anything I can think of.  It has yet to mature considerably for many
fields.

-- 
St�phane Richard
Senior Software and Technology Supervisor
http://www.totalweb-inc.com
For all your hosting and related needs
"Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> wrote in message
news:NGs6b.10770$Pa1.519789@read1.cgocable.net...
> This is not a troll... but I am soliciting some opinion.
>
> I read a disturbing article in the July COTS Journal recently,
> and thought I would bounce the controversial aspects off
> of the group. The complete article can be read at:
>
>   http://www.cotsjournalonline.com/pdfs/2003/07/COTS07_softside.pdf
>
> I have quoted some of the sections for ease of discussion below:
>
> From Article:
>
>   Softer Side: Java in the Military
>   Java Proving Itself Worthy for Defense Apps
>   July 2003 COTS Journal [ 27 ]
>
> ...
>
> Navy's Open Architecture
> ========================
>
> **** <highlight> ****
>
> Among the key motivations for the military's interest in Java is a drive
> to transition away from Ada.
>
> **** </highlight> ****
>
> The feeling is that Java represents a modern and more commercially
> available technology than alternatives. The Navy, for example, is
> drafting their Navy Open Architecture Computing Environment (NOACE) to
> be the standard for all future software systems on Navy warships. That
> includes shipboard weapon systems, such as anti-aircraft cannon controls
> as well as avionics systems aboard naval aircraft. The standard calls
> for all new software to develop in either C++ or Java, and makes
> specific mention of moving away from Ada. They plan to continue to use
> Ada only as required to support legacy systems that have already been
> developed.
>
> ...
>
> Moving Away from Ada
> ====================
>
> For its part, Boeing has also expressed a clear preference to move
> toward Java. Winner of the lead system integrator contract on for U.S.
> Army's Future Combat Systems (FCS) program, Boeing is farming out their
> FCS requirements and telling suppliers they want to use Java, they don't
>
>   **** <highlight> ****
>
> like C++ and they don't like Ada for any new system development. Many
>
>   **** </highlight> ****
>
> suppliers to FCS are therefore tasked to convert reams of Ada code over
> to Java.
>
> There are some basic human resources reasons why Java is a preferred
> approach. Today's new graduates from college are 99% more likely to know
> Java than any other programming language. And among experienced
> programmers out in the workforce, more will tend to highlight Java on
> their resume rather than Ada. The ranks of true Ada gurus are probably
> comprised more of programmers near retirement than otherwise.
>
> </quote>
>
>
> SOME OBSERVATIONS:
> ==================
>
> I have seen many quotes here in comp.lang.ada and other web sources
> that only the mandate to use Ada has been dropped. The position that
> is usually made is that Ada is still considered on a project by
> project basis, where it makes sense.
>
> However, if the above article is accurate, it seems that the U.S.
> military (and Boeing) is making a conscious effort to move away from Ada.
> The article is suggesting that the only reason to use Ada now would
> be for legacy systems. Boeing apparently does not want to use Ada
> in any new development.
>
> CONCLUSION:
>
> Whether or not you agree with the reasoning in the article, the
> disturbing thing in my mind is the "mindset". If the military and big
> industrial companies like Boeing turn their back on Ada, where is Ada
> headed for in the future? Is there enough other momentum to keep Ada
> (and GNAT) going into the foreseeable future?
>
> I attended a small Real-Time conference last week in Toronto, and I only
> heard the name Ada  mentioned once, and in a negative way
> (in passing reference WRT Real-Time Java). None of the vendors there
> that I talked to were using Ada for their SBC and the one vendor
> for flight systems told me they simply do not have the customer
> demand for Ada systems.
>
> So: Is the writing on the wall for Ada?
>
> What is your take on the article?
> -- 
> Warren W. Gay VE3WWG
> http://home.cogeco.ca/~ve3wwg
>
>

Re: Is the Writing on the Wall for Ada?

[Warren W. Gay VE3WWG]

Stephane Richard wrote:
> Here's my perception.  This is from the many messages that exist in this
> thread, since I'm responding to many comments that were made, I just decided
> to put it here in the hierarchy of messages pertaining to this thread.
> 
> If the millitary switches to Java, it will shoot itself in the foot.
> Especially if they expect the same kind of:
> 
> a.  Performances  (Java is slower than Ada, in many places I consider
> essential)
> b.  Readability and Udnerstandability of Code
> c.  Any kind of standard.  A datatype is NOT an object and Java thinks it
> is.  What to make of that?  drop in performances automatically.
> 
> Many Java projects I did in the first release of Java I basically gave up on
> when the JDK 2 came out....what qbout JDK3, 4 or 5 when they pop up?

Well, even if we all agreed that is true, the very thing that
concerns me (if the article is accurate in this), is that they
have made it a goal to get away from Ada. It doesn't matter if
it makes sense or not.

If someone sets out with a goal in mind, at some point, and in
some way, they're going to try to make it work. It seems that they
think that Real Time Java is going to help, if we are to believe
the writer.

Then again, who knows if this is truly their goal? Perhaps it was
the writer's interpretation of things that he has observed. He
didn't exactly quote anyone on that, IIRC.

Anyway, I hope the best for Ada.  Maybe Ada200Y will give it a
significant boost in the right direction.

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Is the Writing on the Wall for Ada?

[Ed Falis]

On Mon, 15 Sep 2003 12:31:57 -0400
"Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> wrote:

> Well, even if we all agreed that is true, the very thing that
> concerns me (if the article is accurate in this), is that they
> have made it a goal to get away from Ada. It doesn't matter if
> it makes sense or not.

The writer seemed a bit short on quotes about this subject, except from
people with an investment in real-time java.

- Ed

Re: Is the Writing on the Wall for Ada?

[Stephane Richard]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3404 bytes --]

Indeed, perhaps it will...like you said, I didn't see neither quotes from
respectable sources in this article or Reasons why they were
switching....But I do hope this guy reads these posts, Java Real time have
yet to be real time especialy with it's garbage collection engine...which
will ultimately interfere with realtime operations.  as much as they want to
say it, I've done simple delays and calculations in Java and and Ada
regarding realtime performances.  my own personal testing for afull fledged
music studio software I'm working on, where realtime isn't mission critical
but very important for realistic playback of a piece of music at a given
tempo.  and the deviation of time per note type and simulated delays for
these lengths is quite stable in Ada as in 2 half notes are equal to 1 whole
note, 2 64th of a note are equal to 1 32th of a note, etc etc....since this
would simulate a non linear time based entity, eact deviation would be a
cumulative error margin averaged for a whole song (3 minutes + total
deviations)....Java didn't do so well I'm affraid, and I wasn't creating /
deleting objects in the process either just simple delays for the allotted
time frame per note type.  I can just imagine what the results would be if I
started playing with resoursces and that garbage collection during the same
simulation.....

If time is a real factor in what they are looking for, I'd do some serious
benchmarking before proclaming that Java realtime is anywhere close to
Ada's....:-)...my tests showed otherwise.

-- 
St�phane Richard
Senior Software and Technology Supervisor
http://www.totalweb-inc.com
For all your hosting and related needs
"Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> wrote in message
news:OPl9b.3508$BT1.119023@news20.bellglobal.com...
> Stephane Richard wrote:
> > Here's my perception.  This is from the many messages that exist in this
> > thread, since I'm responding to many comments that were made, I just
decided
> > to put it here in the hierarchy of messages pertaining to this thread.
> >
> > If the millitary switches to Java, it will shoot itself in the foot.
> > Especially if they expect the same kind of:
> >
> > a.  Performances  (Java is slower than Ada, in many places I consider
> > essential)
> > b.  Readability and Udnerstandability of Code
> > c.  Any kind of standard.  A datatype is NOT an object and Java thinks
it
> > is.  What to make of that?  drop in performances automatically.
> >
> > Many Java projects I did in the first release of Java I basically gave
up on
> > when the JDK 2 came out....what qbout JDK3, 4 or 5 when they pop up?
>
> Well, even if we all agreed that is true, the very thing that
> concerns me (if the article is accurate in this), is that they
> have made it a goal to get away from Ada. It doesn't matter if
> it makes sense or not.
>
> If someone sets out with a goal in mind, at some point, and in
> some way, they're going to try to make it work. It seems that they
> think that Real Time Java is going to help, if we are to believe
> the writer.
>
> Then again, who knows if this is truly their goal? Perhaps it was
> the writer's interpretation of things that he has observed. He
> didn't exactly quote anyone on that, IIRC.
>
> Anyway, I hope the best for Ada.  Maybe Ada200Y will give it a
> significant boost in the right direction.
>
> -- 
> Warren W. Gay VE3WWG
> http://home.cogeco.ca/~ve3wwg
>

Re: Is the Writing on the Wall for Ada?

[chris]

Stephane Richard wrote:

> If the millitary switches to Java, it will shoot itself in the foot.
> Especially if they expect the same kind of:
> 
> a.  Performances  (Java is slower than Ada, in many places I consider
> essential)

Java is slower only in a JVM.  A native compiler for the language need 
not be.  If Javas portable runtime technology was smarter, it could be 
faster or as fast.  It just isn't.  (See Juice - a once promising 
technology hindered by confinement to the Oberon platform).

> b.  Readability and Udnerstandability of Code

Understandibility of code?  A competent programmer in a language should 
be able to understand code in that language, otherwise there's something 
seriously wrong.

> c.  Any kind of standard.  A datatype is NOT an object and Java thinks it
> is.  What to make of that?  drop in performances automatically.

Java does not think anything.  It *specifies* that a program is composed 
of objects, each containing methods and fields.  It also does not 
specify everything is an object and every data type is an object.  You 
get primitives types in Java.  Those are the only concepts in Java 
(threads are active objects in Java; enumerations and templates haven't 
made it into core yet).  Other languages have records, objects, 
procedures, functions, methods, and lots of other concepts.

I also do not see how objects automatically imply a performance drop. 
Perhaps there is a price to pay now, but I do not see how it 
automatically follows that it must always be so.  (Also you have to 
decide what you're willing to sacrifice for abstraction.  Some would say 
things we take for granted incur performance penalties, like range 
checks or records, but we don't get rid of them).

Re: Is the Writing on the Wall for Ada?

[JM]

On Sat, 6 Sep 2003 17:47:06 -0400, "Warren W. Gay VE3WWG"
<ve3wwg@cogeco.ca> wrote:

>This is not a troll... but I am soliciting some opinion.
>


This is always interesting to look at...

http://www.tiobe.com/tpci.htm



-jason

Re: Is the Writing on the Wall for Ada?

[Russ]

JM <jmillard1@cox_removethis_.net> wrote in message news:<b869mvgafn182befc4oagak15m02g6qski@4ax.com>...
> On Sat, 6 Sep 2003 17:47:06 -0400, "Warren W. Gay VE3WWG"
> <ve3wwg@cogeco.ca> wrote:
> 
> >This is not a troll... but I am soliciting some opinion.
> >
> 
> 
> This is always interesting to look at...
> 
> http://www.tiobe.com/tpci.htm

Ouch! Three down arrows! If this survey is even close to accurate, Ada
needs some CPR ASAP.

Someone needs to get the word out about the benefits of Ada. You Ada
experts need to get the attention of The Linux Journal and other such
popular periodicals. If someone could get a positive Ada story on
Slashdot, that would be great.

Re: Is the Writing on the Wall for Ada?

[Wes Groleau]

JM wrote:
> This is always interesting to look at...
> 
> http://www.tiobe.com/tpci.htm

There are some significant unknowns in the method.
Some might call them "flaws" but I suspect that
if they were corrected, the results would be the same.
However, it's possible they wouldn't.

For example, the method counts references of

<language> programming

on google.  But it's possible that folks writing
about a particular language tend to say "scripting"
rather than programming.  Or one group may have a
tendency to say "writing Squiggle" more often than
"Squiggle programming"

It's possible that some write like they talk:
"Sequel programming" instead of "SQL programming"

Another possibility is that advocates of
<ABC> are all out of work, and therefore have
loads of time on their hadns to write web pages
about it.

Or they could be like some Ada programmers:
afraid that if they admit they know Ada, their
other skills won't even be looked at.

-- 
Wes Groleau
    ------
    "The reason most women would rather have beauty than brains is
     they know that most men can see better than they can think."
                                -- James Dobson

Re: Is the Writing on the Wall for Ada?

[Warren W. Gay VE3WWG]

JM wrote:

> On Sat, 6 Sep 2003 17:47:06 -0400, "Warren W. Gay VE3WWG"
> <ve3wwg@cogeco.ca> wrote:
> 
>>This is not a troll... but I am soliciting some opinion.
> 
> This is always interesting to look at...
> 
> http://www.tiobe.com/tpci.htm

Yikes! That rates Ada lower than Awk and FORTRAN!

I'll just go back to burying my head in the sand ;-)

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Is the Writing on the Wall for Ada?

[Dmytry Lavrov]

Warren W. Gay VE3WWG wrote:
> 
> JM wrote:
> 
> > On Sat, 6 Sep 2003 17:47:06 -0400, "Warren W. Gay VE3WWG"
> > <ve3wwg@cogeco.ca> wrote:
> >
> >>This is not a troll... but I am soliciting some opinion.
> >
> > This is always interesting to look at...
> >
> > http://www.tiobe.com/tpci.htm
> 
> Yikes! That rates Ada lower than Awk and FORTRAN!
> 
> I'll just go back to burying my head in the sand ;-)

By google....
WAO!

results:

 Web     Images     Groups     Directory     News   
Searched the web for c.   Results 1 - 30 of about 475,000,000. Search
took 0.14 seconds. 
:   
the speed of light = 299 792 458 m / s 
    More about calculator. 
 Show stock quotes for
C (Citigroup) 

Google search is faster than speed of light if google scrolls all pages
in 0.14 s! ;-)

Searched the web for c++.   Results 1 - 30 of about 12,500,000 
(first result:Visual C++ Home)

Searched the web for ada.   Results 1 - 30 of about 7,110,000
(first result:ADA Home Page - ada.gov - Information and Technical
Assistance on ... )

Searched the web for perl.   Results 1 - 30 of about 19,500,000 
(first result:Perl.com: The Source for Perl -- perl development, perl
...)

It's popularity of words...of course first ten results pages are about
programming,but it's less than 0.01% of all results.And i think many of
"perl" pages not about programming,same with C++ pages.

Inheritance was Re: Is the Writing on the Wall for Ada?

[chris]

Hi,

This was recently posted to lambda.weblogs.com...

http://www.iam.unibe.ch/%7Escg/Research/Traits/index.html

Re: Inheritance was Re: Is the Writing on the Wall for Ada?

[Robert I. Eachus]

chris wrote:
> Hi,
> 
> This was recently posted to lambda.weblogs.com...
> 
> http://www.iam.unibe.ch/%7Escg/Research/Traits/index.html
> 

I just posted a longer article about this paper and others.  The short 
answer is that you can use generics to implement the trait pattern in 
Ada.  But I don't see this pattern as having a significant advantage 
over mix-ins.  (Mix-in inheritance doesn't have the problems in Ada that 
the paper describes for mix-ins in Smalltalk.)  However, I will keep the 
pattern in mind.  It may be a useful tool in some specific cases.

-- 
                                       Robert I. Eachus

"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: Is the Writing on the Wall for Ada?

[Jan Kroken]

"Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> writes:

> So: Is the writing on the wall for Ada?

My view is that it will be a sad day when the writing is not on the
wall for every language.

In addition I don't think it works very well to sell Ada as a general
language when it has done some major sacrifices to be suitable for
real time systems.  A popular language can't have general purpose as
its second priority.

My only Ada experience is with Gnat, so my view is maybe colored by
that, but I miss several things in Ada:

1. A garbage collector

I know perfectly well that the Ada 95 standard allows for GC, but what
does that help me when the implementation doesn't have it.  The
argument against GC is that it's not desireable for realtime systems,
but I have never written a real time system in my life, so why should
I not have one? Solidarity?

2. Better organization on disk

The java idea of organizing packages in directories is really a good
idea. Same with .jar files, and the CLASSPATH.

3. OO

I know the tagged record thingie is considered OO, but that's just
playing with words. OO as a concept is more than inheritance.

4. Dynamic strings

Dynamic strings, with proper library support. It's quite possible it's
in there, but it's not coincidence that the example Ada programs I've
read all seems to impose random limits, like line lengths of input
files limited to 80 characters and such.

-- 
Jan Kroken

Re: Is the Writing on the Wall for Ada?

[Stephen Leake]

Jan Kroken <jankr@nntp.ifi.uio.no> writes:

> My view is that it will be a sad day when the writing is not on the
> wall for every language.

In the long run, that is true. The subject line doesn't mention a time
frame, but it usually means "Real Soon Now".

> My only Ada experience is with Gnat, so my view is maybe colored by
> that, but I miss several things in Ada:
> 
> 1. A garbage collector
> 
> I know perfectly well that the Ada 95 standard allows for GC, but what
> does that help me when the implementation doesn't have it.  The
> argument against GC is that it's not desireable for realtime systems,

Actually, the argument against GC is that it's the wrong solution to
the problem. See the recent thread here on GC.

The reason no current Ada implementations provide GC is that no
customers are demanding it. I have no direct knowledge, but my
impression is there are plenty of customers using Ada for other than
real-time systems.

> but I have never written a real time system in my life, so why
> should I not have one? Solidarity?

You should not have GC because Ada provides better ways to solve the
problems that GC is typically used to solve. Stack based allocation of
dynamically objects is one method; Controlled types is another.

> 2. Better organization on disk
> 
> The java idea of organizing packages in directories is really a good
> idea. Same with .jar files, and the CLASSPATH.

This is totally up to you; the Ada language does not define this. So
if you like it, use it. The GNAT compiler is perfectly happy with this
as well. 

Hmm, I guess the Sun java compiler assumes this directory
organization, so you don't have to add all the directories to the
path. With GNAT, you have to add the directories to the path. You
could write a tool to do that.

But I prefer one directory, with dots in the file names. The directory
gets large, but that's not a problem for me. Consider a typical Ada
package, named SAL.Math_Float.DOF_3.Text_IO. It's in the file
src/sal-math_float-dof_3-text_io.ads. In java, that would be
src/sal/math_float/dof_3/text_io.java. Change the slashes to dots; no
big deal.

> 3. OO
> 
> I know the tagged record thingie is considered OO, but that's just
> playing with words. OO as a concept is more than inheritance.

Yes, OO is more than inheritance. Which OO feature do you think is
missing from Ada? 

Every OO concept I have heard of is in Ada, except C++ style multiple
inheritance, and Java interface inheritance. Java interface
inheritance will be in the next version. Other forms of multiple
inheritance are currently in Ada, allowing very similar programming
styles to the current C++ and Java styles, or different styles if that
fits the problem better.

> 4. Dynamic strings
> 
> Dynamic strings, with proper library support. 

Ada.Strings.Unbounded. Way better than C++ Strings.

-- 
-- Stephe

Re: Is the Writing on the Wall for Ada?

[Hyman Rosen]

Stephen Leake wrote:
> Ada.Strings.Unbounded. Way better than C++ Strings.

How?

Re: Is the Writing on the Wall for Ada?

[Robert I. Eachus]

Hyman Rosen wrote:
> Stephen Leake wrote:
> 
>> Ada.Strings.Unbounded. Way better than C++ Strings.
> 
> How?

For one simple example, an Ada string of any flavor can always contain 
all possible character literals and control codes.

-- 
                                                        Robert I. Eachus

Ryan gunned down the last of his third white wine and told himself it 
would all be over in a few minutes.  One thing he'd learned from 
Operation Beatrix: This field work wasn't for him. --from Red Rabbit by 
Tom Clancy.

Re: Is the Writing on the Wall for Ada?

[Matthew Heaney]

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

> Hyman Rosen wrote:
> > Stephen Leake wrote:
> >
> >> Ada.Strings.Unbounded. Way better than C++ Strings.
> > How?
> 
> For one simple example, an Ada string of any flavor can always contain
> all possible character literals and control codes.

Hmmm... Are we talking about the same thing?  I think the OP was
referring to std::basic_string.  A std::string in C++ is just the
std::basic_string instantiated with type char.

One nice thing about C++ std::string is that you have c_str() and data()
member functions, which give you a traditional nul-terminated const
char* and a non-nul terminated const char*, respectively.  This makes it
trivial to build up a string using std::string (or its close cousin
std::ostringstream), and then to turn around and get the char* array
using c_str(), which means it can basically be used everywhere a const
char* can.

The problem with Ada.Strings.Unbounded is that to do anything useful
with it requires a conversion to type String, which is grossly
inefficient, not to mention awkward.

The ACT people added a Aux child (I think that's the name), which
provides a function to return the underlying String_Access.  This is how
Ada.Strings.Unbounded should have been designed in the first place.

The C++ std::string also has a getline procedure to read from stdin
directly into a std::string.  A similar function should have been
provided for Ada.Strings.Unbounded.

Re: Is the Writing on the Wall for Ada?

[Pascal Obry]

Matthew Heaney <matthewjheaney@earthlink.net> writes:

> The ACT people added a Aux child (I think that's the name), which
> provides a function to return the underlying String_Access.  This is how
> Ada.Strings.Unbounded should have been designed in the first place.

I disagree. This is very dangerous as you get a pointer to a controlled
object, so it is not safe and Ada is always on the safe side.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Is the Writing on the Wall for Ada?

[Dmitry A. Kazakov]

On Fri, 26 Sep 2003 02:31:52 GMT, Matthew Heaney
<matthewjheaney@earthlink.net> wrote:

>The problem with Ada.Strings.Unbounded is that to do anything useful
>with it requires a conversion to type String, which is grossly
>inefficient, not to mention awkward.

Yes, but the problem is deeper - unbounded string are not arrays.

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

Re: Is the Writing on the Wall for Ada?

[Matthew Heaney]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> writes:

> On Fri, 26 Sep 2003 02:31:52 GMT, Matthew Heaney
> <matthewjheaney@earthlink.net> wrote:
> 
> >The problem with Ada.Strings.Unbounded is that to do anything useful
> >with it requires a conversion to type String, which is grossly
> >inefficient, not to mention awkward.
> 
> Yes, but the problem is deeper - unbounded string are not arrays.

That's true of the C++ std::string.  Yet that class manages to have a
c_str() member function that does return an array.

Re: Is the Writing on the Wall for Ada?

[Stephane Richard]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 883 bytes --]

Indeed Matthew, thye seem to be using Type casting....is ther such a thing
in Ada?  could you not typecase the resulting string into a character array?

-- 
St�phane Richard
"Ada World" Webmaster
http://www.adaworld.com


"Matthew Heaney" <matthewjheaney@earthlink.net> wrote in message
news:uisnfj03s.fsf@earthlink.net...
> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> writes:
>
> > On Fri, 26 Sep 2003 02:31:52 GMT, Matthew Heaney
> > <matthewjheaney@earthlink.net> wrote:
> >
> > >The problem with Ada.Strings.Unbounded is that to do anything useful
> > >with it requires a conversion to type String, which is grossly
> > >inefficient, not to mention awkward.
> >
> > Yes, but the problem is deeper - unbounded string are not arrays.
>
> That's true of the C++ std::string.  Yet that class manages to have a
> c_str() member function that does return an array.
>
>
>
>
>
>

Re: Is the Writing on the Wall for Ada?

[Hyman Rosen]

Stephane Richard wrote:
> Indeed Matthew, thye seem to be using Type casting

No, there's no type casting.

C++'s std::string objects have c_str and data methods, both
of which return a pointer to a const array of characters.
That pointer remains the propertry of the string, and is valid
until a potentially mutating operation is performed on the string.

Re: Is the Writing on the Wall for Ada?

[Stephen Leake]

Hyman Rosen <hyrosen@mail.com> writes:

> Stephane Richard wrote:
> > Indeed Matthew, thye seem to be using Type casting
> 
> No, there's no type casting.
> 
> C++'s std::string objects have c_str and data methods, both
> of which return a pointer to a const array of characters.
> That pointer remains the propertry of the string, and is valid
> until a potentially mutating operation is performed on the string.

Is the "validity" of the pointer checked after a mutating operation is
performed, or is it up to the programmer to be aware of that?

If it is not checked, that explains why Ada did not provide the
equivalent operation; Ada doesn't assume the programmer will obey the
rules :).

-- 
-- Stephe

Re: Is the Writing on the Wall for Ada?

[Hyman Rosen]

Stephen Leake wrote:
> Is the "validity" of the pointer checked after a mutating operation is
> performed, or is it up to the programmer to be aware of that?
> 
> If it is not checked, that explains why Ada did not provide the
> equivalent operation; Ada doesn't assume the programmer will obey the
> rules :).

Unchecked, of course; it's just a plain pointer.
It's used when something you're trying to call
demands a plain pointer.

Re: Is the Writing on the Wall for Ada?

[Matthew Heaney]

Stephen Leake <Stephe.Leake@nasa.gov> writes:

> If it is not checked, that explains why Ada did not provide the
> equivalent operation; Ada doesn't assume the programmer will obey the
> rules :).

Then perhaps Ada should stop assuming all programmers are babies.

Re: Is the Writing on the Wall for Ada?

[tmoran]

>Then perhaps Ada should stop assuming all programmers are babies.
  There's an interesting paper on error rates at
http://panko.cba.hawaii.edu/ssr/Mypapers/whatknow.htm
It focuses on spreadsheets, but mentions data from other fields.  Humans
seem to run around 1-5% errors, with the low side being uncorrected
mechanical errors (typos, letting the car drift outside its lane, etc) and
the higher side for logical or judgement errors.  Humans are also
highly overconfident in their estimates of what a good job they've done.

Re: Is the Writing on the Wall for Ada?

[Wes Groleau]

>>If it is not checked, that explains why Ada did not provide the
>>equivalent operation; Ada doesn't assume the programmer will obey the
>>rules :).
> 
> Then perhaps Ada should stop assuming all programmers are babies.

Is breaking the rules completely equivalent to being a baby?

No  -  Ada doesn't assume all programmers are babies.

Yes -  a majority of programmers are babies.

-- 
Wes Groleau
Heroes, Heritage, and History
http://freepages.genealogy.rootsweb.com/~wgroleau/

Re: Is the Writing on the Wall for Ada?

[Stephen Leake]

Matthew Heaney <matthewjheaney@earthlink.net> writes:

> One nice thing about C++ std::string is that you have c_str() and data()
> member functions, which give you a traditional nul-terminated const
> char* and a non-nul terminated const char*, respectively.  This makes it
> trivial to build up a string using std::string (or its close cousin
> std::ostringstream), and then to turn around and get the char* array
> using c_str(), which means it can basically be used everywhere a const
> char* can.
> 
> The problem with Ada.Strings.Unbounded is that to do anything useful
> with it requires a conversion to type String, which is grossly
> inefficient, not to mention awkward.

I don't find "To_String (An_Unbounded)" any more awkward than
"A_String.data()". Please explain.

As to "inefficient", that depends on the implementation. Hm, I guess
you mean To_String almost always requires a copy. But if you use the
result of To_String as the argument to a function, can't the Ada
compiler optimize that to a reference? That's what I would expect.

> The ACT people added a Aux child (I think that's the name), which
> provides a function to return the underlying String_Access. This is
> how Ada.Strings.Unbounded should have been designed in the first
> place.

I expect the compiler to achieve that level of effiency when I write
the code in a way that makes it possible.

> The C++ std::string also has a getline procedure to read from stdin
> directly into a std::string. A similar function should have been
> provided for Ada.Strings.Unbounded.

True, and ACT did so. That would be a good candidate for Ada0Y

-- 
-- Stephe

Re: Is the Writing on the Wall for Ada?

[Randy Brukardt]

"Stephen Leake" <Stephe.Leake@nasa.gov> wrote in message
news:ufzij4fbt.fsf@nasa.gov...
> > The C++ std::string also has a getline procedure to read from stdin
> > directly into a std::string. A similar function should have been
> > provided for Ada.Strings.Unbounded.
>
> True, and ACT did so. That would be a good candidate for Ada0Y

See AI-301.

          Randy.

Re: Is the Writing on the Wall for Ada?

[Craig Carey]

On Fri, 26 Sep 2003 02:31:52 GMT, Matthew Heaney wrote:
>"Robert I. Eachus" <rieachus@attbi.com> writes:
>> Hyman Rosen wrote:
>> > Stephen Leake wrote:
>> >> Ada.Strings.Unbounded. Way better than C++ Strings.
>> > How?
>> 
>> For one simple example, an Ada string of any flavor can always contain
>> all possible character literals and control codes.
>
...
>The problem with Ada.Strings.Unbounded is that to do anything useful
>with it requires a conversion to type String, which is grossly
>inefficient, not to mention awkward.
>

Only if the string is large enough, e.g. 3KB or more, at least for GNAT
(and ObjectAda) in Windows. The requirements of the oft revised RM 7.6
(user controlled finalization) guide vendors to get their Unbounded
strings code to be slow.

----

Suppose there was a destructive Assign operator that is fast and
efficient.

It would do this:

Tmp := Rhs.Ptr;
Rhs.Ptr := Lhs.Ptr;
Lhs.Ptr := Tmp;
Lhs.valid := True
Rhs.valid := False

I vaguely recall these two arguments from persons...:

  * Variant fields mismatch

  * Run time crashes in the vendors compiler software and the exceptions
  coming out of Adjust or Finalize have to be correctly handled.

Those feeble arguments are of no obvious importance in connection with
 the issue.

I have not checked to see if GNAT has already got the "Assign(L,R);"
extension that results in a fast ":=" assignment operator.

With big customers requesting features all the time, it is pssible.



>The ACT people added a Aux child (I think that's the name), which
>provides a function to return the underlying String_Access.  This is how
>Ada.Strings.Unbounded should have been designed in the first place.
>


They could change the Aux package. E.g. produce rewritten Unbounded
 strings code.

Also the Aux package exposes a limited implementation.
E.g. there is no spare space in strings. User code might not run
correctly if that changes.

Also, it is not the case that the RM "should" describe something that
is not known to be defined.



>The C++ std::string also has a getline procedure to read from stdin
>directly into a std::string.  A similar function should have been
>provided for Ada.Strings.Unbounded.


GNAT's Get_Line lost the CP/M disk block padding char (in Windows 2000
[ASCI 26 if I recall right]). ASCII 13 is liable to go too. The RM
allows some of that or all of it.

Expanding the problem for that small purpose might not get voted for.

Also the new Get_Line subroutine, returning a line of any length,
would do unnecessary copying. Above this was written:

    "... The problem with Ada.Strings.Unbounded is that ...
    it requires a conversion to type String, ... which is
    inefficient..."

That seems to be saying that unnecessary copying 'should' be avoided
(i.e. it says "to type String" rather than: "from [the Ada String
 type]").



Craig Carey

A replacement for Charles' Strings:
    http://www.ijs.co.nz/code/ada95_strings_pkg.zip

 Likel to be cmpatible with the ACT modified GPL.

Re: Is the Writing on the Wall for Ada?

[Robert I. Eachus]

Craig Carey wrote:

> Also the new Get_Line subroutine, returning a line of any length,
> would do unnecessary copying.

Not necessarily.  I think that we will end up with both a Get_Line that 
returns an Unbounded_String in Ada 0Y and one that returns a String.

In Ada 83, a function that returned an unbounded String (notice the 
punctuation) was almost useless.  In fact, there was one in Ada 80, and 
it was taken out.  But changes in Ada 95 made such a function much more 
useful, so I think it will get put back.  (It doesn't require any 
changes to the compiler to add it, but some compiler vendors may do some 
work to make it more efficient.)

As for a Get_Line function returning an Unbounded_String, the only real 
question is where it should be defined.  I'd be happy with a child of 
Ada.Text_IO that supported several operations on Unbounded_Strings 
including Get, Get_Line, and Put.
-- 
                                                     Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: Is the Writing on the Wall for Ada?

[tmoran]

>As for a Get_Line function returning an Unbounded_String,
  Isn't that an open invitation to a denial-of-service buffer (available
RAM) overflow?

Re: Is the Writing on the Wall for Ada?

[(see below)]

On 30/9/03 04:24, in article VH6eb.632855$YN5.465410@sccrnsc01,
"tmoran@acm.org" <tmoran@acm.org> wrote:

>> As for a Get_Line function returning an Unbounded_String,
> Isn't that an open invitation to a denial-of-service buffer
> (available RAM) overflow?

I use the following package a lot.  If you are prepared to risk
Storage_Error, instantiate with Max_Length => Integer'Last.

It would probably be better (more modular and perhaps more efficient) to
have the functions return Unbounded_String and leave conversion to
Bounded_String or String to the client.

with Ada.Text_IO; use  Ada.Text_IO;
generic
    Max_Length                   : in Positive := 260;
    Default_Initial_Length       : in Positive := 32;
    Length_Expansion_Numerator   : in Positive := 3;
    Length_Expansion_Denominator : in Positive := 2;
    -- N.B. 260 = 32 + 32*3/2 + (32*3/2)*3/2 + ((32*3/2)*3/2)*3/2
    -- giving efficiency points at 32, 80, 152, 260, ...
package Generic_Get_Line_Functions is

   -- To get a string of bounded, but unknown, length,
   -- from a text file; as a (fixed) String.
   -- These functions ALWAYS consume the end-of-line mark.

   -- The following return a string of generic maximum length Max_Length.
   
    function Get_Line return String;    --from Current_Input
    function Get_Line (Source : File_Type) return String;    -- from Source

   -- The following return a string of specified maximum length Max_Length.
   
    function Get_Line
       (Estimated_Initial_Length, Max_Length : Positive)
    return String;    --from Current_Input

    function Get_Line
       (Source : File_Type;
        Estimated_Initial_Length, Max_Length : Positive)
    return String;    -- from Source

end Generic_Get_Line_Functions;

-- 
Bill:Findlay chez Blue:Yonder dot:co:dot:uk (":" => "")

Re: Is the Writing on the Wall for Ada?

[Robert I. Eachus]

tmoran@acm.org wrote:
>>As for a Get_Line function returning an Unbounded_String,
> 
>   Isn't that an open invitation to a denial-of-service buffer (available
> RAM) overflow?

Then don't use it when reading from an untrusted source.  You will 
always have the option of choosing a fixed buffer size and reading into 
it without the possibility of overflow that exists now.

But just because there are some programs where it may cause problems 
isn't a reason to deny it to others.


-- 
                                         Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: Is the Writing on the Wall for Ada?

[Larry Kilgallen]

In article <3F79EC72.3@comcast.net>, "Robert I. Eachus" <rieachus@comcast.net> writes:
> tmoran@acm.org wrote:
>>>As for a Get_Line function returning an Unbounded_String,
>> 
>>   Isn't that an open invitation to a denial-of-service buffer (available
>> RAM) overflow?
> 
> Then don't use it when reading from an untrusted source.  You will 
> always have the option of choosing a fixed buffer size and reading into 
> it without the possibility of overflow that exists now.
> 
> But just because there are some programs where it may cause problems 
> isn't a reason to deny it to others.

Treating exceptional circumstances with an exception handler seems like
the right thing to do.

Re: Is the Writing on the Wall for Ada?

[Preben Randhol]

On 2003-09-30, Robert I. Eachus <rieachus@comcast.net> wrote:
> Not necessarily.  I think that we will end up with both a Get_Line that 
> returns an Unbounded_String in Ada 0Y and one that returns a String.

Will there be a Bounded_String too?

Preben

Re: Is the Writing on the Wall for Ada?

[Marin David Condic]

I'm not even sure why Bounded_String exists - except for intellectual 
completeness. Yes, I can see where in some cases I might want the 
flexibility of Unbounded_String with the determinism of String. However, 
in practice, I use either String or Unbounded_String. I don't even think 
I ever took the shrink-wrap off of Bounded_String. If I really needed 
it, I could create it on my own rather easily. But I've never needed it.

I suppose it would not hurt too much to make a Bounded_String version. 
More for completeness than anything else. (It would look kind of silly 
to be able to do a Get_Line or Put_Line of String or Unbounded_String 
but not Bounded_String, right?) But I'd be curious to know if there is 
*anybody* out there using Bounded_String on a regular basis. (Maybe it 
should be depricated?)

There's another reason for having a conventional library outside of the 
ARM - we could have experimented with the three string packages and 
discovered if there was much interest in a Bounded_String before 
committing it to permanent existence as part of the standard.

MDC

Preben Randhol wrote:
> 
> 
> Will there be a Bounded_String too?
> 
> Preben


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

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

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Is the Writing on the Wall for Ada?

[Larry Kilgallen]

In article <3F797748.3000203@noplace.com>, Marin David Condic <nobody@noplace.com> writes:

> I'm not even sure why Bounded_String exists - except for intellectual 
> completeness. Yes, I can see where in some cases I might want the 
> flexibility of Unbounded_String with the determinism of String. However, 
> in practice, I use either String or Unbounded_String. I don't even think 
> I ever took the shrink-wrap off of Bounded_String. If I really needed 
> it, I could create it on my own rather easily. But I've never needed it.

But the programming practices of others may differ.  Efficiency concerns
may have different parameters in other environments.

> There's another reason for having a conventional library outside of the 
> ARM - we could have experimented with the three string packages and 
> discovered if there was much interest in a Bounded_String before 
> committing it to permanent existence as part of the standard.

No !  The meaning of a conventional library should be something that will
stay available in perpetuity.  Otherwise it is just like any other library
that may or may not be present.

Re: Is the Writing on the Wall for Ada?

[Marin David Condic]

Larry Kilgallen wrote:
> 
> But the programming practices of others may differ.  Efficiency concerns
> may have different parameters in other environments.
> 
That's why I was asking if anybody else was using it. For me, I go 
either String (efficiency/determinism) or Unbounded_String 
(convenience). I don't know if perhaps there is a whole cult following 
out there for Bounded_String.

> 
> No !  The meaning of a conventional library should be something that will
> stay available in perpetuity.  Otherwise it is just like any other library
> that may or may not be present.

Blasphemy! :-) A huge advantage of NOT insisting that something in a 
library remain there in perpetuity is *PRECISELY* because then it 
becomes no different than the ARM. You'd have a TEN YEAR cycle and 
endless reviews and huge validation requirements all over again - just 
in a different context. You *WANT* the fluidity of being able to say 
"Here's a new release that fixes some of the dumb ideas we had in the 
last one..."

Oh sure, you'd probably do beta releases to some subset of customers and 
get some feedback on what was in there, etc. You wouldn't yank a package 
without having good reasons and hopefully you'd do so before making a 
"general release". But if you can never get some stupid idea out of the 
library, then you've lost one of the big advantages of having one 
outside of the standard. If it required persistence, people would 
quickly start insisting on all the due diligence you see going into the ARM.

MDC



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

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

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Is the Writing on the Wall for Ada?

[Jean-Pierre Rosen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 696 bytes --]


"Marin David Condic" <nobody@noplace.com> a �crit dans le message de news:3F797748.3000203@noplace.com...
> I'm not even sure why Bounded_String exists - except for intellectual
> completeness.
They are great if you want an abstract data type *implemented as* as string of variable length.

For example, if you have Person_Name, Person_Address, etc.
You want them to be different types, they have a maximum length, and
a variable current length. Instead of deriving from String, you get these
types by an instantiation of Bounded_String.

-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Is the Writing on the Wall for Ada?

[Robert I. Eachus]

Jean-Pierre Rosen wrote:

> For example, if you have Person_Name, Person_Address, etc.
> You want them to be different types, they have a maximum length, and
> a variable current length. Instead of deriving from String, you get these
> types by an instantiation of Bounded_String.

Exactly, I often use several instances of Bounded_String when working 
with a database.  Since the name or whatever does have a maximum length 
it makes much more sense to limit it at the point of creation, where you 
can handle errors in a more meaningful manner.

If you want a subtle point to discuss though, should the I/O operations 
for Unbounded_String and instances of Bounded_String be symmetric, and 
symmetrically located?  My inclination is that Get and Put for 
Bounded_String belong in Ada.Strings.Bounded_String, but Get_Line for 
Unbounded_String belongs in Ada.Text_IO...

-- 
                                                     Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: Is the Writing on the Wall for Ada?

[Preben Randhol]

On 2003-09-30, Robert I. Eachus <rieachus@comcast.net> wrote:
> If you want a subtle point to discuss though, should the I/O operations 
> for Unbounded_String and instances of Bounded_String be symmetric, and 
> symmetrically located?  My inclination is that Get and Put for 
> Bounded_String belong in Ada.Strings.Bounded_String, but Get_Line for 
> Unbounded_String belongs in Ada.Text_IO...

I can agree on that since Bounded are generic.

Preben

Re: Is the Writing on the Wall for Ada?

[Frank J. Lhota]

"Preben Randhol" <randhol+valid_for_reply_from_news@pvv.org> wrote in
message
news:slrnbnjv9h.f3.randhol+valid_for_reply_from_news@kiuk0152.chembio.ntnu.no...
> I can agree on that since Bounded are generic.

My only objection to Strings.Bounded is the unnecessary use of a generic. I
would have been happier if they had skipped the Generic_Bounded_Length
package and defined Bounded_String as a type with a discriminant that
defines the maximum length, i.e.

    type Bounded_String ( Max : Positive ) is private;

This approach would be easier to use, at the cost of some additional
constraints on the implementers. I know of no implementation of
Strings.Bounded, however, that could not easily be adapted to this scheme.

Re: Is the Writing on the Wall for Ada?

[Robert I. Eachus]

Frank J. Lhota wrote:

> This approach would be easier to use, at the cost of some additional
> constraints on the implementers. I know of no implementation of
> Strings.Bounded, however, that could not easily be adapted to this scheme.

But see my previous message.  Such a type is useless for ragged arrays. 
  You can create ragged arrays in Ada using Bounded_String or 
Unbounded_String, but doing so requires that there is no discriminant 
for the outer type.

-- 
                                                     Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: Is the Writing on the Wall for Ada?

[Frank J. Lhota]

"Robert I. Eachus" <rieachus@comcast.net> wrote in message
news:3F7B1076.8060106@comcast.net...
> Frank J. Lhota wrote:
> But see my previous message.  Such a type is useless for ragged arrays.
>   You can create ragged arrays in Ada using Bounded_String or
> Unbounded_String, but doing so requires that there is no discriminant
> for the outer type.

Good point!

Re: Is the Writing on the Wall for Ada?

[Dmitry A. Kazakov]

On Wed, 01 Oct 2003 17:36:18 GMT, "Robert I. Eachus"
<rieachus@comcast.net> wrote:

>Frank J. Lhota wrote:
>
>> This approach would be easier to use, at the cost of some additional
>> constraints on the implementers. I know of no implementation of
>> Strings.Bounded, however, that could not easily be adapted to this scheme.
>
>But see my previous message.  Such a type is useless for ragged arrays. 
>  You can create ragged arrays in Ada using Bounded_String or 
>Unbounded_String, but doing so requires that there is no discriminant 
>for the outer type.

Which only means that there is a deficiency in array design. They have
to be allowed to have discriminants. Then:

type Ragged_Array (Max_Size : Positive) is
   array (Integer range <>) of
      Bounded_String (Max_Size);

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

Counter-proposal for variable arrays

[Wes Groleau]

Dmitry A. Kazakov wrote:
> Which only means that there is a deficiency in array design. They have
> to be allowed to have discriminants. Then:

Even better (if it doesn't open some can of worms)
would be

    (sub)type Variable (Lower : <discrete> := <default;
                   Upper : <discrete> := default)
         is array (Lower .. Upper) of <ANY_type>;

    Varies : Variable;

equivalent to

    type Variable (Lower : <discrete> := <default;
                   Upper : <discrete> := default)
         is record
              Actual : array (Lower .. Upper) of <any_type>;
            end record;

    Varies : Variable;

except that any operation legal for Varies.Actual
in the second case would be legal for Varies in the
first including operations that would change the
value of the discriminant in a deterministic way, like

    Varies := Varies & Varies;

(same rules as records regarding variants declared fixed) and

defaults may be omitted - same rules as record discriminants and

discriminant names are flexible and

either discriminant may be omitted if both uses of that
discriminant are literals or already declared entities and

the name of an array (sub)type may be used instead of "array"
in which case it will be a variable length subtype of the other
with the same constraint rules as unvarying subtypes.

I don't see any major difficulty with this (though
I have not thought about it for very long).  However,
I have doubts whether it can be extended to multidimensional
arrays.  If it is practical to extend it that way, with all
currently legal array operations, I would enthusiastically
support it.  If practicality required limitations compared
to current arrays, it would depend on whether the disadvantage
of inconsistency outweighs the potential benefits.


-- 
Wes Groleau
-----------
Daily Hoax: http://www.snopes2.com/cgi-bin/random/random.asp

Re: Counter-proposal for variable arrays

[Dmitry A. Kazakov]

Wes Groleau wrote:

> Dmitry A. Kazakov wrote:
>> Which only means that there is a deficiency in array design. They have
>> to be allowed to have discriminants. Then:
> 
> Even better (if it doesn't open some can of worms)
> would be
> 
>     (sub)type Variable (Lower : <discrete> := <default;
>                    Upper : <discrete> := default)
>          is array (Lower .. Upper) of <ANY_type>;
> 
>     Varies : Variable;

This is another thing. You want to expose the array bounds as discriminants
it would be also possible. But the main problem with arrays is an inability
to constrain elements together with the array:

type Line_Buffer (Height, Width : Positive) is
   array (Integer range 1..Height) of
      String (1..Width); -- Illegal

Moreover, if type tags were considered as discriminants (and they should),
one could even have the arrays of class-wide elements, which could save
rather painful and clumsy attempts to design generic containers "a la" STL.
After all the whole idea behind STL containers is to provide arrays which
C++ does not have!

Yet another issue is the defaults for discriminants. I think that the idea
to tie an existence of the defaults with treating the type constrained (by
the maximal size) was altogether wrong. These issues are unrelated. There
should be a different and a better way to specify this. Especially, to have
constrained subsets of X'Class. For instance, by specifying the whole range
of tags X'Class might have.

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

Re: Counter-proposal for variable arrays

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> After all the whole idea behind STL containers is to provide arrays which
> C++ does not have!

Huh? C++ has arrays, and the STL containers are not particularly
array-like. Maybe vector, if you squint a little.

Re: Counter-proposal for variable arrays

[Pascal Obry]

Hyman Rosen <hyrosen@mail.com> writes:

> Huh? C++ has arrays, and the STL containers are not particularly
> array-like. Maybe vector, if you squint a little.

You are confusiong the language and the libraries. C++ has no vector, no
array not even strings, just pointers to chunk of memories.

Ada has array which support 'first 'last 'length 'range slice and more.

If we count libraries why not say then that Ada or C++ has matrix support or
database support... !!!!

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Counter-proposal for variable arrays

[Marin David Condic]

But here is a really important thing for people to notice: Most 
programmers make little/no distinction between the language and the 
libraries they get with their compiler. Effectively, its the same thing. 
Especially if the language declares some library to be officialy a part 
of the language (such as Ada does with Text_IO.)

Knowing that people won't make that distinction is important when 
discussing what should be "Part of Ada".

MDC


Pascal Obry wrote:
> 
> 
> You are confusiong the language and the libraries. C++ has no vector, no
> array not even strings, just pointers to chunk of memories.
> 
> Ada has array which support 'first 'last 'length 'range slice and more.
> 
> If we count libraries why not say then that Ada or C++ has matrix support or
> database support... !!!!
> 
> Pascal.
> 


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

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

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Counter-proposal for variable arrays

[Hyman Rosen]

Pascal Obry wrote:
> You are confusiong the language and the libraries. C++ has no vector, no
> array not even strings, just pointers to chunk of memories.

I am not confusing anything. C++ has arrays. And C++ string literals
have type "array[N] of char" where N is determined by the contents of
the literal.

> Ada has array which support 'first 'last 'length 'range slice and more.

C++ has arrays. They all start at 0. C++ doesn't have slices. It also
doesn't have arrays with dynamic sizes (although C99 now does). And
you can't assign them in one statement.

The number of elements in array is available through the classic
sizeof/sizeof construct, or through a prettier template version.

Making obviously wrong statements about C++ is silly.

Re: Counter-proposal for variable arrays

[Pascal Obry]

Hyman Rosen <hyrosen@mail.com> writes:

> C++ has arrays. 

No it has pointers.

> Making obviously wrong statements about C++ is silly.

I can send you the same compliment! Or maybe we have a different definition
of array.

   char ptr1[156];
   char ptr2[156];

   ptr1 = ptr2;

Just copy the "pointer" ptr2 to ptr1. That's my point. Array is not a first
class citizen in C++, just "emulated" with pointers. To pass such "array" into
a procedure you can say:

   void proc (char *ptr);

And into ptr you can pass objects such as:

   ptr1        

   new char[12]

   "whatever"

Call this array if you like.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Counter-proposal for variable arrays

[Ole-Hjalmar Kristensen]

>>>>> "PO" == Pascal Obry <p.obry@wanadoo.fr> writes:

    PO> Hyman Rosen <hyrosen@mail.com> writes:

    >> C++ has arrays. 

    PO> No it has pointers.

    >> Making obviously wrong statements about C++ is silly.

    PO> I can send you the same compliment! Or maybe we have a different definition
    PO> of array.

    PO>    char ptr1[156];
    PO>    char ptr2[156];

    PO>    ptr1 = ptr2;

    PO> Just copy the "pointer" ptr2 to ptr1. That's my point. Array is not a first
    PO> class citizen in C++, just "emulated" with pointers. To pass such "array" into
    PO> a procedure you can say:

It would be a good idea to check your facts before posting. Arrays are
*constant* pointers, so the assignment above will not compile.

But I agree that arrays are not first class citizens in C/C++.
The relationship with pointers is obvious if you look at the following
relationship, which always holds:

x[13] == *(x+13) == *(13+x) == 13[x] !!!!

    PO>    void proc (char *ptr);

    PO> And into ptr you can pass objects such as:

    PO>    ptr1        

    PO>    new char[12]

Yes, there is no range check, just like Fortran.

    PO>    "whatever"

Yes, like Ada, C strings are arrays of characters :-)

    PO> Call this array if you like.

I do, the C array is essentially the same as early Fortran, and being
brainwashed by the Univac Fortran compiler at an early age, I cannot
see why this is not an array. You just have to keep track of the
bounds yourself.

    PO> Pascal.

    PO> -- 

    PO> --|------------------------------------------------------
    PO> --| Pascal Obry                           Team-Ada Member
    PO> --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
    PO> --|------------------------------------------------------
    PO> --|         http://perso.wanadoo.fr/pascal.obry
    PO> --| "The best way to travel is by means of imagination"
    PO> --|
    PO> --| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

-- 
This page intentionally left blank

Re: Counter-proposal for variable arrays

[Pascal Obry]

Ole-Hjalmar Kristensen <ole-hjalmar.kristensen@sun.com> writes:

> It would be a good idea to check your facts before posting. Arrays are
> *constant* pointers, so the assignment above will not compile.

Right. Should have been "char *ptr1 = malloc (156);" idem for ptr2.

> But I agree that arrays are not first class citizens in C/C++.
> The relationship with pointers is obvious if you look at the following
> relationship, which always holds:
> 
> x[13] == *(x+13) == *(13+x) == 13[x] !!!!
> 
>     PO>    void proc (char *ptr);
> 
>     PO> And into ptr you can pass objects such as:
> 
>     PO>    ptr1        
> 
>     PO>    new char[12]
> 
> Yes, there is no range check, just like Fortran.

That's not the point. My point is that you can pass ptr1 or "new char[12]"
into a "char*" parameter. Hence the fact that this is pointers not arrays.

>     PO>    "whatever"
> 
> Yes, like Ada, C strings are arrays of characters :-)

Again that's not the point. In Ada you can't pass "whatever" into a procedure
parameter declared as:

   procedure Proc (Ptr : access Character);

In Ada "whatever" is a String, a string is an array:

   type String is array (Positive range <>) of Character;

and there is no relation between Ada String and pointer of characters.

>     PO> Call this array if you like.
> 
> I do, 

As you like!

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Counter-proposal for variable arrays

[Hyman Rosen]

Pascal Obry wrote:
> That's not the point. My point is that you can pass ptr1 or "new char[12]"
> into a "char*" parameter. Hence the fact that this is pointers not arrays.

No. C and C++ have automatic conversion from an array type to
a pointer to (first) element. Also, function parameters cannot
be arrays, and even if they are declared that way, they are not
arrays but pointers.

Nevertheless, the arrays are real arrays, and in C++, their
character is easily preserved by using references.

Re: Counter-proposal for variable arrays

[Hyman Rosen]

Pascal Obry wrote:
> I can send you the same compliment! Or maybe we have a different definition
> of array.
>    char ptr1[156];
>    char ptr2[156];
>    ptr1 = ptr2;

This is illegal in both C and C++, and will compile in neither.

> To pass such "array" into a procedure you can say:
>    void proc (char *ptr);

To pass an array and preserve its array type, just use a reference:
     void proc(char (&array)[156]);

Into this you can pass only conformant arrays, not arbitrary char *s.
Naturally this would normally be written as a template
     template<typename T, unsigned N> void proc(T (&array)[N]);
in order to have it work for arbitrary array types and sizes.

> Call this array if you like.

OK, I will.

Re: Counter-proposal for variable arrays

[Dmitry A. Kazakov]

Hyman Rosen wrote:

> Dmitry A. Kazakov wrote:
>> After all the whole idea behind STL containers is to provide arrays which
>> C++ does not have!
> 
> Huh? C++ has arrays,

Pointer arithmetics is not yet an array.

> and the STL containers are not particularly
> array-like.

For the reason above. I do not consider lists because they never were a
challenge, even in FORTRAN (:-)). The arrays are. Now, with OO stuff it
becomes worse and worse, because an inability to have an array of
class-wide elements forces use of all sorts of pointers.

> Maybe vector, if you squint a little.

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

Re: Counter-proposal for variable arrays

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> Pointer arithmetics is not yet an array.

No. But an array is an array. What are you talking about?

> an array of class-wide elements forces use of all sorts of pointers.

Yeah. So what? What exactly would the implementation of an array of
class-wide elements look like, anyway?

Re: Counter-proposal for variable arrays

[Dmitry A. Kazakov]

On Sun, 05 Oct 2003 05:52:06 GMT, Hyman Rosen <hyrosen@mail.com>
wrote:

>Dmitry A. Kazakov wrote:
>> Pointer arithmetics is not yet an array.
>
>No. But an array is an array. What are you talking about?

Mmm I guess array is something that one can pass as a parameter. For
example:

void Erase (char X [20])
{
   memset (X, 0, sizeof (X)); // How many element will be set?
}

>> an array of class-wide elements forces use of all sorts of pointers.
>
>Yeah. So what? What exactly would the implementation of an array of
>class-wide elements look like, anyway?

For example:

-- This is not Ada, Syntax is imaginary.
type Window is tagged ...;
type Child_Window is new Window with ...;
type Pop_Up_Window is new Child_Window with ...; 

type Container (From, To : Tag) is
   array (Integer range <>) of
      Window'Class (From..To);

Wild_Array : Container  (1..20);
   -- Compile error, not constrained

Children_And_Pop_Up_Array :
   Container 
   (  1..20, -- Constrain the bounds
      From => Child_Window'Tag, -- Constrain the elements
      To => Pop_Up_Window'Tag
   );
   -- This is OK

The array contains 20 elements of types between Child_Window and
Pop_Up_Window. Note that because all possible types are known, the
upper bound of the element size is also known. So the array could be
allocated as usual.

Observe, that this is in full conformance with notorious Ada's concept
of unconstrained types. You can have them, but all instances have to
be constrained. Thus nothing prevents us from having an array of
class-wide elements, IF there were a way to constrain both the array
bounds (we already have this in Ada) and the elements (we do not have
this).

My proposal is to allow discriminants for array to have a way to
constrain array elements.

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

Re: Counter-proposal for variable arrays

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> Mmm I guess array is something that one can pass as a parameter. For
> example:
> void Erase (char X [20])
> {
>    memset (X, 0, sizeof (X)); // How many element will be set?
> }

For C compatibility, C++ arrays have the same decay-to-pointer
semantics in many circumstances. To prevent this, simply use a
reference:

void Erase (char (&X)[20]) { memset(X, 0, sizeof(X)); }

>>Yeah. So what? What exactly would the implementation of an array of
>>class-wide elements look like, anyway?
> 
> Children_And_Pop_Up_Array :
>    Container 
>    (  1..20, -- Constrain the bounds
>       From => Child_Window'Tag, -- Constrain the elements
>       To => Pop_Up_Window'Tag
>    );
> 
> The array contains 20 elements of types between Child_Window and
> Pop_Up_Window. Note that because all possible types are known, the
> upper bound of the element size is also known. So the array could be
> allocated as usual.

This seems like a pretty specialized usage to me, not particularly
worthy of dedicated language support. For one thing, classwide types
are there to support object-oriented programming, where you don't
know at the declaration point what types will be used.

For your purpose above, can't you just use an array of variant records
instead?

Re: Counter-proposal for variable arrays

[Dmitry A. Kazakov]

On Wed, 08 Oct 2003 06:56:37 GMT, Hyman Rosen <hyrosen@mail.com>
wrote:

>Dmitry A. Kazakov wrote:
>> Mmm I guess array is something that one can pass as a parameter. For
>> example:
>> void Erase (char X [20])
>> {
>>    memset (X, 0, sizeof (X)); // How many element will be set?
>> }
>
>For C compatibility, C++ arrays have the same decay-to-pointer
>semantics in many circumstances.

Yep, it has no arrays for compatibility reasons. (:-))

>>>Yeah. So what? What exactly would the implementation of an array of
>>>class-wide elements look like, anyway?
>> 
>> Children_And_Pop_Up_Array :
>>    Container 
>>    (  1..20, -- Constrain the bounds
>>       From => Child_Window'Tag, -- Constrain the elements
>>       To => Pop_Up_Window'Tag
>>    );
>> 
>> The array contains 20 elements of types between Child_Window and
>> Pop_Up_Window. Note that because all possible types are known, the
>> upper bound of the element size is also known. So the array could be
>> allocated as usual.
>
>This seems like a pretty specialized usage to me, not particularly
>worthy of dedicated language support. For one thing, classwide types
>are there to support object-oriented programming, where you don't
>know at the declaration point what types will be used.

Exactly. Therefore, please recall my example. The type Container is
the type which knows *nothing* about the types it will contain. This
is why it is unconstrained. Compare it with the type String, it also
does not know how many characters will be there. Only when you create
a concrete instance of the type, an object, you have to constrain it,
i.e. to say which types are allowed there or how many characters it
will hold. This is the whole idea.

Observe that it is the same idea as in the case ot generic containers,
a pretty specialized usage, you'd say. A "generic type" is also
unconstrained, because its actual parameters are unknown. When you
instantiate it, you constrain it by providing the parameters. It is
exactly the same thing (called generic programming). The difference,
though is that with a discriminants instantiation is much more
simplier and can be done at run-time.

>For your purpose above, can't you just use an array of variant records
>instead?

Of course not. Variant records have to be explicity specified each
time you need an instance of the type. It is same as to propose
variant records instead of the type String:

type Awful_String (Length : Positive) is record
   case (Length) is
      when 1 =>
         One_Char : String (1..1);
      when 2 => 
         Two_Chars : String (1..2);
...

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

Re: Counter-proposal for variable arrays

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> Only when you create a concrete instance of the type, an object,
 > you have to constrain it, i.e. to say which types are allowed there
 > or how many characters it will hold. This is the whole idea.

So now you will have arrays whose stride as well as bounds
is a runtime property. We should equally allow records with
unconstrained field types, and let the constraints get set
upon creation. Then the field offsets themselves could be
runtime properties too. Then we could have classwide objects
in records.

It's all doable. I guess the question is whether you get
enough bang for the buck to make it worthwhile to specify
and implement. My inclination is no, but anyone who really
wants it could have a go at the GNAT sources and make a
proof of concept.

Re: Counter-proposal for variable arrays

[Dmitry A. Kazakov]

On Wed, 08 Oct 2003 13:54:00 -0400, Hyman Rosen <hyrosen@mail.com>
wrote:

>Dmitry A. Kazakov wrote:
>> Only when you create a concrete instance of the type, an object,
> > you have to constrain it, i.e. to say which types are allowed there
> > or how many characters it will hold. This is the whole idea.
>
>So now you will have arrays whose stride as well as bounds
>is a runtime property.

Exactly.

>We should equally allow records with
>unconstrained field types, and let the constraints get set
>upon creation.

It is already possible. Though there should be a work done for the
tagged types. My another proposal is to treat the type tag of a
class-wide as a discrimant. This would allow a lot of very interesting
things to do. To start with, one will be able to assign class-wide
objects, intrigued?

>Then the field offsets themselves could be
>runtime properties too.

It is already so. Consider:

type Tricky (I, J : Positive) is record
   X : String (1..I);
   Y : String (1..J);
end record;

The offset to Y is variable and depends on the value of I.

>Then we could have classwide objects
>in records.

Right. See above, the tags has to be exposed as discriminants.

>It's all doable. I guess the question is whether you get
>enough bang for the buck to make it worthwhile to specify
>and implement. My inclination is no, but anyone who really
>wants it could have a go at the GNAT sources and make a
>proof of concept.

For good or bad, neither Ada is C++ nor I have Stroustrup's influence
on the language design. There should be some consensus reached. And of
course, any change undertaken have to be carefully reviewed. So far I
observe little interest in further evolving Ada's ADT concept. It is a
pity, because in my view Ada has the best potential to become the
first of the next generation languages. (:-()

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

Re: Counter-proposal for variable arrays

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> It is already so. Consider:
> type Tricky (I, J : Positive) is record
>    X : String (1..I);
>    Y : String (1..J);
> end record;
> The offset to Y is variable and depends on the value of I.

I Didn't Know You Could Do That In Ada(tm). :-)
It really works that way? And you can have procedures
which just take unconstrained Tricky parameters, and
they'll know how to deal with all instances? Cool!

> For good or bad, neither Ada is C++ nor I have Stroustrup's influence
> on the language design. There should be some consensus reached. And of
> course, any change undertaken have to be carefully reviewed.

Don't underestimate the power of Just Doing It. You know how they
say that it's easier to get forgiveness than permission. If the
feature were actually added to a popular compiler and worked well,
that would be a big step in gaining acceptance.

Re: Counter-proposal for variable arrays

[Frank J. Lhota]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:1065709998.992831@master.nyc.kbcfp.com...
> Dmitry A. Kazakov wrote:
> > It is already so. Consider:
> > type Tricky (I, J : Positive) is record
> >    X : String (1..I);
> >    Y : String (1..J);
> > end record;
> > The offset to Y is variable and depends on the value of I.
>
> I Didn't Know You Could Do That In Ada(tm). :-)
> It really works that way? And you can have procedures
> which just take unconstrained Tricky parameters, and
> they'll know how to deal with all instances? Cool!

Yep, Ada really works that way, and Ada procedures handle these "Tricky"
parameters all the time. And I'm glad you find it cool. :)

> > For good or bad, neither Ada is C++ nor I have Stroustrup's influence
> > on the language design. There should be some consensus reached. And of
> > course, any change undertaken have to be carefully reviewed.
>
> Don't underestimate the power of Just Doing It. You know how they
> say that it's easier to get forgiveness than permission. If the
> feature were actually added to a popular compiler and worked well,
> that would be a big step in gaining acceptance.

Amen!

Re: Counter-proposal for variable arrays

[Randy Brukardt]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:1065709998.992831@master.nyc.kbcfp.com...
> Dmitry A. Kazakov wrote:
> > It is already so. Consider:
> > type Tricky (I, J : Positive) is record
> >    X : String (1..I);
> >    Y : String (1..J);
> > end record;
> > The offset to Y is variable and depends on the value of I.
>
> I Didn't Know You Could Do That In Ada(tm). :-)
> It really works that way? And you can have procedures
> which just take unconstrained Tricky parameters, and
> they'll know how to deal with all instances? Cool!

You can write this, but it often isn't implemented with variable offsets.
What Janus/Ada does is to use discontinous storage for
depends-on-discriminant components. The component itself is a descriptor,
and has fixed size. The array data is allocated separately. That way, we can
actually change the data memory when the discriminants are changed by
assignment, and we don't use more memory than necessary.

Most other compilers don't do that, but I know that some at least use extra
pointers in cases like the above to avoid having non-static offsets.

On the other hand, if you do generic code sharing (as Janus/Ada does), you
end up with dynamic offsets, dispatching slots, tags, array strides, object
sizes, and pretty much everything else. (But usually not all at the same
time!)

                Randy.



>
> > For good or bad, neither Ada is C++ nor I have Stroustrup's influence
> > on the language design. There should be some consensus reached. And of
> > course, any change undertaken have to be carefully reviewed.
>
> Don't underestimate the power of Just Doing It. You know how they
> say that it's easier to get forgiveness than permission. If the
> feature were actually added to a popular compiler and worked well,
> that would be a big step in gaining acceptance.
>

Re: Counter-proposal for variable arrays

[Dmitry A. Kazakov]

On Wed, 15 Oct 2003 19:52:22 -0500, "Randy Brukardt"
<randy@rrsoftware.com> wrote:

>"Hyman Rosen" <hyrosen@mail.com> wrote in message
>news:1065709998.992831@master.nyc.kbcfp.com...
>> Dmitry A. Kazakov wrote:
>> > It is already so. Consider:
>> > type Tricky (I, J : Positive) is record
>> >    X : String (1..I);
>> >    Y : String (1..J);
>> > end record;
>> > The offset to Y is variable and depends on the value of I.
>>
>> I Didn't Know You Could Do That In Ada(tm). :-)
>> It really works that way? And you can have procedures
>> which just take unconstrained Tricky parameters, and
>> they'll know how to deal with all instances? Cool!
>
>You can write this, but it often isn't implemented with variable offsets.
>What Janus/Ada does is to use discontinous storage for
>depends-on-discriminant components. The component itself is a descriptor,
>and has fixed size. The array data is allocated separately. That way, we can
>actually change the data memory when the discriminants are changed by
>assignment, and we don't use more memory than necessary.

An interesting approach. But what will happen if I write:

type Tricky_Ptr is access Tricky;
for Tricky_Ptr'Storage_Pool use My_Stack_Pool;

Do you switch between representations?

---
As I see, your compiler is ready for:

type Crazy (T : Tag) is record
   Anything : Root_Type'Class (T);
end record;

(:-))

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

Re: Counter-proposal for variable arrays

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:7aisov0u9cha33e1fgvpli7mmdqqmmh7l9@4ax.com...
> On Wed, 15 Oct 2003 19:52:22 -0500, "Randy Brukardt"
> <randy@rrsoftware.com> wrote:
>
> >"Hyman Rosen" <hyrosen@mail.com> wrote in message
> >news:1065709998.992831@master.nyc.kbcfp.com...
> >> Dmitry A. Kazakov wrote:
> >> > It is already so. Consider:
> >> > type Tricky (I, J : Positive) is record
> >> >    X : String (1..I);
> >> >    Y : String (1..J);
> >> > end record;
> >> > The offset to Y is variable and depends on the value of I.
> >>
> >> I Didn't Know You Could Do That In Ada(tm). :-)
> >> It really works that way? And you can have procedures
> >> which just take unconstrained Tricky parameters, and
> >> they'll know how to deal with all instances? Cool!
> >
> >You can write this, but it often isn't implemented with variable offsets.
> >What Janus/Ada does is to use discontinous storage for
> >depends-on-discriminant components. The component itself is a descriptor,
> >and has fixed size. The array data is allocated separately. That way, we
can
> >actually change the data memory when the discriminants are changed by
> >assignment, and we don't use more memory than necessary.
>
> An interesting approach. But what will happen if I write:
>
> type Tricky_Ptr is access Tricky;
> for Tricky_Ptr'Storage_Pool use My_Stack_Pool;
>
> Do you switch between representations?

Huh? We just use whatever pool is the correct one.

To expand on that: For record types, we declare a number of subprograms with
the type (unless it is very simple). One of those is the allocation
subprogram; it takes the object address and a storage pool parameter. This
routine is called whenever an object is constructed (even on the stack); of
course, there is a pool for memory which is recovered when the stack frame
is destroyed. (Tuck has convinced me that our implementation is subtly
wrong; it will need major surgury, but the basic idea will be remain the
same. The main change will be that every stack frame will (logically) have
its own pool - currently, there is one global stack pool.)

> ---
> As I see, your compiler is ready for:
>
> type Crazy (T : Tag) is record
>    Anything : Root_Type'Class (T);
> end record;
>
> (:-))

Yup, the design is very flexible. More flexible than is really needed to
implement Ada 95, but perhaps it will work well for Dmitry 2009. :-)

                 Randy.

Re: Counter-proposal for variable arrays

[Dmitry A. Kazakov]

Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:7aisov0u9cha33e1fgvpli7mmdqqmmh7l9@4ax.com...
>> On Wed, 15 Oct 2003 19:52:22 -0500, "Randy Brukardt"
>> <randy@rrsoftware.com> wrote:
>>
>> >"Hyman Rosen" <hyrosen@mail.com> wrote in message
>> >news:1065709998.992831@master.nyc.kbcfp.com...
>> >> Dmitry A. Kazakov wrote:
>> >> > It is already so. Consider:
>> >> > type Tricky (I, J : Positive) is record
>> >> >    X : String (1..I);
>> >> >    Y : String (1..J);
>> >> > end record;
>> >> > The offset to Y is variable and depends on the value of I.
>> >>
>> >> I Didn't Know You Could Do That In Ada(tm). :-)
>> >> It really works that way? And you can have procedures
>> >> which just take unconstrained Tricky parameters, and
>> >> they'll know how to deal with all instances? Cool!
>> >
>> >You can write this, but it often isn't implemented with variable
>> >offsets. What Janus/Ada does is to use discontinous storage for
>> >depends-on-discriminant components. The component itself is a
>> >descriptor, and has fixed size. The array data is allocated separately.
>> >That way, we
> can
>> >actually change the data memory when the discriminants are changed by
>> >assignment, and we don't use more memory than necessary.
>>
>> An interesting approach. But what will happen if I write:
>>
>> type Tricky_Ptr is access Tricky;
>> for Tricky_Ptr'Storage_Pool use My_Stack_Pool;
>>
>> Do you switch between representations?
> 
> Huh? We just use whatever pool is the correct one.

So either (1) the array data is in effect allocated not in My_Stack_Pool,
but in the heap, or else, (2) you break My_Stack_Pool by calling Deallocate
on array data out of order, when the object gets resized.

> To expand on that: For record types, we declare a number of subprograms
> with the type (unless it is very simple). One of those is the allocation
> subprogram; it takes the object address and a storage pool parameter. This
> routine is called whenever an object is constructed (even on the stack);
> of course, there is a pool for memory which is recovered when the stack
> frame is destroyed. (Tuck has convinced me that our implementation is
> subtly wrong; it will need major surgury, but the basic idea will be
> remain the same. The main change will be that every stack frame will
> (logically) have its own pool - currently, there is one global stack
> pool.)

So the first variant. It would be very interesting to try some time to
expose such things for user as it was finally made with user-defined
storage pools. I mean discontinuously allocated objects without pointers.
Recursive types, infinite types, ragged arrays all that stuff ...

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

Re: Is the Writing on the Wall for Ada?

[Robert I. Eachus]

Dmitry A. Kazakov wrote:

 > Which only means that there is a deficiency in array design. They
 > have to be allowed to have discriminants...

You can't have thought about this.  Ada does allow Multidimensional
arrays, arrays of arrays, and ragged arrays.  But they are different,
and viv� la difference.  I could even create an ISAM type in Ada, but
why bother, ragged arrays are usually better.  The point is though that
all of these structures have structure invariants which are different.

An array is a structure where all the elements are alike.  Ada lets you
play games by "hiding" properties of elemental types to get this
alikeness.  You can have arrays of types with discriminants, but if you
do, all the elements in an array have the same discriminant.  If you
want an array of elements with different discriminants, the type with
the discriminant has to be buried:

type Color is (Red, Orange, Yellow, Green, Blue, Violet);

type Colored_Record (Col: Color := Red) is ...;

type Outer_Record is record
   CR: Colored_Record;
end record;

type Green_Array is array(Integer range <>) of Colored_Record(Green);

type Technicolor_Array is array(Integer range <>) of Outer_Record;

GA: Green_Array(1..10);
TA: Technicolor_Array(1..10);
...

if GA(7).Col = GA(6).Col -- must be true
if TA(7).CR.Col = TA(6).CR.Col  -- may or may not be true.

You may think it would be "nice" to be able to create arrays in Ada
where the elements are of different size, or different lengths, or have 
different ranges.  But they wouldn't be arrays.  If you wanted to add a 
reserved word fwallop to name such a structure, the semantic sugar to 
support declarations of such collections would obviously be pretty trivial.

But again, why bother.  Ada has a nice invariant--all elements of an 
array have the same visible attributes--and a way to wrap up objects to 
hide attributes from arrays if you want to allow them to be different.

-- 
                                                     Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the
goal of Art. It remains to work these concepts into a practical,
down-to-earth context, and for this there is nothing more practical or
down-to-earth than what I have been talking about all along...the repair
of an old motorcycle."  -- from Zen and the Art of Motorcycle
Maintenance by Robert Pirsig

Re: Is the Writing on the Wall for Ada?

[Dmitry A. Kazakov]

Robert I. Eachus wrote:

> Dmitry A. Kazakov wrote:
> 
>  > Which only means that there is a deficiency in array design. They
>  > have to be allowed to have discriminants...
> 
> You can't have thought about this.  Ada does allow Multidimensional
> arrays, arrays of arrays, and ragged arrays.  But they are different,
> and vivé la difference.  I could even create an ISAM type in Ada, but
> why bother, ragged arrays are usually better.  The point is though that
> all of these structures have structure invariants which are different.
>
> An array is a structure where all the elements are alike.  Ada lets you
> play games by "hiding" properties of elemental types to get this
> alikeness.  You can have arrays of types with discriminants, but if you
> do, all the elements in an array have the same discriminant.

This is what I want. And this is what arrays cannot:

type Element (Constraint : Natural) is ...;
type Array_Of_Elements is array (...) of Element;

This is not allowed, because I cannot constrain Element, and there is no way
to do it other than create a constrained subtype of Element.

Even if I pack the array into a record to have a discriminant, even so, it
will be still illegal:

type Array_Of_Same_Elements (Constraint : Natural) is record
   Body : array (...) of Element (Constraint);
end record;

Note that it is *not* a ragged array. All elements are of exactly *same*
size. What is required is:

type Array_Of_Same_Elements (Constraint : Natural) is
   array (...) of Element (Constraint);

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

Re: Is the Writing on the Wall for Ada?

[Wes Groleau]

Dmitry A. Kazakov wrote:
> This is what I want. And this is what arrays cannot:
> 
> type Element (Constraint : Natural) is ...;
> type Array_Of_Elements is array (...) of Element;
> 
> This is not allowed, because I cannot constrain Element, and there is no way
> to do it other than create a constrained subtype of Element.

I realize this is not exactly what you meant,
but is it not possible to do this:

    type Element (Constraint : Natural) is ...;

    type Array_Of_Elements is array (...) of Element;

    Demo : Array_Of_Elements :=
           ( (Constraint =>  1,  .... ),
             (Constraint =>  5,  .... ),
             ....
             (Constraint => 32,  .... ),
             (Constraint => 11,  .... ) );

= OR =

    type Element (Constraint : Natural := 0) is ...;

    type Array_Of_Elements is array (...) of Element;

    Demo : Array_Of_Elements;

-- 
Wes Groleau
    "Would the prodigal have gone home if
     the elder brother was running the farm?"
                       -- James Jordan

Re: Is the Writing on the Wall for Ada?

[Dmitry A. Kazakov]

Wes Groleau wrote:

> Dmitry A. Kazakov wrote:
>> This is what I want. And this is what arrays cannot:
>> 
>> type Element (Constraint : Natural) is ...;
>> type Array_Of_Elements is array (...) of Element;
>> 
>> This is not allowed, because I cannot constrain Element, and there is no
>> way to do it other than create a constrained subtype of Element.
> 
> I realize this is not exactly what you meant,
> but is it not possible to do this:
> 
>     type Element (Constraint : Natural) is ...;
> 
>     type Array_Of_Elements is array (...) of Element;

No. Consider a very simple thing:

   type String_Array is array (...) of String;

You cannot do that because the element is not constrained. The compiler does
not know that in our case all elements are of same length. How to tell him?

You have to do something like:

   type String_In_Record (Length : Positive) is
      The_Body : String (1..Length);
   end record;

and even this artificial construct does not work:

   type String_Array is array (...) of String_In_Record; -- Error

So you have to go further:

   type String_In_Record (Length : Positive := 80) is
      The_Body : String (1..Length);
   end record;

This would result in Storage_Error. Defaulted discriminants are not what
people usualy think about them!

And even if you replace Positive with something of lesser range, you will
not solve the problem:

   type Index is range 1..1024;
   type Yet_Another_String is array (Index range <>) of Character;
   type String_In_Record (Length : Index := 80) is
      The_Body : Yet_Another_String (1..Length);
   end record;
   type String_Array is array (...) of String_In_Record;

Observe that this disgusting construction does not serve the purpose,
because it allocates the memory for the worst case.

And also this does not work for all the cases where the defaults are not
allowed for the discriminants. For example (a very important one), the
tagged types cannot have defaulted discriminants.

Presently this is unsolvable without generics.

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

Re: Is the Writing on the Wall for Ada?

[Wes Groleau]

Dmitry A. Kazakov wrote:
> Observe that this disgusting construction does not serve the purpose,
> because it allocates the memory for the worst case.

Of course it does.  I understand you want constrained
sizes that are not the same, but if you are willing
to make the type have unconstrained elements, nothing
prevents you from putting contrained ones into those slots.

To minimize memory usage in a ragged array, access types
work quite well and do not add significant complexity.
Make them controlled if you're worried about cleanup.

-- 
Wes Groleau

A pessimist says the glass is half empty.

An optimist says the glass is half full.

An engineer says somebody made the glass
        twice as big as it needed to be.

Re: Is the Writing on the Wall for Ada?

[Dmitry A. Kazakov]

On Sat, 04 Oct 2003 19:49:44 -0500, Wes Groleau
<groleau@freeshell.org> wrote:

>Dmitry A. Kazakov wrote:
>> Observe that this disgusting construction does not serve the purpose,
>> because it allocates the memory for the worst case.
>
>Of course it does.  I understand you want constrained
>sizes that are not the same,

No, I want them same:

type Array_Of_Same_Strings (Length : Positive) is
   array (Integer range <>) of
      String (1..Length);

Note, that Bounded_String do have *same* sizes [if their maximal
length is same]. If their design were non-generic:

type Bounded_String (Max_Length : Positive) is record ... end record;

then with array discriminants one could have quasi-ragged arrays,
which are *not* in fact ragged:

type  Array_Of_Varying_Strings  (Max_Length : Positive) is
   array (Integer range <>) of
      Bounded_String (Max_Length); 

>but if you are willing
>to make the type have unconstrained elements, nothing
>prevents you from putting contrained ones into those slots.
>
>To minimize memory usage in a ragged array, access types
>work quite well and do not add significant complexity.
>Make them controlled if you're worried about cleanup.

Access types are inherently bad. After all this solution exists since
K&R C. If you want to say that there are work-arounds odious to
different grades. Yes, they are.

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

Re: Is the Writing on the Wall for Ada?

[Wes Groleau]

Dmitry A. Kazakov wrote:
> No, I want them same:
> 
> type Array_Of_Same_Strings (Length : Positive) is
>    array (Integer range <>) of
>       String (1..Length);

subtype Array_Element is String (1 .. Length);

type Array_Of_Same_Strings (Length : Positive) is
     array (Integer range <>) of Array_Element;

> Access types are inherently bad. After all this solution exists since
> K&R C. If you want to say that there are work-arounds odious to

C's pointer to anything and Ada's access to
a specific type have VERY LITTLE in common.

I do not think an array of controlled types
is odious, nor do I have any problem using
an access type where appropriate.  But since
you want the lengths the same, neither is needed.


-- 
Wes Groleau

    "A man wih an experience is never
     at the mercy of a man with an argument."
                       -- Ron Allen

Re: Is the Writing on the Wall for Ada?

[Dmitry A. Kazakov]

On Mon, 06 Oct 2003 17:57:20 -0500, Wes Groleau
<groleau@freeshell.org> wrote:

>Dmitry A. Kazakov wrote:
>> No, I want them same:
>> 
>> type Array_Of_Same_Strings (Length : Positive) is
>>    array (Integer range <>) of
>>       String (1..Length);
>
>subtype Array_Element is String (1 .. Length);
>
>type Array_Of_Same_Strings (Length : Positive) is
>     array (Integer range <>) of Array_Element;

It does not work, because then Array_Of_Same_Strings is no more a
type, same for all possible elements (String). It is a generic
solution, not a discriminant-based one. Each time you need another
element size you have to instantiate. So you will have another type.
Therefore you will not be able to write a non-generic subprogram
working for all Array_Of_Same_Strings. So it is a "generic" type.

>> Access types are inherently bad. After all this solution exists since
>> K&R C. If you want to say that there are work-arounds odious to
>
>C's pointer to anything and Ada's access to
>a specific type have VERY LITTLE in common.

Like memory leaks.

>I do not think an array of controlled types
>is odious, nor do I have any problem using
>an access type where appropriate.  But since
>you want the lengths the same, neither is needed.

Really? Try to compile this:

type X (I : Integer) is tagged null record;
type Y is array (Integer range <>) of X;

Observe that all X have same size. Note also that the trick of
providing an arbitrary default for the discriminant would not work
here, because X is tagged.

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

Re: Is the Writing on the Wall for Ada?

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:blm0au$dkoad$2@ID-77047.news.uni-berlin.de...
> So you have to go further:
>
>    type String_In_Record (Length : Positive := 80) is
>       The_Body : String (1..Length);
>    end record;
>
> This would result in Storage_Error. Defaulted discriminants are not what
> people usualy think about them!

No, this *can* result in Storage_Error. It certainly will not in Janus/Ada
(which allocates unconstrained records to size). I personally think it is a
mistake to implement unconstrained records so that the above reasonable
construct doesn't work -- but that is a position that is not widely held.

...
> Presently this is unsolvable without generics.

No, just get a better compiler. :-)

(OK, it can't be solve portably, because implementations are allowed to
raise Storage_Error in the above case. But implementations are *always*
allowed to raise Storage_Error. So that is always a risk.)

                  Randy.

Re: Is the Writing on the Wall for Ada?

[Dmitry A. Kazakov]

On Wed, 15 Oct 2003 19:59:34 -0500, "Randy Brukardt"
<randy@rrsoftware.com> wrote:

>"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>news:blm0au$dkoad$2@ID-77047.news.uni-berlin.de...
>> So you have to go further:
>>
>>    type String_In_Record (Length : Positive := 80) is
>>       The_Body : String (1..Length);
>>    end record;
>>
>> This would result in Storage_Error. Defaulted discriminants are not what
>> people usualy think about them!
>
>No, this *can* result in Storage_Error. It certainly will not in Janus/Ada
>(which allocates unconstrained records to size). I personally think it is a
>mistake to implement unconstrained records so that the above reasonable
>construct doesn't work -- but that is a position that is not widely held.
>
>...
>> Presently this is unsolvable without generics.
>
>No, just get a better compiler. :-)

Point taken! (:-))

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

Re: Is the Writing on the Wall for Ada?

[Robert I. Eachus]

Dmitry A. Kazakov wrote:

> Even if I pack the array into a record to have a discriminant, even so, it
> will be still illegal:
> 
> type Array_Of_Same_Elements (Constraint : Natural) is record
>    Body : array (...) of Element (Constraint);
> end record;
> 
> Note that it is *not* a ragged array. All elements are of exactly *same*
> size. What is required is:
> 
> type Array_Of_Same_Elements (Constraint : Natural) is
>    array (...) of Element (Constraint);

What you are complaining about here is that Ada currently allows unnamed 
array types as objects, but not as components of records.  If anything I 
am with you on this one, but I think that the ARG would be more likely 
to eliminate unnamed array types than allow them in new contexts. 
(Notice that Ada is somewhat consistant in this, you can declare task 
types, and task objects, and protected objects and protected types, but 
not record objects.)

-- 
                                                     Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: Is the Writing on the Wall for Ada?

[Dmitry A. Kazakov]

Robert I. Eachus wrote:

> Dmitry A. Kazakov wrote:
> 
>> Even if I pack the array into a record to have a discriminant, even so,
>> it will be still illegal:
>> 
>> type Array_Of_Same_Elements (Constraint : Natural) is record
>>    Body : array (...) of Element (Constraint);
>> end record;
>> 
>> Note that it is *not* a ragged array. All elements are of exactly *same*
>> size. What is required is:
>> 
>> type Array_Of_Same_Elements (Constraint : Natural) is
>>    array (...) of Element (Constraint);
> 
> What you are complaining about here is that Ada currently allows unnamed
> array types as objects, but not as components of records.

No. I am complaining that the universal concept of using the discriminant
values as the constraints is not applicable to all types. This irregularity
causes abberations all over the language design.

For instance, you have used it to justify a generics-based design for
bounded strings as opposed to a much more clearer and easier to use
solution based on discriminated records.

> If anything I
> am with you on this one, but I think that the ARG would be more likely
> to eliminate unnamed array types than allow them in new contexts.
>
> (Notice that Ada is somewhat consistant in this, you can declare task
> types, and task objects, and protected objects and protected types, but
> not record objects.)

... not scalar types, not access types. Whether to allow them is a question.

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

Re: Is the Writing on the Wall for Ada?

[Georg Bauhaus]

>>>>> "Dmitry" == Dmitry A Kazakov <mailbox@dmitry-kazakov.de> writes:

::: Note that it is *not* a ragged array. All elements are of exactly
::: *same* size. What is required is:

: No. I am complaining that the universal concept of using the
: discriminant values as the constraints is not applicable to all
: types. This irregularity causes abberations all over the language
: design.

What kind of algorithms do you have in mind that would profit greatly
from using an array with irregular offsets from one component to the
next?



Georg

Re: Is the Writing on the Wall for Ada?

[Dmitry A. Kazakov]

On 04 Oct 2003 13:28:50 +0200, Georg Bauhaus <sb463ba@uni-duisburg.de>
wrote:

>>>>>> "Dmitry" == Dmitry A Kazakov <mailbox@dmitry-kazakov.de> writes:
>
>::: Note that it is *not* a ragged array. All elements are of exactly
>::: *same* size. What is required is:
>
>: No. I am complaining that the universal concept of using the
>: discriminant values as the constraints is not applicable to all
>: types. This irregularity causes abberations all over the language
>: design.
>
>What kind of algorithms do you have in mind that would profit greatly
>from using an array with irregular offsets from one component to the
>next?

You missed the point. The offsets *are* regular. See examples I have
provided.

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

Re: Is the Writing on the Wall for Ada?

[Georg Bauhaus]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
: You missed the point.

Yep

Re: Is the Writing on the Wall for Ada?

[Robert I. Eachus]

Dmitry A. Kazakov wrote:

> No. I am complaining that the universal concept of using the discriminant
> values as the constraints is not applicable to all types. This irregularity
> causes abberations all over the language design.
> 
> For instance, you have used it to justify a generics-based design for
> bounded strings as opposed to a much more clearer and easier to use
> solution based on discriminated records.

No, the Bounded_String package just uses generics to set the maximum 
length.  You can write a non-generic version of the package if you want. 
  The only 'trick' involved is that you need two record types, and the 
discriminant--and the bounds--of the innner type must not depend on the 
outer type.

subtype Bound is Integer range 1..30;
type Inner(Length: Bound := 0) is record
   S: String(1..Length);
end record;
type Bounded is record C: Contents := Inner; end record;

type Ragged_Array is array(Integer range <>) of Bounded;

That is all of Ada.Strings.Bounded that you really need.  The rest of 
the declarations are for convenience:

function To_String(B: in Bounded) is begin return B.C.S; end To_String;
pragma Inline(To_String);

As you can see, all of the operations for type Bounded end up being very 
efficient, and are really only there as 'syntactic sugar' to make it 
easier for users to used the package.  I guess that is why I am 
"frothing at the mouth" in this discussion of how difficult it is to use 
Ada.Strings.Bounded instead of Strings.  I personally don't like the 
'extra' generic nesting in Ada.Strings.Bounded, but in general when I 
use the package, it is wrapped in another generic that does other things 
with the type, like mapping it to database entries, so I only pay the 
generic instantiation overhead in my programming once.


-- 
                                         Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: Is the Writing on the Wall for Ada?

[Dmitry A. Kazakov]

On Sat, 04 Oct 2003 13:48:17 GMT, "Robert I. Eachus"
<rieachus@comcast.net> wrote:

>Dmitry A. Kazakov wrote:
>
>> No. I am complaining that the universal concept of using the discriminant
>> values as the constraints is not applicable to all types. This irregularity
>> causes abberations all over the language design.
>> 
>> For instance, you have used it to justify a generics-based design for
>> bounded strings as opposed to a much more clearer and easier to use
>> solution based on discriminated records.
>
>No, the Bounded_String package just uses generics to set the maximum 
>length.  You can write a non-generic version of the package if you want.

And why the standard goes other way? (:-))

>  The only 'trick' involved is that you need two record types, and the 
>discriminant--and the bounds--of the innner type must not depend on the 
>outer type.
>
>subtype Bound is Integer range 1..30;
>type Inner(Length: Bound := 0) is record
>   S: String(1..Length);
>end record;
>type Bounded is record C: Contents := Inner; end record;
>
>type Ragged_Array is array(Integer range <>) of Bounded;

What if 31 character length string is required? Now we have answered
the question, why Bounded_String was made generic - to avoid arbitrary
limitations like the number 30 in the example.

BTW I commented this solution in my other post. It is not a solution,
of course.

>That is all of Ada.Strings.Bounded that you really need.  The rest of 
>the declarations are for convenience:
>
>function To_String(B: in Bounded) is begin return B.C.S; end To_String;
>pragma Inline(To_String);
>
>As you can see, all of the operations for type Bounded end up being very 
>efficient, and are really only there as 'syntactic sugar' to make it 
>easier for users to used the package.  I guess that is why I am 
>"frothing at the mouth" in this discussion of how difficult it is to use 
>Ada.Strings.Bounded instead of Strings.  I personally don't like the 
>'extra' generic nesting in Ada.Strings.Bounded, but in general when I 
>use the package, it is wrapped in another generic that does other things 
>with the type, like mapping it to database entries, so I only pay the 
>generic instantiation overhead in my programming once.

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

Re: Is the Writing on the Wall for Ada?

[Robert I. Eachus]

Dmitry A. Kazakov wrote:

> What if 31 character length string is required? Now we have answered
> the question, why Bounded_String was made generic - to avoid arbitrary
> limitations like the number 30 in the example.

I may be misunderstanding you.  If you may be faced with a 31 character 
string (or any arbitrary length) then you should be using 
Unbounded_String.  If there is a firm length limitation then it doesn't 
really matter, as far as the abstraction is concerned, if you put it in 
a variable, a named constant, a numeric literal, a subprogram parameter 
or a generic formal.  Ada.Strings.Bounded uses a generic formal.  The 
only thing to remember is that the size limit for a particular array 
type will be set when the element subtype is elaborated, even if the 
limit is taken from a variable.

-- 
                                                     Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: Is the Writing on the Wall for Ada?

[Dmitry A. Kazakov]

On Wed, 08 Oct 2003 14:16:53 GMT, "Robert I. Eachus"
<rieachus@comcast.net> wrote:

>Dmitry A. Kazakov wrote:
>
>> What if 31 character length string is required? Now we have answered
>> the question, why Bounded_String was made generic - to avoid arbitrary
>> limitations like the number 30 in the example.
>
>I may be misunderstanding you.

Yes

>If you may be faced with a 31 character 
>string (or any arbitrary length) then you should be using 
>Unbounded_String.

Come on! In 80% cases when I do not know the exact length I am not
forced either to turn to generics or to heap-allocated objects.
Conventional String works fine:

Buffer : String (1..Whatsoever);

Why should I use Unbounded_String? If this works with singular objects
and with records of objects why on earth it should not with arrays?

The point is:

A clear deficiency is an inability to constrain [*all*] the array
elements through a discriminant.

This in turn makes a non-generic implementation of Bounded_String less
usable. An example of use:

type Array_Of_Bounded_Strings (Max_Length : Natural) is
   array (...) of Bounded_String (Max_Length);

Where is any limit here?

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

Re: Is the Writing on the Wall for Ada?

[Robert I. Eachus]

Dmitry A. Kazakov wrote:

> A clear deficiency is an inability to constrain [*all*] the array
> elements through a discriminant.
> 
> This in turn makes a non-generic implementation of Bounded_String less
> usable. An example of use:
> 
> type Array_Of_Bounded_Strings (Max_Length : Natural) is
>    array (...) of Bounded_String (Max_Length);
> 
> Where is any limit here?

Um, that the syntax is not legal Ada?  If you look at my recent post you 
will see that you can do something which actually creates what you want. 
  And notice that since the type Bounded_Array is totally non-generic, 
you can write a function that returns an object of type Bounded_Array 
assign it to a variable, then operate on that:

Name_List: Bounded_Array := Get_Names(...);

Since Name_List will take its bounds from the return value of Get_Names, 
Get_Names can be written to return a Bounded_Array where the maximum 
length is chosen based on the strings to be returned.  To go back to an 
earlier question, if your query matches twelve names, and the longest 
name matched has length 31, then Name_List.Size = 12, and Name_List.Max 
= 31.

-- 
                                                     Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: Is the Writing on the Wall for Ada?

[Dmitry A. Kazakov]

On Wed, 08 Oct 2003 23:37:29 GMT, "Robert I. Eachus"
<rieachus@comcast.net> wrote:

>Dmitry A. Kazakov wrote:
>
>> A clear deficiency is an inability to constrain [*all*] the array
>> elements through a discriminant.
>> 
>> This in turn makes a non-generic implementation of Bounded_String less
>> usable. An example of use:
>> 
>> type Array_Of_Bounded_Strings (Max_Length : Natural) is
>>    array (...) of Bounded_String (Max_Length);
>> 
>> Where is any limit here?
>
>Um, that the syntax is not legal Ada?

Of course it is not. Arrays cannot have discriminants.

>If you look at my recent post you 
>will see that you can do something which actually creates what you want.

I do not want a concrete object. I want a regularity. Array of bounded
strings was just an incidental example to bring this issue up.

Much more interesting to me would be arrays of:

1. tagged elements, having discriminants

2. class-wide elements, which tags are constrained by the array
discriminants

3. dimensioned values. Consider:

   type Dimensioned (SI : Unit) is record
      Value : Float;
   end record;

   type Vector (SI : Unit) is array (...) of Dimensioned (SI);
   type Matrix (SI : Unit) is array (..., ...) of Dimensioned (SI);

etc.

Moreover I would propose that *any* type should be allowed to have
discriminants. Examples:

type Dimensioned (SI : Unit) is new Float;
type Vector (SI : Unit) is array (...) of Dimensioned (SI);

type Hard_Coded_String (L, U : Integer) is access all Character;

type Dynamically_Constrained_Value (L, U : Integer) is new Integer;

>And notice that since the type Bounded_Array is totally non-generic, 
>you can write a function that returns an object of type Bounded_Array 
>assign it to a variable, then operate on that:
>
>Name_List: Bounded_Array := Get_Names(...);

Mmm, I found no Bounded_Array definition in your earlier posts, but I
assume it was Ragged_Array.

>Since Name_List will take its bounds from the return value of Get_Names, 
>Get_Names can be written to return a Bounded_Array where the maximum 
>length is chosen based on the strings to be returned.  To go back to an 
>earlier question, if your query matches twelve names, and the longest 
>name matched has length 31, then Name_List.Size = 12, and Name_List.Max 
>= 31.

And with Ragged_Array it won't work. With Array_Of_Bounded_Strings it
will.

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

Re: Is the Writing on the Wall for Ada?

[Robert I. Eachus]

Dmitry A. Kazakov wrote:

> Mmm, I found no Bounded_Array definition in your earlier posts, but I
> assume it was Ragged_Array.

I'll repost it with a new thread name (A nongeneric bounded string array 
type), this one has grown out of control.  But it was very much not 
Ragged_Array, and I wish I had thought of it twenty years ago.  It is 
much more useful than Ada.Strings.Bounded when interfacing to databases.

-- 
                                                     Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: Is the Writing on the Wall for Ada?

[Wes Groleau]

Robert I. Eachus wrote:
> If you want a subtle point to discuss though, should the I/O operations 
> for Unbounded_String and instances of Bounded_String be symmetric, and 
> symmetrically located?  My inclination is that Get and Put for 
> Bounded_String belong in Ada.Strings.Bounded_String, but Get_Line for 
> Unbounded_String belongs in Ada.Text_IO...

My feeling is that any types other than (Wide_)Character
& (Wide_)String should be handled either in the same packages
as their datatypes or _both_ in child packages of Ada.Text_IO

I'd like to minimize adding new withs to predefined packages.
And I prefer symmetry--easier for learners if all the IO
packages/child packages have the same "shape"

-- 
Wes Groleau

Is it an on-line compliment to call someone a Net Wit ?

Re: Is the Writing on the Wall for Ada?

[Marin David Condic]

O.K. So you actually have, and do, use it in real applications.

It makes a kind of good sense to say "I get this string from a database 
and it is always 80 bytes long at max, so I'll make a Bounded_String to 
match it." That's an issue of having to match the external reality while 
getting the most use you can from Ada's tools. When I've had 
circumstances such as this, I'd end up with a "String (1..80)" - mostly 
because I'd feel like I was spitting into the wind with respect to the 
rest of the language by using a Bounded_String and I probably couldn't 
read it directly into a Bounded_String anyway, so why bother with the 
conversion? It might depend some on how you intended to use the 
Bounded_String - lots of manipulation might make the rest of the package 
more handy, but if all you're going to do is pass it around and print it 
out, then String might work just as well.

But do you use Bounded_String in circumstances where you get to design 
the whole thing from bottom-dead-center? (You don't have to match the 
external reality - you can create the external reality to suit your needs.)

MDC

Robert I. Eachus wrote:
> 
> Exactly, I often use several instances of Bounded_String when working 
> with a database.  Since the name or whatever does have a maximum length 
> it makes much more sense to limit it at the point of creation, where you 
> can handle errors in a more meaningful manner.



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

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

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Is the Writing on the Wall for Ada?

[Robert I. Eachus]

Marin David Condic wrote:

> But do you use Bounded_String in circumstances where you get to design 
> the whole thing from bottom-dead-center? (You don't have to match the 
> external reality - you can create the external reality to suit your needs.)

Of course, and again, it is the array case that makes this 
representation highly useful.  Say you get a list of names from a query, 
and want to sort it using a non-standard definition of ">".  I had one 
such program where the sort was required to treat "McFoo" like "MacFoo", 
the accented characters including cedillas were sorted after the base 
letter, except that A with ring above went before A, the AE dipthong was 
sorted as if it were a letter following A, even if the AE was spelled 
out, and of course, Sr. was sorted before Jr., and Jr. before III, etc.

Of course, in Ada, I defined my own ">" for Character inside an ">" for 
Last_Name and used a standard sort routine instantiated for an array of 
Names.

-- 
                                                     Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: Is the Writing on the Wall for Ada?

[Marin David Condic]

O.K. But my question remains, "Does anybody use them in *practice*?" 
When I've needed a record field for something like Person_Name and 
wanted some fixed allocation on it, I use a String and if/when I needed 
to know where the string stopped, I use a "Last_Non_Blank ()" function. 
But in most of the instances where I need something like this, I just 
jump to Unbounded_String and am done with it.

I understand that Bounded_String has some technical advantages, but in 
my experience, the instant I'm on a PC at some astronomical number of 
megahertz/gigahertz with more memory than I can shake a stick at, 
Unbounded_String and all its technical disadvantages compared to 
Bounded_String just seem to not amount to a warm bucket of spit. Hence 
I'm wondering if people actually have/do use it on anything like a 
regular basis.

Maybe I'm unusual and most Ada programmers make use of Bounded_String 
thirteen times a day. My usual question is: "Do I care about speed or 
determinism in this application?" When "Yes" => String; When "No" => 
Unbounded_String; Do other programmers have a When "Maybe" => 
Bounded_String; branch?

I'm sure we could sit here all day and dream up circumstances when 
Bounded_String might make some sense, but I'm wondering if in real-world 
experience, people make use of it. Remember that one of the motivations 
behind RISC architectures was that researchers discovered that in some 
instances, specific CISC architecture instructions were not being 
exploited at all by compilers and started asking the question "Should we 
waste the silicon to implement it if nobody is using it?" That's the 
question I'm asking here.


MDC


Jean-Pierre Rosen wrote:
> They are great if you want an abstract data type *implemented as* as string of variable length.
> 
> For example, if you have Person_Name, Person_Address, etc.
> You want them to be different types, they have a maximum length, and
> a variable current length. Instead of deriving from String, you get these
> types by an instantiation of Bounded_String.
> 


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

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

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Is the Writing on the Wall for Ada?

[Jean-Pierre Rosen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1159 bytes --]


"Marin David Condic" <nobody@noplace.com> a �crit dans le message de news:3F7AC5B0.9080108@noplace.com...
> O.K. But my question remains, "Does anybody use them in *practice*?"
> When I've needed a record field for something like Person_Name and
> wanted some fixed allocation on it, I use a String and if/when I needed
> to know where the string stopped, I use a "Last_Non_Blank ()" function.
> But in most of the instances where I need something like this, I just
> jump to Unbounded_String and am done with it.
>
Maybe you missed the point that you have *different* types for Person_Name
and Person_Address.

Of course, you could use types derived from strings. And keep the current length in
an integer rather looking for a space, so you'll have to pack that into a record.
While we're at it, it would be nice to have a discriminant to parameterize the
maximum length... Well, at that point, you are just rewriting Bounded_Strings.
(except for the discriminant in place of the generic parameter).

-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Is the Writing on the Wall for Ada?

[Marin David Condic]

No. I don't think I missed that point. Person_Name and Person_Address 
can both be derived from String - as you observe. Do I get enough 
*extra* from Bounded_String to make it worth not being "compatible" with 
String for all the usual Ada attributes, subprograms, etc? My usual 
answer is "No". Maybe others have a different answer. Hence the 
question: "Do people use Bounded_String much in practice or is it a 
'Nice To Have' feature that just doesn't see much practical usage."

I'd like to see some semi-reasonable survey of folks doing a "Search 
*.ad* 'Bounded_String'" on their libraries of Ada95 code and discover if 
*in practice* it really gets used much. My personal experience is 'not 
much - if at all.'

I just never thought I got enough out of Bounded_String to make it worth 
the effort of not being compatible with all the 'standard' things that 
utilized the type String. (Yes, I'm aware you can convert. I'm thinking 
of the extra effort involved in doing "with"s and To_Bounded_String, 
etc.) I'd either use String or Unbounded_String. Maybe others don't - 
but intellectual arguments don't settle the question of "real world" usage.

MDC



Jean-Pierre Rosen wrote:
> 
> Maybe you missed the point that you have *different* types for Person_Name
> and Person_Address.
> 
> Of course, you could use types derived from strings. And keep the current length in
> an integer rather looking for a space, so you'll have to pack that into a record.
> While we're at it, it would be nice to have a discriminant to parameterize the
> maximum length... Well, at that point, you are just rewriting Bounded_Strings.
> (except for the discriminant in place of the generic parameter).
> 


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

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

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Is the Writing on the Wall for Ada?

[Marin David Condic]

An excellent moral. But that's why I was asking the question about 
Bounded_String. You apparently have made use of it in real-world apps to 
a non-trivial extent. If some significant amount of code out there 
utilizes it (besides yours), then its clearly worth continuing to 
support with extensions in Ada0x. (By which I mean if we were to expand 
the role of Unbounded_String WRT Text_IO, etc., there should be similar 
expansion for Bounded_String.)

You don't know the answers to these sorts of questions by sitting in an 
ivory tower and theorizing about how wonderful a given feature is. You 
know the answers by looking at how real-world users are making use of it.

MDC



tmoran@acm.org wrote:

> or string processing than they did executing OS code.  I take the moral to
> be "look at all your users, not just your own code, when deciding what's
> important".


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

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

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Is the Writing on the Wall for Ada?

[Jacob Sparre Andersen]

Marin David Condic wrote:

> I'd like to see some semi-reasonable survey of folks doing a "Search 
> *.ad* 'Bounded_String'" on their libraries of Ada95 code and discover if 
> *in practice* it really gets used much. My personal experience is 'not 
> much - if at all.'

with Ada.Strings.Bounded	 27 files
with Ada.Strings.Fixed		222 files
with Ada.Strings.Unbounded	401 files

from a total of 3_041 source files.

Jacob
-- 
from DoD Directive 2000.12

"DEFINITIONS
  (...)
  18. Terrorism.  The calculated use of violence or threat of
  violence to inculcate fear; intended to coerce or to
  intimidate governments or societies in the pursuit of goals
  that are generally political, religious, or ideological."

Re: Is the Writing on the Wall for Ada?

[Marin David Condic]

It seems that you favor Unbounded_String as do I. Your usage would look 
similar to mine: Unbounded being favored with Fixed used next most 
frequently. (You can't get entirely away from Fixed since everything in 
the language utilizes it.)

Could you get along fine without Bounded had it never existed? Or do you 
think it was pretty critical where it was used?

MDC


Jacob Sparre Andersen wrote:
> 
> 
> with Ada.Strings.Bounded     27 files
> with Ada.Strings.Fixed        222 files
> with Ada.Strings.Unbounded    401 files
> 
> from a total of 3_041 source files.
> 
> Jacob


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

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

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Is the Writing on the Wall for Ada?

[Wes Groleau]

Jean-Pierre Rosen wrote:
> Of course, you could use types derived from strings. And keep the current length in
> an integer rather looking for a space, so you'll have to pack that into a record.
> While we're at it, it would be nice to have a discriminant to parameterize the
> maximum length... Well, at that point, you are just rewriting Bounded_Strings.
> (except for the discriminant in place of the generic parameter).

I generally set the maximum length by the declaration
of the index subtype, and used a value of that type
as the discriminant to set the actual length.

-- 
Wes Groleau
   ----
   The man who reads nothing at all is better educated
   than the man who reads nothing but newspapers.
                             -- Thomas Jefferson

Re: Is the Writing on the Wall for Ada?

[tmoran]

> I understand that Bounded_String has some technical advantages, but in
> my experience, the instant I'm on a PC at some astronomical number of
> megahertz/gigahertz with more memory than I can shake a stick at,
> Unbounded_String and all its technical disadvantages compared to
> Bounded_String just seem to not amount to a warm bucket of spit. Hence
> I'm wondering if people actually have/do use it on anything like a
> regular basis.

    Liking numbers, I tried some timings on three different Ada compilers.
The results are all over the map.

  s1 : string(1 .. 10);
  s2 : string(1 .. 100);
  abs1 : bs1.bounded_string; -- length 10
  abs2 : bs2.bounded_string; -- length 100
  u : ada.strings.unbounded.unbounded_string;
  test : constant string := "12345";
  cabs1 : bs1.bounded_string:=to_bounded_string(test);
  cabs2 : bs2.bounded_string:=to_bounded_string(test);
  cu : ada.strings.unbounded.unbounded_string:=to_unbounded_string(test);

Each column represents a different compiler.  The numbers are times for a
million iterations, divided by the total for that compiler, so each column
sums to the same value (within rounding).  So the first row shows that
assigning a 5 character string to another 5 character string is among the
fastest things each compiler can do.  Compiler A and C are at their
slowest doing "&" of unbounded strings, while B's slowest is "&" of
bounded strings.

 A       B      C
0.01    0.01   0.01   s1(1 .. 5) := test
0.01    0.00   0.01   s1(1 .. 5) := test;
0.02    0.01   0.00   s2(1 .. 5) := test;
0.20    1.86   0.25   abs1 := bs1.to_bounded_string(test);
2.49    2.13   0.63   abs2 := bs2.to_bounded_string(test);
1.98    3.25   7.69   u := ada.strings.unbounded.to_unbounded_string(test);

0.24    0.06   1.17   s1(1 .. 10) := s1(1 .. 5) & s1(1 .. 5);
0.24    0.06   1.16   s2(1 .. 10) := s2(1 .. 5) & s2(1 .. 5);
1.10    3.84   0.28   abs1 := cabs1 & cabs1;
4.00    4.18   0.70   abs2 := cabs2 & cabs2;
5.89    3.70   7.95   u := cu & cu;

0.01    0.01   0.00   if s1 = test then junk:=true;end if;
0       0.00   0.00   if s2 = test then junk:=true;end if;
0.31    0.04   0.08   if abs1 = test then junk:=true;end if;
0.32    0.03   0.07   if abs2 = test then junk:=true;end if;
0.31    0.05   0.09   if u = test then junk:=true;end if;

0.48    0.03   0.06   if abs1 = cabs1 then junk:=true;end if;
0.54    0.03   0.06   if abs2 = cabs2 then junk:=true;end if;
0.02    0.05   0.08   if u = cu then junk:=true;end if;

0.40    1.23   0.64   s1(1 .. 5) := slice(abs1,1,5);
1.30    1.26   0.66   s1(1 .. 5) := slice(u,1,5);
0.03    0.06   0.03   abs1 := cabs1;
0.37    0.16   0.21   abs2 := cabs2;
0.35    0.78   2.35   u := cu;

0.63    0.78   0.74   si:=index(s1,test);
3.51    0.78   2.48   si:=index(s2,test);
0.48    0.83   0.60   si:=index(abs1,test);
0.48    0.82   0.62   si:=index(abs2,test);
0.70    0.81   0.58   si:=index(u,test);

0.81    1.24   1.82   if length(u) < 100 then append(u,'x');else u := cu;end if;
3.52    2.69   0.10   if length(abs2)<100 then append(abs2,'x');else abs2:=cabs2;end if;

Re: Is the Writing on the Wall for Ada?

[Marin David Condic]

Really interesting, but not necessarily compeling.

If all I'm basically after is some particular user input that I intend 
to store and/or process in some semi-insignificant way, a few extra 
miliseconds is probably unnoticable. ("I got your input. Thanks. I'll 
check it for validity and then go store it for you. See you later... 
Bye!") How is anybody going to know the difference? Maybe in some apps 
that are *really* heavy into string parsing, it might make a difference 
big enough to matter. (5 minutes per batch-compile versus 10 minutes per 
batch compile?) But usually - even in that case - the answer "buy a 
bigger computer" tends to be cheaper than "go make your programmers 
optimize it to save me some time..."

I'm not saying you're wrong. Just that in most practical circumstances, 
nobody cares. Hence, the question: "Does anybody really need 
Bounded_String?"

MDC



tmoran@acm.org wrote:
> 
>     Liking numbers, I tried some timings on three different Ada compilers.
> The results are all over the map.
> 
>   s1 : string(1 .. 10);
>   s2 : string(1 .. 100);
>   abs1 : bs1.bounded_string; -- length 10
>   abs2 : bs2.bounded_string; -- length 100
>   u : ada.strings.unbounded.unbounded_string;
>   test : constant string := "12345";
>   cabs1 : bs1.bounded_string:=to_bounded_string(test);
>   cabs2 : bs2.bounded_string:=to_bounded_string(test);
>   cu : ada.strings.unbounded.unbounded_string:=to_unbounded_string(test);
> 
> Each column represents a different compiler.  The numbers are times for a
> million iterations, divided by the total for that compiler, so each column
> sums to the same value (within rounding).  So the first row shows that
> assigning a 5 character string to another 5 character string is among the
> fastest things each compiler can do.  Compiler A and C are at their
> slowest doing "&" of unbounded strings, while B's slowest is "&" of
> bounded strings.
> 
>  A       B      C
> 0.01    0.01   0.01   s1(1 .. 5) := test
> 0.01    0.00   0.01   s1(1 .. 5) := test;
> 0.02    0.01   0.00   s2(1 .. 5) := test;
> 0.20    1.86   0.25   abs1 := bs1.to_bounded_string(test);
> 2.49    2.13   0.63   abs2 := bs2.to_bounded_string(test);
> 1.98    3.25   7.69   u := ada.strings.unbounded.to_unbounded_string(test);
> 
> 0.24    0.06   1.17   s1(1 .. 10) := s1(1 .. 5) & s1(1 .. 5);
> 0.24    0.06   1.16   s2(1 .. 10) := s2(1 .. 5) & s2(1 .. 5);
> 1.10    3.84   0.28   abs1 := cabs1 & cabs1;
> 4.00    4.18   0.70   abs2 := cabs2 & cabs2;
> 5.89    3.70   7.95   u := cu & cu;
> 
> 0.01    0.01   0.00   if s1 = test then junk:=true;end if;
> 0       0.00   0.00   if s2 = test then junk:=true;end if;
> 0.31    0.04   0.08   if abs1 = test then junk:=true;end if;
> 0.32    0.03   0.07   if abs2 = test then junk:=true;end if;
> 0.31    0.05   0.09   if u = test then junk:=true;end if;
> 
> 0.48    0.03   0.06   if abs1 = cabs1 then junk:=true;end if;
> 0.54    0.03   0.06   if abs2 = cabs2 then junk:=true;end if;
> 0.02    0.05   0.08   if u = cu then junk:=true;end if;
> 
> 0.40    1.23   0.64   s1(1 .. 5) := slice(abs1,1,5);
> 1.30    1.26   0.66   s1(1 .. 5) := slice(u,1,5);
> 0.03    0.06   0.03   abs1 := cabs1;
> 0.37    0.16   0.21   abs2 := cabs2;
> 0.35    0.78   2.35   u := cu;
> 
> 0.63    0.78   0.74   si:=index(s1,test);
> 3.51    0.78   2.48   si:=index(s2,test);
> 0.48    0.83   0.60   si:=index(abs1,test);
> 0.48    0.82   0.62   si:=index(abs2,test);
> 0.70    0.81   0.58   si:=index(u,test);
> 
> 0.81    1.24   1.82   if length(u) < 100 then append(u,'x');else u := cu;end if;
> 3.52    2.69   0.10   if length(abs2)<100 then append(abs2,'x');else abs2:=cabs2;end if;


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

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

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Is the Writing on the Wall for Ada?

[Robert I. Eachus]

Marin David Condic wrote:

> I'm not saying you're wrong. Just that in most practical circumstances, 
> nobody cares. Hence, the question: "Does anybody really need 
> Bounded_String?"

Yes, as I said, in database work, the nice thing about instantiating 
Bounded_String for each data dictionary string item is that the value 
gets checked for validity at the right point--where it can be fixed. 
Once you have validated it, the string is never going to grow outside 
the bounds, so you don't have to worry about checking again.  In other 
words, the visible interface of the package that deals with say surnames 
may be:

package Surnames is

    type Surname is private;

    function To_Surname(S: in String) return Surname;

    function Get(S: in Surname) return String;

private...

The only legitimate way to create a surname is by calling To_Surname, 
which does the error checking.

-- 
                                                     Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: Is the Writing on the Wall for Ada?

[Marin David Condic]

O.K. but how is that any different/better if the underlying 
implementation of Surname were to be a String? Here's my point: In the 
process of doing whatever programming might be going on underneath 
Surnames, if I have a type String - I can make use of all the things 
that just naturally work in Ada with no additional effort. Examples 
include literals, attributes or other functions that return String, 
utilizing Text_IO, etc. The instant I go to Bounded_String, I'm with'ing 
a package, making a generic instantiation, diddling around with type 
conversions, etc. I'm not compatible with Text_IO or other things 
without a conversion and I'd bet dollars to doughnuts that most database 
interfaces are going to make you read/write a String rather than a 
Bounded_String - so you've got type conversion hassle again there anyway.

And what do I get for the extra effort? I get to know the actual length 
of the text stored in there rather than have to go figure that out for 
myself by scanning backward from the end of the string or maintaining my 
own counter. I get X amound of nuisance and Y amount of extra advantage. 
Normally, when I do the math, X - Y is greater than zero. Hence I just 
use type String and am done with it. It changes *nothing* in terms of 
what is happening in the underlying implementation because a 
Bounded_String is just a fixed length string with a "Last" counter 
coasting along with it. I can do that myself and still have visibility 
to the fixed string as a String - compatible with all the usual Ada stuff.

Or I go to my beloved Unbounded_String and have infinite amount of space 
to play with and no restrictions to get in my way. All it costs me is a 
little time. :-)

MDC



Robert I. Eachus wrote:
> 
> Yes, as I said, in database work, the nice thing about instantiating 
> Bounded_String for each data dictionary string item is that the value 
> gets checked for validity at the right point--where it can be fixed. 
> Once you have validated it, the string is never going to grow outside 
> the bounds, so you don't have to worry about checking again.  In other 
> words, the visible interface of the package that deals with say surnames 
> may be:
> 
> package Surnames is
> 
>    type Surname is private;
> 
>    function To_Surname(S: in String) return Surname;
> 
>    function Get(S: in Surname) return String;
> 
> private...
> 
> The only legitimate way to create a surname is by calling To_Surname, 
> which does the error checking.
> 


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

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

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Is the Writing on the Wall for Ada?

[Preben Randhol]

On 2003-10-03, Marin David Condic <nobody@noplace.com> wrote:
> And what do I get for the extra effort? 

No buffer overflow f.ex. Especially if your interfacing a database or
library written in C.

Preben

Re: Is the Writing on the Wall for Ada?

[Marin David Condic]

Bzzzzt. Wrong answer. Type String is NOT going to let you overflow any 
buffers either, is it? Last time I checked, you can't index off the end 
of a String. (Or is that about to change in Ada0x? :-) Second, if I'm 
interfacing to C a) I'll bet it won't take a Bounded_String to begin 
with - must convert to something C can recognize - and b) all bets are 
off the instant you gave the address of your parameter to C. C doesn't 
feel any moral obligation whatsoever to respect Ada's bounds checking 
and a Bounded_String is just another chunk of memory to it.

So I just don't see how I get *anything* of any really big advantage by 
using Bounded_String. I get X amount of nuisance and Y amount of extra 
advantage and X - Y is greater than zero.

MDC


Preben Randhol wrote:
> On 2003-10-03, Marin David Condic <nobody@noplace.com> wrote:
> 
>>And what do I get for the extra effort? 
> 
> 
> No buffer overflow f.ex. Especially if your interfacing a database or
> library written in C.
> 
> Preben


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

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

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Is the Writing on the Wall for Ada?

[Preben Randhol]

On 2003-10-03, Marin David Condic <nobody@noplace.com> wrote:
> Bzzzzt. Wrong answer. Type String is NOT going to let you overflow any 
> buffers either, is it? Last time I checked, you can't index off the end 
> of a String. (Or is that about to change in Ada0x? :-) Second, if I'm 
> interfacing to C a) I'll bet it won't take a Bounded_String to begin 
> with - must convert to something C can recognize - and b) all bets are 
> off the instant you gave the address of your parameter to C. C doesn't 
> feel any moral obligation whatsoever to respect Ada's bounds checking 
> and a Bounded_String is just another chunk of memory to it.

I mean if you use Unbounded_Strings and you convert to a C array without
checking that the length is correct according to the length the C lib/db
expects. Of course there must be an error in the C part for this to
happen, but it usually is. Another is of course DOS attacks if you use a
Get_Line version that returns a Unbounded_String.

> So I just don't see how I get *anything* of any really big advantage by 
> using Bounded_String. I get X amount of nuisance and Y amount of extra 
> advantage and X - Y is greater than zero.

Well Unbounded_Strings are quite slow if you deal with a lot of data.

Preben

Re: Is the Writing on the Wall for Ada?

[Marin David Condic]

But then just use String. The position I've been taking here is that if 
I need speed, or certainty about allocation or other issues - I use 
String. If not, I use Unbounded_String. I don't find enough nutritional 
value in Bounded_String to make it worth the relative incompatibility 
with the rest of the language's use of String - so when I need fixed 
maximum lengths, I use some version of String and I can easily put into 
it the 'Image of something or send it to Text_IO or compare it to 
literals or any number of other other conveniences without any extra 
with's, instantiations or type conversions.

MDC



Preben Randhol wrote:
> 
> 
> I mean if you use Unbounded_Strings and you convert to a C array without
> checking that the length is correct according to the length the C lib/db
> expects. Of course there must be an error in the C part for this to
> happen, but it usually is. Another is of course DOS attacks if you use a
> Get_Line version that returns a Unbounded_String.
> 

> 
> 
> Well Unbounded_Strings are quite slow if you deal with a lot of data.
> 
> Preben


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

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

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Is the Writing on the Wall for Ada?

[Robert I. Eachus]

Marin David Condic wrote:
> ...I'm not compatible with Text_IO or other things 
> without a conversion and I'd bet dollars to doughnuts that most database 
> interfaces are going to make you read/write a String rather than a 
> Bounded_String - so you've got type conversion hassle again there anyway.

I totally agree! ;-)  But if you use a database interface that uses 
Bounded_Strings for such datatypes then youy wrap it all up in one 
package and instantiate that to get everything.  The advantaga, again is 
when you have queries that return an array of whatever.  An array of 
some instance of Bounded_String is much easier to work with than an 
array of records, containing both name length and a String.

-- 
                                                     Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: Is the Writing on the Wall for Ada?

[Marin David Condic]

Right. O.K. Fine. How many databases out there support Ada's 
Bounded_String? I don't do much database programming anymore but back 
when I did, I didn't notice much support for Ada - beyond maybe a vendor 
gave you an Ada pre-processor so you could put SQL into your code. The 
data types *maybe* aligned with the more primitive Ada types, but 
typically, if the database had some variety of string/text data, you had 
to provide a buffer of type String. Maybe its different now - does MySQL 
provide something compatible with Bounded_String?

So I'm back to where I started: The database has a field that is an 
array of 80 characters. I declare something like Person_Address: String 
(1..80) ; I read it in. I scan it to determine where it stops and keep a 
Person_Address_Last count lying around somewhere. I can now use that 
with Text_IO to display to a file or use the 'Image on some numeric 
value to add some info to it, or use all the usual attributes of 'First, 
'Last 'Range, etc. It was automatically limited by the language to no 
more than 80 characters. It couldn't have buffer-overflowed and provided 
a security leak. I've got Ada.Strings.Fixed to do a variety of parsing 
things for me that are basically the same as those in 
Ada.Strings.Bounded. How is it I get more value out of Bounded_String?

Granted, I've got to do a bit more work by keeping some kind of Last 
counter around and Bounded_String would have done that for me - once I 
went to some effort to figure out where the actual string stopped when I 
read it into my String (1..80). But for that little bit of extra work, 
I've got visibility to the field as a String - compatible with all the 
other language features. Bounded_String means extra with's, 
instantiation, conversions, etc. What do I get in exchange that isn't 
already there for type String?

MDC


Robert I. Eachus wrote:
> 
> I totally agree! ;-)  But if you use a database interface that uses 
> Bounded_Strings for such datatypes then youy wrap it all up in one 
> package and instantiate that to get everything.  The advantaga, again is 
> when you have queries that return an array of whatever.  An array of 
> some instance of Bounded_String is much easier to work with than an 
> array of records, containing both name length and a String.
> 


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

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

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Is the Writing on the Wall for Ada?

[Robert I. Eachus]

Marin David Condic wrote:
> Right. O.K. Fine. How many databases out there support Ada's 
> Bounded_String? I don't do much database programming anymore but back 
> when I did, I didn't notice much support for Ada - beyond maybe a vendor 
> gave you an Ada pre-processor so you could put SQL into your code. The 
> data types *maybe* aligned with the more primitive Ada types, but 
> typically, if the database had some variety of string/text data, you had 
> to provide a buffer of type String. Maybe its different now - does MySQL 
> provide something compatible with Bounded_String?

Hmmm.  I use my own binding to ODBC.  This is something that needs to be 
fixed this time around.  During tne last two standarization efforts it 
was clear that choosing any existing database binding would have been 
wrong.  I think this time that ODBC is probably the right thing to have 
a binding to, but we will probably have a binding that can be mapped to 
ODBC, but doesn't specifically require it.  Incidently as I write this, 
the ARG is meeting in Halifax, Nova Scotia.

-- 
                                         Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: Is the Writing on the Wall for Ada?

[Marin David Condic]

Now if there were some standardized Ada binding to databases (ODBC or 
whatever you like - so long as it is standard and The Ada Way) - I could 
maybe see some goodness in Bounded_String for that sort of thing. So 
long as I can make an instantiation of Bounded_String and just say 
"Go_Find_Me_This_Thing (X)" where X is a Bounded_String and I get it 
back length-adjusted - *then* I could see it having sufficient utility 
to make it worth whatever extra pain in the posterior it creates. 
(Granted, its not a huge pain - but enough that I'd feel I needed to get 
something more than knowing where the end of the string was.) Oh, and 
BTW, it would have to be fixed to work nicely and automatically with 
Text_IO while we're at it. Then you'd have something there.

Nova Scotia? Interesting venue. If you have a meeting in the winter 
months, you may want to consider Sunny West Palm Beach Florida. Schedule 
the meeting to start on a Friday and end on a Monday. :-) Its a very 
popular thing to do.

BTW, if you think I'm making a big deal of the extra work in 
Bounded_String - I'm not really of the opinion that it is hugely 
inconvenient. Its just that the effort to utilize it compared to String 
is some number greater than zero (not a big number - but bigger than 0) 
and basically, I think I only get two things from it: "Jack" and "S**t" 
and "Jack" is only going to tell me where the last character is, so he 
doesn't do much. ;-)

MDC



Robert I. Eachus wrote:
> 
> 
> Hmmm.  I use my own binding to ODBC.  This is something that needs to be 
> fixed this time around.  During tne last two standarization efforts it 
> was clear that choosing any existing database binding would have been 
> wrong.  I think this time that ODBC is probably the right thing to have 
> a binding to, but we will probably have a binding that can be mapped to 
> ODBC, but doesn't specifically require it.  Incidently as I write this, 
> the ARG is meeting in Halifax, Nova Scotia.
> 


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

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

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Is the Writing on the Wall for Ada?

[Warren W. Gay VE3WWG]

Marin David Condic wrote:
> Now if there were some standardized Ada binding to databases (ODBC or 
> whatever you like - so long as it is standard and The Ada Way) - I could 
> maybe see some goodness in Bounded_String for that sort of thing.

I personally believe that it is probably too early to standardize on
database access. The problem is that they vary way too much. Some
support row ids (most), while others do not (MySQL). Some sort of
support row ids (Informix: can duplicate depending upon database table
layout).

MySQL avoids row ids completely. They insist on serial values, but they
do serial values their own way. Just about every other vendor supports
serial values (or sequences in yet another way).

Databases vary in their fetch capabilities. Some support random row
fetches, others only sequentially. Some require you fetch all of the
results (MySQL), while others allow you to just fetch the rows you
feel like (PostgreSQL for example). Others require you to declare
a cursor, like Sybase for random fetches, and the privilege of
fetching only the rows you want.

And this is just a sampling of the differences, and we havn't even
touched on SQL syntax and data type names yet.

ODBC tries to dumb down these differences, but a number of these
issues still come through. I am fielding many of these complications
as I continue to add more support to APQ for different database
platforms.

Warren.
--
http://home.cogeco.ca/~ve3wwg

Re: Is the Writing on the Wall for Ada?

[Marin David Condic]

But that's the point of "standardizing" without really "standardizing". 
Having a library that is "Conventional" but without being in the 
standard allows you to try different flavors of things and settle 
ultimately on that which gains majority acceptance.

MDC



Warren W. Gay VE3WWG wrote:
> Marin David Condic wrote:
> 
>> Now if there were some standardized Ada binding to databases (ODBC or 
>> whatever you like - so long as it is standard and The Ada Way) - I 
>> could maybe see some goodness in Bounded_String for that sort of thing.
> 
> 
> I personally believe that it is probably too early to standardize on
> database access. The problem is that they vary way too much. Some
> support row ids (most), while others do not (MySQL). Some sort of
> support row ids (Informix: can duplicate depending upon database table
> layout).
> 
> MySQL avoids row ids completely. They insist on serial values, but they
> do serial values their own way. Just about every other vendor supports
> serial values (or sequences in yet another way).
> 
> Databases vary in their fetch capabilities. Some support random row
> fetches, others only sequentially. Some require you fetch all of the
> results (MySQL), while others allow you to just fetch the rows you
> feel like (PostgreSQL for example). Others require you to declare
> a cursor, like Sybase for random fetches, and the privilege of
> fetching only the rows you want.
> 
> And this is just a sampling of the differences, and we havn't even
> touched on SQL syntax and data type names yet.
> 
> ODBC tries to dumb down these differences, but a number of these
> issues still come through. I am fielding many of these complications
> as I continue to add more support to APQ for different database
> platforms.
> 
> Warren.
> -- 
> http://home.cogeco.ca/~ve3wwg
> 


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

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

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Is the Writing on the Wall for Ada?

[Warren W. Gay VE3WWG]

Marin David Condic wrote:
> Right. O.K. Fine. How many databases out there support Ada's 
> Bounded_String? I don't do much database programming anymore but back 
> when I did, I didn't notice much support for Ada - beyond maybe a vendor 
> gave you an Ada pre-processor so you could put SQL into your code. The 
> data types *maybe* aligned with the more primitive Ada types, but 
> typically, if the database had some variety of string/text data, you had 
> to provide a buffer of type String. Maybe its different now - does MySQL 
> provide something compatible with Bounded_String?

This is my big chance to say... APQ supports Bounded_String! ;-)

   See http://home.cogeco.ca/~ve3wwg/software.html#APQ

The database need not support it by name, because a CHAR(n) or
VARCHAR(n) can easily translate into/out of a Bounded_String,
which is exactly what APQ does within a OO framework.

Mind you, I've personally not had much reason to use Bounded_String,
but within a package for general use, you try not to set policy.
Rather you leave it up to the user to decide if a data type or
interface is useful to him or not. So it is there, whether it
gets used or not, is another matter ;-)

> So I'm back to where I started: The database has a field that is an 
> array of 80 characters. I declare something like Person_Address: String 
> (1..80) ; I read it in. I scan it to determine where it stops and keep a 
> Person_Address_Last count lying around somewhere. I can now use that 
> with Text_IO to display to a file or use the 'Image on some numeric 
> value to add some info to it, or use all the usual attributes of 'First, 
> 'Last 'Range, etc. It was automatically limited by the language to no 
> more than 80 characters. It couldn't have buffer-overflowed and provided 
> a security leak. I've got Ada.Strings.Fixed to do a variety of parsing 
> things for me that are basically the same as those in 
> Ada.Strings.Bounded. How is it I get more value out of Bounded_String?

It really only gives you the advantage of Unbounded_Strings, with the
limitation applied. APQ also allows you to retrieve a column value as
a normal string of any length, using the function call syntax.

However, the
disadvantage of that is that the caller is not limiting the maximum
length of the data being returned (it might overflow the stack for
example). Unbounded_String might permit the heap to be overflowed,
although both of these scenarios are unlikely unless the user is
misusing the interface to retrieve some large BLOB-like data.

> Granted, I've got to do a bit more work by keeping some kind of Last 
> counter around and Bounded_String would have done that for me - once I 
> went to some effort to figure out where the actual string stopped when I 
> read it into my String (1..80). But for that little bit of extra work, 
> I've got visibility to the field as a String - compatible with all the 
> other language features. Bounded_String means extra with's, 
> instantiation, conversions, etc. What do I get in exchange that isn't 
> already there for type String?
> 
> MDC
> 
> Robert I. Eachus wrote:
>> I totally agree! ;-)  But if you use a database interface that uses 
>> Bounded_Strings for such datatypes then youy wrap it all up in one 
>> package and instantiate that to get everything.  The advantaga, again 
>> is when you have queries that return an array of whatever.  An array 
>> of some instance of Bounded_String is much easier to work with than an 
>> array of records, containing both name length and a String.

One of the things that discourages me from using Bounded_Strings is the
number of instantiations that you end up making (for each different
string size). I would have preferred one instantiation, and then a
discriminant that set the maximum size on the object. But that may
have problems of its own.

Warren.
--
http://home.cogeco.ca/~ve3wwg

A nongeneric bounded string array type (was Re: Is the Writing on the Wall for Ada?)

[Robert I. Eachus]

Warren W. Gay VE3WWG wrote:

> One of the things that discourages me from using Bounded_Strings is the
> number of instantiations that you end up making (for each different
> string size). I would have preferred one instantiation, and then a
> discriminant that set the maximum size on the object. But that may
> have problems of its own.

Ask, and it shall be given unto you; seek, and you shall find; knock, 
and it shall be opened to you. -- Matthew 7:7

Sorry, I couldn't resist.  Here is a package with NO instantiations, and 
a bounded array type that can handle different length strings.  The 
silly thing is that I could have written this package twenty years ago, 
since it doesn't require anything that wasn't originally in Ada 83.  Do 
I feel stupid that I didn't discover this package then?

Definitely not!  I have never been one to worry in Ada about the number 
of generic instantiations, so the number required to use 
Ada.Strings.Bounded was not something that bothered me much.  But the 
way the pieces of the discussion here all fell together implies to me 
that it could have been another twenty years before someone realized 
that you really could do this.

I would like comments on the interface, and any other operations that 
might make sense.  (For example relational operations between rows and 
Strings.)  You had better believe that if this pattern is this hard to 
find, it probably belongs in the standard, rather than in my back 
pocket.  But please, no comments about the way the body is 
written--unless you are a compiler implementor and want to provide a 
version which takes advantage of your optimizer.  This body is designed 
to be canonical, and a good optimizer should do a decent job on the 
'extra' string copies.

It is possible to use overlays, view conversions, or even 
Unchecked_Conversion in writing the body for the package.  And of 
course, doing that may improve performance when using a specific 
compiler.  (Which is why this package probably does belong in 
Ada.Strings.)  But I wanted a canonical version that said basically when 
Constraint_Error is raised.  As far as I am concerned, the only 
non-obvious bit about exceptions is that I decided that appending a null 
string to a nonexistant row should still raise Constraint_Error.

-------------------------------------------------------------------------

package Ada_Strings_Bounded_Array is

    type Bounded_Array(Size, Max: Natural) is private;

    procedure Set(B: in out Bounded_Array;
                  Row: in Positive;
                  To: in String);

    procedure Append(B: in out Bounded_Array;
                     Row: in Positive;
                     Add: in String);

    function Get(From: Bounded_Array;
                 Row: Positive) return String;

    function Get_Length(From: Bounded_Array;
                        Row: Positive) return Natural;

private

    type Element_Array is
           array (Natural range <>, Natural range <>) of Character;

    type Length_Array is array(Natural range <>) of Natural;

    type Bounded_Array(Size, Max: Natural) is record
       Lengths: Length_Array(1..Size) := (others => 0);
       Contents: Element_Array(1..Size, 1..Max);
    end record;

end Ada_Strings_Bounded_Array;

----------------------------------------------------------------------

package body Ada_Strings_Bounded_Array is

    procedure Set(B: in out Bounded_Array;
                  Row: in Positive;
                  To: in String) is
      Temp: String(1..To'Length) := To; -- insure lower bound is 1.
    begin
      if To'Length > B.Max then raise Constraint_Error; end if;
      B.Lengths(Row) := Temp'Last; -- will raise C_E if Row out of bounds.
      for I in Temp'Range loop
        B.Contents(Row,I) := Temp(I);
      end loop;
    end Set;

    procedure Append(B: in out Bounded_Array;
                     Row: in Positive;
                     Add: in String) is
      Temp: String(B.Lengths(Row)+ 1.. B.Lengths(Row) + Add'Length) := Add;
    begin
      if Temp'Last > B.Max then raise Constraint_Error; end if;
      B.Lengths(Row) := Temp'Last;
      for I in Temp'Range loop
        B.Contents(Row,I) := Temp(I);
      end loop;
    end Append;

    function Get(From: Bounded_Array;
                 Row: Positive) return String is
      Temp: String(1..From.Lengths(Row));
    begin
      for I in Temp'Range loop
        Temp(I) := From.Contents(Row,I);
      end loop;
      return Temp;
    end Get;


    function Get_Length(From: Bounded_Array;
                        Row: Positive) return Natural is
    begin return From.Lengths(Row); end Get_Length;

    pragma Inline(Set, Append, Get, Get_Length);

end Ada_Strings_Bounded_Array;

-------------------------------------------------------------------------

with Ada.Text_IO; use Ada.Text_IO;
with Ada_Strings_Bounded_Array; use Ada_Strings_Bounded_Array;
procedure Bounded_Array_Test is
   BA1: Bounded_Array(5, 30);
   BA2: Bounded_Array(2, 10);
begin
   Set(BA1,1, "Robert I. Eachus");
   Set(BA1,2, "Mortimer Q. Snerd");
   Set(BA2,1, "foo");
   Append(BA2,1, "bar");
   Put_Line(Get(BA1,1));
   Put_Line(Get(BA1,2));
   Put_Line(Get(BA2,1));
   if Get_Length(BA1,1) /= 16 then Put_Line("Oops! BA1,1"); end if;
   if Get_Length(BA2,1) /= 6 then Put_Line("Oops! BA2,1"); end if;
   if Get_Length(BA1,3) /= 0 then Put_Line("Oops! BA1,3"); end if;
end Bounded_Array_Test;

---------------------------------------------------------------------------

-- 
                                       Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: A nongeneric bounded string array type (was Re: Is the Writing on the Wall for Ada?)

[Warren W. Gay VE3WWG]

Robert I. Eachus wrote:
> Warren W. Gay VE3WWG wrote:
> 
>> One of the things that discourages me from using Bounded_Strings is the
>> number of instantiations that you end up making (for each different
>> string size). I would have preferred one instantiation, and then a
>> discriminant that set the maximum size on the object. But that may
>> have problems of its own.
> 
> Ask, and it shall be given unto you; seek, and you shall find; knock, 
> and it shall be opened to you. -- Matthew 7:7
> 
> Sorry, I couldn't resist.  

Hey, I have no objection here ;-)

> Here is a package with NO instantiations, and 
> a bounded array type that can handle different length strings.  

I think your package is addressing some other poster's wishes here.

I was simply referring to the need to instantiate different
bounded strings for _different_ variables. Arrays, of course
present another challenge, which is the problem you have proposed
a solution to.

 >...
> Definitely not!  I have never been one to worry in Ada about the number 
> of generic instantiations, so the number required to use 
> Ada.Strings.Bounded was not something that bothered me much.  

Well, I tend not to worry about this in my own projects,
since I prefer to look at the abstraction first, and implementation
last. But I did note that in one or two projects,
where I had a large number of instantiations,
that the code size started to look rather large compared to the
functionality that was being offered. This made me pause to
consider the ramifications of this on a truly large project.
I have also noted others mentioning similar concerns here.

Obviously, this is a place where the compiler should be able
to help, with the emphasis on "should". ;-)

Warren.

Re: A nongeneric bounded string array type (was Re: Is the Writing on the Wall for Ada?)

[Robert I. Eachus]

Warren W. Gay VE3WWG wrote:

> I think your package is addressing some other poster's wishes here

> I was simply referring to the need to instantiate different
> bounded strings for _different_ variables. Arrays, of course
> present another challenge, which is the problem you have proposed
> a solution to.

Ah, but I find I most often use Ada.Strings.Bounded for return values 
from database queries where you can get an arbitrary number of matches 
returned.  The new package is perfect for that role, since I just have 
to with the package and not worry about setting maximum string lengths.

> Well, I tend not to worry about this in my own projects,
> since I prefer to look at the abstraction first, and implementation
> last. But I did note that in one or two projects,
> where I had a large number of instantiations,
> that the code size started to look rather large compared to the
> functionality that was being offered. This made me pause to
> consider the ramifications of this on a truly large project.
> I have also noted others mentioning similar concerns here.

Depends on the compiler I guess, and whether they do some form of shared 
generics.  It is fine with me if compilers create a new instance for 
each textual appearance of a generic with formal type parameters.  But I 
expect that when I instantiate a generic in a nested context, that there 
will only be one code instance of the generic:

procedure Foo(X: in Integer; ...) is
   package My_Bounded is new
       Ada.Strings.Bounded.Generic_Bounded_Length(X);
   ...
begin...

I often use that idiom for database queries.  Since compilers have to 
support this in any case, I would expect them to try to share the code 
for other similar instances.

-- 
                                                     Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: A nongeneric bounded string array type (was Re: Is the Writing on the Wall for Ada?)

[Warren W. Gay VE3WWG]

Robert I. Eachus wrote:
> Warren W. Gay VE3WWG wrote:
> 
>> I think your package is addressing some other poster's wishes here
> 
>> I was simply referring to the need to instantiate different
>> bounded strings for _different_ variables. Arrays, of course
>> present another challenge, which is the problem you have proposed
>> a solution to.
> 
> Ah, but I find I most often use Ada.Strings.Bounded for return values 
> from database queries where you can get an arbitrary number of matches 
> returned.  The new package is perfect for that role, since I just have 
> to with the package and not worry about setting maximum string lengths.

Ah, but "arbitrary number of matches" could mean billions of
rows! Do you really want to process columns that way? ;-)
--
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: A nongeneric bounded string array type (was Re: Is the Writing on the Wall for Ada?)

[Robert I. Eachus]

Warren W. Gay VE3WWG wrote:

> Ah, but "arbitrary number of matches" could mean billions of
> rows! Do you really want to process columns that way? ;-)

Ah, it could mean that, but, depending on the database, you can either 
ask for the number of records that match, or return at most say 50, and 
a count of how many more records remain.  That is an implementation 
detail that the programmer needs to thing about and handle appropriately.

For example, a "white pages" database for New York City or Los Angeles 
will have to worry about how many "John Smiths" there are that can be 
returned for one query, but it won't be a problem for a database of 
people in West Podunk.
-- 
                                            Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: A nongeneric bounded string array type (in database code)

[Warren W. Gay VE3WWG]

Robert I. Eachus wrote:
> Warren W. Gay VE3WWG wrote:
> 
>> Ah, but "arbitrary number of matches" could mean billions of
>> rows! Do you really want to process columns that way? ;-)
> 
> Ah, it could mean that, but, depending on the database, you can either 
> ask for the number of records that match, or return at most say 50, and 
> a count of how many more records remain.  That is an implementation 
> detail that the programmer needs to thing about and handle appropriately.

Yes, depending on the database indeed. But you see how easy it
is to forget that important detail? ;-)  And databases vary
widely in that level of support (MySQL supports a LIMIT clause,
but many others do not).

Using a fetch loop that processes one row at a time is so
much easier (at least when possible). This eliminates the resource
issue. The CLIENT LIBRARY should already be handling the EFFICIENCY
aspects of fetching, in bunches of rows, thus freeing your code
from such implementation details.

If you insist on arrays at a time processing, then you
are usually focusing on efficiency, which is very implementation
minded design. This is what many Ada people try to get
away from (and certainly my focus).

There is another problem with the array approach. You start referring
to values by subscript (either by constant, variable or by number),
and that can lead to more possibilities for error. I suppose you
could use renaming, but you have to ask yourself why am I coding
all of these extra language constructs?

Whereas if you process a row at a time, you have no possibility
of mixing the wrong Customer_Name with another's Customer_Account.
Its readable, its simple and it can be strongly typed.

As a side note, your Ada_Strings_Bounded_Array package makes a
common mistake: it does not allow for the processing of NULL
values. This is one fault I see so frequently in embedded SQL
code, because the programmer never took the trouble to code
for that possibility. This leads to all sorts of hideous
problems when NULLs are encountered in processing. There is
no doubt that Ada_Strings_Bounded_Array could be augmented
to handle this, but does illustrate how this RDBMS feature
gets overlooked. Microsoft is another one that is guilty of
this in their database controls (try handling a null date
type in the date picker, for example ;-)

This is why in APQ, if the programmer doesn't allow for a NULL
value, he will get the appropriate exception raised. While this
is less than ideal (compile time errors would be better), it
does guarantee that it will get addressed if the NULL value
ever shows up and it was not anticipated.

If you take arrays to the further level of columns x rows, then
you have a 2-dimensional array to mess with -- which in my view
is very dangerous from a code readability/code-write-reliability
point of view. Don't get me wrong, arrays have their place.

But here I can't help but think that it is for programer
convenience and/or efficiency, which IMO is not the best
approach. No offense intended here, but this approach seems
to transport the "Perl way" into Ada code. ;-)

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: A nongeneric bounded string array type (in database code)

[Robert I. Eachus]

Warren W. Gay VE3WWG wrote:

> Using a fetch loop that processes one row at a time is so
> much easier (at least when possible). This eliminates the resource
> issue. The CLIENT LIBRARY should already be handling the EFFICIENCY
> aspects of fetching, in bunches of rows, thus freeing your code
> from such implementation details.
> 
> If you insist on arrays at a time processing, then you
> are usually focusing on efficiency, which is very implementation
> minded design. This is what many Ada people try to get
> away from (and certainly my focus).

No, there are queries where the normal case is one matching record, and 
discriminating between two (or more) records is an extra step.  When I 
go to the drug store, they check my date of birth because they also have 
records for my son.  (The same thing happens at the HMO, but they 
usually figure it out without asking me if I was born in 1946 or 1982. ;-)

> As a side note, your Ada_Strings_Bounded_Array package makes a
> common mistake: it does not allow for the processing of NULL
> values. This is one fault I see so frequently in embedded SQL
> code, because the programmer never took the trouble to code
> for that possibility. This leads to all sorts of hideous
> problems when NULLs are encountered in processing. There is
> no doubt that Ada_Strings_Bounded_Array could be augmented
> to handle this, but does illustrate how this RDBMS feature
> gets overlooked. Microsoft is another one that is guilty of
> this in their database controls (try handling a null date
> type in the date picker, for example ;-)

You are confused.  The Ada_Strings_Bounded_Array package allows for null 
strings in any row, and an array with no rows. (Or both. ;-)  Was there 
some other type of NULL value I should allow for?

 > If you take arrays to the further level of columns x rows, then
> you have a 2-dimensional array to mess with -- which in my view
> is very dangerous from a code readability/code-write-reliability
> point of view. Don't get me wrong, arrays have their place.

No, as far as I am concerned, it handles perfectly the case where you 
expect a "few" matches, for some version of few.  As you say, for cases 
where you expect many matches, an iteration scheme is better, and if 
zero or one matches, a string is fine.

Let me use the registry for Ada packages that I have been proposing as 
an example.  If I did a search for packages named ODBC, that would be a 
good case for the "few" type query.  A query for all database packages 
would best be handled by returning an iterator of some sort.  A 
programmer can decide on the best query for his particular purpose.

-- 
                                         Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: A nongeneric bounded string array type (in database code)

[Warren W. Gay VE3WWG]

Robert I. Eachus wrote:
> Warren W. Gay VE3WWG wrote:
>> Using a fetch loop that processes one row at a time is so
>> much easier (at least when possible). This eliminates the resource
>> issue. The CLIENT LIBRARY should already be handling the EFFICIENCY
>> aspects of fetching, in bunches of rows, thus freeing your code
>> from such implementation details.
>>
>> If you insist on arrays at a time processing, then you
>> are usually focusing on efficiency, which is very implementation
>> minded design. This is what many Ada people try to get
>> away from (and certainly my focus).
> 
> No, there are queries where the normal case is one matching record, and 
> discriminating between two (or more) records is an extra step.  When I 
> go to the drug store, they check my date of birth because they also have 
> records for my son.  (The same thing happens at the HMO, but they 
> usually figure it out without asking me if I was born in 1946 or 1982. ;-)

I'll agree that you can find exceptions to any "normal". But
even in this particular case, you might just load a drop down
or list box in a GUI (one row at a time), and let the user
choose the correct one.

I mean, is the program going to say "select the oldest person,
because the younger person is less likely to need drugs?"
I doubt it ;-) Even if you have such a process, then you
would use a ORDER BY clause, and accept the first row.

>> As a side note, your Ada_Strings_Bounded_Array package makes a
>> common mistake: it does not allow for the processing of NULL
>> values. This is one fault I see so frequently in embedded SQL
>> code, because the programmer never took the trouble to code
>> for that possibility. This leads to all sorts of hideous
>> problems when NULLs are encountered in processing. There is
>> no doubt that Ada_Strings_Bounded_Array could be augmented
>> to handle this, but does illustrate how this RDBMS feature
>> gets overlooked. Microsoft is another one that is guilty of
>> this in their database controls (try handling a null date
>> type in the date picker, for example ;-)
> 
> You are confused.  The Ada_Strings_Bounded_Array package allows for null 
> strings in any row, and an array with no rows. (Or both. ;-)  Was there 
> some other type of NULL value I should allow for?

I am not confused at all. What you have just admitted is that
you equate an empty string to a NULL column value, which is
not quite the same thing!

Why are they different?

Well, for some applications an empty string "" says, that
I have explicitly stated that I have defined its contents
as empty (ie. there is "no comment" for example, when the
column might represent a description/comment).

NULL OTOH, indicates that the value is not defined ("a
comment is not yet defined", for example), or that there
is no value for it ("no comment is possible/applicable",
for example).

Your package doesn't allow the programmer to make that
distinction, which, for me is a show stopper.

Now, before you jump all over that, I am aware that _some_
databases don't make that distinction well, or in some cases,
not at all. Sybase makes them equivalent in their ctlib
client library, much to my disappointment. However, I do
believe that their stored procedure code will see the
values as being "different" (unconfirmed).

In other cases, the distinction is made in some APIs,
for the same database, but not in others API/API-modes.

For example, using Informix embedded SQL/C, you can
work without null indicators (a separate int variable) or
with them. When using the null indicator, you _can_
make that fine distinction.

When choosing _not_ to use Informix null indicator host
variable, you have to rely on the empty string idea, which
can only tell you that the string is empty (you can
assume NULL if you want to, but it may not accurately
reflect the column value). In this case, you have to use
the string value ' ' to represent an empty string.

The distinction however, remains _VERY REAL_ on the database
server side! Try pretending that they are the same in the
stored procedure code, and things will blow up on you ;-)

Your applications may never care about that distinction, and
that is fine if it works for you. But my point is that
your package does not "properly" make the NULL distinction.

> Let me use the registry for Ada packages that I have been proposing as 
> an example.  If I did a search for packages named ODBC, that would be a 
> good case for the "few" type query.  A query for all database packages 
> would best be handled by returning an iterator of some sort.  A 
> programmer can decide on the best query for his particular purpose.

But you have not sold the idea why an array for the first
example is any better. All you have demonstrated is that
"it works".

The first example does not necessarily require
processing the rows in a "batch". You could :

  - spit them out to a web server connection one row at a time
  - load them into a GUI control one row at a time
  - pump them out to a report one row at a time

Even your earlier example, represents a situation
where that information is likely to be presented to a human
operator to choose. Given that, that information is just as
likely to be loaded into a drop down/list box one row at a
time. In _most_ cases, I see no need for this type of
"batching" of rows (emphasis on the "most") ;-)

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: A nongeneric bounded string array type (in database code)

[Robert I. Eachus]

Warren W. Gay VE3WWG wrote:

> I mean, is the program going to say "select the oldest person,
> because the younger person is less likely to need drugs?"
> I doubt it ;-) Even if you have such a process, then you
> would use a ORDER BY clause, and accept the first row.

The (personal) phone book example is a good one to explain this.  If I 
really want to display all matches as long as all is less than say 20, 
the code for doing so is much simpler.  I ask for the first 20 matches, 
and if I get less than 20 I display them and I am done.  If I get twenty 
matches returned now I get the total count and do all the paging cruft. 
  It keeps the normal case fast, simple and easy for the user to use, 
while allowing for extreme cases.

> I am not confused at all. What you have just admitted is that
> you equate an empty string to a NULL column value, which is
> not quite the same thing!
> 
> Why are they different?
> 
> Well, for some applications an empty string "" says, that
> I have explicitly stated that I have defined its contents
> as empty (ie. there is "no comment" for example, when the
> column might represent a description/comment).
> 
> NULL OTOH, indicates that the value is not defined ("a
> comment is not yet defined", for example), or that there
> is no value for it ("no comment is possible/applicable",
> for example).
> 
> Your package doesn't allow the programmer to make that
> distinction, which, for me is a show stopper.

Actually, I have a trick I use for that.  There are four values in the 
Ada definition of Latin-1 that are not only control characters, but have 
no defined meaning in ISO 6429.  (Reserved_128, Reserved_129, 
Reserved_132, and Reserved_153.) I often use these in database text 
fields as markers for special types of data.  For example, I'll use a 
null middle name string to indicate a value not supplied, but 
Reserved_128 as "NMN" (No middle name), and Reserved_129 followed by a 
letter as "MIO" (Middle initial only).

> But you have not sold the idea why an array for the first
> example is any better. All you have demonstrated is that
> "it works".

I figure using the type cuts my effort in writing programs that access a 
database and display the results as HTML by about 25%.  I'll be the 
first to say that it is possible that I could use some other method and 
do it even faster, but right now coding and debugging the queries is a 
small part of the effort.  In fact the big improvement from using the 
new type is that the code is all independent of field sizes, including 
the Ada declarations.  (Of course I still have to set some sizes in the 
data dictionary.)

-- 
                                                     Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: A nongeneric bounded string array type (in database code)

[Warren W. Gay VE3WWG]

Robert I. Eachus wrote:
> Warren W. Gay VE3WWG wrote:
>> I mean, is the program going to say "select the oldest person,
>> because the younger person is less likely to need drugs?"
>> I doubt it ;-) Even if you have such a process, then you
>> would use a ORDER BY clause, and accept the first row.
> 
> The (personal) phone book example is a good one to explain this.  If I 
> really want to display all matches as long as all is less than say 20, 
> the code for doing so is much simpler.  I ask for the first 20 matches, 
> and if I get less than 20 I display them and I am done.  If I get twenty 
> matches returned now I get the total count and do all the paging cruft. 
>  It keeps the normal case fast, simple and easy for the user to use, 
> while allowing for extreme cases.

But you don't need an array to do this.

...
>> Your package doesn't allow the programmer to make that
>> distinction, which, for me is a show stopper.
> 
> Actually, I have a trick I use for that.  There are four values in the 
> Ada definition of Latin-1 that are not only control characters, but have 
> no defined meaning in ISO 6429.  (Reserved_128, Reserved_129, 
> Reserved_132, and Reserved_153.) I often use these in database text 

Major yuk.. bending all the rules to push an implementation.

> fields as markers for special types of data.  For example, I'll use a 
> null middle name string to indicate a value not supplied, but 
> Reserved_128 as "NMN" (No middle name), and Reserved_129 followed by a 
> letter as "MIO" (Middle initial only).

And now, how do you code this in SQL, when you want to
to do an ad-hoc query for those cases? Man that is ugly!

> I figure using the type cuts my effort in writing programs 

OK, it is the "write the program efficiently" argument. You're
in league with Perl! ;-)

> that access a 
> database and display the results as HTML by about 25%.  I'll be the 
> first to say that it is possible that I could use some other method and 
> do it even faster,

The lowest price is not always the law ;-)

> but right now coding and debugging the queries is a 
> small part of the effort.  

Right, so why not stick to more ideal abstractions, then looking
for ways to bend the rules?

> In fact the big improvement from using the 
> new type is that the code is all independent of field sizes, including 
> the Ada declarations.  (Of course I still have to set some sizes in the 
> data dictionary.)

Well, the null handling definitely is lacking. No type strength,
and all numerics must be marshalled into and out of strings, with
of course, no type checking either. Ad-hoc queries must adopt the
strangest of null conventions; certainly non-standard ones!

Sorry, but I cannot agree that this is good or "better".  But then,
its your code, and you're free to express yourself in that code,
as you please... just as the Perl programmers are ;-)

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: A nongeneric bounded string array type (in database code)

[Robert I. Eachus]

Warren W. Gay VE3WWG wrote:

> Well, the null handling definitely is lacking. No type strength,
> and all numerics must be marshalled into and out of strings, with
> of course, no type checking either. Ad-hoc queries must adopt the
> strangest of null conventions; certainly non-standard ones! 

Of course, I don't use strings for numeric data, and when I use 
non-standard characters to represent a null text field they are the only 
string there (with the curious exception of MIO).

I think you have a different vision of what I am doing than what is 
actually going on.  I don't have a record type in the database, but rows 
  which can be indexed or selected based on using one field as an index. 
  (More usually, one field for selection, and others for primary and 
secondary sort indexes.)  Then, in our example, I would be pulling out 
last name, first name, middle name, street address, town, state, zip, 
phone-number, or whatever.

I find it much easier to build a web-page with a "few" records displayed 
left to right instead of top to bottom.  The nice thing is that instead 
of choosing some arbitrary spacing for columns, I can make each column 
as large (or small) as it needs to be.

All this gets real complicated to explain and very easy to write.
--


                                         Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: Is the Writing on the Wall for Ada?

[Preben Randhol]

On 2003-10-01, Marin David Condic <nobody@noplace.com> wrote:
> O.K. But my question remains, "Does anybody use them in *practice*?" 
> When I've needed a record field for something like Person_Name and 
> wanted some fixed allocation on it, I use a String and if/when I needed 
> to know where the string stopped, I use a "Last_Non_Blank ()" function. 

How does a Last_Non_Blank () function work? Have you initialised the
Strings with blanks?

Preben

Re: Is the Writing on the Wall for Ada?

[Marin David Condic]

Back in Ada83 where you essentially had to Roll Your Own when it came to 
string manipulation, yes - you made sure everything you did got 
initialized to spaces. (Or whatever local convention you wanted to 
adopt. I knew programmers who used the C 'NUL' convention.) This isn't 
hard to accomplish and you could go build yourself a package to do all 
your string stuff and pretty much insure you got it right. (Never once 
had a problem with it in all the years I used it.)

Now that we have Ada-provided string tools, I don't waste my time with 
that sort of thing. I jump to Unbounded_String and am done with dealing 
with all those problems.

MDC


Preben Randhol wrote:
> 
> 
> How does a Last_Non_Blank () function work? Have you initialised the
> Strings with blanks?
> 
> Preben


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

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

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Is the Writing on the Wall for Ada?

[Preben Randhol]

On 2003-10-02, Marin David Condic <nobody@noplace.com> wrote:
> Now that we have Ada-provided string tools, I don't waste my time with 
> that sort of thing.

Exactly! Bounded_Strings.

Preben
-- 
"... in Ada, you can never have a buffer overflow error. Unless of
course you go very far out of your way to specifically program one
[...] most Ada programmers would consider going out of your way to
construct an Ada program that had a potential buffer overflow not
as a challenge, but as a kind of pornography." - Robert I. Eachus

Re: Is the Writing on the Wall for Ada?

[Marin David Condic]

Well, not exactly - at least not in the usage I've had. I simulated 
something like Bounded_String in Ada83 because I had nothing else. I had 
my own utilities for String because I had nothing else. In Ada95, I've 
got Ada.Strings for any sort of fixed-allocation string needs and I've 
got Unbounded_String for anything else that didn't have some fixed 
allocaton requirement. I just find little need for the middle-ground of 
Bounded_String and I think it is sufficiently inconvenient that I don't 
use it. Apparently, others do have some use for them. Fine. But in 
asking if a feature is needed, one needs to look at real-world use 
rather than an intellectual argument that "Feature X is cool..."

It might make an interesting PhD disertation to research usage of 
various Ada95 features in real applications and what conclusions could 
be drawn about the kinds of things languages ought to support.

MDC


Preben Randhol wrote:
> 
> Exactly! Bounded_Strings.
> 
> Preben


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

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

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Is the Writing on the Wall for Ada?

[Marin David Condic]

Marin David Condic wrote:
> Well, not exactly - at least not in the usage I've had. I simulated 
> something like Bounded_String in Ada83 because I had nothing else. I had 
> my own utilities for String because I had nothing else. In Ada95, I've 
> got Ada.Strings for any sort of fixed-allocation string needs and I've 
        ^^^^^^^^^^ I meant Ada.Strings.Fixed



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

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

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Is the Writing on the Wall for Ada?

[Jacob Sparre Andersen]

Marin David Condic wrote:

> O.K. But my question remains, "Does anybody use them in *practice*?" 

Yes.

> When I've needed a record field for something like Person_Name and 
> wanted some fixed allocation on it, I use a String and if/when I needed 
> to know where the string stopped, I use a "Last_Non_Blank ()" function. 
> But in most of the instances where I need something like this, I just 
> jump to Unbounded_String and am done with it.

It is my experience that Unbounded_String is too heavy - both memory and
processor wise - for some of my tasks (hundreds of thousands of
strings), so I stick to Bounded_String there.

But whenever it is a small task, where memory and processor footprint
isn't a real problem, I am also lazy and just use Unbounded_String.

> I understand that Bounded_String has some technical advantages, but in 
> my experience, the instant I'm on a PC at some astronomical number of 
> megahertz/gigahertz with more memory than I can shake a stick at, 
> Unbounded_String and all its technical disadvantages compared to 
> Bounded_String just seem to not amount to a warm bucket of spit. Hence 
> I'm wondering if people actually have/do use it on anything like a 
> regular basis.

I seem never to have enough Hertz and bytes to throw at my largest tasks...

> Maybe I'm unusual and most Ada programmers make use of Bounded_String 
> thirteen times a day. My usual question is: "Do I care about speed or 
> determinism in this application?" When "Yes" => String; When "No" => 
> Unbounded_String; Do other programmers have a When "Maybe" => 
> Bounded_String; branch?

No.  But there is definitely a "if Use_In_Arrays then Bounded_String"
statement inside the "when Cares_About_Speed =>" and the "when
Cares_About_Memory =>" branches.

Jacob
-- 
"I just might be wrong."

Re: Is the Writing on the Wall for Ada?

[Mark A. Biggar]

Marin David Condic wrote:

> I'm not even sure why Bounded_String exists - except for intellectual 
> completeness. Yes, I can see where in some cases I might want the 
> flexibility of Unbounded_String with the determinism of String. However, 
> in practice, I use either String or Unbounded_String. I don't even think 
> I ever took the shrink-wrap off of Bounded_String. If I really needed 
> it, I could create it on my own rather easily. But I've never needed it.
> 
> I suppose it would not hurt too much to make a Bounded_String version. 
> More for completeness than anything else. (It would look kind of silly 
> to be able to do a Get_Line or Put_Line of String or Unbounded_String 
> but not Bounded_String, right?) But I'd be curious to know if there is 
> *anybody* out there using Bounded_String on a regular basis. (Maybe it 
> should be depricated?)
> 
> There's another reason for having a conventional library outside of the 
> ARM - we could have experimented with the three string packages and 
> discovered if there was much interest in a Bounded_String before 
> committing it to permanent existence as part of the standard.


Bounded string is suppose to be for those cases where you need strings
that vary in length but also don't want to or can't support heap
allocation of string buffers (embedded, etc.).  It's a small but
necessary nitch.

-- 
mark@biggar.org
mark.a.biggar@comcast.net

Re: Is the Writing on the Wall for Ada?

[Marin David Condic]

I understand when its appropriate and why it may hve been included. I'm 
wondering if in *practice* people actually make much use of it. To 
create it from String is near trivial (just a record with a string and a 
discriminant - Been there. Done that. Got the Ada83 T-Shirt.) and most 
of the places where I would have put it to use, the type String works 
pretty much as well. You can look for the last non-blank character and 
treat that as the end of the string, so its semi-flexible and of a fixed 
maximum length.

I'm not really complaining that it exists - at least not that much. It 
just seems that it is of marginal usefulness and now means that any 
extensions to Ada involving strings has to support three variants 
instead of two if you want to keep things orthogonal. (Creating a 
Text_IO variant for String, Bounded_String and Unbounded_String along 
with whatever else seems to need such variants.)

Like I said, I've never personally used it for anything (and yes, I do 
embedded work as well as other things) and I'm wondering if others have 
actually used it in practice or do people just hop over to 
Unbounded_String the instant the type String seems to be the wrong answer.

MDC


Mark A. Biggar wrote:
> 
> Bounded string is suppose to be for those cases where you need strings
> that vary in length but also don't want to or can't support heap
> allocation of string buffers (embedded, etc.).  It's a small but
> necessary nitch.
> 


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

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

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Is the Writing on the Wall for Ada?

[Robert I. Eachus]

Marin David Condic wrote:

 > Like I said, I've never personally used it for anything (and yes, I
 > do embedded work as well as other things) and I'm wondering if others
 > have actually used it in practice or do people just hop over to
 > Unbounded_String the instant the type String seems to be the wrong
 > answer.

I initially invented what is now Bounded_String when I needed to create 
a ragged array of names in Ada.  I posted it to the ARG list (so long 
ago it was actually the LMC list) in answer to someone saying "It would 
be nice to have the equivalent in Ada of PL/I's char(N) varying."

There are some tricky bits to writing the package in Ada and making it 
would "right" and efficiently.  You have to have two record types.   The 
inner record type has a discriminant that doesn't depend on the outer. 
And defining the "&" overloadings is tricky--put in one too many and 
nothing works.  But as it is you can write:

    package Bounded is new
                 Ada.Strings.Bounded_String.Generic_Bounded_String(30);
    use Bounded;

    Foo: Bounded_String := Null_Bounded_String;
    Bar: String := "ABCD";
  begin
    Foo := Foo & Bar;
    Put_Line(' ' & Foo);

So I never understand all those complaints about explicitly converting 
to and from Bounded_String (or Unbounded_String).

In any case, people kept remembering that I had some working solution to 
the problem of ragged arrays in Ada, and sending me e-mail to get a copy 
of the package.  I probably rewrote it from memory a half-dozen times 
because I wasn't answering mail from a system where I had a copy.  (The 
body of the package is trivial, the key part is in the private part of 
the spec.)

Since lots of language experts would remember that there was a solution, 
but would e-mail me becuase they didn't remember the 'trick', it got 
added to Ada 95. Unbounded_String was essentially an argument by example 
for supporting Adjust for non-limited controlled types in Ada 95.

-- 
                                      Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the
goal of Art. It remains to work these concepts into a practical,
down-to-earth context, and for this there is nothing more practical or
down-to-earth than what I have been talking about all along...the repair
of an old motorcycle."  -- from Zen and the Art of Motorcycle
Maintenance by Robert Pirsig

Re: Is the Writing on the Wall for Ada?

[Alexander Kopilovitch]

Robert I. Eachus wrote:

> ...
> So I never understand all those complaints about explicitly converting
> to and from Bounded_String (or Unbounded_String).

(Let's speak about Unbounded_Strings, for clarity).

There are 2 main reasons for those complaints:

1) types Unbounded_String and String appear unrelated, while they are conceptually
related for all natural purposes. (If you want specifically a fixed-size array
of characters which is not assumed to be a textual line in the application then
say "array of Character", and not "String").

2) there is no literals in Ada for Unbounded_Strings which contradicts the
natural concept of a textual line of varying (unlimited) size.

[From all my experience in (non-corporate) application programming I must say
that while this seemingly tiny and unimportant point remains unresolved, Ada
never will be more popular among programmers than she is now. And if this point
will be resolved with some satifactory way then Ada's popularity will increase
(well, certainly not by magnitude, but quite noticeably) almost immediately.
Well, I'm not sure that it is a good goal to make Ada more popular; therefore
I can admit that preserving status quo here may be actually a proper decision.]



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

Re: Is the Writing on the Wall for Ada?

[Marin David Condic]

I doubt that this is a significant factor in popularity - or lack 
thereof. After all, Ada'a type String is really no different than that 
of C. C++ has inherited C's concept of string and essentially come up 
with their own "Unbounded_String" with a class. The two are no more 
related than Ada's String and Unbounded_String.

Language popularity is far less concerned with this or that specific 
syntax feature and far more concerned with "big issues". Fortran got 
enormously popular because it was all there was to use besides 
assembler. Cobol got popular because businessmen were not mathematicians 
and couldn't understand Fortran as readily as something that spoke more 
in "plain English". (Their needs were dramatically different too, so 
they got "leverage" out of what Cobol provided.) C got popular because 
there was this really cheap OS available called Unix that fit on small 
computers and it was programmed in C and came with a freebie C compiler. 
C++ became popular because it provided a means of using Object Oriented 
Programming while still being compatible with all that old C code the 
Unix hackers had lying around. Java got popular because it provided a 
means of building apps that could run across the Internet on PCs or 
Workstations running Windows or Unix or lots of other things. (Portable 
GUI and big library didn't hurt either.)

So what does Ada offer that will address some crying need out there in 
ProgrammerLand? I'd bet good money it won't be "We changed String and 
Unbounded_String to be the same thing..." I'd think it would have far 
more of a chance to gain in popularity if the amount of developmental 
leverage it provided were to increase - beyond what you get with C, C++, 
Java, etc. It wouldn't hurt if Ada could identify some market segment 
that is emerging and give that segment far more leverage than any other 
language. Tinkering with the syntax and semantics won't do it.

MDC


Alexander Kopilovitch wrote:
> 
> [From all my experience in (non-corporate) application programming I must say
> that while this seemingly tiny and unimportant point remains unresolved, Ada
> never will be more popular among programmers than she is now. And if this point
> will be resolved with some satifactory way then Ada's popularity will increase
> (well, certainly not by magnitude, but quite noticeably) almost immediately.
> Well, I'm not sure that it is a good goal to make Ada more popular; therefore
> I can admit that preserving status quo here may be actually a proper decision.]
> 


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

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

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Is the Writing on the Wall for Ada?

[Alexander Kopilovitch]

Marin David Condic wrote:

>After all, Ada'a type String is really no different than that of C.

I spoke not just about String, but primarily about Unbounded_String.

> C++ has inherited C's concept of string and essentially come up
> with their own "Unbounded_String" with a class. The two are no more
> related than Ada's String and Unbounded_String.

They may be no more related in language lawyer's view or implementor's view,
but they surely are much more related in application programmer's view:
you can assign a C-string (including most important case of literal string)
to C++ (class) string quite straightforwardly, without any convertions (it
doesn't matter which implicit methods are applied behind the scenes there).
In fact, conceptually C-string is just a "property" (or part) of C++ string
object - quite strong relation. isn't it?.

> Language popularity is far less concerned with this or that specific
> syntax feature and far more concerned with "big issues".

Ada 95 already addressed those "big issues", quite enough to be attractive.
What is wrong here - concerning popularity - is rigid maintenance of too straight
preference of hardware-related concept over application-related concept in one
particularly sensitive (for non-corporate application programmers) point.

> So what does Ada offer that will address some crying need out there in
> ProgrammerLand? I'd bet good money it won't be "We changed String and
> Unbounded_String to be the same thing..."

Certainly you'll never hear massive crying about that String/Unbounded_String
issue. This is not a thing that makes people crying, but this is high enough 
barrier for those undecided people who are just tasting the language. From
this issue too many of them quickly acquire a feeling that the language design
goals were somehow alien.

(Metaphorically, it is like an "improper" slight current of smell... if you
recognize that feeling then you can overcome it (appropriately adjusting criteria
in your internal recognizers/classifiers of good and bad smell), but if not -
then the feeling will effectively deter you from a closer contact.)



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

Re: Is the Writing on the Wall for Ada?

[Robert I. Eachus]

Alexander Kopilovitch wrote:
> Robert I. Eachus wrote: 
>>...
>>So I never understand all those complaints about explicitly converting
>>to and from Bounded_String (or Unbounded_String). 
> 
> (Let's speak about Unbounded_Strings, for clarity).
> 
> There are 2 main reasons for those complaints:
> 
> 1) types Unbounded_String and String appear unrelated, while they are conceptually
> related for all natural purposes. (If you want specifically a fixed-size array
> of characters which is not assumed to be a textual line in the application then
> say "array of Character", and not "String").
> 
> 2) there is no literals in Ada for Unbounded_Strings which contradicts the
> natural concept of a textual line of varying (unlimited) size.
> 
> [From all my experience in (non-corporate) application programming I must say
> that while this seemingly tiny and unimportant point remains unresolved, Ada
> never will be more popular among programmers than she is now. And if this point
> will be resolved with some satifactory way then Ada's popularity will increase
> (well, certainly not by magnitude, but quite noticeably) almost immediately.
> Well, I'm not sure that it is a good goal to make Ada more popular; therefore
> I can admit that preserving status quo here may be actually a proper decision.]

If I could wave a magic wand and convince Alexander of the close 
relationship between String, Unbounded_String, and Bounded_String, I 
would.  Each is an abstract data type representing arbitrary sized 
chunks of text.  The only difference between the three is that for a 
String, the bounds are a dynamic property of the value. A Bounded_String 
has a maximum size, and a current size but no bounds, and an 
Unbounded_String just a current size (and of course the value of the 
string literal).  All of these types are closely related to string 
literals and character literals so I can say:

A: String := "ABC" & 'd';
B: My_Bounded_String := "abc" & 'D' & Null_Bounded_String;
C: Unbounded_String := "Abc" & 'd' & Null_Unbounded_String;

To_String, To_Bounded_String, and To_Unbounded_String have to do with 
these attributes.  To_String(C) creates a String with 'First = 1 and 
'Last = 4.

E: String(1000..999);
F: String := E & C;

Will result in F'First being 1000.

So Strings have bounds. Bounded_Strings, Unbounded_Strings, and string 
literals don't.  This is why you can't do indexing or slicing of 
Unbounded_Strings as such.  Either you call a special operation defined 
in Ada.Strings, or you convert to a String--which has indexes--and index 
or slice that.

Oh, and not all of the potential implicit conversions are defined, just 
like all the possible catenation operators are not defined, because 
going any further would tend to make lots of straightforward expressions 
ambiguous. And if renaming To_Unbounded_String, and To_String as "+" 
will make you happy, feel free.

-- 
                                      Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: Is the Writing on the Wall for Ada?

[Alexander Kopilovitch]

Robert I. Eachus wrote:

> If I could wave a magic wand and convince Alexander of the close
> relationship between String, Unbounded_String, and Bounded_String, I
> would.

They are certainly closely related at the implementation level and in the
language documentation. But only relation between them at the specification
level is a set of conversions, and no more. This relation is too weak to be
applied automatically, and it leads to the necessity of explicit conversions.

> A: String := "ABC" & 'd';
> B: My_Bounded_String := "abc" & 'D' & Null_Bounded_String;
> C: Unbounded_String := "Abc" & 'd' & Null_Unbounded_String;
>...
> if renaming To_Unbounded_String, and To_String as "+"
> will make you happy, feel free.

Yes, we can almost hide those conversions, either by catenation with Null_*,
or by that "+", but never entirely - there always will be clearly visible
stamp. What does it mean, that stamp? - well, let's see either in docs or in
implementation... perhaps someone was creative enough to "enhance" its meaning.

> Oh, and not all of the potential implicit conversions are defined, just
> like all the possible catenation operators are not defined, because
> going any further would tend to make lots of straightforward expressions
> ambiguous.

Yes, I understand that perfectly.

I do not think that this issue is important to anyone who already decided
to use Ada anyway (or who already is fluent in Ada). For those people it is
just one of those slight irregularities, which you inevitably find in any
real programming language. But for many programmers who are neither fluent
in Ada nor forced to use Ada (for any reasons), and who are in position to
determine their attitude to Ada (and to do that relatively quickly), this issue
easily may be among the critical ones, and it may lead to early rejection.
Not because those programmers find it too hard to write explicit conversions,
but because they suspect that those conceptually unnecesessary conversions
are signs of some unfriendliness of the language... and they quit with the
usual sentence: "Ah, Ada - it's a language for military only".

Well, I would not pursue this issue if it concerns popularity (of Ada) only.
But I believe that this is indeed a violation of Ada's purpose for type system.
The question is whether this violation is significant enough to justify efforts
needed for correction. My remark about popularity is for proper view on this
subject.

Then, I understand that such a correction can't be a simple job, as it must
not break many existing relations and concepts involved. Nevertheless, I think
that there is a proper way to do that - by introducing an entirely new kind
of relation between types. I can even propose a form, but I surely can't work
out all related issues - I'm not a language lawyer. (I actually proposed that
form more than a year ago in Ada-Comment, and Robert Duff replied with a list
of questions, which reminded me one Russian play "Dragon", where Dragon said
to Knight: "I will take you seriously, I will annihilate you immediately." -;)
I understand that the String issue is certainly insufficient reason for such
a major move as introduction of new kind of relation between types, but it is
my feeling (well, pure feeling, no more), that this new kind of relation may
be useful in other situations also.



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

Re: Is the Writing on the Wall for Ada?

[Wes Groleau]

Marin David Condic wrote:
> actually used it in practice or do people just hop over to 
> Unbounded_String the instant the type String seems to be the wrong answer.

I so often needed a variable-length string in Ada-83 days
that I got quite experienced with my own implementation
and consequently have not yet used either of the new ones.

But mine was closer to Bounded, so I will likely shift
to that the next time the need arises.

-- 
Wes Groleau

  Guidelines for judging others:

  1. Don't attribute to malice that which
     can be adequately explained by stupidity.

  2. Don't attribute to stupidity that which
     can be adequately explained by ignorance.

  3. Don't attribute to ignorance that which
     can be adequately explained by misunderstanding.

Re: Is the Writing on the Wall for Ada?

[tmoran]

>*anybody* out there using Bounded_String on a regular basis. (Maybe it
>should be depricated?)
  There are many cases where a variable length string has an upper bound -
Person Name in a database, a file name in Windows, a variable name in
source code - and many are being processed so the efficiency of
Bounded_String is preferable.
  There are also cases where input comes from the outside world and
allowing an Unbounded_String could be fatal.  For instance, my HTTP
package uses bounded strings for alternate locations (eg 301s) and
content-type (eg text/html).  To use unbounded strings would mean the
first web page visited that had a humongous value for either of those,
by accident or design, would cause a Storage_Error, or unacceptable page
thrashing.

======================================================================
  "The well off generally feel that the system that made them well off
is not in need of substantial reform."

Re: Is the Writing on the Wall for Ada?

[Simon Wright]

Marin David Condic <nobody@noplace.com> writes:

> I suppose it would not hurt too much to make a Bounded_String
> version. More for completeness than anything else. (It would look
> kind of silly to be able to do a Get_Line or Put_Line of String or
> Unbounded_String but not Bounded_String, right?) But I'd be curious
> to know if there is *anybody* out there using Bounded_String on a
> regular basis. (Maybe it should be depricated?)

We are using bounded strings. I guess unbounded strings with an
overridable storage pool would do too.

Re: Is the Writing on the Wall for Ada?

[Jacob Sparre Andersen]

Marin David Condic wrote:

> I'm not even sure why Bounded_String exists - except for intellectual 
> completeness.

Sometimes it is the right tool for the job.  I use it in quite a few of
my programs.

Jacob
-- 
"I am an old man now, and when I die and go to Heaven there are two
   matters on which I hope enlightenment. One is quantum electro-dynamics
   and the other is turbulence of fluids. About the former, I am rather
   optimistic."  --  Sir Horace Lamb.

Re: Is the Writing on the Wall for Ada?

[Marin David Condic]

It would be nice to have unbounded string versions of all the 
subprograms that use strings. Open, Create, etc., all could be 
duplicated with an Unbounded_String parameter. Don't forget the 
sub-packages like Integer_IO, et alia. They have string parameters as 
well and I'd like to be able to use Unbounded_String everywhere.

Should there be Unbounded_String versions of anything else besides 
Text_IO? The other IO packages could utilize Unbounded_String for 
filenames, etc. Offhand, I can't think of where else type String occurs 
where I'd like to use Unbounded_String. Attributes that return a String 
so I don't have to encase them in a call to To_Unbounded_String () to 
get them in some location where I can use them? I'd personally like to 
program totally in Unbounded_String up until the point where I might 
need efficiency or determinism. Don't throw out String - just make it 
possible to ignore it.

A child package vs a separate package? I could see reasons for going 
both ways. We have Wide_Text_IO as a separate package, so there's a case 
for Unbounded_Text_IO (and Unbounded_Wide_Text_IO). However 
Ada.Text_IO.Unbounded would mean you're just adding the new things 
rather than duplicating everything, so there's a case for that as well. 
Toss a coin. I don't think there is any huge sufferings to be caused by 
going either way (as you observe, it doesn't mean making compiler 
changes - just writing a new package) and whichever way it goes, the 
user will have something new to "with" and "use", so it doesn't really 
make much difference to the end user.

MDC


Robert I. Eachus wrote:
> 
> As for a Get_Line function returning an Unbounded_String, the only real 
> question is where it should be defined.  I'd be happy with a child of 
> Ada.Text_IO that supported several operations on Unbounded_Strings 
> including Get, Get_Line, and Put.


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

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

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Is the Writing on the Wall for Ada?

[Dmitry A. Kazakov]

On Tue, 30 Sep 2003 12:21:00 GMT, Marin David Condic
<nobody@noplace.com> wrote:

>It would be nice to have unbounded string versions of all the 
>subprograms that use strings. Open, Create, etc., all could be 
>duplicated with an Unbounded_String parameter. Don't forget the 
>sub-packages like Integer_IO, et alia. They have string parameters as 
>well and I'd like to be able to use Unbounded_String everywhere.

Which means that Unbounded_String has to be a subtype of String. 

Actually interface inheritance should have solved this (by providing
user-defined type conversions). You inherit a String interface and
implement it via Unbounded_String, and here you are, all instances are
substitutable where a String is expected.

Unfortunately, the AI goes other way.

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

Re: Is the Writing on the Wall for Ada?

[Marin David Condic]

Dmitry A. Kazakov wrote:
> 
> Which means that Unbounded_String has to be a subtype of String. 
> 
Why? You create some package that has an "Open" procedrue that uses an 
Unbounded_String as the filename parameter - why does it have to be a 
subtype of String?

Maybe if we got to design the language from the ground up there would 
have been a better way of implementing all this so you could have 
strings of fixed or indeterminate length and uased them interchangably. 
Given that we can't do that, I guess we could get the same net effect by 
having some wider variety of packages with different parameter types for 
the same functions.

MDC

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

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

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Is the Writing on the Wall for Ada?

[Dmitry A. Kazakov]

On Wed, 01 Oct 2003 12:34:29 GMT, Marin David Condic
<nobody@noplace.com> wrote:

>Dmitry A. Kazakov wrote:
>> 
>> Which means that Unbounded_String has to be a subtype of String. 
>> 
>Why? You create some package that has an "Open" procedrue that uses an 
>Unbounded_String as the filename parameter - why does it have to be a 
>subtype of String?

No, I create Open with String as the parameter and it will accept
Unbounded_String for free.

Compare:

procedure OpenByNumber (X : Integer);
subtype Channel_Number is Integer range 1..29;

No : Channel_Number := 10;

OpenByNumber  (No); -- It is fine

>Maybe if we got to design the language from the ground up there would 
>have been a better way of implementing all this so you could have 
>strings of fixed or indeterminate length and uased them interchangably.

This is the point. The present design of strings just reflects some
fundamental language design deficiencies in ADT. Now you have a
choice, either to make it right or to patch a leaking bucket.

>Given that we can't do that, I guess we could get the same net effect by 
>having some wider variety of packages with different parameter types for 
>the same functions.

And have a geometric explosion of specifications. Surely we have to
provide generic variants of all possible subroutines to support
Bounded_Strings as well! (:-))

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

Re: Is the Writing on the Wall for Ada?

[Marin David Condic]

I understand. But I think it would be really hard to avoid this without 
breaking the language. If you tried to do something to make all that 
stuff subtypes of something so you could have "compatibility" and no 
proliferation of package specs, my guess would be that you wouldn't be 
able to pass millions of lines of existing Ada through the new compiler 
and have it work. You just can't do that to your user base. Better to 
start a whole new language.

MDC


Dmitry A. Kazakov wrote:
> 
> And have a geometric explosion of specifications. Surely we have to
> provide generic variants of all possible subroutines to support
> Bounded_Strings as well! (:-))
> 


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

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

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Is the Writing on the Wall for Ada?

[Dmitry A. Kazakov]

On Thu, 02 Oct 2003 12:42:33 GMT, Marin David Condic
<nobody@noplace.com> wrote:

>I understand. But I think it would be really hard to avoid this without 
>breaking the language. If you tried to do something to make all that 
>stuff subtypes of something so you could have "compatibility" and no 
>proliferation of package specs, my guess would be that you wouldn't be 
>able to pass millions of lines of existing Ada through the new compiler 
>and have it work. You just can't do that to your user base. Better to 
>start a whole new language.

AFAIK, so far no irreparable damage was made. So in my view it is
pretty possible to add for *all* types:

- classes (tags are embedded for tagged types only);
- interface inheritance which includes interfaces of *all* predefined
types such as scalar types, arrays, record types;
- discriminants;

And to do it in a way 99% compatible to the existing standard.

This would allow to drastically reduce the size of the standard
libraries.

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

Re: Is the Writing on the Wall for Ada?

[Jeffrey Carter]

Robert I. Eachus wrote:

> In Ada 83, a function that returned an unbounded String (notice the 
> punctuation) was almost useless.  In fact, there was one in Ada 80, and 
> it was taken out.  But changes in Ada 95 made such a function much more 
> useful, so I think it will get put back.  (It doesn't require any 
> changes to the compiler to add it, but some compiler vendors may do some 
> work to make it more efficient.)

Really? I had, and made frequent use of, one. I could pass its result to 
a subprogram (including a To_Variable_String type subprogram*), or use 
it to define a constant. I found that I didn't need variable string 
objects (what we would now call bounded strings) very much. The things 
you could do with type String in Ada 83 was quite large; I think it was 
ignorance that resulted in people thinking that variable strings were 
very important. (They're nice to have, though, and I'm glad Ada now has 
them.)

*Actually, the variable string type I used was a limited type, so I had 
Assign procedures; one took type String for its From parameter.

-- 
Jeff Carter
"All citizens will be required to change their underwear
every half hour. Underwear will be worn on the outside,
so we can check."
Bananas
29

Re: Is the Writing on the Wall for Ada?

[Alexander Kopilovitch]

Hyman Rosen wrote:

> > Ada.Strings.Unbounded. Way better than C++ Strings.
> 
> How?

Because you can't assign literals to them (even in initialization) without 
explicit conversion -;) .



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

Re: Is the Writing on the Wall for Ada?

[Matthew Heaney]

Jan Kroken <jankr@nntp.ifi.uio.no> writes:

> 4. Dynamic strings
> 
> Dynamic strings, with proper library support. It's quite possible it's
> in there, but it's not coincidence that the example Ada programs I've
> read all seems to impose random limits, like line lengths of input
> files limited to 80 characters and such.

Well, you have Ada.Strings.Unbounded.  The Charles library also has a
vector-like container for type String.

<http://home.earthlink.net/~matthewjheaney/charles/index.html>

I'm not sure what limit you're talking about.  There's no limit to the
length of input lines.  You can either use a loop to read the entire
line into an unbounded string, or use a recursive algorithm to read the
entire line.

Re: Is the Writing on the Wall for Ada?

[Marin David Condic]

Jan Kroken wrote:
> 
> 1. A garbage collector
> 
> I know perfectly well that the Ada 95 standard allows for GC, but what
> does that help me when the implementation doesn't have it.  The
> argument against GC is that it's not desireable for realtime systems,
> but I have never written a real time system in my life, so why should
> I not have one? Solidarity?
> 

The problem seems to be that nobody wants one bad enough to want to pay 
for it. The subject has been raised here before and the usual response 
from those working for vendors has been "Our customers don't seem to 
care". Since GNAT is available in source, its possible someone could go 
cobble it in there and try to get it accepted for the general 
distribution, but again, nobody seems to care enough to do that. 
Conclusion: It must not be very important or someone would have done it 
by now. (Idea: Get together with everyone else who has ever asked here 
for GC in Ada and start a project to add it to Gnat. Chances are, if it 
can be enabled/disabled easily, it would be able to get into the general 
distribution. Why *wouldn't* ACT, et alia accept it if it can be 
disabled and it otherwise works reliably?)

> 2. Better organization on disk
> 
> The java idea of organizing packages in directories is really a good
> idea. Same with .jar files, and the CLASSPATH.
> 

I don't know what that means. Disk-stuff is external to the language. 
The compilation environment could organize packages any way they like 
and if somehow or other it is desirable to keep each package in a 
directory, that could probably be done. It sounds more like an IDE issue 
- and that could forever be debated just like "What is the best text 
editor for programming?". (Let's see if the emacs crowd will come out of 
the woodwork now! :-) The language can't really fix that. It would have 
to be a byproduct of your development environment and there you'd have 
to point a vendor at something specific and say "I want one that will do 
it this way..." If its a really good concept, it might make an 
interesting project to add another IDE for Ada - or modify one of the 
ones out there already.



> 3. OO
> 
> I know the tagged record thingie is considered OO, but that's just
> playing with words. OO as a concept is more than inheritance.
> 

It seems that you get more than inheritance with tagged records and 
packages. What did you want? (Is this the great "method->object vs 
object->method debate? :-) You have all the features you need to support 
full OO Programming from OO Design - just maybe not in the syntax you'd 
be used to. Realistically, it wouldn't be possible to perform major 
surgery on Ada's syntax to make it more like some languages that started 
out as OO Concepts. There's too much history and need for upward 
compatibility to go radically modifying the syntax in any serious way. 
You've got to take the good with the bad - the capabilities are there, 
but not necessarily as conveniently as you might like because of prior 
history. But a solution does exist. Practically speaking we can't just 
say "Ada would be better if only Ada were Eiffel..." - Trying to make 
Ada look like some other language just won't work and will only annoy 
existing users.



> 4. Dynamic strings
> 
> Dynamic strings, with proper library support. It's quite possible it's
> in there, but it's not coincidence that the example Ada programs I've
> read all seems to impose random limits, like line lengths of input
> files limited to 80 characters and such.
> 
See Ada.Strings.Unbounded. One might wish for more string-manipulation 
utility from the package, but all the basics are there. Most of the 
fixed-length examples you see are the result of history - Ada83 didn't 
have unbounded strings. Personally, I almost *never* use the fixed 
length strings anymore when programming for general use on a PC. You've 
got to read them in as fixed (for now - lets see what Ada0x does) but 
then I instantly convert them to unbounded strings. When designing 
objects, I may have parameters or function returns that are the standard 
type "String" because you sometimes need these as parameters to other 
"standard" routines, but that's just a quick call to To_String (X) or 
To_Unbounded_String (X) on the way in or out. But for any internal 
manipulation, I use only unbounded strings and am quite happy to do so.

MDC

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

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

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Is the Writing on the Wall for Ada?

[chris]

Marin David Condic wrote:
> 
> It seems that you get more than inheritance with tagged records and 
> packages. What did you want? (Is this the great "method->object vs 
> object->method debate? :-) You have all the features you need to support 
> full OO Programming from OO Design - just maybe not in the syntax you'd 
> be used to. Realistically, it wouldn't be possible to perform major 
> surgery on Ada's syntax to make it more like some languages that started 
> out as OO Concepts. There's too much history and need for upward 
> compatibility to go radically modifying the syntax in any serious way. 
> You've got to take the good with the bad - the capabilities are there, 
> but not necessarily as conveniently as you might like because of prior 
> history. But a solution does exist. Practically speaking we can't just 
> say "Ada would be better if only Ada were Eiffel..." - Trying to make 
> Ada look like some other language just won't work and will only annoy 
> existing users.

"Protected" members, without using child packages.

Re: Is the Writing on the Wall for Ada?

[Stephen Leake]

chris <spamoff.danx@ntlworld.com> writes:

> Marin David Condic wrote:
> > It seems that you get more than inheritance with tagged records and
> > packages. What did you want? <snip>
> 
> "Protected" members, without using child packages.

The way you get "protected" members in Ada is to use child packages.
Why don't you like child packages?

Imagine if I said about C++ : "I want protected members, without using
the 'protected' keyword". Would you consider that a valid critique? I
don't think so.

-- 
-- Stephe

Re: Is the Writing on the Wall for Ada?

[chris]

Stephen Leake wrote:
> chris <spamoff.danx@ntlworld.com> writes:
> 
> 
>>Marin David Condic wrote:
>>
>>>It seems that you get more than inheritance with tagged records and
>>>packages. What did you want? <snip>
>>
>>"Protected" members, without using child packages.
> 
> 
> The way you get "protected" members in Ada is to use child packages.
> Why don't you like child packages?

I didn't say that.  I just wonder if it's always possible to use a child 
package.  Is it?  If so then I take it back.

Re: Is the Writing on the Wall for Ada?

[Stephen Leake]

chris <spamoff.danx@ntlworld.com> writes:

> Stephen Leake wrote:
> > chris <spamoff.danx@ntlworld.com> writes:
> >
> >>Marin David Condic wrote:
> >>
> >>>It seems that you get more than inheritance with tagged records and
> >>>packages. What did you want? <snip>
> >>
> >>"Protected" members, without using child packages.
> > The way you get "protected" members in Ada is to use child packages.
> > Why don't you like child packages?
> 
> I didn't say that.  I just wonder if it's always possible to use a
> child package.  Is it?  If so then I take it back.

Well, "always" is a very inclusive term. But yes, in general, any
package can have a child package. Whether that gets you exactly what
you want, I can't say.

-- 
-- Stephe

Re: Is the Writing on the Wall for Ada?

[Marin David Condic]

And a bit more to the original point: How does this stop anyone from 
realizing a truly OO Implementation of a given OO Design? I *did* 
observe that the syntax may not be exactly what one may want - but that 
a solution does exist, so its hard to say "Ada isn't OO enough". It 
isn't Eiffel or Smalltalk or Java, so the syntax won't necessarily be in 
perfect alignment with someone's concepts of what makes something "look 
OO", but if you want inheritance, polymorphism, information hiding, and 
all the other "classic OO" qualities, it seems like you can get them in Ada.

I often hear critics of Ada complaining about this or that, and usually 
it comes down to "Ada isn't C++, so Ada sucks..." Well, it isn't C++ and 
it never will be. Its Ada. Its always going to look like Ada and if it 
takes looking like C++ in order to be considered Stuff That's Cool, then 
I guess Ada is now and forever shall be Stuff That Sucks. I'd hope we 
could now get over it and just learn how to use the features it *does* 
have to do OO Programming and maybe try to discover if there are some 
featrues it *must* have in order to implement an OO Design.

MDC


Stephen Leake wrote:
> 
> 
> The way you get "protected" members in Ada is to use child packages.
> Why don't you like child packages?
> 
> Imagine if I said about C++ : "I want protected members, without using
> the 'protected' keyword". Would you consider that a valid critique? I
> don't think so.
> 


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

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

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Is the Writing on the Wall for Ada?

[Robert I. Eachus]

Marin David Condic wrote:

>> 1. A garbage collector
>>
>> I know perfectly well that the Ada 95 standard allows for GC, but what
>> does that help me when the implementation doesn't have it.  The
>> argument against GC is that it's not desireable for realtime systems,
>> but I have never written a real time system in my life, so why should
>> I not have one? Solidarity?
>>
> 
> The problem seems to be that nobody wants one bad enough to want to pay 
> for it. The subject has been raised here before and the usual response 
> from those working for vendors has been "Our customers don't seem to 
> care". Since GNAT is available in source, its possible someone could go 
> cobble it in there and try to get it accepted for the general 
> distribution, but again, nobody seems to care enough to do that. 

Not quite true.  There is a more subtle problem.  There have been many 
Ada compilers that supported GC over the years, but in every case except 
possibly Symbolics, the general purpose garbage collection didn't get 
exercised enough and eventually died due to "bit rot".*  (The extra cost 
of supplying a garbage collector, such as a garbage collected storage 
pool for Ada 95 is that you have to test it by forcing garbage 
collection by exhausting storage space every time you modify the 
compiler.  This gets old fast.  And calling the GC routines specifically 
is not enough.)

*Yes, I know that the belief that unmaintained code rots may not be true 
for some things, but a storage allocation and management system that is 
part of a compiler is one case where the bit rot is pretty fast.

-- 
                                           Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: Is the Writing on the Wall for Ada?

[Marin David Condic]

You may be right, but at the end of the day, here's the benefit of my 
experience: I've been using Ada for 20 years in one capacity or another. 
I've written big, databasey-workstationish applications for 
VAX/ALPHA/VMS, Unix and PC platforms. I've done hard realtime embedded 
Ada code for a variety of systems. I've hacked thousands of little 
one-shot fixit tools or utilities. Some apps have made extensive use of 
dynamic data structures and others not at all. In all these cases, I've 
never once felt even the slightest bit deprived by not having a compiler 
that had GC. (Its possible one of them might have had it - I never 
noticed.) Hence, I find it difficult to understand why people regularly 
bring up GC as some sort of "significant shortcoming" of Ada.

Maybe there is some problem domain in which the algorithms tend to 
depend on GC being around. Midieval Botswainian Lute Music Pattern 
Recognition, perhaps? But generally, if you build your data structures 
correctly, you're properly managing the storage anyway and GC should not 
be an issue. I don't get why it always seems to be one with some folks - 
yet never enough so that it really motivates adding it to some compiler.

MDC


Robert I. Eachus wrote:
> 
> 
> Not quite true.  There is a more subtle problem.  There have been many 
> Ada compilers that supported GC over the years, but in every case except 
> possibly Symbolics, the general purpose garbage collection didn't get 
> exercised enough and eventually died due to "bit rot".*  (The extra cost 
> of supplying a garbage collector, such as a garbage collected storage 
> pool for Ada 95 is that you have to test it by forcing garbage 
> collection by exhausting storage space every time you modify the 
> compiler.  This gets old fast.  And calling the GC routines specifically 
> is not enough.)
> 

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

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

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Is the Writing on the Wall for Ada?

[Robert I. Eachus]

Marin David Condic wrote:
> In all these cases, I've 
> never once felt even the slightest bit deprived by not having a compiler 
> that had GC. (Its possible one of them might have had it - I never 
> noticed.) Hence, I find it difficult to understand why people regularly 
> bring up GC as some sort of "significant shortcoming" of Ada.

Actually I may have stated things incorrectly.  Every Ada compiler you 
have used has garbage collection.  But what is required to implement the 
standard is that certain types that can be managed by some variation on 
reference counting be managed correctly.  In fact, the only such case in 
Ada 83 was objects of a task type.

And of course, it is exactly in the task type case that you can't use a 
"general" garbage collector with arbitrary collection times.  In Ada 95 
we added Ada.Strings.Unbounded.  Unbounded_Strings can't contain user 
defined pointers to other Unbounded_Strings, but it is required to be 
collected.  (Whether an Unbounded_String object contains other pointers
including pointers to other Unbounded_Strings is, of course, 
implementation defined.)

So it comes down to the fact that Ada provides a rich set (if you 
include Controlled types) of primitives for managing garbage, but no 
generalized garbage collection.

Now let me digress for a bit.  Anyone here who has studied compiler 
design knows that there is a tree, the abstract syntax tree (AST) that 
corresponds to a program being parsed.  This is then "decorated" with 
symantic information.  The symantic information creates lots of further 
nodes, and also creates lots of further links converting the parse tree 
into a directed graph.  Horrible garbage collection problem right? 
Wrong.  To be useful it has to be be possible to walk both the AST and 
the decorated tree visiting each node.  This is done by keeping 
structural relationships separate from semantic relationships.  When a 
new node is created, it has a parent, either the node that the compiler 
was looking at when it recognized new syntax structures (very generally 
speaking) or the parse node that the semantic information belongs to.

In fact on some parse tools I have used, you can set a debug mode which 
will instantly detect any loop in the AST.  (This is obviously an error, 
  and it is much easier to catch it immediately.)  I have never used 
that capability, since in that environment I was always doing the 
parsing, and someone else did the semantic analysis.  And since I was 
using a tool to build the parser, anything that would have caused a loop 
in the AST meant that my grammar wasn't going to get through the tool.

(End digression.)  So here we have an area that "looks like" it is 
perfect for full garbage collection, and any compiler group that writes 
their compiler in Ada is going to be putting a lot of effort into 
maintaining ASTs and decorating them.  So why don't they just use 
garbage collection?  It is way too damn slow.  I don't know if any Ada 
compilers are still using relocatable parse tree structures, I know 
Intermetrics and Verdix both did once upon a time.  So it is not the 
overhead of relocation that can occur in a compacting garbage collector 
that is the issue, it is garbage collection overhead itself.

The problem is that the parse tree in Ada is really a forest of trees 
for separate compilation units (or I think in the original DEC Ada 
compiler compilations).  When you compile a with clause, you need to 
bring a representation of the parse tree for that unit in from the 
library.  (Yes, I know that GNAT and the Intermetrics front-end now 
reparse package specs instead of loading the AST, but that is an 
optimization.) Think of the number of calls to malloc or the equivalent 
that would be required, and compiling with clauses will make the 
compiler crawl a lot slower than it does now.  So you grab chunks of 
memory, slice them up with internal pointers, and when you no longer 
need that tree you free the chunks--which have valid pointers all over 
the place, along with valid pointers in from other trees into them.  So 
a full garbage collect would fail, but a reference counting collector 
works just fine.

And that is the biggest problem with getting "full" garbage collection 
in most Ada compilers.  The compiler group knows that they need to 
protect their parse trees from the collector, or the compiler will run 
significantly slower with no real benefit to them or to the user.  So 
they install a switch.  The compiler runs significantly faster when 
compiled with the switch off, and surprise, so do most other programs as 
well.  Eventually someone runs out of memory, and say, "Ah, ha! Now I 
turn on GC."  But it doesn't work.  And no one wants to take the effort 
to figure out whether the garbage collection was just that slow when 
invoked, or if it was broken three compiler releases back.

You would think that "just" managing a particular storage pool would be 
a solution.  But you still have the distributed overhead in that the 
garbage collector has to manage (or identify) all pointers into the GC 
pool.  There is another attempt to add a usable version of a 
conservative collector to GNAT, we will see if it is successful.

Of course, if you have been following, you will realize that my 
definition of successful is become widely used and be supported.  The 
work to add a GC managed storage pool to Ada is about three days work 
for any particular hardware.  It probably takes a lot less to add a 
conservative collector for a second and subsequent ISA targets.  But 
supporting such a collector and maintaining it is probably call it 1/4 
of a full-time job.  Way too much for a hobbiest, and as we have seen 
there just isn't enough interest for a comiler vendor to do it.  At 
Symbolics, they had the "advantage" that supporting their garbage 
collector was already a full-time or more job for the OS department, and 
the Ada compiler could just use it along with the Lisp people.

-- 
                                      Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: Is the Writing on the Wall for Ada?

[Wes Groleau]

> noticed.) Hence, I find it difficult to understand why people regularly 
> bring up GC as some sort of "significant shortcoming" of Ada.

The only thing I can think of, is that the
lack _could_ be interpreted as contrary to
Ada's safety goals.

"We don't need garbage collection because a
good programmer should determine where it's
needed and ensure it's there."

"But whether good or not, experience teaches
us that programmers don't do this."

Doesn't that sound a lot like our disputes
with Ada-bashers about strong typing?

-- 
Wes Groleau
-----------
I've been framed! ...
http://www.useit.com/alertbox/9612.html

Re: Is the Writing on the Wall for Ada?

[Marin David Condic]

Possibly - that does sound a bit like the "Any *competent* 
programmer..." argument. However, I'd still end up putting it in the 
category of "Below the noise floor". I just have not seen that many 
memory leak sort of problems in the real-world systems that I have built 
or those built by others that were done in Ada. I'm not saying it 
doesn't happen. Just that in my experience, I have not seen it often 
enough to consider it a significant weakness that no Ada compilers today 
have GC or that it ought to be a priority to add it. (Robert Eachus 
seems to be making a case that it is really rather expensive and doesn't 
usually help much anyway.)

Now when I've worked with C/C++, GC seems like it would make a lot more 
sense. There you *must* use pointers to just about everything and things 
are easily dropped on the floor. Because of the extensive need for 
pointers and malloc/free usage everywhere, it seems to make more sense 
to have GC. But I don't know that there are lots of C++ compilers out 
there supporting GC either.

MDC



Wes Groleau wrote:
> 
> The only thing I can think of, is that the
> lack _could_ be interpreted as contrary to
> Ada's safety goals.
> 
> "We don't need garbage collection because a
> good programmer should determine where it's
> needed and ensure it's there."
> 
> "But whether good or not, experience teaches
> us that programmers don't do this."
> 
> Doesn't that sound a lot like our disputes
> with Ada-bashers about strong typing?
> 


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

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

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Is the Writing on the Wall for Ada?

[Wes Groleau]

Marin David Condic wrote:
> enough to consider it a significant weakness that no Ada compilers today 
> have GC or that it ought to be a priority to add it. (Robert Eachus 
> seems to be making a case that it is really rather expensive and doesn't 
> usually help much anyway.)

Well, I don't consider it a significant weakness.
I have fixed a few memory leaks in Ada, but AFAIK
never caused one.  All the ones I've found and fixed,
with one exception, were due to exception handlers
not repeating the cleanup that _was_ included in the
regular code.

Now, the designer of the data type that needs cleanup
can take care of it.

-- 
Wes Groleau
   "Grant me the serenity to accept those I cannot change;
    the courage to change the one I can;
    and the wisdom to know it's me."
                                -- unknown

Re: Is the Writing on the Wall for Ada?

[Hyman Rosen]

Marin David Condic wrote:
> Now when I've worked with C/C++, GC seems like it would make a lot more 
> sense. There you *must* use pointers to just about everything and things 
> are easily dropped on the floor. Because of the extensive need for 
> pointers and malloc/free usage everywhere, it seems to make more sense 
> to have GC. But I don't know that there are lots of C++ compilers out 
> there supporting GC either.

When talking about memory leaks, it doesn't make any sense to talk
about "C/C++". There are aspects of C++ which were designed precisely
to handle the kinds of memory problems found in C. In particular, the
simple fact that destructors are always called for objects when their
lifetime ends means that most pointers will never be "dropped on the
floor". Memory leaks still happen, but mostly in complexly linked
data structures where ownership of pointers can become unclear.