* Re: Is the Writing on the Wall for Ada?
2003-09-06 21:47 Warren W. Gay VE3WWG
@ 2003-09-07 4:05 ` Wes Groleau
2003-09-07 4:59 ` Russ
` (16 subsequent siblings)
17 siblings, 0 replies; 427+ messages in thread
From: Wes Groleau @ 2003-09-07 4:05 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-06 21:47 Warren W. Gay VE3WWG
2003-09-07 4:05 ` Wes Groleau
@ 2003-09-07 4:59 ` Russ
2003-09-07 6:02 ` Hyman Rosen
2003-09-14 6:24 ` Matthew Heaney
2003-09-07 6:19 ` Mike Silva
` (15 subsequent siblings)
17 siblings, 2 replies; 427+ messages in thread
From: Russ @ 2003-09-07 4:59 UTC (permalink / raw)
"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.
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-07 4:59 ` Russ
@ 2003-09-07 6:02 ` Hyman Rosen
2003-09-07 8:12 ` David Marceau
2003-09-07 11:24 ` Russ
2003-09-14 6:24 ` Matthew Heaney
1 sibling, 2 replies; 427+ messages in thread
From: Hyman Rosen @ 2003-09-07 6:02 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-07 6:02 ` Hyman Rosen
@ 2003-09-07 8:12 ` David Marceau
2003-09-07 10:17 ` Hyman Rosen
2003-09-08 18:37 ` svaa
2003-09-07 11:24 ` Russ
1 sibling, 2 replies; 427+ messages in thread
From: David Marceau @ 2003-09-07 8:12 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-07 8:12 ` David Marceau
@ 2003-09-07 10:17 ` Hyman Rosen
2003-09-07 14:31 ` Jerry van Dijk
2003-09-08 7:49 ` olehjalmar kristensen - Sun Microsystems - Trondheim Norway
2003-09-08 18:37 ` svaa
1 sibling, 2 replies; 427+ messages in thread
From: Hyman Rosen @ 2003-09-07 10:17 UTC (permalink / raw)
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?
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-07 10:17 ` Hyman Rosen
@ 2003-09-07 14:31 ` Jerry van Dijk
2003-09-14 11:39 ` Alex Gibson
2003-09-08 7:49 ` olehjalmar kristensen - Sun Microsystems - Trondheim Norway
1 sibling, 1 reply; 427+ messages in thread
From: Jerry van Dijk @ 2003-09-07 14:31 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-07 14:31 ` Jerry van Dijk
@ 2003-09-14 11:39 ` Alex Gibson
0 siblings, 0 replies; 427+ messages in thread
From: Alex Gibson @ 2003-09-14 11:39 UTC (permalink / raw)
"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 ?
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-07 10:17 ` Hyman Rosen
2003-09-07 14:31 ` Jerry van Dijk
@ 2003-09-08 7:49 ` olehjalmar kristensen - Sun Microsystems - Trondheim Norway
1 sibling, 0 replies; 427+ messages in thread
From: olehjalmar kristensen - Sun Microsystems - Trondheim Norway @ 2003-09-08 7:49 UTC (permalink / raw)
>>>>> "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.
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-07 8:12 ` David Marceau
2003-09-07 10:17 ` Hyman Rosen
@ 2003-09-08 18:37 ` svaa
1 sibling, 0 replies; 427+ messages in thread
From: svaa @ 2003-09-08 18:37 UTC (permalink / raw)
> 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.
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-07 6:02 ` Hyman Rosen
2003-09-07 8:12 ` David Marceau
@ 2003-09-07 11:24 ` Russ
2003-09-07 19:01 ` Robert I. Eachus
2003-09-09 1:47 ` Hyman Rosen
1 sibling, 2 replies; 427+ messages in thread
From: Russ @ 2003-09-07 11:24 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-07 11:24 ` Russ
@ 2003-09-07 19:01 ` Robert I. Eachus
2003-09-07 19:41 ` Jerry van Dijk
` (4 more replies)
2003-09-09 1:47 ` Hyman Rosen
1 sibling, 5 replies; 427+ messages in thread
From: Robert I. Eachus @ 2003-09-07 19:01 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-07 19:01 ` Robert I. Eachus
@ 2003-09-07 19:41 ` Jerry van Dijk
2003-09-07 20:17 ` David C. Hoos
` (3 subsequent siblings)
4 siblings, 0 replies; 427+ messages in thread
From: Jerry van Dijk @ 2003-09-07 19:41 UTC (permalink / raw)
"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
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-07 19:01 ` Robert I. Eachus
2003-09-07 19:41 ` Jerry van Dijk
@ 2003-09-07 20:17 ` David C. Hoos
2003-09-07 21:45 ` Russ
` (2 subsequent siblings)
4 siblings, 0 replies; 427+ messages in thread
From: David C. Hoos @ 2003-09-07 20:17 UTC (permalink / raw)
"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>
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-07 19:01 ` Robert I. Eachus
2003-09-07 19:41 ` Jerry van Dijk
2003-09-07 20:17 ` David C. Hoos
@ 2003-09-07 21:45 ` Russ
2003-09-08 4:10 ` Matthew Heaney
2003-09-08 18:35 ` Alexander Kopilovitch
2003-09-08 5:09 ` Robert C. Leif
2003-09-08 14:36 ` Ed Falis
4 siblings, 2 replies; 427+ messages in thread
From: Russ @ 2003-09-07 21:45 UTC (permalink / raw)
"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?
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-07 21:45 ` Russ
@ 2003-09-08 4:10 ` Matthew Heaney
2003-09-08 18:35 ` Alexander Kopilovitch
1 sibling, 0 replies; 427+ messages in thread
From: Matthew Heaney @ 2003-09-08 4:10 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-07 21:45 ` Russ
2003-09-08 4:10 ` Matthew Heaney
@ 2003-09-08 18:35 ` Alexander Kopilovitch
2003-09-09 0:19 ` Hyman Rosen
1 sibling, 1 reply; 427+ messages in thread
From: Alexander Kopilovitch @ 2003-09-08 18:35 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-08 18:35 ` Alexander Kopilovitch
@ 2003-09-09 0:19 ` Hyman Rosen
2003-09-09 7:41 ` Russ
0 siblings, 1 reply; 427+ messages in thread
From: Hyman Rosen @ 2003-09-09 0:19 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-09 0:19 ` Hyman Rosen
@ 2003-09-09 7:41 ` Russ
2003-09-11 2:59 ` Hyman Rosen
0 siblings, 1 reply; 427+ messages in thread
From: Russ @ 2003-09-09 7:41 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-09 7:41 ` Russ
@ 2003-09-11 2:59 ` Hyman Rosen
0 siblings, 0 replies; 427+ messages in thread
From: Hyman Rosen @ 2003-09-11 2:59 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 427+ messages in thread
* RE: Is the Writing on the Wall for Ada?
2003-09-07 19:01 ` Robert I. Eachus
` (2 preceding siblings ...)
2003-09-07 21:45 ` Russ
@ 2003-09-08 5:09 ` Robert C. Leif
2003-09-08 9:54 ` Rod Chapman
2003-09-09 0:25 ` Hyman Rosen
2003-09-08 14:36 ` Ed Falis
4 siblings, 2 replies; 427+ messages in thread
From: Robert C. Leif @ 2003-09-08 5:09 UTC (permalink / raw)
To: 'Robert I. Eachus', comp.lang.ada
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
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-08 5:09 ` Robert C. Leif
@ 2003-09-08 9:54 ` Rod Chapman
2003-09-09 0:25 ` Hyman Rosen
1 sibling, 0 replies; 427+ messages in thread
From: Rod Chapman @ 2003-09-08 9:54 UTC (permalink / raw)
"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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-08 5:09 ` Robert C. Leif
2003-09-08 9:54 ` Rod Chapman
@ 2003-09-09 0:25 ` Hyman Rosen
2003-09-09 6:51 ` Alexander Kopilovitch
` (3 more replies)
1 sibling, 4 replies; 427+ messages in thread
From: Hyman Rosen @ 2003-09-09 0:25 UTC (permalink / raw)
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?
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-09 0:25 ` Hyman Rosen
@ 2003-09-09 6:51 ` Alexander Kopilovitch
2003-09-09 7:33 ` Russ
` (2 subsequent siblings)
3 siblings, 0 replies; 427+ messages in thread
From: Alexander Kopilovitch @ 2003-09-09 6:51 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-09 0:25 ` Hyman Rosen
2003-09-09 6:51 ` Alexander Kopilovitch
@ 2003-09-09 7:33 ` Russ
2003-09-09 9:24 ` Dmitry A. Kazakov
2003-09-11 3:10 ` Hyman Rosen
2003-09-09 7:34 ` olehjalmar kristensen - Sun Microsystems - Trondheim Norway
2003-09-10 19:47 ` Robert I. Eachus
3 siblings, 2 replies; 427+ messages in thread
From: Russ @ 2003-09-09 7:33 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-09 7:33 ` Russ
@ 2003-09-09 9:24 ` Dmitry A. Kazakov
2003-09-11 3:10 ` Hyman Rosen
1 sibling, 0 replies; 427+ messages in thread
From: Dmitry A. Kazakov @ 2003-09-09 9:24 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-09 7:33 ` Russ
2003-09-09 9:24 ` Dmitry A. Kazakov
@ 2003-09-11 3:10 ` Hyman Rosen
1 sibling, 0 replies; 427+ messages in thread
From: Hyman Rosen @ 2003-09-11 3:10 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-09 0:25 ` Hyman Rosen
2003-09-09 6:51 ` Alexander Kopilovitch
2003-09-09 7:33 ` Russ
@ 2003-09-09 7:34 ` olehjalmar kristensen - Sun Microsystems - Trondheim Norway
2003-09-09 13:13 ` Ed Falis
` (2 more replies)
2003-09-10 19:47 ` Robert I. Eachus
3 siblings, 3 replies; 427+ messages in thread
From: olehjalmar kristensen - Sun Microsystems - Trondheim Norway @ 2003-09-09 7:34 UTC (permalink / raw)
>>>>> "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.
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-09 7:34 ` olehjalmar kristensen - Sun Microsystems - Trondheim Norway
@ 2003-09-09 13:13 ` Ed Falis
2003-09-10 6:09 ` Robert C. Leif
[not found] ` <20030910060915.VSBE25714.mta015.verizon.net@smtp.covadmail.net>
2003-09-09 23:48 ` Alexander Kopilovitch
2003-09-14 21:44 ` Matthew Heaney
2 siblings, 2 replies; 427+ messages in thread
From: Ed Falis @ 2003-09-09 13:13 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread* RE: Is the Writing on the Wall for Ada?
2003-09-09 13:13 ` Ed Falis
@ 2003-09-10 6:09 ` Robert C. Leif
[not found] ` <20030910060915.VSBE25714.mta015.verizon.net@smtp.covadmail.net>
1 sibling, 0 replies; 427+ messages in thread
From: Robert C. Leif @ 2003-09-10 6:09 UTC (permalink / raw)
To: 'Ed Falis', comp.lang.ada
"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
^ permalink raw reply [flat|nested] 427+ messages in thread[parent not found: <20030910060915.VSBE25714.mta015.verizon.net@smtp.covadmail.net>]
* Re: Is the Writing on the Wall for Ada?
2003-09-09 7:34 ` olehjalmar kristensen - Sun Microsystems - Trondheim Norway
2003-09-09 13:13 ` Ed Falis
@ 2003-09-09 23:48 ` Alexander Kopilovitch
2003-09-10 7:13 ` olehjalmar kristensen - Sun Microsystems - Trondheim Norway
2003-09-10 7:48 ` Dmitry A. Kazakov
2003-09-14 21:44 ` Matthew Heaney
2 siblings, 2 replies; 427+ messages in thread
From: Alexander Kopilovitch @ 2003-09-09 23:48 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-09 23:48 ` Alexander Kopilovitch
@ 2003-09-10 7:13 ` olehjalmar kristensen - Sun Microsystems - Trondheim Norway
2003-09-11 1:39 ` Alexander Kopilovitch
2003-09-10 7:48 ` Dmitry A. Kazakov
1 sibling, 1 reply; 427+ messages in thread
From: olehjalmar kristensen - Sun Microsystems - Trondheim Norway @ 2003-09-10 7:13 UTC (permalink / raw)
>>>>> "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
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-10 7:13 ` olehjalmar kristensen - Sun Microsystems - Trondheim Norway
@ 2003-09-11 1:39 ` Alexander Kopilovitch
0 siblings, 0 replies; 427+ messages in thread
From: Alexander Kopilovitch @ 2003-09-11 1:39 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-09 23:48 ` Alexander Kopilovitch
2003-09-10 7:13 ` olehjalmar kristensen - Sun Microsystems - Trondheim Norway
@ 2003-09-10 7:48 ` Dmitry A. Kazakov
1 sibling, 0 replies; 427+ messages in thread
From: Dmitry A. Kazakov @ 2003-09-10 7:48 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-09 7:34 ` olehjalmar kristensen - Sun Microsystems - Trondheim Norway
2003-09-09 13:13 ` Ed Falis
2003-09-09 23:48 ` Alexander Kopilovitch
@ 2003-09-14 21:44 ` Matthew Heaney
2003-09-15 9:19 ` olehjalmar kristensen - Sun Microsystems - Trondheim Norway
2 siblings, 1 reply; 427+ messages in thread
From: Matthew Heaney @ 2003-09-14 21:44 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-14 21:44 ` Matthew Heaney
@ 2003-09-15 9:19 ` olehjalmar kristensen - Sun Microsystems - Trondheim Norway
2003-09-15 23:31 ` Matthew Heaney
0 siblings, 1 reply; 427+ messages in thread
From: olehjalmar kristensen - Sun Microsystems - Trondheim Norway @ 2003-09-15 9:19 UTC (permalink / raw)
>>>>> "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.
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-15 9:19 ` olehjalmar kristensen - Sun Microsystems - Trondheim Norway
@ 2003-09-15 23:31 ` Matthew Heaney
2003-09-16 0:26 ` Ed Falis
2003-09-16 1:46 ` Hyman Rosen
0 siblings, 2 replies; 427+ messages in thread
From: Matthew Heaney @ 2003-09-15 23:31 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-15 23:31 ` Matthew Heaney
@ 2003-09-16 0:26 ` Ed Falis
2003-09-16 7:05 ` Ole-Hjalmar Kristensen
2003-09-16 1:46 ` Hyman Rosen
1 sibling, 1 reply; 427+ messages in thread
From: Ed Falis @ 2003-09-16 0:26 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-16 0:26 ` Ed Falis
@ 2003-09-16 7:05 ` Ole-Hjalmar Kristensen
0 siblings, 0 replies; 427+ messages in thread
From: Ole-Hjalmar Kristensen @ 2003-09-16 7:05 UTC (permalink / raw)
>>>>> "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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-15 23:31 ` Matthew Heaney
2003-09-16 0:26 ` Ed Falis
@ 2003-09-16 1:46 ` Hyman Rosen
2003-09-16 2:52 ` Matthew Heaney
1 sibling, 1 reply; 427+ messages in thread
From: Hyman Rosen @ 2003-09-16 1:46 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-16 1:46 ` Hyman Rosen
@ 2003-09-16 2:52 ` Matthew Heaney
2003-09-16 17:29 ` Hyman Rosen
2003-09-17 16:56 ` Warren W. Gay VE3WWG
0 siblings, 2 replies; 427+ messages in thread
From: Matthew Heaney @ 2003-09-16 2:52 UTC (permalink / raw)
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++.
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-16 2:52 ` Matthew Heaney
@ 2003-09-16 17:29 ` Hyman Rosen
2003-09-17 0:50 ` Robert I. Eachus
2003-09-17 16:56 ` Warren W. Gay VE3WWG
1 sibling, 1 reply; 427+ messages in thread
From: Hyman Rosen @ 2003-09-16 17:29 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-16 17:29 ` Hyman Rosen
@ 2003-09-17 0:50 ` Robert I. Eachus
2003-09-17 1:25 ` Hyman Rosen
0 siblings, 1 reply; 427+ messages in thread
From: Robert I. Eachus @ 2003-09-17 0:50 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-17 0:50 ` Robert I. Eachus
@ 2003-09-17 1:25 ` Hyman Rosen
2003-09-22 14:33 ` Robert I. Eachus
0 siblings, 1 reply; 427+ messages in thread
From: Hyman Rosen @ 2003-09-17 1:25 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-17 1:25 ` Hyman Rosen
@ 2003-09-22 14:33 ` Robert I. Eachus
2003-09-22 15:26 ` Hyman Rosen
0 siblings, 1 reply; 427+ messages in thread
From: Robert I. Eachus @ 2003-09-22 14:33 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-22 14:33 ` Robert I. Eachus
@ 2003-09-22 15:26 ` Hyman Rosen
2003-09-23 8:04 ` Dmitry A. Kazakov
2003-09-23 8:19 ` Robert I. Eachus
0 siblings, 2 replies; 427+ messages in thread
From: Hyman Rosen @ 2003-09-22 15:26 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-22 15:26 ` Hyman Rosen
@ 2003-09-23 8:04 ` Dmitry A. Kazakov
2003-09-23 12:24 ` Hyman Rosen
2003-09-24 2:13 ` Matthew Heaney
2003-09-23 8:19 ` Robert I. Eachus
1 sibling, 2 replies; 427+ messages in thread
From: Dmitry A. Kazakov @ 2003-09-23 8:04 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-23 8:04 ` Dmitry A. Kazakov
@ 2003-09-23 12:24 ` Hyman Rosen
2003-09-23 13:29 ` Dmitry A. Kazakov
2003-09-24 2:13 ` Matthew Heaney
1 sibling, 1 reply; 427+ messages in thread
From: Hyman Rosen @ 2003-09-23 12:24 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-23 12:24 ` Hyman Rosen
@ 2003-09-23 13:29 ` Dmitry A. Kazakov
2003-09-23 13:38 ` Hyman Rosen
0 siblings, 1 reply; 427+ messages in thread
From: Dmitry A. Kazakov @ 2003-09-23 13:29 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-23 8:04 ` Dmitry A. Kazakov
2003-09-23 12:24 ` Hyman Rosen
@ 2003-09-24 2:13 ` Matthew Heaney
2003-09-24 8:17 ` Dmitry A. Kazakov
1 sibling, 1 reply; 427+ messages in thread
From: Matthew Heaney @ 2003-09-24 2:13 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-24 2:13 ` Matthew Heaney
@ 2003-09-24 8:17 ` Dmitry A. Kazakov
2003-09-24 11:43 ` Matthew Heaney
0 siblings, 1 reply; 427+ messages in thread
From: Dmitry A. Kazakov @ 2003-09-24 8:17 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-24 8:17 ` Dmitry A. Kazakov
@ 2003-09-24 11:43 ` Matthew Heaney
2003-09-24 12:55 ` Dmitry A. Kazakov
0 siblings, 1 reply; 427+ messages in thread
From: Matthew Heaney @ 2003-09-24 11:43 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-24 11:43 ` Matthew Heaney
@ 2003-09-24 12:55 ` Dmitry A. Kazakov
0 siblings, 0 replies; 427+ messages in thread
From: Dmitry A. Kazakov @ 2003-09-24 12:55 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-22 15:26 ` Hyman Rosen
2003-09-23 8:04 ` Dmitry A. Kazakov
@ 2003-09-23 8:19 ` Robert I. Eachus
2003-09-23 12:29 ` Hyman Rosen
1 sibling, 1 reply; 427+ messages in thread
From: Robert I. Eachus @ 2003-09-23 8:19 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-23 8:19 ` Robert I. Eachus
@ 2003-09-23 12:29 ` Hyman Rosen
2003-09-23 13:38 ` Dmitry A. Kazakov
2003-09-24 1:55 ` Matthew Heaney
0 siblings, 2 replies; 427+ messages in thread
From: Hyman Rosen @ 2003-09-23 12:29 UTC (permalink / raw)
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?
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-23 12:29 ` Hyman Rosen
@ 2003-09-23 13:38 ` Dmitry A. Kazakov
2003-09-24 1:55 ` Matthew Heaney
1 sibling, 0 replies; 427+ messages in thread
From: Dmitry A. Kazakov @ 2003-09-23 13:38 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-23 12:29 ` Hyman Rosen
2003-09-23 13:38 ` Dmitry A. Kazakov
@ 2003-09-24 1:55 ` Matthew Heaney
2003-09-24 2:38 ` Hyman Rosen
1 sibling, 1 reply; 427+ messages in thread
From: Matthew Heaney @ 2003-09-24 1:55 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-24 1:55 ` Matthew Heaney
@ 2003-09-24 2:38 ` Hyman Rosen
2003-09-24 3:52 ` Matthew Heaney
0 siblings, 1 reply; 427+ messages in thread
From: Hyman Rosen @ 2003-09-24 2:38 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-24 2:38 ` Hyman Rosen
@ 2003-09-24 3:52 ` Matthew Heaney
2003-09-24 8:28 ` Dmitry A. Kazakov
0 siblings, 1 reply; 427+ messages in thread
From: Matthew Heaney @ 2003-09-24 3:52 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-24 3:52 ` Matthew Heaney
@ 2003-09-24 8:28 ` Dmitry A. Kazakov
0 siblings, 0 replies; 427+ messages in thread
From: Dmitry A. Kazakov @ 2003-09-24 8:28 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-16 2:52 ` Matthew Heaney
2003-09-16 17:29 ` Hyman Rosen
@ 2003-09-17 16:56 ` Warren W. Gay VE3WWG
1 sibling, 0 replies; 427+ messages in thread
From: Warren W. Gay VE3WWG @ 2003-09-17 16:56 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-09 0:25 ` Hyman Rosen
` (2 preceding siblings ...)
2003-09-09 7:34 ` olehjalmar kristensen - Sun Microsystems - Trondheim Norway
@ 2003-09-10 19:47 ` Robert I. Eachus
2003-09-11 3:21 ` Hyman Rosen
2003-09-11 8:53 ` Dmitry A. Kazakov
3 siblings, 2 replies; 427+ messages in thread
From: Robert I. Eachus @ 2003-09-10 19:47 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-10 19:47 ` Robert I. Eachus
@ 2003-09-11 3:21 ` Hyman Rosen
2003-09-11 13:33 ` Robert I. Eachus
2003-09-11 8:53 ` Dmitry A. Kazakov
1 sibling, 1 reply; 427+ messages in thread
From: Hyman Rosen @ 2003-09-11 3:21 UTC (permalink / raw)
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?
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-11 3:21 ` Hyman Rosen
@ 2003-09-11 13:33 ` Robert I. Eachus
2003-09-11 14:04 ` Stephen Leake
` (2 more replies)
0 siblings, 3 replies; 427+ messages in thread
From: Robert I. Eachus @ 2003-09-11 13:33 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-11 13:33 ` Robert I. Eachus
@ 2003-09-11 14:04 ` Stephen Leake
2003-09-11 21:05 ` Robert I. Eachus
2003-09-11 17:25 ` Hyman Rosen
2003-09-12 4:00 ` Amir Yantimirov
2 siblings, 1 reply; 427+ messages in thread
From: Stephen Leake @ 2003-09-11 14:04 UTC (permalink / raw)
"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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-11 14:04 ` Stephen Leake
@ 2003-09-11 21:05 ` Robert I. Eachus
2003-09-11 22:01 ` Stephen Leake
2003-09-15 8:20 ` olehjalmar kristensen - Sun Microsystems - Trondheim Norway
0 siblings, 2 replies; 427+ messages in thread
From: Robert I. Eachus @ 2003-09-11 21:05 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-11 21:05 ` Robert I. Eachus
@ 2003-09-11 22:01 ` Stephen Leake
2003-09-11 23:04 ` Hyman Rosen
2003-09-15 8:20 ` olehjalmar kristensen - Sun Microsystems - Trondheim Norway
1 sibling, 1 reply; 427+ messages in thread
From: Stephen Leake @ 2003-09-11 22:01 UTC (permalink / raw)
"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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-11 22:01 ` Stephen Leake
@ 2003-09-11 23:04 ` Hyman Rosen
2003-09-12 4:36 ` Robert I. Eachus
0 siblings, 1 reply; 427+ messages in thread
From: Hyman Rosen @ 2003-09-11 23:04 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-11 23:04 ` Hyman Rosen
@ 2003-09-12 4:36 ` Robert I. Eachus
0 siblings, 0 replies; 427+ messages in thread
From: Robert I. Eachus @ 2003-09-12 4:36 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-11 21:05 ` Robert I. Eachus
2003-09-11 22:01 ` Stephen Leake
@ 2003-09-15 8:20 ` olehjalmar kristensen - Sun Microsystems - Trondheim Norway
2003-09-15 16:47 ` Dmytry Lavrov
2003-09-18 5:24 ` Jacob Sparre Andersen
1 sibling, 2 replies; 427+ messages in thread
From: olehjalmar kristensen - Sun Microsystems - Trondheim Norway @ 2003-09-15 8:20 UTC (permalink / raw)
>>>>> "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
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-15 8:20 ` olehjalmar kristensen - Sun Microsystems - Trondheim Norway
@ 2003-09-15 16:47 ` Dmytry Lavrov
2003-09-16 7:48 ` Dmitry A. Kazakov
2003-09-16 15:24 ` Mark A. Biggar
2003-09-18 5:24 ` Jacob Sparre Andersen
1 sibling, 2 replies; 427+ messages in thread
From: Dmytry Lavrov @ 2003-09-15 16:47 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-15 16:47 ` Dmytry Lavrov
@ 2003-09-16 7:48 ` Dmitry A. Kazakov
2003-09-16 15:24 ` Mark A. Biggar
1 sibling, 0 replies; 427+ messages in thread
From: Dmitry A. Kazakov @ 2003-09-16 7:48 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-15 16:47 ` Dmytry Lavrov
2003-09-16 7:48 ` Dmitry A. Kazakov
@ 2003-09-16 15:24 ` Mark A. Biggar
1 sibling, 0 replies; 427+ messages in thread
From: Mark A. Biggar @ 2003-09-16 15:24 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-15 8:20 ` olehjalmar kristensen - Sun Microsystems - Trondheim Norway
2003-09-15 16:47 ` Dmytry Lavrov
@ 2003-09-18 5:24 ` Jacob Sparre Andersen
2003-09-18 8:28 ` Ole-Hjalmar Kristensen
1 sibling, 1 reply; 427+ messages in thread
From: Jacob Sparre Andersen @ 2003-09-18 5:24 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-18 5:24 ` Jacob Sparre Andersen
@ 2003-09-18 8:28 ` Ole-Hjalmar Kristensen
2003-09-22 15:34 ` Robert I. Eachus
2003-09-23 10:49 ` Jacob Sparre Andersen
0 siblings, 2 replies; 427+ messages in thread
From: Ole-Hjalmar Kristensen @ 2003-09-18 8:28 UTC (permalink / raw)
>>>>> "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
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-18 8:28 ` Ole-Hjalmar Kristensen
@ 2003-09-22 15:34 ` Robert I. Eachus
2003-09-22 16:26 ` Hyman Rosen
2003-09-23 10:49 ` Jacob Sparre Andersen
1 sibling, 1 reply; 427+ messages in thread
From: Robert I. Eachus @ 2003-09-22 15:34 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-22 15:34 ` Robert I. Eachus
@ 2003-09-22 16:26 ` Hyman Rosen
2003-09-23 8:34 ` Robert I. Eachus
0 siblings, 1 reply; 427+ messages in thread
From: Hyman Rosen @ 2003-09-22 16:26 UTC (permalink / raw)
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?
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-22 16:26 ` Hyman Rosen
@ 2003-09-23 8:34 ` Robert I. Eachus
0 siblings, 0 replies; 427+ messages in thread
From: Robert I. Eachus @ 2003-09-23 8:34 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-18 8:28 ` Ole-Hjalmar Kristensen
2003-09-22 15:34 ` Robert I. Eachus
@ 2003-09-23 10:49 ` Jacob Sparre Andersen
2003-09-23 13:57 ` Dmitry A. Kazakov
2003-09-24 1:47 ` Matthew Heaney
1 sibling, 2 replies; 427+ messages in thread
From: Jacob Sparre Andersen @ 2003-09-23 10:49 UTC (permalink / raw)
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."
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-23 10:49 ` Jacob Sparre Andersen
@ 2003-09-23 13:57 ` Dmitry A. Kazakov
2003-09-24 1:47 ` Matthew Heaney
1 sibling, 0 replies; 427+ messages in thread
From: Dmitry A. Kazakov @ 2003-09-23 13:57 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-23 10:49 ` Jacob Sparre Andersen
2003-09-23 13:57 ` Dmitry A. Kazakov
@ 2003-09-24 1:47 ` Matthew Heaney
2003-09-24 2:03 ` Stephane Richard
1 sibling, 1 reply; 427+ messages in thread
From: Matthew Heaney @ 2003-09-24 1:47 UTC (permalink / raw)
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;
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-24 1:47 ` Matthew Heaney
@ 2003-09-24 2:03 ` Stephane Richard
2003-09-24 2:26 ` Matthew Heaney
2003-09-24 3:03 ` Hyman Rosen
0 siblings, 2 replies; 427+ messages in thread
From: Stephane Richard @ 2003-09-24 2:03 UTC (permalink / raw)
[-- 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
>
>
>
>
>
>
>
>
>
>
>
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-24 2:03 ` Stephane Richard
@ 2003-09-24 2:26 ` Matthew Heaney
2003-09-24 10:49 ` Stephane Richard
2003-09-24 3:03 ` Hyman Rosen
1 sibling, 1 reply; 427+ messages in thread
From: Matthew Heaney @ 2003-09-24 2:26 UTC (permalink / raw)
"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.
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-24 2:26 ` Matthew Heaney
@ 2003-09-24 10:49 ` Stephane Richard
0 siblings, 0 replies; 427+ messages in thread
From: Stephane Richard @ 2003-09-24 10:49 UTC (permalink / raw)
[-- 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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-24 2:03 ` Stephane Richard
2003-09-24 2:26 ` Matthew Heaney
@ 2003-09-24 3:03 ` Hyman Rosen
1 sibling, 0 replies; 427+ messages in thread
From: Hyman Rosen @ 2003-09-24 3:03 UTC (permalink / raw)
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;
}
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-11 13:33 ` Robert I. Eachus
2003-09-11 14:04 ` Stephen Leake
@ 2003-09-11 17:25 ` Hyman Rosen
2003-09-11 20:56 ` Chad R. Meiners
` (2 more replies)
2003-09-12 4:00 ` Amir Yantimirov
2 siblings, 3 replies; 427+ messages in thread
From: Hyman Rosen @ 2003-09-11 17:25 UTC (permalink / raw)
"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.
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-11 17:25 ` Hyman Rosen
@ 2003-09-11 20:56 ` Chad R. Meiners
2003-09-11 23:10 ` Hyman Rosen
2003-09-11 21:38 ` Alexander Kopilovitch
[not found] ` <u9v2mvgt0ih71a8i780bmos6nrik4v23l9@4ax.com>
2 siblings, 1 reply; 427+ messages in thread
From: Chad R. Meiners @ 2003-09-11 20:56 UTC (permalink / raw)
"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
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-11 20:56 ` Chad R. Meiners
@ 2003-09-11 23:10 ` Hyman Rosen
2003-09-11 23:33 ` Chad R. Meiners
2003-09-12 4:03 ` tmoran
0 siblings, 2 replies; 427+ messages in thread
From: Hyman Rosen @ 2003-09-11 23:10 UTC (permalink / raw)
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".
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-11 23:10 ` Hyman Rosen
@ 2003-09-11 23:33 ` Chad R. Meiners
2003-09-12 4:03 ` tmoran
1 sibling, 0 replies; 427+ messages in thread
From: Chad R. Meiners @ 2003-09-11 23:33 UTC (permalink / raw)
"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.
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-11 23:10 ` Hyman Rosen
2003-09-11 23:33 ` Chad R. Meiners
@ 2003-09-12 4:03 ` tmoran
2003-09-12 5:02 ` Robert I. Eachus
2003-09-12 16:02 ` Stephen Leake
1 sibling, 2 replies; 427+ messages in thread
From: tmoran @ 2003-09-12 4:03 UTC (permalink / raw)
> > 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.
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-12 4:03 ` tmoran
@ 2003-09-12 5:02 ` Robert I. Eachus
2003-09-12 20:11 ` Hyman Rosen
2003-09-12 16:02 ` Stephen Leake
1 sibling, 1 reply; 427+ messages in thread
From: Robert I. Eachus @ 2003-09-12 5:02 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-12 5:02 ` Robert I. Eachus
@ 2003-09-12 20:11 ` Hyman Rosen
2003-09-13 17:05 ` Robert I. Eachus
2003-09-15 15:09 ` Matthew Heaney
0 siblings, 2 replies; 427+ messages in thread
From: Hyman Rosen @ 2003-09-12 20:11 UTC (permalink / raw)
"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();
};
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-12 20:11 ` Hyman Rosen
@ 2003-09-13 17:05 ` Robert I. Eachus
2003-09-13 17:31 ` Stephane Richard
2003-09-14 1:38 ` Hyman Rosen
2003-09-15 15:09 ` Matthew Heaney
1 sibling, 2 replies; 427+ messages in thread
From: Robert I. Eachus @ 2003-09-13 17:05 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-13 17:05 ` Robert I. Eachus
@ 2003-09-13 17:31 ` Stephane Richard
2003-09-13 19:07 ` Robert I. Eachus
2003-09-14 1:38 ` Hyman Rosen
1 sibling, 1 reply; 427+ messages in thread
From: Stephane Richard @ 2003-09-13 17:31 UTC (permalink / raw)
[-- 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
>
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-13 17:31 ` Stephane Richard
@ 2003-09-13 19:07 ` Robert I. Eachus
0 siblings, 0 replies; 427+ messages in thread
From: Robert I. Eachus @ 2003-09-13 19:07 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-13 17:05 ` Robert I. Eachus
2003-09-13 17:31 ` Stephane Richard
@ 2003-09-14 1:38 ` Hyman Rosen
2003-09-14 19:53 ` Robert I. Eachus
2003-09-14 20:14 ` Robert C. Leif
1 sibling, 2 replies; 427+ messages in thread
From: Hyman Rosen @ 2003-09-14 1:38 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-14 1:38 ` Hyman Rosen
@ 2003-09-14 19:53 ` Robert I. Eachus
2003-09-15 8:33 ` olehjalmar kristensen - Sun Microsystems - Trondheim Norway
2003-09-14 20:14 ` Robert C. Leif
1 sibling, 1 reply; 427+ messages in thread
From: Robert I. Eachus @ 2003-09-14 19:53 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-14 19:53 ` Robert I. Eachus
@ 2003-09-15 8:33 ` olehjalmar kristensen - Sun Microsystems - Trondheim Norway
0 siblings, 0 replies; 427+ messages in thread
From: olehjalmar kristensen - Sun Microsystems - Trondheim Norway @ 2003-09-15 8:33 UTC (permalink / raw)
>>>>> "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.
^ permalink raw reply [flat|nested] 427+ messages in thread
* RE: Is the Writing on the Wall for Ada?
2003-09-14 1:38 ` Hyman Rosen
2003-09-14 19:53 ` Robert I. Eachus
@ 2003-09-14 20:14 ` Robert C. Leif
1 sibling, 0 replies; 427+ messages in thread
From: Robert C. Leif @ 2003-09-14 20:14 UTC (permalink / raw)
To: comp.lang.ada
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-12 20:11 ` Hyman Rosen
2003-09-13 17:05 ` Robert I. Eachus
@ 2003-09-15 15:09 ` Matthew Heaney
2003-09-16 4:32 ` Amir Yantimirov
1 sibling, 1 reply; 427+ messages in thread
From: Matthew Heaney @ 2003-09-15 15:09 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-15 15:09 ` Matthew Heaney
@ 2003-09-16 4:32 ` Amir Yantimirov
0 siblings, 0 replies; 427+ messages in thread
From: Amir Yantimirov @ 2003-09-16 4:32 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-12 4:03 ` tmoran
2003-09-12 5:02 ` Robert I. Eachus
@ 2003-09-12 16:02 ` Stephen Leake
2003-09-12 18:17 ` Ed Falis
2003-09-14 1:41 ` Hyman Rosen
1 sibling, 2 replies; 427+ messages in thread
From: Stephen Leake @ 2003-09-12 16:02 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-12 16:02 ` Stephen Leake
@ 2003-09-12 18:17 ` Ed Falis
2003-09-14 1:41 ` Hyman Rosen
1 sibling, 0 replies; 427+ messages in thread
From: Ed Falis @ 2003-09-12 18:17 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-12 16:02 ` Stephen Leake
2003-09-12 18:17 ` Ed Falis
@ 2003-09-14 1:41 ` Hyman Rosen
2003-09-15 17:00 ` Stephen Leake
1 sibling, 1 reply; 427+ messages in thread
From: Hyman Rosen @ 2003-09-14 1:41 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-14 1:41 ` Hyman Rosen
@ 2003-09-15 17:00 ` Stephen Leake
0 siblings, 0 replies; 427+ messages in thread
From: Stephen Leake @ 2003-09-15 17:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-11 17:25 ` Hyman Rosen
2003-09-11 20:56 ` Chad R. Meiners
@ 2003-09-11 21:38 ` Alexander Kopilovitch
2003-09-11 23:19 ` Hyman Rosen
[not found] ` <u9v2mvgt0ih71a8i780bmos6nrik4v23l9@4ax.com>
2 siblings, 1 reply; 427+ messages in thread
From: Alexander Kopilovitch @ 2003-09-11 21:38 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread[parent not found: <u9v2mvgt0ih71a8i780bmos6nrik4v23l9@4ax.com>]
* Re: Is the Writing on the Wall for Ada?
[not found] ` <u9v2mvgt0ih71a8i780bmos6nrik4v23l9@4ax.com>
@ 2003-09-15 9:33 ` Matthew Heaney
2003-09-16 7:56 ` Dmitry A. Kazakov
0 siblings, 1 reply; 427+ messages in thread
From: Matthew Heaney @ 2003-09-15 9:33 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-15 9:33 ` Matthew Heaney
@ 2003-09-16 7:56 ` Dmitry A. Kazakov
2003-09-17 1:00 ` Robert I. Eachus
0 siblings, 1 reply; 427+ messages in thread
From: Dmitry A. Kazakov @ 2003-09-16 7:56 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-16 7:56 ` Dmitry A. Kazakov
@ 2003-09-17 1:00 ` Robert I. Eachus
2003-09-17 15:42 ` Dmitry A. Kazakov
0 siblings, 1 reply; 427+ messages in thread
From: Robert I. Eachus @ 2003-09-17 1:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-17 1:00 ` Robert I. Eachus
@ 2003-09-17 15:42 ` Dmitry A. Kazakov
0 siblings, 0 replies; 427+ messages in thread
From: Dmitry A. Kazakov @ 2003-09-17 15:42 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-11 13:33 ` Robert I. Eachus
2003-09-11 14:04 ` Stephen Leake
2003-09-11 17:25 ` Hyman Rosen
@ 2003-09-12 4:00 ` Amir Yantimirov
2003-09-12 8:30 ` Dmitry A. Kazakov
2 siblings, 1 reply; 427+ messages in thread
From: Amir Yantimirov @ 2003-09-12 4:00 UTC (permalink / raw)
"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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-12 4:00 ` Amir Yantimirov
@ 2003-09-12 8:30 ` Dmitry A. Kazakov
0 siblings, 0 replies; 427+ messages in thread
From: Dmitry A. Kazakov @ 2003-09-12 8:30 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-10 19:47 ` Robert I. Eachus
2003-09-11 3:21 ` Hyman Rosen
@ 2003-09-11 8:53 ` Dmitry A. Kazakov
1 sibling, 0 replies; 427+ messages in thread
From: Dmitry A. Kazakov @ 2003-09-11 8:53 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-07 19:01 ` Robert I. Eachus
` (3 preceding siblings ...)
2003-09-08 5:09 ` Robert C. Leif
@ 2003-09-08 14:36 ` Ed Falis
2003-09-08 14:55 ` olehjalmar kristensen - Sun Microsystems - Trondheim Norway
4 siblings, 1 reply; 427+ messages in thread
From: Ed Falis @ 2003-09-08 14:36 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-08 14:36 ` Ed Falis
@ 2003-09-08 14:55 ` olehjalmar kristensen - Sun Microsystems - Trondheim Norway
2003-09-08 16:35 ` Ed Falis
2003-09-08 17:35 ` Robert Spooner
0 siblings, 2 replies; 427+ messages in thread
From: olehjalmar kristensen - Sun Microsystems - Trondheim Norway @ 2003-09-08 14:55 UTC (permalink / raw)
>>>>> "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.
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-07 11:24 ` Russ
2003-09-07 19:01 ` Robert I. Eachus
@ 2003-09-09 1:47 ` Hyman Rosen
2003-09-09 6:46 ` Russ
1 sibling, 1 reply; 427+ messages in thread
From: Hyman Rosen @ 2003-09-09 1:47 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-09 1:47 ` Hyman Rosen
@ 2003-09-09 6:46 ` Russ
2003-09-09 8:19 ` Dr. Michael Paus
2003-09-09 20:35 ` Wes Groleau
0 siblings, 2 replies; 427+ messages in thread
From: Russ @ 2003-09-09 6:46 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-09 6:46 ` Russ
@ 2003-09-09 8:19 ` Dr. Michael Paus
2003-09-11 3:03 ` Hyman Rosen
2003-09-09 20:35 ` Wes Groleau
1 sibling, 1 reply; 427+ messages in thread
From: Dr. Michael Paus @ 2003-09-09 8:19 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-09 8:19 ` Dr. Michael Paus
@ 2003-09-11 3:03 ` Hyman Rosen
0 siblings, 0 replies; 427+ messages in thread
From: Hyman Rosen @ 2003-09-11 3:03 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-09 6:46 ` Russ
2003-09-09 8:19 ` Dr. Michael Paus
@ 2003-09-09 20:35 ` Wes Groleau
1 sibling, 0 replies; 427+ messages in thread
From: Wes Groleau @ 2003-09-09 20:35 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-07 4:59 ` Russ
2003-09-07 6:02 ` Hyman Rosen
@ 2003-09-14 6:24 ` Matthew Heaney
2003-09-14 10:51 ` Frank J. Lhota
2003-09-14 22:45 ` Wes Groleau
1 sibling, 2 replies; 427+ messages in thread
From: Matthew Heaney @ 2003-09-14 6:24 UTC (permalink / raw)
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?
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-14 6:24 ` Matthew Heaney
@ 2003-09-14 10:51 ` Frank J. Lhota
2003-09-14 12:49 ` Matthew Heaney
2003-09-14 22:45 ` Wes Groleau
1 sibling, 1 reply; 427+ messages in thread
From: Frank J. Lhota @ 2003-09-14 10:51 UTC (permalink / raw)
"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.
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-14 10:51 ` Frank J. Lhota
@ 2003-09-14 12:49 ` Matthew Heaney
2003-09-14 19:59 ` Russ
0 siblings, 1 reply; 427+ messages in thread
From: Matthew Heaney @ 2003-09-14 12:49 UTC (permalink / raw)
"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;
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-14 12:49 ` Matthew Heaney
@ 2003-09-14 19:59 ` Russ
2003-09-15 0:46 ` Robert I. Eachus
0 siblings, 1 reply; 427+ messages in thread
From: Russ @ 2003-09-14 19:59 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-14 19:59 ` Russ
@ 2003-09-15 0:46 ` Robert I. Eachus
2003-09-15 7:11 ` Russ
0 siblings, 1 reply; 427+ messages in thread
From: Robert I. Eachus @ 2003-09-15 0:46 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-15 0:46 ` Robert I. Eachus
@ 2003-09-15 7:11 ` Russ
2003-09-15 17:48 ` Wes Groleau
2003-09-18 5:05 ` Jacob Sparre Andersen
0 siblings, 2 replies; 427+ messages in thread
From: Russ @ 2003-09-15 7:11 UTC (permalink / raw)
"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;
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-15 7:11 ` Russ
@ 2003-09-15 17:48 ` Wes Groleau
2003-09-17 0:29 ` Robert I. Eachus
2003-09-18 5:05 ` Jacob Sparre Andersen
1 sibling, 1 reply; 427+ messages in thread
From: Wes Groleau @ 2003-09-15 17:48 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-15 17:48 ` Wes Groleau
@ 2003-09-17 0:29 ` Robert I. Eachus
2003-09-17 4:56 ` Wes Groleau
0 siblings, 1 reply; 427+ messages in thread
From: Robert I. Eachus @ 2003-09-17 0:29 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-17 0:29 ` Robert I. Eachus
@ 2003-09-17 4:56 ` Wes Groleau
2003-09-17 19:10 ` Russ
2003-09-22 13:15 ` Robert I. Eachus
0 siblings, 2 replies; 427+ messages in thread
From: Wes Groleau @ 2003-09-17 4:56 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-17 4:56 ` Wes Groleau
@ 2003-09-17 19:10 ` Russ
2003-09-17 20:13 ` Martin Dowie
2003-09-23 10:48 ` Jacob Sparre Andersen
2003-09-22 13:15 ` Robert I. Eachus
1 sibling, 2 replies; 427+ messages in thread
From: Russ @ 2003-09-17 19:10 UTC (permalink / raw)
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).
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-17 19:10 ` Russ
@ 2003-09-17 20:13 ` Martin Dowie
2003-09-18 6:48 ` Mark A. Biggar
2003-09-23 10:48 ` Jacob Sparre Andersen
1 sibling, 1 reply; 427+ messages in thread
From: Martin Dowie @ 2003-09-17 20:13 UTC (permalink / raw)
"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.
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-17 20:13 ` Martin Dowie
@ 2003-09-18 6:48 ` Mark A. Biggar
2003-09-18 16:06 ` Martin Dowie
` (2 more replies)
0 siblings, 3 replies; 427+ messages in thread
From: Mark A. Biggar @ 2003-09-18 6:48 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-18 6:48 ` Mark A. Biggar
@ 2003-09-18 16:06 ` Martin Dowie
2003-09-18 21:00 ` Wes Groleau
2003-09-18 22:37 ` Russ
2003-09-19 20:14 ` Robert A Duff
2 siblings, 1 reply; 427+ messages in thread
From: Martin Dowie @ 2003-09-18 16:06 UTC (permalink / raw)
"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.
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-18 16:06 ` Martin Dowie
@ 2003-09-18 21:00 ` Wes Groleau
0 siblings, 0 replies; 427+ messages in thread
From: Wes Groleau @ 2003-09-18 21:00 UTC (permalink / raw)
"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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-18 6:48 ` Mark A. Biggar
2003-09-18 16:06 ` Martin Dowie
@ 2003-09-18 22:37 ` Russ
2003-09-19 20:14 ` Robert A Duff
2 siblings, 0 replies; 427+ messages in thread
From: Russ @ 2003-09-18 22:37 UTC (permalink / raw)
"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.
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-18 6:48 ` Mark A. Biggar
2003-09-18 16:06 ` Martin Dowie
2003-09-18 22:37 ` Russ
@ 2003-09-19 20:14 ` Robert A Duff
2 siblings, 0 replies; 427+ messages in thread
From: Robert A Duff @ 2003-09-19 20:14 UTC (permalink / raw)
"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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-17 19:10 ` Russ
2003-09-17 20:13 ` Martin Dowie
@ 2003-09-23 10:48 ` Jacob Sparre Andersen
2003-09-23 18:59 ` Russ
1 sibling, 1 reply; 427+ messages in thread
From: Jacob Sparre Andersen @ 2003-09-23 10:48 UTC (permalink / raw)
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."
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-23 10:48 ` Jacob Sparre Andersen
@ 2003-09-23 18:59 ` Russ
2003-09-24 14:17 ` Jacob Sparre Andersen
0 siblings, 1 reply; 427+ messages in thread
From: Russ @ 2003-09-23 18:59 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-23 18:59 ` Russ
@ 2003-09-24 14:17 ` Jacob Sparre Andersen
2003-09-25 0:42 ` Russ
0 siblings, 1 reply; 427+ messages in thread
From: Jacob Sparre Andersen @ 2003-09-24 14:17 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-24 14:17 ` Jacob Sparre Andersen
@ 2003-09-25 0:42 ` Russ
2003-09-25 8:22 ` Preben Randhol
2003-09-25 9:11 ` Vinzent 'Gadget' Hoefler
0 siblings, 2 replies; 427+ messages in thread
From: Russ @ 2003-09-25 0:42 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-25 0:42 ` Russ
@ 2003-09-25 8:22 ` Preben Randhol
2003-09-25 9:11 ` Vinzent 'Gadget' Hoefler
1 sibling, 0 replies; 427+ messages in thread
From: Preben Randhol @ 2003-09-25 8:22 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-25 0:42 ` Russ
2003-09-25 8:22 ` Preben Randhol
@ 2003-09-25 9:11 ` Vinzent 'Gadget' Hoefler
2003-09-25 15:55 ` Wes Groleau
1 sibling, 1 reply; 427+ messages in thread
From: Vinzent 'Gadget' Hoefler @ 2003-09-25 9:11 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-25 9:11 ` Vinzent 'Gadget' Hoefler
@ 2003-09-25 15:55 ` Wes Groleau
2003-09-25 16:11 ` Vinzent 'Gadget' Hoefler
2003-09-25 16:36 ` Stephen Leake
0 siblings, 2 replies; 427+ messages in thread
From: Wes Groleau @ 2003-09-25 15:55 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-25 15:55 ` Wes Groleau
@ 2003-09-25 16:11 ` Vinzent 'Gadget' Hoefler
2003-09-25 16:36 ` Stephen Leake
1 sibling, 0 replies; 427+ messages in thread
From: Vinzent 'Gadget' Hoefler @ 2003-09-25 16:11 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-25 15:55 ` Wes Groleau
2003-09-25 16:11 ` Vinzent 'Gadget' Hoefler
@ 2003-09-25 16:36 ` Stephen Leake
2003-09-25 23:41 ` Russ
1 sibling, 1 reply; 427+ messages in thread
From: Stephen Leake @ 2003-09-25 16:36 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-25 16:36 ` Stephen Leake
@ 2003-09-25 23:41 ` Russ
2003-09-26 19:45 ` Randy Brukardt
0 siblings, 1 reply; 427+ messages in thread
From: Russ @ 2003-09-25 23:41 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-25 23:41 ` Russ
@ 2003-09-26 19:45 ` Randy Brukardt
2003-09-28 8:48 ` Russ
0 siblings, 1 reply; 427+ messages in thread
From: Randy Brukardt @ 2003-09-26 19:45 UTC (permalink / raw)
"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.
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-26 19:45 ` Randy Brukardt
@ 2003-09-28 8:48 ` Russ
2003-09-28 14:32 ` Marin David Condic
2003-09-29 20:07 ` Randy Brukardt
0 siblings, 2 replies; 427+ messages in thread
From: Russ @ 2003-09-28 8:48 UTC (permalink / raw)
"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.
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-28 8:48 ` Russ
@ 2003-09-28 14:32 ` Marin David Condic
2003-09-28 23:38 ` Russ
2003-09-29 20:07 ` Randy Brukardt
1 sibling, 1 reply; 427+ messages in thread
From: Marin David Condic @ 2003-09-28 14:32 UTC (permalink / raw)
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
======================================================================
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-28 14:32 ` Marin David Condic
@ 2003-09-28 23:38 ` Russ
0 siblings, 0 replies; 427+ messages in thread
From: Russ @ 2003-09-28 23:38 UTC (permalink / raw)
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).
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-28 8:48 ` Russ
2003-09-28 14:32 ` Marin David Condic
@ 2003-09-29 20:07 ` Randy Brukardt
1 sibling, 0 replies; 427+ messages in thread
From: Randy Brukardt @ 2003-09-29 20:07 UTC (permalink / raw)
"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.
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-17 4:56 ` Wes Groleau
2003-09-17 19:10 ` Russ
@ 2003-09-22 13:15 ` Robert I. Eachus
2003-09-23 7:05 ` Russ
1 sibling, 1 reply; 427+ messages in thread
From: Robert I. Eachus @ 2003-09-22 13:15 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-22 13:15 ` Robert I. Eachus
@ 2003-09-23 7:05 ` Russ
2003-09-23 8:10 ` Robert I. Eachus
0 siblings, 1 reply; 427+ messages in thread
From: Russ @ 2003-09-23 7:05 UTC (permalink / raw)
"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.)
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-23 7:05 ` Russ
@ 2003-09-23 8:10 ` Robert I. Eachus
0 siblings, 0 replies; 427+ messages in thread
From: Robert I. Eachus @ 2003-09-23 8:10 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-15 7:11 ` Russ
2003-09-15 17:48 ` Wes Groleau
@ 2003-09-18 5:05 ` Jacob Sparre Andersen
1 sibling, 0 replies; 427+ messages in thread
From: Jacob Sparre Andersen @ 2003-09-18 5:05 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-14 6:24 ` Matthew Heaney
2003-09-14 10:51 ` Frank J. Lhota
@ 2003-09-14 22:45 ` Wes Groleau
1 sibling, 0 replies; 427+ messages in thread
From: Wes Groleau @ 2003-09-14 22:45 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-06 21:47 Warren W. Gay VE3WWG
2003-09-07 4:05 ` Wes Groleau
2003-09-07 4:59 ` Russ
@ 2003-09-07 6:19 ` Mike Silva
2003-09-07 6:58 ` David Marceau
` (14 subsequent siblings)
17 siblings, 0 replies; 427+ messages in thread
From: Mike Silva @ 2003-09-07 6:19 UTC (permalink / raw)
What about switching to COBOL to take advantage of all the cheap
leftover Y2K talent?
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-06 21:47 Warren W. Gay VE3WWG
` (2 preceding siblings ...)
2003-09-07 6:19 ` Mike Silva
@ 2003-09-07 6:58 ` David Marceau
2003-09-07 21:55 ` Warren W. Gay VE3WWG
2003-09-08 12:57 ` Marin David Condic
2003-09-07 13:23 ` chris
` (13 subsequent siblings)
17 siblings, 2 replies; 427+ messages in thread
From: David Marceau @ 2003-09-07 6:58 UTC (permalink / raw)
"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
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-07 6:58 ` David Marceau
@ 2003-09-07 21:55 ` Warren W. Gay VE3WWG
2003-09-08 12:57 ` Marin David Condic
1 sibling, 0 replies; 427+ messages in thread
From: Warren W. Gay VE3WWG @ 2003-09-07 21:55 UTC (permalink / raw)
"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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-07 6:58 ` David Marceau
2003-09-07 21:55 ` Warren W. Gay VE3WWG
@ 2003-09-08 12:57 ` Marin David Condic
1 sibling, 0 replies; 427+ messages in thread
From: Marin David Condic @ 2003-09-08 12:57 UTC (permalink / raw)
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
======================================================================
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-06 21:47 Warren W. Gay VE3WWG
` (3 preceding siblings ...)
2003-09-07 6:58 ` David Marceau
@ 2003-09-07 13:23 ` chris
2003-09-11 7:19 ` David Marceau
2003-09-14 6:34 ` Matthew Heaney
2003-09-07 14:20 ` Alexander Kopilovitch
` (12 subsequent siblings)
17 siblings, 2 replies; 427+ messages in thread
From: chris @ 2003-09-07 13:23 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-07 13:23 ` chris
@ 2003-09-11 7:19 ` David Marceau
2003-09-14 6:41 ` Matthew Heaney
2003-09-14 6:34 ` Matthew Heaney
1 sibling, 1 reply; 427+ messages in thread
From: David Marceau @ 2003-09-11 7:19 UTC (permalink / raw)
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 :)
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-07 13:23 ` chris
2003-09-11 7:19 ` David Marceau
@ 2003-09-14 6:34 ` Matthew Heaney
1 sibling, 0 replies; 427+ messages in thread
From: Matthew Heaney @ 2003-09-14 6:34 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-06 21:47 Warren W. Gay VE3WWG
` (4 preceding siblings ...)
2003-09-07 13:23 ` chris
@ 2003-09-07 14:20 ` Alexander Kopilovitch
2003-09-09 14:39 ` Dmytry Lavrov
2003-09-07 15:41 ` Ludovic Brenta
` (11 subsequent siblings)
17 siblings, 1 reply; 427+ messages in thread
From: Alexander Kopilovitch @ 2003-09-07 14:20 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-07 14:20 ` Alexander Kopilovitch
@ 2003-09-09 14:39 ` Dmytry Lavrov
0 siblings, 0 replies; 427+ messages in thread
From: Dmytry Lavrov @ 2003-09-09 14:39 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-06 21:47 Warren W. Gay VE3WWG
` (5 preceding siblings ...)
2003-09-07 14:20 ` Alexander Kopilovitch
@ 2003-09-07 15:41 ` Ludovic Brenta
2003-09-07 19:06 ` Robert I. Eachus
2003-09-10 4:43 ` John R. Strohm
2003-09-07 16:13 ` Robert C. Leif
` (10 subsequent siblings)
17 siblings, 2 replies; 427+ messages in thread
From: Ludovic Brenta @ 2003-09-07 15:41 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-07 15:41 ` Ludovic Brenta
@ 2003-09-07 19:06 ` Robert I. Eachus
2003-09-10 4:43 ` John R. Strohm
1 sibling, 0 replies; 427+ messages in thread
From: Robert I. Eachus @ 2003-09-07 19:06 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-07 15:41 ` Ludovic Brenta
2003-09-07 19:06 ` Robert I. Eachus
@ 2003-09-10 4:43 ` John R. Strohm
2003-09-10 16:35 ` Warren W. Gay VE3WWG
1 sibling, 1 reply; 427+ messages in thread
From: John R. Strohm @ 2003-09-10 4:43 UTC (permalink / raw)
"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.
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-10 4:43 ` John R. Strohm
@ 2003-09-10 16:35 ` Warren W. Gay VE3WWG
2003-09-14 6:55 ` Matthew Heaney
0 siblings, 1 reply; 427+ messages in thread
From: Warren W. Gay VE3WWG @ 2003-09-10 16:35 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-10 16:35 ` Warren W. Gay VE3WWG
@ 2003-09-14 6:55 ` Matthew Heaney
0 siblings, 0 replies; 427+ messages in thread
From: Matthew Heaney @ 2003-09-14 6:55 UTC (permalink / raw)
"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?
^ permalink raw reply [flat|nested] 427+ messages in thread
* RE: Is the Writing on the Wall for Ada?
2003-09-06 21:47 Warren W. Gay VE3WWG
` (6 preceding siblings ...)
2003-09-07 15:41 ` Ludovic Brenta
@ 2003-09-07 16:13 ` Robert C. Leif
2003-09-07 22:21 ` chris
2003-09-10 4:44 ` John R. Strohm
2003-09-08 0:34 ` Jeffrey Creem
` (9 subsequent siblings)
17 siblings, 2 replies; 427+ messages in thread
From: Robert C. Leif @ 2003-09-07 16:13 UTC (permalink / raw)
To: 'Warren W. Gay VE3WWG', comp.lang.ada
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
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-07 16:13 ` Robert C. Leif
@ 2003-09-07 22:21 ` chris
2003-09-07 23:31 ` Christopher Browne
2003-09-08 15:01 ` Robert C. Leif
2003-09-10 4:44 ` John R. Strohm
1 sibling, 2 replies; 427+ messages in thread
From: chris @ 2003-09-07 22:21 UTC (permalink / raw)
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?
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-07 22:21 ` chris
@ 2003-09-07 23:31 ` Christopher Browne
2003-09-07 23:10 ` chris
2003-09-08 15:01 ` Robert C. Leif
1 sibling, 1 reply; 427+ messages in thread
From: Christopher Browne @ 2003-09-07 23:31 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-07 23:31 ` Christopher Browne
@ 2003-09-07 23:10 ` chris
2003-09-08 2:11 ` Christopher Browne
0 siblings, 1 reply; 427+ messages in thread
From: chris @ 2003-09-07 23:10 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-07 23:10 ` chris
@ 2003-09-08 2:11 ` Christopher Browne
0 siblings, 0 replies; 427+ messages in thread
From: Christopher Browne @ 2003-09-08 2:11 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 427+ messages in thread
* RE: Is the Writing on the Wall for Ada?
2003-09-07 22:21 ` chris
2003-09-07 23:31 ` Christopher Browne
@ 2003-09-08 15:01 ` Robert C. Leif
2003-09-08 15:51 ` chris
2003-09-13 11:57 ` Michael Erdmann
1 sibling, 2 replies; 427+ messages in thread
From: Robert C. Leif @ 2003-09-08 15:01 UTC (permalink / raw)
To: 'chris', Comp. Lang. Ada
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?
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-08 15:01 ` Robert C. Leif
@ 2003-09-08 15:51 ` chris
2003-09-10 6:09 ` Robert C. Leif
2003-09-13 11:57 ` Michael Erdmann
1 sibling, 1 reply; 427+ messages in thread
From: chris @ 2003-09-08 15:51 UTC (permalink / raw)
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?
^ permalink raw reply [flat|nested] 427+ messages in thread
* RE: Is the Writing on the Wall for Ada?
2003-09-08 15:51 ` chris
@ 2003-09-10 6:09 ` Robert C. Leif
0 siblings, 0 replies; 427+ messages in thread
From: Robert C. Leif @ 2003-09-10 6:09 UTC (permalink / raw)
To: 'chris', comp.lang.ada
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?
^ permalink raw reply [flat|nested] 427+ messages in thread
* RE: Is the Writing on the Wall for Ada?
2003-09-08 15:01 ` Robert C. Leif
2003-09-08 15:51 ` chris
@ 2003-09-13 11:57 ` Michael Erdmann
1 sibling, 0 replies; 427+ messages in thread
From: Michael Erdmann @ 2003-09-13 11:57 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-07 16:13 ` Robert C. Leif
2003-09-07 22:21 ` chris
@ 2003-09-10 4:44 ` John R. Strohm
2003-09-10 14:15 ` Ludovic Brenta
1 sibling, 1 reply; 427+ messages in thread
From: John R. Strohm @ 2003-09-10 4:44 UTC (permalink / raw)
"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.
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-10 4:44 ` John R. Strohm
@ 2003-09-10 14:15 ` Ludovic Brenta
2003-09-10 16:40 ` Warren W. Gay VE3WWG
0 siblings, 1 reply; 427+ messages in thread
From: Ludovic Brenta @ 2003-09-10 14:15 UTC (permalink / raw)
"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.
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-10 14:15 ` Ludovic Brenta
@ 2003-09-10 16:40 ` Warren W. Gay VE3WWG
2003-09-11 0:01 ` Alexander Kopilovitch
0 siblings, 1 reply; 427+ messages in thread
From: Warren W. Gay VE3WWG @ 2003-09-10 16:40 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-10 16:40 ` Warren W. Gay VE3WWG
@ 2003-09-11 0:01 ` Alexander Kopilovitch
2003-09-12 12:39 ` Warren W. Gay VE3WWG
0 siblings, 1 reply; 427+ messages in thread
From: Alexander Kopilovitch @ 2003-09-11 0:01 UTC (permalink / raw)
"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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-11 0:01 ` Alexander Kopilovitch
@ 2003-09-12 12:39 ` Warren W. Gay VE3WWG
0 siblings, 0 replies; 427+ messages in thread
From: Warren W. Gay VE3WWG @ 2003-09-12 12:39 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-06 21:47 Warren W. Gay VE3WWG
` (7 preceding siblings ...)
2003-09-07 16:13 ` Robert C. Leif
@ 2003-09-08 0:34 ` Jeffrey Creem
2003-09-08 1:36 ` David Emery
` (8 subsequent siblings)
17 siblings, 0 replies; 427+ messages in thread
From: Jeffrey Creem @ 2003-09-08 0:34 UTC (permalink / raw)
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).
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-06 21:47 Warren W. Gay VE3WWG
` (8 preceding siblings ...)
2003-09-08 0:34 ` Jeffrey Creem
@ 2003-09-08 1:36 ` David Emery
2003-09-08 20:07 ` Alexander Kopilovitch
2003-09-08 3:40 ` William J. Thomas
` (7 subsequent siblings)
17 siblings, 1 reply; 427+ messages in thread
From: David Emery @ 2003-09-08 1:36 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-08 1:36 ` David Emery
@ 2003-09-08 20:07 ` Alexander Kopilovitch
0 siblings, 0 replies; 427+ messages in thread
From: Alexander Kopilovitch @ 2003-09-08 20:07 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-06 21:47 Warren W. Gay VE3WWG
` (9 preceding siblings ...)
2003-09-08 1:36 ` David Emery
@ 2003-09-08 3:40 ` William J. Thomas
2003-09-08 19:36 ` Alexander Kopilovitch
2003-09-08 8:56 ` Dmitry A. Kazakov
` (6 subsequent siblings)
17 siblings, 1 reply; 427+ messages in thread
From: William J. Thomas @ 2003-09-08 3:40 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-08 3:40 ` William J. Thomas
@ 2003-09-08 19:36 ` Alexander Kopilovitch
2003-09-08 21:14 ` Robert I. Eachus
0 siblings, 1 reply; 427+ messages in thread
From: Alexander Kopilovitch @ 2003-09-08 19:36 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-08 19:36 ` Alexander Kopilovitch
@ 2003-09-08 21:14 ` Robert I. Eachus
2003-09-09 8:28 ` Alexander Kopilovitch
0 siblings, 1 reply; 427+ messages in thread
From: Robert I. Eachus @ 2003-09-08 21:14 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-08 21:14 ` Robert I. Eachus
@ 2003-09-09 8:28 ` Alexander Kopilovitch
2003-09-10 19:09 ` Robert I. Eachus
0 siblings, 1 reply; 427+ messages in thread
From: Alexander Kopilovitch @ 2003-09-09 8:28 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-09 8:28 ` Alexander Kopilovitch
@ 2003-09-10 19:09 ` Robert I. Eachus
2003-09-11 17:07 ` Alexander Kopilovitch
0 siblings, 1 reply; 427+ messages in thread
From: Robert I. Eachus @ 2003-09-10 19:09 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-10 19:09 ` Robert I. Eachus
@ 2003-09-11 17:07 ` Alexander Kopilovitch
2003-09-11 21:36 ` Robert I. Eachus
0 siblings, 1 reply; 427+ messages in thread
From: Alexander Kopilovitch @ 2003-09-11 17:07 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-11 17:07 ` Alexander Kopilovitch
@ 2003-09-11 21:36 ` Robert I. Eachus
2003-09-13 2:23 ` Alexander Kopilovitch
0 siblings, 1 reply; 427+ messages in thread
From: Robert I. Eachus @ 2003-09-11 21:36 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-11 21:36 ` Robert I. Eachus
@ 2003-09-13 2:23 ` Alexander Kopilovitch
2003-09-15 6:58 ` Dmytry Lavrov
2003-09-15 9:17 ` Dmitry A. Kazakov
0 siblings, 2 replies; 427+ messages in thread
From: Alexander Kopilovitch @ 2003-09-13 2:23 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-13 2:23 ` Alexander Kopilovitch
@ 2003-09-15 6:58 ` Dmytry Lavrov
2003-09-15 9:17 ` Dmitry A. Kazakov
1 sibling, 0 replies; 427+ messages in thread
From: Dmytry Lavrov @ 2003-09-15 6:58 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-13 2:23 ` Alexander Kopilovitch
2003-09-15 6:58 ` Dmytry Lavrov
@ 2003-09-15 9:17 ` Dmitry A. Kazakov
1 sibling, 0 replies; 427+ messages in thread
From: Dmitry A. Kazakov @ 2003-09-15 9:17 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-06 21:47 Warren W. Gay VE3WWG
` (10 preceding siblings ...)
2003-09-08 3:40 ` William J. Thomas
@ 2003-09-08 8:56 ` Dmitry A. Kazakov
2003-09-08 19:50 ` Alexander Kopilovitch
2003-09-08 12:43 ` Marin David Condic
` (5 subsequent siblings)
17 siblings, 1 reply; 427+ messages in thread
From: Dmitry A. Kazakov @ 2003-09-08 8:56 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-08 8:56 ` Dmitry A. Kazakov
@ 2003-09-08 19:50 ` Alexander Kopilovitch
2003-09-09 8:36 ` Peter Amey
2003-09-09 8:43 ` Dmitry A. Kazakov
0 siblings, 2 replies; 427+ messages in thread
From: Alexander Kopilovitch @ 2003-09-08 19:50 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-08 19:50 ` Alexander Kopilovitch
@ 2003-09-09 8:36 ` Peter Amey
2003-09-09 8:43 ` Dmitry A. Kazakov
1 sibling, 0 replies; 427+ messages in thread
From: Peter Amey @ 2003-09-09 8:36 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-08 19:50 ` Alexander Kopilovitch
2003-09-09 8:36 ` Peter Amey
@ 2003-09-09 8:43 ` Dmitry A. Kazakov
2003-09-10 0:53 ` Alexander Kopilovitch
1 sibling, 1 reply; 427+ messages in thread
From: Dmitry A. Kazakov @ 2003-09-09 8:43 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-09 8:43 ` Dmitry A. Kazakov
@ 2003-09-10 0:53 ` Alexander Kopilovitch
2003-09-10 8:22 ` Dmitry A. Kazakov
0 siblings, 1 reply; 427+ messages in thread
From: Alexander Kopilovitch @ 2003-09-10 0:53 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-10 0:53 ` Alexander Kopilovitch
@ 2003-09-10 8:22 ` Dmitry A. Kazakov
2003-09-10 12:36 ` Marin David Condic
` (2 more replies)
0 siblings, 3 replies; 427+ messages in thread
From: Dmitry A. Kazakov @ 2003-09-10 8:22 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-10 8:22 ` Dmitry A. Kazakov
@ 2003-09-10 12:36 ` Marin David Condic
2003-09-10 13:48 ` Dmitry A. Kazakov
` (2 more replies)
2003-09-10 16:45 ` Warren W. Gay VE3WWG
2003-09-12 18:55 ` Alexander Kopilovitch
2 siblings, 3 replies; 427+ messages in thread
From: Marin David Condic @ 2003-09-10 12:36 UTC (permalink / raw)
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
======================================================================
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-10 12:36 ` Marin David Condic
@ 2003-09-10 13:48 ` Dmitry A. Kazakov
2003-09-10 16:56 ` Warren W. Gay VE3WWG
2003-09-10 20:08 ` Robert I. Eachus
2 siblings, 0 replies; 427+ messages in thread
From: Dmitry A. Kazakov @ 2003-09-10 13:48 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-10 12:36 ` Marin David Condic
2003-09-10 13:48 ` Dmitry A. Kazakov
@ 2003-09-10 16:56 ` Warren W. Gay VE3WWG
2003-09-10 20:08 ` Robert I. Eachus
2 siblings, 0 replies; 427+ messages in thread
From: Warren W. Gay VE3WWG @ 2003-09-10 16:56 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-10 12:36 ` Marin David Condic
2003-09-10 13:48 ` Dmitry A. Kazakov
2003-09-10 16:56 ` Warren W. Gay VE3WWG
@ 2003-09-10 20:08 ` Robert I. Eachus
2003-09-11 12:35 ` Marin David Condic
2 siblings, 1 reply; 427+ messages in thread
From: Robert I. Eachus @ 2003-09-10 20:08 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-10 20:08 ` Robert I. Eachus
@ 2003-09-11 12:35 ` Marin David Condic
2003-09-11 13:51 ` Robert I. Eachus
0 siblings, 1 reply; 427+ messages in thread
From: Marin David Condic @ 2003-09-11 12:35 UTC (permalink / raw)
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
======================================================================
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-11 12:35 ` Marin David Condic
@ 2003-09-11 13:51 ` Robert I. Eachus
2003-09-12 12:39 ` Marin David Condic
[not found] ` <wvbrisnulbiy.fsf@sun.com>
0 siblings, 2 replies; 427+ messages in thread
From: Robert I. Eachus @ 2003-09-11 13:51 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-11 13:51 ` Robert I. Eachus
@ 2003-09-12 12:39 ` Marin David Condic
2003-09-12 16:50 ` tmoran
` (2 more replies)
[not found] ` <wvbrisnulbiy.fsf@sun.com>
1 sibling, 3 replies; 427+ messages in thread
From: Marin David Condic @ 2003-09-12 12:39 UTC (permalink / raw)
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
======================================================================
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-12 12:39 ` Marin David Condic
@ 2003-09-12 16:50 ` tmoran
2003-09-12 16:50 ` Robert I. Eachus
2003-09-13 3:48 ` Russ
2 siblings, 0 replies; 427+ messages in thread
From: tmoran @ 2003-09-12 16:50 UTC (permalink / raw)
> 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.
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-12 12:39 ` Marin David Condic
2003-09-12 16:50 ` tmoran
@ 2003-09-12 16:50 ` Robert I. Eachus
2003-09-13 12:25 ` Marin David Condic
2003-09-13 3:48 ` Russ
2 siblings, 1 reply; 427+ messages in thread
From: Robert I. Eachus @ 2003-09-12 16:50 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-12 16:50 ` Robert I. Eachus
@ 2003-09-13 12:25 ` Marin David Condic
2003-09-13 19:16 ` Robert I. Eachus
0 siblings, 1 reply; 427+ messages in thread
From: Marin David Condic @ 2003-09-13 12:25 UTC (permalink / raw)
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
======================================================================
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-13 12:25 ` Marin David Condic
@ 2003-09-13 19:16 ` Robert I. Eachus
0 siblings, 0 replies; 427+ messages in thread
From: Robert I. Eachus @ 2003-09-13 19:16 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-12 12:39 ` Marin David Condic
2003-09-12 16:50 ` tmoran
2003-09-12 16:50 ` Robert I. Eachus
@ 2003-09-13 3:48 ` Russ
2003-09-13 12:27 ` Marin David Condic
2 siblings, 1 reply; 427+ messages in thread
From: Russ @ 2003-09-13 3:48 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-13 3:48 ` Russ
@ 2003-09-13 12:27 ` Marin David Condic
2003-09-14 22:30 ` Robert C. Leif
0 siblings, 1 reply; 427+ messages in thread
From: Marin David Condic @ 2003-09-13 12:27 UTC (permalink / raw)
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
======================================================================
^ permalink raw reply [flat|nested] 427+ messages in thread* RE: Is the Writing on the Wall for Ada?
2003-09-13 12:27 ` Marin David Condic
@ 2003-09-14 22:30 ` Robert C. Leif
2003-09-15 16:38 ` Warren W. Gay VE3WWG
0 siblings, 1 reply; 427+ messages in thread
From: Robert C. Leif @ 2003-09-14 22:30 UTC (permalink / raw)
To: 'Marin David Condic', comp.lang.ada
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
======================================================================
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-14 22:30 ` Robert C. Leif
@ 2003-09-15 16:38 ` Warren W. Gay VE3WWG
0 siblings, 0 replies; 427+ messages in thread
From: Warren W. Gay VE3WWG @ 2003-09-15 16:38 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
[parent not found: <wvbrisnulbiy.fsf@sun.com>]
* Re: Is the Writing on the Wall for Ada?
[not found] ` <wvbrisnulbiy.fsf@sun.com>
@ 2003-09-16 15:20 ` Marin David Condic
2003-09-16 16:38 ` Stephane Richard
0 siblings, 1 reply; 427+ messages in thread
From: Marin David Condic @ 2003-09-16 15:20 UTC (permalink / raw)
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
======================================================================
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-16 15:20 ` Marin David Condic
@ 2003-09-16 16:38 ` Stephane Richard
2003-09-17 12:26 ` Marin David Condic
0 siblings, 1 reply; 427+ messages in thread
From: Stephane Richard @ 2003-09-16 16:38 UTC (permalink / raw)
[-- 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
> ======================================================================
>
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-16 16:38 ` Stephane Richard
@ 2003-09-17 12:26 ` Marin David Condic
2003-09-17 12:56 ` Stephane Richard
0 siblings, 1 reply; 427+ messages in thread
From: Marin David Condic @ 2003-09-17 12:26 UTC (permalink / raw)
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
======================================================================
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-17 12:26 ` Marin David Condic
@ 2003-09-17 12:56 ` Stephane Richard
0 siblings, 0 replies; 427+ messages in thread
From: Stephane Richard @ 2003-09-17 12:56 UTC (permalink / raw)
[-- 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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-10 8:22 ` Dmitry A. Kazakov
2003-09-10 12:36 ` Marin David Condic
@ 2003-09-10 16:45 ` Warren W. Gay VE3WWG
2003-09-12 18:55 ` Alexander Kopilovitch
2 siblings, 0 replies; 427+ messages in thread
From: Warren W. Gay VE3WWG @ 2003-09-10 16:45 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-10 8:22 ` Dmitry A. Kazakov
2003-09-10 12:36 ` Marin David Condic
2003-09-10 16:45 ` Warren W. Gay VE3WWG
@ 2003-09-12 18:55 ` Alexander Kopilovitch
2003-09-15 12:38 ` Dmitry A. Kazakov
2 siblings, 1 reply; 427+ messages in thread
From: Alexander Kopilovitch @ 2003-09-12 18:55 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-12 18:55 ` Alexander Kopilovitch
@ 2003-09-15 12:38 ` Dmitry A. Kazakov
2003-09-16 1:36 ` Alexander Kopilovitch
0 siblings, 1 reply; 427+ messages in thread
From: Dmitry A. Kazakov @ 2003-09-15 12:38 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-15 12:38 ` Dmitry A. Kazakov
@ 2003-09-16 1:36 ` Alexander Kopilovitch
2003-09-16 13:12 ` Dmitry A. Kazakov
0 siblings, 1 reply; 427+ messages in thread
From: Alexander Kopilovitch @ 2003-09-16 1:36 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-16 1:36 ` Alexander Kopilovitch
@ 2003-09-16 13:12 ` Dmitry A. Kazakov
2003-09-17 3:15 ` Alexander Kopilovitch
0 siblings, 1 reply; 427+ messages in thread
From: Dmitry A. Kazakov @ 2003-09-16 13:12 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-16 13:12 ` Dmitry A. Kazakov
@ 2003-09-17 3:15 ` Alexander Kopilovitch
2003-09-17 16:08 ` Dmitry A. Kazakov
0 siblings, 1 reply; 427+ messages in thread
From: Alexander Kopilovitch @ 2003-09-17 3:15 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-17 3:15 ` Alexander Kopilovitch
@ 2003-09-17 16:08 ` Dmitry A. Kazakov
2003-09-17 22:16 ` Alexander Kopilovitch
0 siblings, 1 reply; 427+ messages in thread
From: Dmitry A. Kazakov @ 2003-09-17 16:08 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-17 16:08 ` Dmitry A. Kazakov
@ 2003-09-17 22:16 ` Alexander Kopilovitch
2003-09-18 7:56 ` Dmitry A. Kazakov
0 siblings, 1 reply; 427+ messages in thread
From: Alexander Kopilovitch @ 2003-09-17 22:16 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-17 22:16 ` Alexander Kopilovitch
@ 2003-09-18 7:56 ` Dmitry A. Kazakov
2003-09-18 18:46 ` Alexander Kopilovitch
0 siblings, 1 reply; 427+ messages in thread
From: Dmitry A. Kazakov @ 2003-09-18 7:56 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-18 7:56 ` Dmitry A. Kazakov
@ 2003-09-18 18:46 ` Alexander Kopilovitch
2003-09-19 8:17 ` Dmitry A. Kazakov
0 siblings, 1 reply; 427+ messages in thread
From: Alexander Kopilovitch @ 2003-09-18 18:46 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-18 18:46 ` Alexander Kopilovitch
@ 2003-09-19 8:17 ` Dmitry A. Kazakov
2003-09-20 1:44 ` Alexander Kopilovitch
0 siblings, 1 reply; 427+ messages in thread
From: Dmitry A. Kazakov @ 2003-09-19 8:17 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-19 8:17 ` Dmitry A. Kazakov
@ 2003-09-20 1:44 ` Alexander Kopilovitch
2003-09-22 11:48 ` Dmitry A. Kazakov
0 siblings, 1 reply; 427+ messages in thread
From: Alexander Kopilovitch @ 2003-09-20 1:44 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-20 1:44 ` Alexander Kopilovitch
@ 2003-09-22 11:48 ` Dmitry A. Kazakov
2003-09-22 13:38 ` Frank J. Lhota
2003-09-23 2:05 ` Alexander Kopilovitch
0 siblings, 2 replies; 427+ messages in thread
From: Dmitry A. Kazakov @ 2003-09-22 11:48 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-22 11:48 ` Dmitry A. Kazakov
@ 2003-09-22 13:38 ` Frank J. Lhota
2003-09-22 14:22 ` Dmitry A. Kazakov
2003-09-23 2:05 ` Alexander Kopilovitch
1 sibling, 1 reply; 427+ messages in thread
From: Frank J. Lhota @ 2003-09-22 13:38 UTC (permalink / raw)
"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.
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-22 13:38 ` Frank J. Lhota
@ 2003-09-22 14:22 ` Dmitry A. Kazakov
2003-09-22 16:45 ` Steffen Huber
` (3 more replies)
0 siblings, 4 replies; 427+ messages in thread
From: Dmitry A. Kazakov @ 2003-09-22 14:22 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-22 14:22 ` Dmitry A. Kazakov
@ 2003-09-22 16:45 ` Steffen Huber
2003-09-23 8:15 ` Dmitry A. Kazakov
2003-09-22 18:24 ` Frank J. Lhota
` (2 subsequent siblings)
3 siblings, 1 reply; 427+ messages in thread
From: Steffen Huber @ 2003-09-22 16:45 UTC (permalink / raw)
"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/
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-22 16:45 ` Steffen Huber
@ 2003-09-23 8:15 ` Dmitry A. Kazakov
2003-09-23 16:00 ` Steffen Huber
0 siblings, 1 reply; 427+ messages in thread
From: Dmitry A. Kazakov @ 2003-09-23 8:15 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-23 8:15 ` Dmitry A. Kazakov
@ 2003-09-23 16:00 ` Steffen Huber
2003-09-24 8:42 ` Dmitry A. Kazakov
0 siblings, 1 reply; 427+ messages in thread
From: Steffen Huber @ 2003-09-23 16:00 UTC (permalink / raw)
"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/
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-23 16:00 ` Steffen Huber
@ 2003-09-24 8:42 ` Dmitry A. Kazakov
2003-09-24 14:15 ` Steffen Huber
0 siblings, 1 reply; 427+ messages in thread
From: Dmitry A. Kazakov @ 2003-09-24 8:42 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-22 14:22 ` Dmitry A. Kazakov
2003-09-22 16:45 ` Steffen Huber
@ 2003-09-22 18:24 ` Frank J. Lhota
2003-09-23 4:05 ` Amir Yantimirov
2003-09-23 8:32 ` Dmitry A. Kazakov
2003-09-23 7:17 ` Russ
2003-09-23 16:06 ` Chad R. Meiners
3 siblings, 2 replies; 427+ messages in thread
From: Frank J. Lhota @ 2003-09-22 18:24 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-22 18:24 ` Frank J. Lhota
@ 2003-09-23 4:05 ` Amir Yantimirov
2003-09-25 17:13 ` Warren W. Gay VE3WWG
2003-09-23 8:32 ` Dmitry A. Kazakov
1 sibling, 1 reply; 427+ messages in thread
From: Amir Yantimirov @ 2003-09-23 4:05 UTC (permalink / raw)
"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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-23 4:05 ` Amir Yantimirov
@ 2003-09-25 17:13 ` Warren W. Gay VE3WWG
0 siblings, 0 replies; 427+ messages in thread
From: Warren W. Gay VE3WWG @ 2003-09-25 17:13 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-22 18:24 ` Frank J. Lhota
2003-09-23 4:05 ` Amir Yantimirov
@ 2003-09-23 8:32 ` Dmitry A. Kazakov
1 sibling, 0 replies; 427+ messages in thread
From: Dmitry A. Kazakov @ 2003-09-23 8:32 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-22 14:22 ` Dmitry A. Kazakov
2003-09-22 16:45 ` Steffen Huber
2003-09-22 18:24 ` Frank J. Lhota
@ 2003-09-23 7:17 ` Russ
2003-09-24 2:17 ` Alexander Kopilovitch
2003-09-23 16:06 ` Chad R. Meiners
3 siblings, 1 reply; 427+ messages in thread
From: Russ @ 2003-09-23 7:17 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-23 7:17 ` Russ
@ 2003-09-24 2:17 ` Alexander Kopilovitch
0 siblings, 0 replies; 427+ messages in thread
From: Alexander Kopilovitch @ 2003-09-24 2:17 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-22 14:22 ` Dmitry A. Kazakov
` (2 preceding siblings ...)
2003-09-23 7:17 ` Russ
@ 2003-09-23 16:06 ` Chad R. Meiners
2003-09-23 16:57 ` Hyman Rosen
3 siblings, 1 reply; 427+ messages in thread
From: Chad R. Meiners @ 2003-09-23 16:06 UTC (permalink / raw)
"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
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-23 16:06 ` Chad R. Meiners
@ 2003-09-23 16:57 ` Hyman Rosen
2003-09-25 17:16 ` Warren W. Gay VE3WWG
0 siblings, 1 reply; 427+ messages in thread
From: Hyman Rosen @ 2003-09-23 16:57 UTC (permalink / raw)
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 :-)
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-23 16:57 ` Hyman Rosen
@ 2003-09-25 17:16 ` Warren W. Gay VE3WWG
0 siblings, 0 replies; 427+ messages in thread
From: Warren W. Gay VE3WWG @ 2003-09-25 17:16 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-22 11:48 ` Dmitry A. Kazakov
2003-09-22 13:38 ` Frank J. Lhota
@ 2003-09-23 2:05 ` Alexander Kopilovitch
2003-09-23 9:14 ` Dmitry A. Kazakov
1 sibling, 1 reply; 427+ messages in thread
From: Alexander Kopilovitch @ 2003-09-23 2:05 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-23 2:05 ` Alexander Kopilovitch
@ 2003-09-23 9:14 ` Dmitry A. Kazakov
2003-09-24 2:52 ` Alexander Kopilovitch
0 siblings, 1 reply; 427+ messages in thread
From: Dmitry A. Kazakov @ 2003-09-23 9:14 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-23 9:14 ` Dmitry A. Kazakov
@ 2003-09-24 2:52 ` Alexander Kopilovitch
2003-09-24 9:45 ` Dmitry A. Kazakov
0 siblings, 1 reply; 427+ messages in thread
From: Alexander Kopilovitch @ 2003-09-24 2:52 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-24 2:52 ` Alexander Kopilovitch
@ 2003-09-24 9:45 ` Dmitry A. Kazakov
2003-09-25 2:51 ` Alexander Kopilovitch
0 siblings, 1 reply; 427+ messages in thread
From: Dmitry A. Kazakov @ 2003-09-24 9:45 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-24 9:45 ` Dmitry A. Kazakov
@ 2003-09-25 2:51 ` Alexander Kopilovitch
2003-09-25 9:07 ` Dmitry A. Kazakov
0 siblings, 1 reply; 427+ messages in thread
From: Alexander Kopilovitch @ 2003-09-25 2:51 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-25 2:51 ` Alexander Kopilovitch
@ 2003-09-25 9:07 ` Dmitry A. Kazakov
2003-09-25 21:12 ` Alexander Kopilovitch
0 siblings, 1 reply; 427+ messages in thread
From: Dmitry A. Kazakov @ 2003-09-25 9:07 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-25 9:07 ` Dmitry A. Kazakov
@ 2003-09-25 21:12 ` Alexander Kopilovitch
2003-09-26 8:48 ` Dmitry A. Kazakov
0 siblings, 1 reply; 427+ messages in thread
From: Alexander Kopilovitch @ 2003-09-25 21:12 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-25 21:12 ` Alexander Kopilovitch
@ 2003-09-26 8:48 ` Dmitry A. Kazakov
2003-09-26 17:22 ` Alexander Kopilovitch
0 siblings, 1 reply; 427+ messages in thread
From: Dmitry A. Kazakov @ 2003-09-26 8:48 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-26 8:48 ` Dmitry A. Kazakov
@ 2003-09-26 17:22 ` Alexander Kopilovitch
2003-09-29 8:43 ` Dmitry A. Kazakov
0 siblings, 1 reply; 427+ messages in thread
From: Alexander Kopilovitch @ 2003-09-26 17:22 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-26 17:22 ` Alexander Kopilovitch
@ 2003-09-29 8:43 ` Dmitry A. Kazakov
0 siblings, 0 replies; 427+ messages in thread
From: Dmitry A. Kazakov @ 2003-09-29 8:43 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-06 21:47 Warren W. Gay VE3WWG
` (11 preceding siblings ...)
2003-09-08 8:56 ` Dmitry A. Kazakov
@ 2003-09-08 12:43 ` Marin David Condic
2003-09-08 19:15 ` Jacob Sparre Andersen
` (4 subsequent siblings)
17 siblings, 0 replies; 427+ messages in thread
From: Marin David Condic @ 2003-09-08 12:43 UTC (permalink / raw)
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
======================================================================
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-06 21:47 Warren W. Gay VE3WWG
` (12 preceding siblings ...)
2003-09-08 12:43 ` Marin David Condic
@ 2003-09-08 19:15 ` Jacob Sparre Andersen
2003-09-09 16:48 ` Warren W. Gay VE3WWG
2003-09-08 19:58 ` Gautier Write-only
` (3 subsequent siblings)
17 siblings, 1 reply; 427+ messages in thread
From: Jacob Sparre Andersen @ 2003-09-08 19:15 UTC (permalink / raw)
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...
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-08 19:15 ` Jacob Sparre Andersen
@ 2003-09-09 16:48 ` Warren W. Gay VE3WWG
2003-09-09 21:16 ` Ed Falis
2003-09-10 12:46 ` Marin David Condic
0 siblings, 2 replies; 427+ messages in thread
From: Warren W. Gay VE3WWG @ 2003-09-09 16:48 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-09 16:48 ` Warren W. Gay VE3WWG
@ 2003-09-09 21:16 ` Ed Falis
2003-09-10 16:58 ` Warren W. Gay VE3WWG
2003-09-10 12:46 ` Marin David Condic
1 sibling, 1 reply; 427+ messages in thread
From: Ed Falis @ 2003-09-09 21:16 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-09 21:16 ` Ed Falis
@ 2003-09-10 16:58 ` Warren W. Gay VE3WWG
0 siblings, 0 replies; 427+ messages in thread
From: Warren W. Gay VE3WWG @ 2003-09-10 16:58 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-09 16:48 ` Warren W. Gay VE3WWG
2003-09-09 21:16 ` Ed Falis
@ 2003-09-10 12:46 ` Marin David Condic
1 sibling, 0 replies; 427+ messages in thread
From: Marin David Condic @ 2003-09-10 12:46 UTC (permalink / raw)
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
======================================================================
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-06 21:47 Warren W. Gay VE3WWG
` (13 preceding siblings ...)
2003-09-08 19:15 ` Jacob Sparre Andersen
@ 2003-09-08 19:58 ` Gautier Write-only
2003-09-13 17:52 ` Stephane Richard
` (2 subsequent siblings)
17 siblings, 0 replies; 427+ messages in thread
From: Gautier Write-only @ 2003-09-08 19:58 UTC (permalink / raw)
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!
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-06 21:47 Warren W. Gay VE3WWG
` (14 preceding siblings ...)
2003-09-08 19:58 ` Gautier Write-only
@ 2003-09-13 17:52 ` Stephane Richard
2003-09-15 16:31 ` Warren W. Gay VE3WWG
2003-09-15 16:34 ` chris
2003-09-14 17:03 ` JM
2003-09-25 18:04 ` Jan Kroken
17 siblings, 2 replies; 427+ messages in thread
From: Stephane Richard @ 2003-09-13 17:52 UTC (permalink / raw)
[-- 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
>
>
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-13 17:52 ` Stephane Richard
@ 2003-09-15 16:31 ` Warren W. Gay VE3WWG
2003-09-16 0:22 ` Ed Falis
2003-09-16 0:38 ` Stephane Richard
2003-09-15 16:34 ` chris
1 sibling, 2 replies; 427+ messages in thread
From: Warren W. Gay VE3WWG @ 2003-09-15 16:31 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-15 16:31 ` Warren W. Gay VE3WWG
@ 2003-09-16 0:22 ` Ed Falis
2003-09-16 0:38 ` Stephane Richard
1 sibling, 0 replies; 427+ messages in thread
From: Ed Falis @ 2003-09-16 0:22 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-15 16:31 ` Warren W. Gay VE3WWG
2003-09-16 0:22 ` Ed Falis
@ 2003-09-16 0:38 ` Stephane Richard
1 sibling, 0 replies; 427+ messages in thread
From: Stephane Richard @ 2003-09-16 0:38 UTC (permalink / raw)
[-- 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
>
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-13 17:52 ` Stephane Richard
2003-09-15 16:31 ` Warren W. Gay VE3WWG
@ 2003-09-15 16:34 ` chris
1 sibling, 0 replies; 427+ messages in thread
From: chris @ 2003-09-15 16:34 UTC (permalink / raw)
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).
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-06 21:47 Warren W. Gay VE3WWG
` (15 preceding siblings ...)
2003-09-13 17:52 ` Stephane Richard
@ 2003-09-14 17:03 ` JM
2003-09-14 21:05 ` Russ
` (2 more replies)
2003-09-25 18:04 ` Jan Kroken
17 siblings, 3 replies; 427+ messages in thread
From: JM @ 2003-09-14 17:03 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-14 17:03 ` JM
@ 2003-09-14 21:05 ` Russ
2003-09-14 21:37 ` Wes Groleau
2003-09-15 16:34 ` Warren W. Gay VE3WWG
2 siblings, 0 replies; 427+ messages in thread
From: Russ @ 2003-09-14 21:05 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-14 17:03 ` JM
2003-09-14 21:05 ` Russ
@ 2003-09-14 21:37 ` Wes Groleau
2003-09-15 16:34 ` Warren W. Gay VE3WWG
2 siblings, 0 replies; 427+ messages in thread
From: Wes Groleau @ 2003-09-14 21:37 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-14 17:03 ` JM
2003-09-14 21:05 ` Russ
2003-09-14 21:37 ` Wes Groleau
@ 2003-09-15 16:34 ` Warren W. Gay VE3WWG
2003-09-15 18:07 ` Dmytry Lavrov
2 siblings, 1 reply; 427+ messages in thread
From: Warren W. Gay VE3WWG @ 2003-09-15 16:34 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-15 16:34 ` Warren W. Gay VE3WWG
@ 2003-09-15 18:07 ` Dmytry Lavrov
0 siblings, 0 replies; 427+ messages in thread
From: Dmytry Lavrov @ 2003-09-15 18:07 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-06 21:47 Warren W. Gay VE3WWG
` (16 preceding siblings ...)
2003-09-14 17:03 ` JM
@ 2003-09-25 18:04 ` Jan Kroken
2003-09-25 21:50 ` Stephen Leake
` (2 more replies)
17 siblings, 3 replies; 427+ messages in thread
From: Jan Kroken @ 2003-09-25 18:04 UTC (permalink / raw)
"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
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-25 18:04 ` Jan Kroken
@ 2003-09-25 21:50 ` Stephen Leake
2003-09-25 22:06 ` Hyman Rosen
2003-09-26 0:05 ` Matthew Heaney
2003-09-26 12:52 ` Marin David Condic
2 siblings, 1 reply; 427+ messages in thread
From: Stephen Leake @ 2003-09-25 21:50 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-25 21:50 ` Stephen Leake
@ 2003-09-25 22:06 ` Hyman Rosen
2003-09-26 1:53 ` Robert I. Eachus
2003-09-26 3:21 ` Alexander Kopilovitch
0 siblings, 2 replies; 427+ messages in thread
From: Hyman Rosen @ 2003-09-25 22:06 UTC (permalink / raw)
Stephen Leake wrote:
> Ada.Strings.Unbounded. Way better than C++ Strings.
How?
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-25 22:06 ` Hyman Rosen
@ 2003-09-26 1:53 ` Robert I. Eachus
2003-09-26 2:31 ` Matthew Heaney
2003-09-26 3:21 ` Alexander Kopilovitch
1 sibling, 1 reply; 427+ messages in thread
From: Robert I. Eachus @ 2003-09-26 1:53 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-26 1:53 ` Robert I. Eachus
@ 2003-09-26 2:31 ` Matthew Heaney
2003-09-26 5:40 ` Pascal Obry
` (3 more replies)
0 siblings, 4 replies; 427+ messages in thread
From: Matthew Heaney @ 2003-09-26 2:31 UTC (permalink / raw)
"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.
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-26 2:31 ` Matthew Heaney
@ 2003-09-26 5:40 ` Pascal Obry
2003-09-26 8:51 ` Dmitry A. Kazakov
` (2 subsequent siblings)
3 siblings, 0 replies; 427+ messages in thread
From: Pascal Obry @ 2003-09-26 5:40 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-26 2:31 ` Matthew Heaney
2003-09-26 5:40 ` Pascal Obry
@ 2003-09-26 8:51 ` Dmitry A. Kazakov
2003-09-26 10:47 ` Matthew Heaney
2003-09-26 17:41 ` Stephen Leake
2003-09-29 2:46 ` Craig Carey
3 siblings, 1 reply; 427+ messages in thread
From: Dmitry A. Kazakov @ 2003-09-26 8:51 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-26 8:51 ` Dmitry A. Kazakov
@ 2003-09-26 10:47 ` Matthew Heaney
2003-09-26 10:56 ` Stephane Richard
0 siblings, 1 reply; 427+ messages in thread
From: Matthew Heaney @ 2003-09-26 10:47 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-26 10:47 ` Matthew Heaney
@ 2003-09-26 10:56 ` Stephane Richard
2003-09-26 13:00 ` Hyman Rosen
0 siblings, 1 reply; 427+ messages in thread
From: Stephane Richard @ 2003-09-26 10:56 UTC (permalink / raw)
[-- 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.
>
>
>
>
>
>
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-26 10:56 ` Stephane Richard
@ 2003-09-26 13:00 ` Hyman Rosen
2003-09-26 17:43 ` Stephen Leake
0 siblings, 1 reply; 427+ messages in thread
From: Hyman Rosen @ 2003-09-26 13:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-26 13:00 ` Hyman Rosen
@ 2003-09-26 17:43 ` Stephen Leake
2003-09-26 19:07 ` Hyman Rosen
2003-09-26 22:27 ` Matthew Heaney
0 siblings, 2 replies; 427+ messages in thread
From: Stephen Leake @ 2003-09-26 17:43 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-26 2:31 ` Matthew Heaney
2003-09-26 5:40 ` Pascal Obry
2003-09-26 8:51 ` Dmitry A. Kazakov
@ 2003-09-26 17:41 ` Stephen Leake
2003-09-26 19:32 ` Randy Brukardt
2003-09-29 2:46 ` Craig Carey
3 siblings, 1 reply; 427+ messages in thread
From: Stephen Leake @ 2003-09-26 17:41 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-26 17:41 ` Stephen Leake
@ 2003-09-26 19:32 ` Randy Brukardt
0 siblings, 0 replies; 427+ messages in thread
From: Randy Brukardt @ 2003-09-26 19:32 UTC (permalink / raw)
"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.
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-26 2:31 ` Matthew Heaney
` (2 preceding siblings ...)
2003-09-26 17:41 ` Stephen Leake
@ 2003-09-29 2:46 ` Craig Carey
2003-09-30 2:20 ` Robert I. Eachus
3 siblings, 1 reply; 427+ messages in thread
From: Craig Carey @ 2003-09-29 2:46 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-29 2:46 ` Craig Carey
@ 2003-09-30 2:20 ` Robert I. Eachus
2003-09-30 3:24 ` tmoran
` (3 more replies)
0 siblings, 4 replies; 427+ messages in thread
From: Robert I. Eachus @ 2003-09-30 2:20 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-30 2:20 ` Robert I. Eachus
@ 2003-09-30 3:24 ` tmoran
2003-09-30 12:33 ` (see below)
2003-09-30 20:50 ` Robert I. Eachus
2003-09-30 7:01 ` Preben Randhol
` (2 subsequent siblings)
3 siblings, 2 replies; 427+ messages in thread
From: tmoran @ 2003-09-30 3:24 UTC (permalink / raw)
>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?
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-30 3:24 ` tmoran
@ 2003-09-30 12:33 ` (see below)
2003-09-30 20:50 ` Robert I. Eachus
1 sibling, 0 replies; 427+ messages in thread
From: (see below) @ 2003-09-30 12:33 UTC (permalink / raw)
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 (":" => "")
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-30 3:24 ` tmoran
2003-09-30 12:33 ` (see below)
@ 2003-09-30 20:50 ` Robert I. Eachus
2003-09-30 22:13 ` Larry Kilgallen
1 sibling, 1 reply; 427+ messages in thread
From: Robert I. Eachus @ 2003-09-30 20:50 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-30 20:50 ` Robert I. Eachus
@ 2003-09-30 22:13 ` Larry Kilgallen
0 siblings, 0 replies; 427+ messages in thread
From: Larry Kilgallen @ 2003-09-30 22:13 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-30 2:20 ` Robert I. Eachus
2003-09-30 3:24 ` tmoran
@ 2003-09-30 7:01 ` Preben Randhol
2003-09-30 12:30 ` Marin David Condic
2003-09-30 12:21 ` Marin David Condic
2003-09-30 20:42 ` Jeffrey Carter
3 siblings, 1 reply; 427+ messages in thread
From: Preben Randhol @ 2003-09-30 7:01 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-30 7:01 ` Preben Randhol
@ 2003-09-30 12:30 ` Marin David Condic
2003-09-30 12:35 ` Larry Kilgallen
` (5 more replies)
0 siblings, 6 replies; 427+ messages in thread
From: Marin David Condic @ 2003-09-30 12:30 UTC (permalink / raw)
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
======================================================================
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-30 12:30 ` Marin David Condic
@ 2003-09-30 12:35 ` Larry Kilgallen
2003-09-30 13:02 ` Marin David Condic
2003-09-30 14:28 ` Jean-Pierre Rosen
` (4 subsequent siblings)
5 siblings, 1 reply; 427+ messages in thread
From: Larry Kilgallen @ 2003-09-30 12:35 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-30 12:35 ` Larry Kilgallen
@ 2003-09-30 13:02 ` Marin David Condic
0 siblings, 0 replies; 427+ messages in thread
From: Marin David Condic @ 2003-09-30 13:02 UTC (permalink / raw)
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
======================================================================
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-30 12:30 ` Marin David Condic
2003-09-30 12:35 ` Larry Kilgallen
@ 2003-09-30 14:28 ` Jean-Pierre Rosen
2003-09-30 21:01 ` Robert I. Eachus
2003-10-01 12:17 ` Marin David Condic
2003-09-30 14:58 ` Mark A. Biggar
` (3 subsequent siblings)
5 siblings, 2 replies; 427+ messages in thread
From: Jean-Pierre Rosen @ 2003-09-30 14:28 UTC (permalink / raw)
[-- 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
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-30 14:28 ` Jean-Pierre Rosen
@ 2003-09-30 21:01 ` Robert I. Eachus
2003-09-30 22:01 ` Preben Randhol
` (2 more replies)
2003-10-01 12:17 ` Marin David Condic
1 sibling, 3 replies; 427+ messages in thread
From: Robert I. Eachus @ 2003-09-30 21:01 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-30 21:01 ` Robert I. Eachus
@ 2003-09-30 22:01 ` Preben Randhol
2003-10-01 12:47 ` Frank J. Lhota
2003-09-30 23:46 ` Wes Groleau
2003-10-01 12:28 ` Marin David Condic
2 siblings, 1 reply; 427+ messages in thread
From: Preben Randhol @ 2003-09-30 22:01 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-30 22:01 ` Preben Randhol
@ 2003-10-01 12:47 ` Frank J. Lhota
2003-10-01 17:36 ` Robert I. Eachus
0 siblings, 1 reply; 427+ messages in thread
From: Frank J. Lhota @ 2003-10-01 12:47 UTC (permalink / raw)
"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.
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-10-01 12:47 ` Frank J. Lhota
@ 2003-10-01 17:36 ` Robert I. Eachus
2003-10-01 20:15 ` Frank J. Lhota
2003-10-02 7:29 ` Dmitry A. Kazakov
0 siblings, 2 replies; 427+ messages in thread
From: Robert I. Eachus @ 2003-10-01 17:36 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-10-01 17:36 ` Robert I. Eachus
@ 2003-10-01 20:15 ` Frank J. Lhota
2003-10-02 7:29 ` Dmitry A. Kazakov
1 sibling, 0 replies; 427+ messages in thread
From: Frank J. Lhota @ 2003-10-01 20:15 UTC (permalink / raw)
"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!
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-10-01 17:36 ` Robert I. Eachus
2003-10-01 20:15 ` Frank J. Lhota
@ 2003-10-02 7:29 ` Dmitry A. Kazakov
2003-10-02 19:48 ` Robert I. Eachus
1 sibling, 1 reply; 427+ messages in thread
From: Dmitry A. Kazakov @ 2003-10-02 7:29 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-10-02 7:29 ` Dmitry A. Kazakov
@ 2003-10-02 19:48 ` Robert I. Eachus
2003-10-03 20:30 ` Dmitry A. Kazakov
0 siblings, 1 reply; 427+ messages in thread
From: Robert I. Eachus @ 2003-10-02 19:48 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-10-02 19:48 ` Robert I. Eachus
@ 2003-10-03 20:30 ` Dmitry A. Kazakov
2003-10-03 21:42 ` Wes Groleau
2003-10-04 1:43 ` Robert I. Eachus
0 siblings, 2 replies; 427+ messages in thread
From: Dmitry A. Kazakov @ 2003-10-03 20:30 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-10-03 20:30 ` Dmitry A. Kazakov
@ 2003-10-03 21:42 ` Wes Groleau
2003-10-04 8:33 ` Dmitry A. Kazakov
2003-10-04 1:43 ` Robert I. Eachus
1 sibling, 1 reply; 427+ messages in thread
From: Wes Groleau @ 2003-10-03 21:42 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-10-03 21:42 ` Wes Groleau
@ 2003-10-04 8:33 ` Dmitry A. Kazakov
2003-10-05 0:49 ` Wes Groleau
2003-10-16 0:59 ` Randy Brukardt
0 siblings, 2 replies; 427+ messages in thread
From: Dmitry A. Kazakov @ 2003-10-04 8:33 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-10-04 8:33 ` Dmitry A. Kazakov
@ 2003-10-05 0:49 ` Wes Groleau
2003-10-06 12:25 ` Dmitry A. Kazakov
2003-10-16 0:59 ` Randy Brukardt
1 sibling, 1 reply; 427+ messages in thread
From: Wes Groleau @ 2003-10-05 0:49 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-10-05 0:49 ` Wes Groleau
@ 2003-10-06 12:25 ` Dmitry A. Kazakov
2003-10-06 22:57 ` Wes Groleau
0 siblings, 1 reply; 427+ messages in thread
From: Dmitry A. Kazakov @ 2003-10-06 12:25 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-10-06 12:25 ` Dmitry A. Kazakov
@ 2003-10-06 22:57 ` Wes Groleau
2003-10-07 8:21 ` Dmitry A. Kazakov
0 siblings, 1 reply; 427+ messages in thread
From: Wes Groleau @ 2003-10-06 22:57 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-10-06 22:57 ` Wes Groleau
@ 2003-10-07 8:21 ` Dmitry A. Kazakov
0 siblings, 0 replies; 427+ messages in thread
From: Dmitry A. Kazakov @ 2003-10-07 8:21 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-10-04 8:33 ` Dmitry A. Kazakov
2003-10-05 0:49 ` Wes Groleau
@ 2003-10-16 0:59 ` Randy Brukardt
2003-10-16 7:27 ` Dmitry A. Kazakov
1 sibling, 1 reply; 427+ messages in thread
From: Randy Brukardt @ 2003-10-16 0:59 UTC (permalink / raw)
"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.
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-10-16 0:59 ` Randy Brukardt
@ 2003-10-16 7:27 ` Dmitry A. Kazakov
0 siblings, 0 replies; 427+ messages in thread
From: Dmitry A. Kazakov @ 2003-10-16 7:27 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-10-03 20:30 ` Dmitry A. Kazakov
2003-10-03 21:42 ` Wes Groleau
@ 2003-10-04 1:43 ` Robert I. Eachus
2003-10-04 8:33 ` Dmitry A. Kazakov
1 sibling, 1 reply; 427+ messages in thread
From: Robert I. Eachus @ 2003-10-04 1:43 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-10-04 1:43 ` Robert I. Eachus
@ 2003-10-04 8:33 ` Dmitry A. Kazakov
2003-10-04 11:28 ` Georg Bauhaus
2003-10-04 13:48 ` Robert I. Eachus
0 siblings, 2 replies; 427+ messages in thread
From: Dmitry A. Kazakov @ 2003-10-04 8:33 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-10-04 8:33 ` Dmitry A. Kazakov
@ 2003-10-04 11:28 ` Georg Bauhaus
2003-10-06 12:07 ` Dmitry A. Kazakov
2003-10-04 13:48 ` Robert I. Eachus
1 sibling, 1 reply; 427+ messages in thread
From: Georg Bauhaus @ 2003-10-04 11:28 UTC (permalink / raw)
>>>>> "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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-10-04 11:28 ` Georg Bauhaus
@ 2003-10-06 12:07 ` Dmitry A. Kazakov
2003-10-08 18:05 ` Georg Bauhaus
0 siblings, 1 reply; 427+ messages in thread
From: Dmitry A. Kazakov @ 2003-10-06 12:07 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-10-04 8:33 ` Dmitry A. Kazakov
2003-10-04 11:28 ` Georg Bauhaus
@ 2003-10-04 13:48 ` Robert I. Eachus
2003-10-06 12:14 ` Dmitry A. Kazakov
1 sibling, 1 reply; 427+ messages in thread
From: Robert I. Eachus @ 2003-10-04 13:48 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-10-04 13:48 ` Robert I. Eachus
@ 2003-10-06 12:14 ` Dmitry A. Kazakov
2003-10-08 14:16 ` Robert I. Eachus
0 siblings, 1 reply; 427+ messages in thread
From: Dmitry A. Kazakov @ 2003-10-06 12:14 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-10-06 12:14 ` Dmitry A. Kazakov
@ 2003-10-08 14:16 ` Robert I. Eachus
2003-10-08 14:58 ` Dmitry A. Kazakov
0 siblings, 1 reply; 427+ messages in thread
From: Robert I. Eachus @ 2003-10-08 14:16 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-10-08 14:16 ` Robert I. Eachus
@ 2003-10-08 14:58 ` Dmitry A. Kazakov
2003-10-08 23:37 ` Robert I. Eachus
0 siblings, 1 reply; 427+ messages in thread
From: Dmitry A. Kazakov @ 2003-10-08 14:58 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-10-08 14:58 ` Dmitry A. Kazakov
@ 2003-10-08 23:37 ` Robert I. Eachus
2003-10-09 7:52 ` Dmitry A. Kazakov
0 siblings, 1 reply; 427+ messages in thread
From: Robert I. Eachus @ 2003-10-08 23:37 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-10-08 23:37 ` Robert I. Eachus
@ 2003-10-09 7:52 ` Dmitry A. Kazakov
2003-10-10 17:21 ` Robert I. Eachus
0 siblings, 1 reply; 427+ messages in thread
From: Dmitry A. Kazakov @ 2003-10-09 7:52 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-10-09 7:52 ` Dmitry A. Kazakov
@ 2003-10-10 17:21 ` Robert I. Eachus
0 siblings, 0 replies; 427+ messages in thread
From: Robert I. Eachus @ 2003-10-10 17:21 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-30 21:01 ` Robert I. Eachus
2003-09-30 22:01 ` Preben Randhol
@ 2003-09-30 23:46 ` Wes Groleau
2003-10-01 12:28 ` Marin David Condic
2 siblings, 0 replies; 427+ messages in thread
From: Wes Groleau @ 2003-09-30 23:46 UTC (permalink / raw)
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 ?
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-30 21:01 ` Robert I. Eachus
2003-09-30 22:01 ` Preben Randhol
2003-09-30 23:46 ` Wes Groleau
@ 2003-10-01 12:28 ` Marin David Condic
2003-10-01 17:51 ` Robert I. Eachus
2 siblings, 1 reply; 427+ messages in thread
From: Marin David Condic @ 2003-10-01 12:28 UTC (permalink / raw)
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
======================================================================
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-10-01 12:28 ` Marin David Condic
@ 2003-10-01 17:51 ` Robert I. Eachus
0 siblings, 0 replies; 427+ messages in thread
From: Robert I. Eachus @ 2003-10-01 17:51 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-30 14:28 ` Jean-Pierre Rosen
2003-09-30 21:01 ` Robert I. Eachus
@ 2003-10-01 12:17 ` Marin David Condic
2003-10-01 13:50 ` Jean-Pierre Rosen
` (3 more replies)
1 sibling, 4 replies; 427+ messages in thread
From: Marin David Condic @ 2003-10-01 12:17 UTC (permalink / raw)
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
======================================================================
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-10-01 12:17 ` Marin David Condic
@ 2003-10-01 13:50 ` Jean-Pierre Rosen
2003-10-02 0:38 ` Marin David Condic
2003-10-02 4:17 ` Wes Groleau
2003-10-01 21:54 ` tmoran
` (2 subsequent siblings)
3 siblings, 2 replies; 427+ messages in thread
From: Jean-Pierre Rosen @ 2003-10-01 13:50 UTC (permalink / raw)
[-- 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
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-10-01 13:50 ` Jean-Pierre Rosen
@ 2003-10-02 0:38 ` Marin David Condic
[not found] ` <NhMeb.477065$Oz4.311358@rwcrnsc54>
2003-10-20 7:43 ` Jacob Sparre Andersen
2003-10-02 4:17 ` Wes Groleau
1 sibling, 2 replies; 427+ messages in thread
From: Marin David Condic @ 2003-10-02 0:38 UTC (permalink / raw)
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
======================================================================
^ permalink raw reply [flat|nested] 427+ messages in thread[parent not found: <NhMeb.477065$Oz4.311358@rwcrnsc54>]
* Re: Is the Writing on the Wall for Ada?
[not found] ` <NhMeb.477065$Oz4.311358@rwcrnsc54>
@ 2003-10-02 12:31 ` Marin David Condic
0 siblings, 0 replies; 427+ messages in thread
From: Marin David Condic @ 2003-10-02 12:31 UTC (permalink / raw)
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
======================================================================
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-10-02 0:38 ` Marin David Condic
[not found] ` <NhMeb.477065$Oz4.311358@rwcrnsc54>
@ 2003-10-20 7:43 ` Jacob Sparre Andersen
2003-10-20 12:20 ` Marin David Condic
1 sibling, 1 reply; 427+ messages in thread
From: Jacob Sparre Andersen @ 2003-10-20 7:43 UTC (permalink / raw)
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."
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-10-20 7:43 ` Jacob Sparre Andersen
@ 2003-10-20 12:20 ` Marin David Condic
0 siblings, 0 replies; 427+ messages in thread
From: Marin David Condic @ 2003-10-20 12:20 UTC (permalink / raw)
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
======================================================================
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-10-01 13:50 ` Jean-Pierre Rosen
2003-10-02 0:38 ` Marin David Condic
@ 2003-10-02 4:17 ` Wes Groleau
1 sibling, 0 replies; 427+ messages in thread
From: Wes Groleau @ 2003-10-02 4:17 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-10-01 12:17 ` Marin David Condic
2003-10-01 13:50 ` Jean-Pierre Rosen
@ 2003-10-01 21:54 ` tmoran
2003-10-02 0:50 ` Marin David Condic
2003-10-02 9:19 ` Preben Randhol
2003-10-20 7:42 ` Jacob Sparre Andersen
3 siblings, 1 reply; 427+ messages in thread
From: tmoran @ 2003-10-01 21:54 UTC (permalink / raw)
> 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;
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-10-01 21:54 ` tmoran
@ 2003-10-02 0:50 ` Marin David Condic
2003-10-02 20:03 ` Robert I. Eachus
0 siblings, 1 reply; 427+ messages in thread
From: Marin David Condic @ 2003-10-02 0:50 UTC (permalink / raw)
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
======================================================================
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-10-02 0:50 ` Marin David Condic
@ 2003-10-02 20:03 ` Robert I. Eachus
2003-10-03 12:22 ` Marin David Condic
0 siblings, 1 reply; 427+ messages in thread
From: Robert I. Eachus @ 2003-10-02 20:03 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-10-02 20:03 ` Robert I. Eachus
@ 2003-10-03 12:22 ` Marin David Condic
2003-10-03 12:26 ` Preben Randhol
2003-10-04 1:49 ` Robert I. Eachus
0 siblings, 2 replies; 427+ messages in thread
From: Marin David Condic @ 2003-10-03 12:22 UTC (permalink / raw)
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
======================================================================
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-10-03 12:22 ` Marin David Condic
@ 2003-10-03 12:26 ` Preben Randhol
2003-10-03 12:36 ` Marin David Condic
2003-10-04 1:49 ` Robert I. Eachus
1 sibling, 1 reply; 427+ messages in thread
From: Preben Randhol @ 2003-10-03 12:26 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-10-03 12:26 ` Preben Randhol
@ 2003-10-03 12:36 ` Marin David Condic
2003-10-03 14:24 ` Preben Randhol
0 siblings, 1 reply; 427+ messages in thread
From: Marin David Condic @ 2003-10-03 12:36 UTC (permalink / raw)
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
======================================================================
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-10-03 12:36 ` Marin David Condic
@ 2003-10-03 14:24 ` Preben Randhol
2003-10-03 18:13 ` Marin David Condic
0 siblings, 1 reply; 427+ messages in thread
From: Preben Randhol @ 2003-10-03 14:24 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-10-03 14:24 ` Preben Randhol
@ 2003-10-03 18:13 ` Marin David Condic
0 siblings, 0 replies; 427+ messages in thread
From: Marin David Condic @ 2003-10-03 18:13 UTC (permalink / raw)
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
======================================================================
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-10-03 12:22 ` Marin David Condic
2003-10-03 12:26 ` Preben Randhol
@ 2003-10-04 1:49 ` Robert I. Eachus
2003-10-04 12:31 ` Marin David Condic
1 sibling, 1 reply; 427+ messages in thread
From: Robert I. Eachus @ 2003-10-04 1:49 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-10-04 1:49 ` Robert I. Eachus
@ 2003-10-04 12:31 ` Marin David Condic
2003-10-04 13:54 ` Robert I. Eachus
2003-10-06 16:47 ` Warren W. Gay VE3WWG
0 siblings, 2 replies; 427+ messages in thread
From: Marin David Condic @ 2003-10-04 12:31 UTC (permalink / raw)
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
======================================================================
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-10-04 12:31 ` Marin David Condic
@ 2003-10-04 13:54 ` Robert I. Eachus
2003-10-04 21:10 ` Marin David Condic
2003-10-06 16:47 ` Warren W. Gay VE3WWG
1 sibling, 1 reply; 427+ messages in thread
From: Robert I. Eachus @ 2003-10-04 13:54 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-10-04 13:54 ` Robert I. Eachus
@ 2003-10-04 21:10 ` Marin David Condic
2003-10-06 17:09 ` Warren W. Gay VE3WWG
0 siblings, 1 reply; 427+ messages in thread
From: Marin David Condic @ 2003-10-04 21:10 UTC (permalink / raw)
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
======================================================================
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-10-04 21:10 ` Marin David Condic
@ 2003-10-06 17:09 ` Warren W. Gay VE3WWG
2003-10-06 23:26 ` Marin David Condic
0 siblings, 1 reply; 427+ messages in thread
From: Warren W. Gay VE3WWG @ 2003-10-06 17:09 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-10-06 17:09 ` Warren W. Gay VE3WWG
@ 2003-10-06 23:26 ` Marin David Condic
0 siblings, 0 replies; 427+ messages in thread
From: Marin David Condic @ 2003-10-06 23:26 UTC (permalink / raw)
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
======================================================================
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-10-04 12:31 ` Marin David Condic
2003-10-04 13:54 ` Robert I. Eachus
@ 2003-10-06 16:47 ` Warren W. Gay VE3WWG
1 sibling, 0 replies; 427+ messages in thread
From: Warren W. Gay VE3WWG @ 2003-10-06 16:47 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-10-01 12:17 ` Marin David Condic
2003-10-01 13:50 ` Jean-Pierre Rosen
2003-10-01 21:54 ` tmoran
@ 2003-10-02 9:19 ` Preben Randhol
2003-10-02 12:37 ` Marin David Condic
2003-10-20 7:42 ` Jacob Sparre Andersen
3 siblings, 1 reply; 427+ messages in thread
From: Preben Randhol @ 2003-10-02 9:19 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-10-02 9:19 ` Preben Randhol
@ 2003-10-02 12:37 ` Marin David Condic
2003-10-02 13:07 ` Preben Randhol
0 siblings, 1 reply; 427+ messages in thread
From: Marin David Condic @ 2003-10-02 12:37 UTC (permalink / raw)
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
======================================================================
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-10-02 12:37 ` Marin David Condic
@ 2003-10-02 13:07 ` Preben Randhol
2003-10-02 16:39 ` Marin David Condic
0 siblings, 1 reply; 427+ messages in thread
From: Preben Randhol @ 2003-10-02 13:07 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-10-02 13:07 ` Preben Randhol
@ 2003-10-02 16:39 ` Marin David Condic
2003-10-02 16:44 ` Marin David Condic
0 siblings, 1 reply; 427+ messages in thread
From: Marin David Condic @ 2003-10-02 16:39 UTC (permalink / raw)
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
======================================================================
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-10-02 16:39 ` Marin David Condic
@ 2003-10-02 16:44 ` Marin David Condic
0 siblings, 0 replies; 427+ messages in thread
From: Marin David Condic @ 2003-10-02 16:44 UTC (permalink / raw)
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
======================================================================
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-10-01 12:17 ` Marin David Condic
` (2 preceding siblings ...)
2003-10-02 9:19 ` Preben Randhol
@ 2003-10-20 7:42 ` Jacob Sparre Andersen
3 siblings, 0 replies; 427+ messages in thread
From: Jacob Sparre Andersen @ 2003-10-20 7:42 UTC (permalink / raw)
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."
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-30 12:30 ` Marin David Condic
2003-09-30 12:35 ` Larry Kilgallen
2003-09-30 14:28 ` Jean-Pierre Rosen
@ 2003-09-30 14:58 ` Mark A. Biggar
2003-10-01 11:59 ` Marin David Condic
2003-09-30 17:43 ` tmoran
` (2 subsequent siblings)
5 siblings, 1 reply; 427+ messages in thread
From: Mark A. Biggar @ 2003-09-30 14:58 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-30 14:58 ` Mark A. Biggar
@ 2003-10-01 11:59 ` Marin David Condic
2003-10-01 17:33 ` Robert I. Eachus
2003-10-02 4:14 ` Wes Groleau
0 siblings, 2 replies; 427+ messages in thread
From: Marin David Condic @ 2003-10-01 11:59 UTC (permalink / raw)
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
======================================================================
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-10-01 11:59 ` Marin David Condic
@ 2003-10-01 17:33 ` Robert I. Eachus
2003-10-02 1:29 ` Alexander Kopilovitch
2003-10-02 4:14 ` Wes Groleau
1 sibling, 1 reply; 427+ messages in thread
From: Robert I. Eachus @ 2003-10-01 17:33 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-10-01 17:33 ` Robert I. Eachus
@ 2003-10-02 1:29 ` Alexander Kopilovitch
2003-10-02 12:24 ` Marin David Condic
2003-10-02 19:15 ` Robert I. Eachus
0 siblings, 2 replies; 427+ messages in thread
From: Alexander Kopilovitch @ 2003-10-02 1:29 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-10-02 1:29 ` Alexander Kopilovitch
@ 2003-10-02 12:24 ` Marin David Condic
2003-10-02 20:50 ` Alexander Kopilovitch
2003-10-02 19:15 ` Robert I. Eachus
1 sibling, 1 reply; 427+ messages in thread
From: Marin David Condic @ 2003-10-02 12:24 UTC (permalink / raw)
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
======================================================================
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-10-02 12:24 ` Marin David Condic
@ 2003-10-02 20:50 ` Alexander Kopilovitch
0 siblings, 0 replies; 427+ messages in thread
From: Alexander Kopilovitch @ 2003-10-02 20:50 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-10-02 1:29 ` Alexander Kopilovitch
2003-10-02 12:24 ` Marin David Condic
@ 2003-10-02 19:15 ` Robert I. Eachus
2003-10-03 1:55 ` Alexander Kopilovitch
1 sibling, 1 reply; 427+ messages in thread
From: Robert I. Eachus @ 2003-10-02 19:15 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-10-02 19:15 ` Robert I. Eachus
@ 2003-10-03 1:55 ` Alexander Kopilovitch
0 siblings, 0 replies; 427+ messages in thread
From: Alexander Kopilovitch @ 2003-10-03 1:55 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-10-01 11:59 ` Marin David Condic
2003-10-01 17:33 ` Robert I. Eachus
@ 2003-10-02 4:14 ` Wes Groleau
1 sibling, 0 replies; 427+ messages in thread
From: Wes Groleau @ 2003-10-02 4:14 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-30 12:30 ` Marin David Condic
` (2 preceding siblings ...)
2003-09-30 14:58 ` Mark A. Biggar
@ 2003-09-30 17:43 ` tmoran
2003-10-02 19:30 ` Simon Wright
2003-10-20 7:39 ` Jacob Sparre Andersen
5 siblings, 0 replies; 427+ messages in thread
From: tmoran @ 2003-09-30 17:43 UTC (permalink / raw)
>*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."
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-30 12:30 ` Marin David Condic
` (3 preceding siblings ...)
2003-09-30 17:43 ` tmoran
@ 2003-10-02 19:30 ` Simon Wright
2003-10-20 7:39 ` Jacob Sparre Andersen
5 siblings, 0 replies; 427+ messages in thread
From: Simon Wright @ 2003-10-02 19:30 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-30 12:30 ` Marin David Condic
` (4 preceding siblings ...)
2003-10-02 19:30 ` Simon Wright
@ 2003-10-20 7:39 ` Jacob Sparre Andersen
5 siblings, 0 replies; 427+ messages in thread
From: Jacob Sparre Andersen @ 2003-10-20 7:39 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-30 2:20 ` Robert I. Eachus
2003-09-30 3:24 ` tmoran
2003-09-30 7:01 ` Preben Randhol
@ 2003-09-30 12:21 ` Marin David Condic
2003-09-30 13:56 ` Dmitry A. Kazakov
2003-09-30 20:42 ` Jeffrey Carter
3 siblings, 1 reply; 427+ messages in thread
From: Marin David Condic @ 2003-09-30 12:21 UTC (permalink / raw)
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
======================================================================
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-30 12:21 ` Marin David Condic
@ 2003-09-30 13:56 ` Dmitry A. Kazakov
2003-10-01 12:34 ` Marin David Condic
0 siblings, 1 reply; 427+ messages in thread
From: Dmitry A. Kazakov @ 2003-09-30 13:56 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-30 13:56 ` Dmitry A. Kazakov
@ 2003-10-01 12:34 ` Marin David Condic
2003-10-02 7:41 ` Dmitry A. Kazakov
0 siblings, 1 reply; 427+ messages in thread
From: Marin David Condic @ 2003-10-01 12:34 UTC (permalink / raw)
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
======================================================================
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-10-01 12:34 ` Marin David Condic
@ 2003-10-02 7:41 ` Dmitry A. Kazakov
2003-10-02 12:42 ` Marin David Condic
0 siblings, 1 reply; 427+ messages in thread
From: Dmitry A. Kazakov @ 2003-10-02 7:41 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-10-02 7:41 ` Dmitry A. Kazakov
@ 2003-10-02 12:42 ` Marin David Condic
2003-10-02 14:15 ` Dmitry A. Kazakov
0 siblings, 1 reply; 427+ messages in thread
From: Marin David Condic @ 2003-10-02 12:42 UTC (permalink / raw)
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
======================================================================
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-10-02 12:42 ` Marin David Condic
@ 2003-10-02 14:15 ` Dmitry A. Kazakov
0 siblings, 0 replies; 427+ messages in thread
From: Dmitry A. Kazakov @ 2003-10-02 14:15 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-30 2:20 ` Robert I. Eachus
` (2 preceding siblings ...)
2003-09-30 12:21 ` Marin David Condic
@ 2003-09-30 20:42 ` Jeffrey Carter
3 siblings, 0 replies; 427+ messages in thread
From: Jeffrey Carter @ 2003-09-30 20:42 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-25 22:06 ` Hyman Rosen
2003-09-26 1:53 ` Robert I. Eachus
@ 2003-09-26 3:21 ` Alexander Kopilovitch
1 sibling, 0 replies; 427+ messages in thread
From: Alexander Kopilovitch @ 2003-09-26 3:21 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-25 18:04 ` Jan Kroken
2003-09-25 21:50 ` Stephen Leake
@ 2003-09-26 0:05 ` Matthew Heaney
2003-09-26 12:52 ` Marin David Condic
2 siblings, 0 replies; 427+ messages in thread
From: Matthew Heaney @ 2003-09-26 0:05 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-25 18:04 ` Jan Kroken
2003-09-25 21:50 ` Stephen Leake
2003-09-26 0:05 ` Matthew Heaney
@ 2003-09-26 12:52 ` Marin David Condic
2003-09-26 13:09 ` chris
2003-09-27 0:53 ` Robert I. Eachus
2 siblings, 2 replies; 427+ messages in thread
From: Marin David Condic @ 2003-09-26 12:52 UTC (permalink / raw)
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
======================================================================
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-26 12:52 ` Marin David Condic
@ 2003-09-26 13:09 ` chris
2003-09-26 17:46 ` Stephen Leake
2003-09-27 0:53 ` Robert I. Eachus
1 sibling, 1 reply; 427+ messages in thread
From: chris @ 2003-09-26 13:09 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-26 13:09 ` chris
@ 2003-09-26 17:46 ` Stephen Leake
2003-09-26 17:57 ` chris
2003-09-26 21:46 ` Marin David Condic
0 siblings, 2 replies; 427+ messages in thread
From: Stephen Leake @ 2003-09-26 17:46 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-26 17:46 ` Stephen Leake
@ 2003-09-26 17:57 ` chris
2003-09-29 14:58 ` Stephen Leake
2003-09-26 21:46 ` Marin David Condic
1 sibling, 1 reply; 427+ messages in thread
From: chris @ 2003-09-26 17:57 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-26 17:57 ` chris
@ 2003-09-29 14:58 ` Stephen Leake
0 siblings, 0 replies; 427+ messages in thread
From: Stephen Leake @ 2003-09-29 14:58 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-26 17:46 ` Stephen Leake
2003-09-26 17:57 ` chris
@ 2003-09-26 21:46 ` Marin David Condic
1 sibling, 0 replies; 427+ messages in thread
From: Marin David Condic @ 2003-09-26 21:46 UTC (permalink / raw)
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
======================================================================
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-26 12:52 ` Marin David Condic
2003-09-26 13:09 ` chris
@ 2003-09-27 0:53 ` Robert I. Eachus
2003-09-27 14:34 ` Marin David Condic
1 sibling, 1 reply; 427+ messages in thread
From: Robert I. Eachus @ 2003-09-27 0:53 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-27 0:53 ` Robert I. Eachus
@ 2003-09-27 14:34 ` Marin David Condic
2003-09-27 19:24 ` Robert I. Eachus
2003-09-28 2:38 ` Wes Groleau
0 siblings, 2 replies; 427+ messages in thread
From: Marin David Condic @ 2003-09-27 14:34 UTC (permalink / raw)
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
======================================================================
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-27 14:34 ` Marin David Condic
@ 2003-09-27 19:24 ` Robert I. Eachus
2003-09-28 2:38 ` Wes Groleau
1 sibling, 0 replies; 427+ messages in thread
From: Robert I. Eachus @ 2003-09-27 19:24 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-27 14:34 ` Marin David Condic
2003-09-27 19:24 ` Robert I. Eachus
@ 2003-09-28 2:38 ` Wes Groleau
2003-09-28 14:46 ` Marin David Condic
1 sibling, 1 reply; 427+ messages in thread
From: Wes Groleau @ 2003-09-28 2:38 UTC (permalink / raw)
> 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
^ permalink raw reply [flat|nested] 427+ messages in thread
* Re: Is the Writing on the Wall for Ada?
2003-09-28 2:38 ` Wes Groleau
@ 2003-09-28 14:46 ` Marin David Condic
2003-09-28 19:58 ` Wes Groleau
2003-09-29 3:17 ` Hyman Rosen
0 siblings, 2 replies; 427+ messages in thread
From: Marin David Condic @ 2003-09-28 14:46 UTC (permalink / raw)
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
======================================================================
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-28 14:46 ` Marin David Condic
@ 2003-09-28 19:58 ` Wes Groleau
2003-09-29 3:17 ` Hyman Rosen
1 sibling, 0 replies; 427+ messages in thread
From: Wes Groleau @ 2003-09-28 19:58 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 427+ messages in thread* Re: Is the Writing on the Wall for Ada?
2003-09-28 14:46 ` Marin David Condic
2003-09-28 19:58 ` Wes Groleau
@ 2003-09-29 3:17 ` Hyman Rosen
1 sibling, 0 replies; 427+ messages in thread
From: Hyman Rosen @ 2003-09-29 3:17 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 427+ messages in thread