Re: Early Ada Mistakes (was: Re: += in ada)

Re: Early Ada Mistakes (was: Re: += in ada)

[Ed Falis]

On Wed, 22 Oct 2003 16:25:44 -0400, Beard, Frank Randolph CIV 
<frank.beard@navy.mil> wrote:

> I believe they were bought out by IBM.  We were using their compiler
> on the IBM Mainframe for Space Station.  If you ever wondered how to
> make compiler messages more obscure, compile on MVS.
>

Telesoft was bought by Alsys after the latter was bought by Thomson.  The 
remnants of the original Telesoft development group are still part of 
Aonix, I think (though I wouldn't swear it).

- Ed

Re: Early Ada Mistakes (was: Re: += in ada)

[Ed Falis]

On Wed, 22 Oct 2003 17:39:56 -0400, Beard, Frank Randolph CIV 
<frank.beard@navy.mil> wrote:

> I thought that was TeleUSE, not TeleSoft, but you would know better than
> me.  Sorry for the misinformation.  At least, I'm pretty sure it was the
> TeleSoft compiler we used on the IBM Mainframe.

Oh, it's easy to get confused - I'm still confused about why the orignal 
Alsys US office was shut down.  But's that's the software industry, eh?

Someone should write a biography of Ada along the lines of "Soul of a New 
Machine".  All of the dramatic elements are there for the general 
entertainment.

- Ed

Re: Early Ada Mistakes (was: Re: += in ada)

[Alexandre E. Kopilovitch]

Ed Falis wrote:

>Someone should write a biography of Ada along the lines of "Soul of a New 
>Machine".  All of the dramatic elements are there for the general 
>entertainment.

I have read "Soul of a New Machine" about 15 years ago, and I still remember it.
And I don't think that it is possible to compose something similar about Ada,
because a problem of hardware (in broad sense, it shouldn't be necessarily
computers). Hardware must be in place, you can't produce really good literature
about software only... because that software must have a valid purpose (without
known purpose all software-related problems will look just as a kind of soap
opera). And I think that this is particularly true for Ada. So, if you include
both Ada and hardware, you'll get not a small book, but a huge volume.

Then, look at the characters: those in "Soul..." are good persons, but even
the main character is still not heavyweight - and what we have in Ada history
in this respect?

Although... if you ask Tim Rice, perhaps he will find it an interesting idea? -:)



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

Ed Falis wrote:

>Someone should write a biography of Ada along the lines of "Soul of a New 
>Machine".  All of the dramatic elements are there for the general 
>entertainment.

I have read "Soul of a New Machine" about 15 years ago, and I still remember it.
And I don't think that it is possible to compose something similar about Ada,
because a problem of hardware (in broad sense, it shouldn't be necessarily
computers). Hardware must be in place, you can't produce really good literature
about software only... because that software must have a valid purpose (without
known purpose all software-related problems will look just as a kind of soap
opera). And I think that this is particularly true for Ada. So, if you include
both Ada and hardware, you'll get not a small book, but a huge volume.

Then, look at the characters: those in "Soul..." are good persons, but even
the main character is still not heavyweight - and what we have in Ada history
in this respect?

Although... if you ask Tim Rice, perhaps he will find it an interesting idea? -:)



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

Re: Early Ada Mistakes (was: Re: += in ada)

[Ole-Hjalmar Kristensen]

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

    EF> On  Wed,  22  Oct  2003  17:39:56 -0400,  Beard,  Frank  Randolph  CIV
    EF> <frank.beard@navy.mil> wrote:


    >> I thought that was TeleUSE, not TeleSoft, but you would know better than
    >> me.  Sorry for the misinformation.  At least, I'm pretty sure it was the
    >> TeleSoft compiler we used on the IBM Mainframe.

    EF> Oh,  it's easy  to get  confused -  I'm still  confused about  why the
    EF> orignal  Alsys US  office was  shut down.  But's that's  the software
    EF> industry, eh?


    EF> Someone should write a biography of  Ada along the lines of "Soul of a
    EF> New Machine". All of the  dramatic elements are there for the general
    EF> entertainment.


    EF> - Ed

If I remember correctly, both the TeleSoft compiler and the TeleUse
UIMS came from the same company (TeleSoft).

-- 
This page intentionally left blank

Re: += in ada

[Lutz Donnerhacke]

* Dmytry Lavrov wrote:
> begin
> declare_new_name a _for_ X(b(i).all+7);
> -- for example, "a is X(b(i).all+7)"
> a:=a+2/a;
> end;

declare
   a : Typ renames X(b(i).all + 7);
begin
   a := a + 2/a;
end;   

is legal Ada and a common idiom.

> "+=" is a idea about in-place operations,and @ is about readability.

Both ideas fail on considering a consitent semantic for volatile types and
exception handling. In both cases it's necessary to require a temporary copy
of the LHS. So nothing is gained from this proposal, beside a clear semantic
about access frequency for volatile data (one read and one write access).

So I have to conlude, that the whole "idem" Idiom is useless at all.

In order to generate a more general solution, the S'Type attibute would
helpful, because it's possible to write:

declare
   a : a'Type renames X(b(i).all + 7);
begin
   a := a + 2/a;
end;   

> IMO,in place operations should be used as normal procedures like
> inc(a,b) or juliafractalstep(z,c);

Yep.

Re: += in ada

[Hyman Rosen]

Georg Bauhaus wrote:
> Also, with respect to the syntactic choice += etc, I think one could boil
> C, Java, and Perl down to 1 language, not 3. Or is there a difference
> in "+=" in these languages, from a user perspective?

Java does not support user-defined operators at all.
All operators in Java are built-in only. Ditto for C.
C++ and Perl allow user-defined operators to be written
when at least one operand is a user-defined type.

> Interesting. So programming languages are obviously chosen because
> there is some form of augmented assinment in the language?
> Why do people choose Visual Basic, or Fortran, or Delphi?

Even in COBOL you could say "ADD A TO B."

Re: += in ada

[Vinzent 'Gadget' Hoefler]

Hyman Rosen wrote:

>> Interesting. So programming languages are obviously chosen because
>> there is some form of augmented assinment in the language?
>> Why do people choose Visual Basic, or Fortran, or Delphi?
>
>Even in COBOL you could say "ADD A TO B."

You can already do it in Ada, too:

|Add (A, To => B);

So, what's your point? ;-) That it is not "built-in"?


Vinzent.

Re: += in ada

[Hyman Rosen]

Vinzent 'Gadget' Hoefler wrote:
> So, what's your point? ;-) That it is not "built-in"?

My point is that "augmented assignment" is a very old
feature of programming languages. In fact, it's a basic
feature of computers, since most of them have machine
instructions which add one thing to another.

That isn't to say that I think this feature should be
added to Ada. I don't care one way or the other.

Re: += in ada

[Russ]

Hyman Rosen <hyrosen@mail.com> wrote in message news:<1066231159.711433@master.nyc.kbcfp.com>...
> Vinzent 'Gadget' Hoefler wrote:
> > So, what's your point? ;-) That it is not "built-in"?
> 
> My point is that "augmented assignment" is a very old
> feature of programming languages. In fact, it's a basic
> feature of computers, since most of them have machine
> instructions which add one thing to another.

Good point.

> That isn't to say that I think this feature should be
> added to Ada. I don't care one way or the other.

Fine, but I get the impression from some of your previous posts that
Ada is not your primary programming language anyway, and perhaps that
explains your apathy.

Just for fun, suppose that Ada was the *only* language you (or anyone
who works for you) could use for the rest of your life. Then would you
care if augmented assignment operators are added to Ada? Just curious.

Re: += in ada

[Hyman Rosen]

Russ wrote:
> Just for fun, suppose that Ada was the *only* language you (or anyone
> who works for you) could use for the rest of your life. Then would you
> care if augmented assignment operators are added to Ada? Just curious.

I might. But I would already have created a bunch of generic
procedures (AddTo, DivideInto, SubtractFrom, etc.) and would
instantiate them when their use would appear to be needed. It
would be wordier, but then if I was an Ada user, I would be
firmly convinced that this enhances readability :-)

Hmm. Ada is not my primary language. I guess those would be
Add(a, To=>b), Subtract(a, From=>b), etc. as others have said.

Re: += in ada

[Robert I. Eachus]

Hyman Rosen wrote:

> Hmm. Ada is not my primary language. I guess those would be
> Add(a, To=>b), Subtract(a, From=>b), etc. as others have said.

Actually I find I often create

procedure Inc(X: in out Integer);

I could also create procedure Dec, or add By with a default of 1, etc. 
But it just doesn't turn out to be worth the bother.  And I think that 
is the real problem with Russ's rantings.  Some where between 98% and 
all of the benefit of the extended operators in C comes from +=, and 
that from X += 1;  In Ada I write that as Inc(X); and use the same 
number of keystrokes.  True those people who prefer to write X+=1; in C 
do save two characters, but I refuse to worry about it.
-- 
                                                     Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: += in ada

[Russ]

"Robert I. Eachus" <rieachus@comcast.net> wrote in message news:<3F8F3077.60402@comcast.net>...
> Hyman Rosen wrote:
> 
> > Hmm. Ada is not my primary language. I guess those would be
> > Add(a, To=>b), Subtract(a, From=>b), etc. as others have said.
> 
> Actually I find I often create
> 
> procedure Inc(X: in out Integer);
> 
> I could also create procedure Dec, or add By with a default of 1, etc. 
> But it just doesn't turn out to be worth the bother.  And I think that 
> is the real problem with Russ's rantings.  Some where between 98% and 
> all of the benefit of the extended operators in C comes from +=, and 
> that from X += 1;  In Ada I write that as Inc(X); and use the same 
> number of keystrokes.  True those people who prefer to write X+=1; in C 
> do save two characters, but I refuse to worry about it.

Two characters? Apparently you forgot about, or don't count, having to
write "Inc" in the first place.

As I said before, I am not an Ada programmer, so perhaps you can help
me understand something. In a large program or software system of your
design, approximately how many versions of "Inc" and the like do you
have floating around just for basic scalar types? I know that Ada
allows, and in fact encourages, the use of specialized types for
everything. Do you need to write an "Inc" procedure for each type? Or
do you perhaps use generics?

Whatever the case, wouldn't it be simpler and cleaner to just use a
standard ":+" and let the compiler do it for you? Do you get paid
extra for writing code that the compiler can generate all by itself?
And how many meetings do you need to inform your programmers of your
particular procedure naming conventions when you could avoid all that
with a simple standard for the entire Ada world?

I read all sorts of discussion on this forum about the need for
standard libraries for Ada. Well, why not start at the bottom with
standard symbols for common procedures? C++ has the STL, and it also
has a standard symbol for incrementing a stupid counter. Every
C/C++/Java/Perl/Python programmer in the world is on the same page.
But Ada leaves the naming as an excercize for the programmer, and I'm
sure there are almost as many conventions as programmers. If that
somehow helps "readability", then your definition of "readability" is
not the same as mine.

Re: += in ada

[Robert I. Eachus]

Russ wrote:

> Two characters? Apparently you forgot about, or don't count, having to
> write "Inc" in the first place.

No, I didn't, I have a package I use when I am doing "serious" 
development.  I will probably post it as the root for an "Eachus" 
heirarchy here, although I have been calling it Common.  It contains Inc 
for Integer and Character, but the part I use even more than that is a 
set of TBD declarations.  These allow me to say for example:

function Do_Something(A, B: Parameters) return Integer is
begin return TBD("Do_Something"); end Do_Something;

(And yes I do add the optional name to the end automatically, I type 
pretty fast, and it is easier to always add it than to stop to think.)

Of course, now my code compiles cleanly and if I run it, the call to 
TBD, if called prints a message and raises To_Be_Done. ;-)  Very handy 
feature.

Of course, when code is "complete" I want to get rid of the with Common; 
use Common; so I will cut and paste some declarations like Inc if 
necessary to do that.  I have been thinking of splitting thing and 
having a separate package "To_Be_Done".

> As I said before, I am not an Ada programmer, so perhaps you can help
> me understand something. In a large program or software system of your
> design, approximately how many versions of "Inc" and the like do you
> have floating around just for basic scalar types? I know that Ada
> allows, and in fact encourages, the use of specialized types for
> everything. Do you need to write an "Inc" procedure for each type? Or
> do you perhaps use generics?

It may be a failure of my style, but I think it is pretty common for Ada 
programmers, things you want to increment are almost always Integers or 
a subtype of Integer.  I do have a quirk of writing some Inc calls for 
Character and other character types, but that is almost certainly due to 
my involvement with character set issues.  (Things like printing tables 
of Characters and their classification if you use a non-Latin1 character 
set via compile-time option.)

> Whatever the case, wouldn't it be simpler and cleaner to just use a
> standard ":+" and let the compiler do it for you? Do you get paid
> extra for writing code that the compiler can generate all by itself?
> And how many meetings do you need to inform your programmers of your
> particular procedure naming conventions when you could avoid all that
> with a simple standard for the entire Ada world?

I would love to replace the almost useless Character'Succ function with 
an Inc procedure in the standard, or just add Inc.  I wouldn't even mind 
if it were called Succ instead.  But ":+" is a non-starter for me and 
most Ada programmers. Same goes for Foo++; which, if anything would be 
much more acceptable to Ada programmers, and which you seem to ignore. 
(Hmmm. In fact, ++Foo; might be acceptable to most Ada programmers, and 
should be much more acceptable than Foo++; even though the pre- and 
post- semantics wouldn't apply to Ada.)

> I read all sorts of discussion on this forum about the need for
> standard libraries for Ada. Well, why not start at the bottom with
> standard symbols for common procedures? C++ has the STL, and it also
> has a standard symbol for incrementing a stupid counter. Every
> C/C++/Java/Perl/Python programmer in the world is on the same page.
> But Ada leaves the naming as an excercize for the programmer, and I'm
> sure there are almost as many conventions as programmers. If that
> somehow helps "readability", then your definition of "readability" is
> not the same as mine.

This is where you are just p***ing up a rope.  Ada programmers don't 
LIKE the implied side effects associated with += and other such 
operators in C.  You will never get anyone who does a lot of programming 
in Ada to accept it.  On the other hand for Inc(Foo); and ++Foo; there 
is one effect, and it is the intended effect, not a side effect.

There is a HUGE difference between X += 1; and X := 1; and that is what 
you are fighting. It is a readability issue.  How many times do I have 
to misread :+ as := to wipe out all the advantage from adding :+ to Ada? 
  Oh, and in C where do you most often use +=?  Right, in for loops. 
(And yes, most good C programmers use ++ more often there than +=.) But 
in Ada there is an implied increment function in: for I in Foo'Range 
loop and a decrement in for I in reverse Foo'Range; so even if it was 
available, :+ in Ada would appear a lot less frequently than += in C.

-- 
                                                     Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: += in ada

[Russ]

"Robert I. Eachus" <rieachus@comcast.net> wrote in message news:<3F900F35.50203@comcast.net>...
> Russ wrote:

> > I read all sorts of discussion on this forum about the need for
> > standard libraries for Ada. Well, why not start at the bottom with
> > standard symbols for common procedures? C++ has the STL, and it also
> > has a standard symbol for incrementing a stupid counter. Every
> > C/C++/Java/Perl/Python programmer in the world is on the same page.
> > But Ada leaves the naming as an excercize for the programmer, and I'm
> > sure there are almost as many conventions as programmers. If that
> > somehow helps "readability", then your definition of "readability" is
> > not the same as mine.
> 
> This is where you are just p***ing up a rope.  Ada programmers don't 
> LIKE the implied side effects associated with += and other such 
> operators in C.  You will never get anyone who does a lot of programming 
> in Ada to accept it.  On the other hand for Inc(Foo); and ++Foo; there 
> is one effect, and it is the intended effect, not a side effect.

I simply do not understand your reasoning here. How does "+=" (or
":+") have any more side effects than "Inc" or "++"? They are all just
procedures. Please give me an example where "+=" has a side effect
that "Inc" or "++" cannot have. Until you do, I think you may have
just exposed the irrationality of your objection to augmented
assignment operators.

> There is a HUGE difference between X += 1; and X := 1; and that is what 
> you are fighting. It is a readability issue.  How many times do I have 
> to misread :+ as := to wipe out all the advantage from adding :+ to Ada? 

Yes, and there is a huge difference between 100000.0 and 1000000.0
too. There is a huge difference between X := Y * 2 and X := Y + 2.
There is a huge difference between X <= Y and X >= Y. So what? I have
no trouble distinguishing between them, and I have no trouble
distinguishing between := and :+. They look as different as day and
night to me.

As I said before, I am not a professional programmer or computer
scientist. I am aerospace engineer working on future concepts for
safety critical air traffic management systems 20 years in the future.
I would like to think that Ada will be an option when the time comes
to implement my concepts, but I am losing hope.

Because my formal training is not in programming or computer science,
I have restricted my comments on Ada to relatively low-level aspects
of the language. I don't consider myself qualified to comment on more
complicated issues. However, judging by my experience here, I am
losing faith in the Ada community. If you can't get the little things
right, how in the world can you can the complicated things right? I
don't think you can, and I don't think you will.

I have read several times here that augmented assignment operators are
a "non-starter", but I have yet to read any good reason why, other
than the lack of manpower in the Ada world. That tells me that Ada is
over the hill. Yesterday's news. Ossified. Ada is a legacy language.
RIP.

Re: += in ada

[Robert A Duff]

18k11tm001@sneakemail.com (Russ) writes:

> Yes, and there is a huge difference between 100000.0 and 1000000.0
> too. There is a huge difference between X := Y * 2 and X := Y + 2.
> There is a huge difference between X <= Y and X >= Y. So what? I have
> no trouble distinguishing between them, and I have no trouble
> distinguishing between := and :+. They look as different as day and
> night to me.

I agree that X <= Y and X >= Y can be distinguished easily.
But 100000.0 and 1000000.0?  They look almost the same to me.
A good Ada programmer would write 100_000.0 and 1_000_000.0.
In C (etc), you can't do that.

I still don't get what you think is so important about these increment
operators.

It would certainly be convenient if there were a built-in way to
increment a variable without writing the variable name twice,
especially when the variable name is something complicated like
A[I].C.all.  Is that what you're getting at?

Or do you insist that "A[I].C.all :+ 1" or "A[I].C.all += 1" is somehow
much more readable than "Inc(A[I].C.all)"?  Or, in pseudo-COBOL,
"Add 1 to A[I].C.all"?

What about the fact that += in C can have side effects?  That is, you
can say "while (x += 7)...", using both the *result* of +=, and its
effect of addition.  I consider that bad.  Do you?

The best solution to this, in my opinion, would be to allow one to
write:

    procedure Inc(X: in out Root_Integer'Class);

This would require that the type Root_Integer (from which all integer
types are ultimately derived, in Ada) to be nameable, and it would
require the class of all such types to be nameable via 'Class.

Such a facility would be quite powerful and quite useful.
And of course Inc could easily be predefined.
And some folks might prefer it called by infix ":+" or some such
(not me).

What I don't get, though, is why you think such notations are so
*important*.  Yes, C has a nice notation +=.  Yes, many languages have
inherited that notation.  So what?  It's just plain silly to suggest
that this notation is responsible for those languages' popularity,
or that the lack of such notations leads inevitably to the demise of
Ada.

I do agree with you that it would be nice to have a notation for
incrementing a variable without naming that variable twice.
And I do agree with you that "procedure Inc" is not a good solution
(in current Ada) because it requires a separate Inc procedure for
every integer type.

- Bob

Re: += in ada

[Russ]

Robert A Duff <bobduff@shell01.TheWorld.com> wrote in message news:<wccwub0dddq.fsf@shell01.TheWorld.com>...
> 18k11tm001@sneakemail.com (Russ) writes:

> I still don't get what you think is so important about these increment
> operators.

I admit that I'm probably making too much of them, and I hereby
apologize to everyone for my rudeness. They just seem like a good idea
to me for several reasons, and I am a bit obsessive/compulsive, so I
have a hard time letting it go.

> It would certainly be convenient if there were a built-in way to
> increment a variable without writing the variable name twice,
> especially when the variable name is something complicated like
> A[I].C.all.  Is that what you're getting at?

That's part of it.

> Or do you insist that "A[I].C.all :+ 1" or "A[I].C.all += 1" is somehow
> much more readable than "Inc(A[I].C.all)"?  Or, in pseudo-COBOL,
> "Add 1 to A[I].C.all"?

I think there should be one standard that can be overloaded for
user-defined types. I think ":+" is a good candidate for that
standard, but "Inc" would do, I suppose (with a default argument of
1). Unfortunately, "Inc(A,B)" for vector matrix addition leaves a lot
to be desired. The nice thing about "+=" or ":+" is that they look
right for both integers and matrices.

> What about the fact that += in C can have side effects?  That is, you
> can say "while (x += 7)...", using both the *result* of +=, and its
> effect of addition.  I consider that bad.  Do you?

Yes, I do, but it would not be an issue in Ada because "+=" or ":+"
would be a procedure, and as such it wouldn't return a value. So the
example you give above would not be valid.

> The best solution to this, in my opinion, would be to allow one to
> write:
> 
>     procedure Inc(X: in out Root_Integer'Class);
> 
> This would require that the type Root_Integer (from which all integer
> types are ultimately derived, in Ada) to be nameable, and it would
> require the class of all such types to be nameable via 'Class.
> 
> Such a facility would be quite powerful and quite useful.
> And of course Inc could easily be predefined.
> And some folks might prefer it called by infix ":+" or some such
> (not me).

As I said, ":+" is more versatile. It applies both to integer
incrementation *and* vector/matrix addition.

> What I don't get, though, is why you think such notations are so
> *important*.  Yes, C has a nice notation +=.  Yes, many languages have
> inherited that notation.  So what?  It's just plain silly to suggest
> that this notation is responsible for those languages' popularity,
> or that the lack of such notations leads inevitably to the demise of
> Ada.

At some point one must ask *why* Ada is so unpopular, despite the fact
that the DoD forced its use on a massive scale. Yes, the DoD mandate
created some resentment, but if Ada is really so good, those who
adopted it under duress should have eventually learned to appreciate
it. Many did, I realize, but why are so many of them now rushing to
throw off the yoke?

Yes, I realize that the issue is complex and many "higher-level"
problems exist, such as lack of standard libraries, development tools,
etc. But then you have to ask why those problems developed in the
first place. I just think that the root cause of Ada's lack of
popularity, when you get right down to it, is the awkward syntax,
notably ":=", and perhaps to a lesser extent the lack of "+=" type
operators.

Can I prove this? No, but I have a truckload of circumstantial
evidence for it. I've been over this before. Think of the most popular
languages in existence: C, C++, Java, Perl, Python, Fortran, Basic,
COBOL, even Matlab and Mathematica. Every one of them uses "=" for
assigment. Now name one wildly popular language that does *not* use
"=" for assignment. You can't do it. And no, Pascal and Modula are not
what I call wildly popular.

I realize that standard Ada is stuck with ":=", of course. However, I
have developed a relatively simple pre-processor that effectively
implements a dialect of Ada that uses "=". I call it "MyAda". I also
have the inverse pre-processor, so I can go in both directions. With a
few additional utilities, it should be possible for a member of an Ada
devepment team to use MyAda without anyone else on the team ever even
knowing. I realize that this is a long shot, but as I said, I am a bit
obsessive/compulsive.

> I do agree with you that it would be nice to have a notation for
> incrementing a variable without naming that variable twice.
> And I do agree with you that "procedure Inc" is not a good solution
> (in current Ada) because it requires a separate Inc procedure for
> every integer type.

Thanks for acknowledging that.

Re: += in ada

[Wes Groleau]

Russ wrote:
> Yes, I realize that the issue is complex and many "higher-level"
> problems exist, such as lack of standard libraries, development tools,
> etc. But then you have to ask why those problems developed in the
> first place. I just think that the root cause of Ada's lack of
> popularity, when you get right down to it, is the awkward syntax,

I don't think Ada's alleged "awkward syntax"
is a reason for its unpopularity.  I think that's
a rationalization (i.e., excuse) cooked up by folks
who either don't know or won't admit the real reasons
they don't like it.

As for the lack of libraries, the reason is not
Ada's lack of popularity.  The reasons are:

1. Some of the libraries wanted are not in great
    demand in Ada's original primary problem domain.

2. At one time, even though Ada made it very easy
    to re-use code, contract rules made it difficult.

3. At one time, mandated development methods also
    made it difficult to reuse code.  If it didn't
    _exactly_ meet project requirements, the project
    couldn't use it.

4. The safety-mindedness of Ada folks sometimes
    manifested as not trusting anything that didn't
    jump through the exact hoops of "OUR" process.

5. When (3) and (4) did not apply, sometimes
    people thought they did apply.

probably lots more. ...

-- 
Wes Groleau
    "Would the prodigal have gone home if
     the elder brother was running the farm?"
                       -- James Jordan

Re: += in ada

[Hyman Rosen]

Wes Groleau wrote:
> I don't think Ada's alleged "awkward syntax"
> is a reason for its unpopularity.

All I know is that when I first became aware of Ada many
years ago, my reaction was "Oh no! Pascal! Why did it have
to be Pascal?" (or something to that effect, since I guess
Ada predates the Indiana Jones movies). I don't think I
ever recovered from that initial visceral dislike.

> won't admit the real reasons they don't like it.

So what do you think the "real" reasons are?

> 2. At one time, even though Ada made it very easy
>    to re-use code, contract rules made it difficult.

I don't think it's ever been easy to reuse code.
Ariane 5? (ducking :-)

Re: += in ada

[Marin David Condic]

With the initial target being embedded programming for military systems, 
there were some very real problems with Ada: It was too big for many of 
the processors of its time (and still is for a lot of small embedded 
processors). There was a general lack of good quality compilers that 
would target those processors (and you *really* needed very high quality 
code generation - remember all those efficiency things surrounding 
Ariane 4 and the hand optimizations?) Ada missed supporting things that 
were seen as "critical" to embedded programming - unsigned integers, 
and/or/xor on words, etc. (And I'll spare Robert the jab about the lack 
of sqrt :-) Ada promised a lot to embedded developers (Chapter 13) but 
was very late in delivering it. Developers had lots of specialized tools 
surrounding their embedded projects and Ada wasn't there with 
replacements. Ada was ahead of compiler technology and the hardware on 
which to run the compilers and nobody was willing to "subset" the 
language to get some portion of it working reliably & efficiently in a 
reasonable time frame, etc., etc., etc.

Add to this some perceptual problems backed up by reality initially, but 
they took a long time to cure. Various language constructs were viewed 
as inherently inefficient - backed up by poor quality compilers. Ada was 
viewed as outrageously expensive and too grandeose for embedded 
programming - backed up by outrageously expensive compilers and lack of 
implementations for embedded targets. That list goes on too.

Toss in a major factor of psychology: Embedded programmers are (or at 
least tended to be back then - maybe attitudes have shifted) "Bit 
Twiddlers". Basically guys who get tied up in the small stuff and often 
miss the "Big Picture". They were used to dealing in raw words and bytes 
with shifts and rotates and such. Ada brought to it a discipline they 
weren't used to and didn't like as they saw it standing in their way. 
The value of strong typing in particular was not seen as "user 
friendly". They tried to write "Adatran" code and found it difficult. So 
they saw Ada as some obstacle that was being forced on them by people 
who knew nothing about how the job was really done. At that point they 
hated Ada and no amount of fixing other problems with the language was 
going to get them to start liking it.

That and various bad management decisions on the part of the powers that 
be who were trying to create/promote Ada, and you had a pretty horrible 
reputation right out of the starting gate. This reputation spread like 
wildfire and has been *enormously* hard to overcome. Some of it is 
reality and some of it is myth, but in the world of "Marketing" - 
"Perception *IS* Reality".

Hence - back on subject - I see no reason to believe that adding trivial 
syntax changes is going to in any way win over the crowd that hated Ada 
for a hell of a lot bigger things than lack of a "+=" operator.

MDC


Hyman Rosen wrote:
> 
> 
> So what do you think the "real" reasons are?
> 


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

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

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: += in ada

[Wes Groleau]

Marin David Condic wrote:
> which to run the compilers and nobody was willing to "subset" the 
> language to get some portion of it working reliably & efficiently in a 

Janus was willing.  I had a copy runnable on a CP/M
64 K machine.  Never did anything with it.

> The value of strong typing in particular was not seen as "user 
> friendly". They tried to write "Adatran" code and found it difficult. So 

And people on the other extreme, who thought that just
because the language offered something, you had to use it.

I remember one program that had 26 tasks when given
to me.  When I was done with it, it had five, and
still met all its requirements.

-- 
Wes Groleau
    "Lewis's case for the existence of God is fallacious."
"You mean like circular reasoning?"
    "He believes in God.  Therefore, he's fallacious."

Early Ada Mistakes (was: Re: += in ada)

[Marin David Condic]

Wes Groleau wrote:
 > Marin David Condic wrote:
 >
 >> which to run the compilers and nobody was willing to "subset" the
 >> language to get some portion of it working reliably & efficiently
 >> in a
 >
 > Janus was willing.  I had a copy runnable on a CP/M 64 K machine.
 > Never did anything with it.
 >
I owned one of those too for a PC. Also the Telesoft compiler. Both couldn't
figure out how to get generics implemented, so they ended up with
butt-ugly, non-portable kludges in order to make something vaguely
resembling Text_IO work. Eventually, this got fixed, but, as I observed,
it put people off and made them believe that all the promises were just
hype - that Ada *was* just to big and complicated and inefficient and
would never meet its promises of portability.

BTW, I liked the RR product, so please don't throw stones at me Randy!
However, I don't have anything nice to say about Telesoft - mostly for
bad business practices - so those guys are free to go pile sand. Except
they don't exist anymore. Wonder why? ;-)

As for subsets - that was viewed as heresy at the time. Nobody official
wanted to sanction a subset and most of the potential users didn't seem
to want there to be one. In point of fact, subsets got made anyway, but
there was no "conventional" subset anyone could count on and there were
non-portabilities (as I observed with Text_IO). This ought to be a 
"Lesson Learned" - if the vendors are going to end up doing it anyway, 
then its better to accommodate it in some manner so it gets done in a 
*standard* way.

I thought it would be A Good Thing(tm) had there been some kind of
semi-official subset that could have been validated so that a compiler
might have been "Level 1 Compliant". That may have let compiler writers
come out with something that would have met the needs of us guys with
really small target processors and/or inexpensive home computers. We
would have been able to play the game and do so in a way that was
"Portable". As technology improved, vendors might have more easily
become "Level 2 Compliant" and customers could have upgraded as their
hardware grew to meet the needs.

But that's all 20/20 hindsight. Perhaps if we get to have *another* DoD
mandated programming language.... :-)


 >

 >> The value of strong typing in particular was not seen as "user
 >> friendly". They tried to write "Adatran" code and found it
 >> difficult. So
 >
 >
 > And people on the other extreme, who thought that just because the
 > language offered something, you had to use it.
 >

Yup. You still see that today and not just with Ada. People go off and take
a course and get all hyped up about some particular set of features and
have to run off and make use of each and every one in their first program.

We still occasionally see religious wars here over the use of standard
("Predefined" - Sorry Robert.) Integer and Float types. Some folks
believe it is morally wrong under any circumstances *not* to define your
own types for every conceivable use. Others are more lax about it.

I'm in the "Others" category, but I did learn a lesson about not using
the predefined type Integer in an embedded machine where later, when we
needed to meet requirements to guarantee saturation on overflows, I was
unable to override the "+" (etc) operators. Had I defined my own integer
type, I could have done this. Fortunately, it wasn't too hard to review
the code and determine that we were O.K. without it & get waivers from
the requirement.



 > I remember one program that had 26 tasks when given to me.  When I
 > was done with it, it had five, and still met all its requirements.
 >
I recall one that was built by the Special Olympics Software Development
Team at a company that shall remain nameless. They had been sent off to
Object Oriented Programming School (on the Short Bus) and came back and
turned *everything* into a task. As well you can imagine, this
complicated analysis of program behavior immensely. It could have been
done a hell of a lot simpler, but, well, they *were* the Special
Olympics Software Development Team. :-)

MDC

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

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

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Early Ada Mistakes (was: Re: += in ada)

[Robert I. Eachus]

Marin David Condic wrote:

> I thought it would be A Good Thing(tm) had there been some kind of
> semi-official subset that could have been validated so that a compiler
> might have been "Level 1 Compliant". That may have let compiler writers
> come out with something that would have met the needs of us guys with
> really small target processors and/or inexpensive home computers. We
> would have been able to play the game and do so in a way that was
> "Portable". As technology improved, vendors might have more easily
> become "Level 2 Compliant" and customers could have upgraded as their
> hardware grew to meet the needs.

There were actually two, pretty well understood by all compiler 
developers.  The first was the Pascal subset, this was basically 
everything in Ada that was also in Pascal.  A lot of compiler developers 
either modified a Pascal compiler to compile this subset, or built a 
tool to convert from the Pascal subset of Ada into Pascal.

The next step up was the Pascal superset.  This was basically everything 
in Ada except chapters 9 (Tasking), 12 (Generics) and most of 13.  This 
was the language that most compiler developers used--and possibly still 
do--to implement the Ada run-time.  Of course, a lot of people would say 
that some compilers, such as the original Telesoft compiler were only 
useable with the Pascal superset.  I am not one of them.  I never found 
the original Telesoft compiler useable.  But then again, maybe I never 
found the right Pascal subset to use with it.

-- 
                                             Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: Early Ada Mistakes (was: Re: += in ada)

[Marin David Condic]

Yea, there was the "Pascal-Like Subset" that was a starting point for a 
lot of vendors, but a) it wasn't any kind of approved, validated 
standard, so you couldn't be sure of any kind of portability (every 
vendor had their own rules about what they were going to implement) and 
b) there were things that had to be included that were way off of the 
standard in order to make it work. The most obvious was Text_IO: You 
couldn't do I/O for anything except text (numeric types, enumerations, 
etc.) without generic instantiation and, as you observed, that was the 
"Level 2" part. So compilers had to come up with some sort of hack-job 
to give you I/O for floats, integers, etc., without having generics. 
Double-Plus-Ungood for developing anything you hoped to make portable.

I realize it all got fixed eventually, but it *did* leave a bad taste in 
  the mouths of a lot of users. Ada was supposed to be this wonderful 
language that was going to be portable across all machines and all 
compilers - but the wonderful parts were not there and the portability 
was no better - perhaps worse - than your average Fortran or C compiler. 
Disillusionment followed rapidly.

Even today, I think there might be some food-value in a "standard" 
subset that would be aimed at small embedded machines. (Assuming anyone 
wants to try to venture into that market again.) Spark might make a nice 
start - except that it isn't a "Standard". I don't know enough about 
Spark to know if it limits itself to things that would hack the language 
down to something easily targeted to small embedded machines. It just 
might be valuable to have something that could easily fit a small target.

MDC



Robert I. Eachus wrote:
> 
> There were actually two, pretty well understood by all compiler 
> developers.  The first was the Pascal subset, this was basically 
> everything in Ada that was also in Pascal.  A lot of compiler developers 
> either modified a Pascal compiler to compile this subset, or built a 
> tool to convert from the Pascal subset of Ada into Pascal.
> 
> The next step up was the Pascal superset.  This was basically everything 
> in Ada except chapters 9 (Tasking), 12 (Generics) and most of 13.  This 
> was the language that most compiler developers used--and possibly still 
> do--to implement the Ada run-time.  Of course, a lot of people would say 
> that some compilers, such as the original Telesoft compiler were only 
> useable with the Pascal superset.  I am not one of them.  I never found 
> the original Telesoft compiler useable.  But then again, maybe I never 
> found the right Pascal subset to use with it.
> 


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