* Re: Early Ada Mistakes (was: Re: += in ada) [not found] <mailman.181.1066858869.25614.comp.lang.ada@ada-france.org> @ 2003-10-22 21:49 ` Ed Falis 2003-10-23 3:21 ` Alexandre E. Kopilovitch 2003-10-23 7:15 ` Ole-Hjalmar Kristensen 0 siblings, 2 replies; 7+ messages in thread From: Ed Falis @ 2003-10-22 21:49 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Early Ada Mistakes (was: Re: += in ada) 2003-10-22 21:49 ` Early Ada Mistakes (was: Re: += in ada) Ed Falis @ 2003-10-23 3:21 ` Alexandre E. Kopilovitch 2003-10-23 7:15 ` Ole-Hjalmar Kristensen 1 sibling, 0 replies; 7+ messages in thread From: Alexandre E. Kopilovitch @ 2003-10-23 3:21 UTC (permalink / raw) To: comp.lang.ada 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Early Ada Mistakes (was: Re: += in ada) 2003-10-22 21:49 ` Early Ada Mistakes (was: Re: += in ada) Ed Falis 2003-10-23 3:21 ` Alexandre E. Kopilovitch @ 2003-10-23 7:15 ` Ole-Hjalmar Kristensen 1 sibling, 0 replies; 7+ messages in thread From: Ole-Hjalmar Kristensen @ 2003-10-23 7:15 UTC (permalink / raw) >>>>> "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 ^ permalink raw reply [flat|nested] 7+ messages in thread
[parent not found: <mailman.180.1066854383.25614.comp.lang.ada@ada-france.org>]
* Re: Early Ada Mistakes (was: Re: += in ada) [not found] <mailman.180.1066854383.25614.comp.lang.ada@ada-france.org> @ 2003-10-22 20:58 ` Ed Falis 0 siblings, 0 replies; 7+ messages in thread From: Ed Falis @ 2003-10-22 20:58 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: += in ada @ 2003-10-07 11:56 Lutz Donnerhacke 2003-10-15 13:25 ` Hyman Rosen 0 siblings, 1 reply; 7+ messages in thread From: Lutz Donnerhacke @ 2003-10-07 11:56 UTC (permalink / raw) * 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: += in ada @ 2003-10-15 13:25 ` Hyman Rosen 2003-10-15 14:04 ` Vinzent 'Gadget' Hoefler 0 siblings, 1 reply; 7+ messages in thread From: Hyman Rosen @ 2003-10-15 13:25 UTC (permalink / raw) 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." ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: += in ada 2003-10-15 13:25 ` Hyman Rosen @ 2003-10-15 14:04 ` Vinzent 'Gadget' Hoefler 2003-10-15 15:19 ` Hyman Rosen 0 siblings, 1 reply; 7+ messages in thread From: Vinzent 'Gadget' Hoefler @ 2003-10-15 14:04 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: += in ada 2003-10-15 14:04 ` Vinzent 'Gadget' Hoefler @ 2003-10-15 15:19 ` Hyman Rosen 2003-10-16 5:05 ` Russ 0 siblings, 1 reply; 7+ messages in thread From: Hyman Rosen @ 2003-10-15 15:19 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: += in ada 2003-10-15 15:19 ` Hyman Rosen @ 2003-10-16 5:05 ` Russ 2003-10-16 13:43 ` Hyman Rosen 0 siblings, 1 reply; 7+ messages in thread From: Russ @ 2003-10-16 5:05 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: += in ada 2003-10-16 5:05 ` Russ @ 2003-10-16 13:43 ` Hyman Rosen 2003-10-16 23:57 ` Robert I. Eachus 0 siblings, 1 reply; 7+ messages in thread From: Hyman Rosen @ 2003-10-16 13:43 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: += in ada 2003-10-16 13:43 ` Hyman Rosen @ 2003-10-16 23:57 ` Robert I. Eachus 2003-10-17 6:22 ` Russ 0 siblings, 1 reply; 7+ messages in thread From: Robert I. Eachus @ 2003-10-16 23:57 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: += in ada 2003-10-16 23:57 ` Robert I. Eachus @ 2003-10-17 6:22 ` Russ 2003-10-17 15:48 ` Robert I. Eachus 0 siblings, 1 reply; 7+ messages in thread From: Russ @ 2003-10-17 6:22 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: += in ada 2003-10-17 6:22 ` Russ @ 2003-10-17 15:48 ` Robert I. Eachus 2003-10-19 1:15 ` Russ 0 siblings, 1 reply; 7+ messages in thread From: Robert I. Eachus @ 2003-10-17 15:48 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: += in ada 2003-10-17 15:48 ` Robert I. Eachus @ 2003-10-19 1:15 ` Russ 2003-10-19 23:19 ` Robert A Duff 0 siblings, 1 reply; 7+ messages in thread From: Russ @ 2003-10-19 1:15 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: += in ada 2003-10-19 1:15 ` Russ @ 2003-10-19 23:19 ` Robert A Duff 2003-10-20 6:16 ` Russ 0 siblings, 1 reply; 7+ messages in thread From: Robert A Duff @ 2003-10-19 23:19 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: += in ada 2003-10-19 23:19 ` Robert A Duff @ 2003-10-20 6:16 ` Russ 2003-10-21 0:40 ` Wes Groleau 0 siblings, 1 reply; 7+ messages in thread From: Russ @ 2003-10-20 6:16 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: += in ada 2003-10-20 6:16 ` Russ @ 2003-10-21 0:40 ` Wes Groleau 2003-10-21 3:45 ` Hyman Rosen 0 siblings, 1 reply; 7+ messages in thread From: Wes Groleau @ 2003-10-21 0:40 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: += in ada 2003-10-21 0:40 ` Wes Groleau @ 2003-10-21 3:45 ` Hyman Rosen 2003-10-21 12:45 ` Marin David Condic 0 siblings, 1 reply; 7+ messages in thread From: Hyman Rosen @ 2003-10-21 3:45 UTC (permalink / raw) 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 :-) ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: += in ada 2003-10-21 3:45 ` Hyman Rosen @ 2003-10-21 12:45 ` Marin David Condic 2003-10-22 0:14 ` Wes Groleau 0 siblings, 1 reply; 7+ messages in thread From: Marin David Condic @ 2003-10-21 12:45 UTC (permalink / raw) 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 ====================================================================== ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: += in ada 2003-10-21 12:45 ` Marin David Condic @ 2003-10-22 0:14 ` Wes Groleau 2003-10-22 12:31 ` Early Ada Mistakes (was: Re: += in ada) Marin David Condic 0 siblings, 1 reply; 7+ messages in thread From: Wes Groleau @ 2003-10-22 0:14 UTC (permalink / raw) 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." ^ permalink raw reply [flat|nested] 7+ messages in thread
* Early Ada Mistakes (was: Re: += in ada) 2003-10-22 0:14 ` Wes Groleau @ 2003-10-22 12:31 ` Marin David Condic 2003-10-22 20:05 ` Robert I. Eachus 0 siblings, 1 reply; 7+ messages in thread From: Marin David Condic @ 2003-10-22 12:31 UTC (permalink / raw) 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 ====================================================================== ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Early Ada Mistakes (was: Re: += in ada) 2003-10-22 12:31 ` Early Ada Mistakes (was: Re: += in ada) Marin David Condic @ 2003-10-22 20:05 ` Robert I. Eachus 2003-10-23 4:47 ` Marin David Condic 0 siblings, 1 reply; 7+ messages in thread From: Robert I. Eachus @ 2003-10-22 20:05 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Early Ada Mistakes (was: Re: += in ada) 2003-10-22 20:05 ` Robert I. Eachus @ 2003-10-23 4:47 ` Marin David Condic 0 siblings, 0 replies; 7+ messages in thread From: Marin David Condic @ 2003-10-23 4:47 UTC (permalink / raw) 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 ====================================================================== ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2003-10-23 7:15 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <mailman.181.1066858869.25614.comp.lang.ada@ada-france.org> 2003-10-22 21:49 ` Early Ada Mistakes (was: Re: += in ada) Ed Falis 2003-10-23 3:21 ` Alexandre E. Kopilovitch 2003-10-23 7:15 ` Ole-Hjalmar Kristensen [not found] <mailman.180.1066854383.25614.comp.lang.ada@ada-france.org> 2003-10-22 20:58 ` Ed Falis 2003-10-07 11:56 += in ada Lutz Donnerhacke 2003-10-15 13:25 ` Hyman Rosen 2003-10-15 14:04 ` Vinzent 'Gadget' Hoefler 2003-10-15 15:19 ` Hyman Rosen 2003-10-16 5:05 ` Russ 2003-10-16 13:43 ` Hyman Rosen 2003-10-16 23:57 ` Robert I. Eachus 2003-10-17 6:22 ` Russ 2003-10-17 15:48 ` Robert I. Eachus 2003-10-19 1:15 ` Russ 2003-10-19 23:19 ` Robert A Duff 2003-10-20 6:16 ` Russ 2003-10-21 0:40 ` Wes Groleau 2003-10-21 3:45 ` Hyman Rosen 2003-10-21 12:45 ` Marin David Condic 2003-10-22 0:14 ` Wes Groleau 2003-10-22 12:31 ` Early Ada Mistakes (was: Re: += in ada) Marin David Condic 2003-10-22 20:05 ` Robert I. Eachus 2003-10-23 4:47 ` Marin David Condic
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox