* Re: "Subtract C, add Ada" [not found] <3fdcoi$chn@miranda.gmrc.gecm.com> @ 1995-01-20 5:01 ` Samuel Mize 1995-01-20 22:07 ` Garlington KE 0 siblings, 1 reply; 85+ messages in thread From: Samuel Mize @ 1995-01-20 5:01 UTC (permalink / raw) In article <3fdcoi$chn@miranda.gmrc.gecm.com>, R.A.L Williams <bill@valiant> wrote: > >Robert Dewar wrote.. >> Bill comments that for his points 3. and 4. >> >> 3. uninitialised pointer access >> 4. pointer references to local variables in defunct procedures >> >> "The syntax of Ada .. does not really address 3. or 4." >> >> Taking point 3, it is impossible to have an uninitialized pointer in Ada, >> all pointers are initialized to null, and any attempt to use a null pointer, >> i.e. to dereference it, will cause a constraint error. Seems like pretty >> complete protection to me. > >Yes, you're right, Ada *guarantees* a run time crash, in C/C++ it's just very >likely. ... The rest of your post suggests that you understand this, but I will point it out for the less-versed souls reading this newsgroup: Ada does not guarantee a run-time crash. It guarantees that the program will identify, and respond to, the error. If you have exception handlers properly in place, they can do some default action; e.g., you can drop to a degraded mode. In C/C++, you can (1) dereference a bad value and merrily use it (2) write to an arbitrary address (e.g., the OS or your instruction pointer), creating phantom bugs in other code (3) seg error (core dump). Even a well-designed C program can provide these exciting opportunities, since the occasional human error is unavoidable, not to mention hardware failures. In Ada, you have to make the original error, *and* not provide a fall-back in your exception handlers. Only if you do both will you get a run-time crash. Otherwise, you will get a run-time performance degradation. >likely. It's still not a compile time check so you're relying on the >quality of your run time environment to tie down where the problem >occurs. ... True. Wish we could solve the problem of uninitialized variables, 'cause then we'd know how to solve undecidable problems. >occurs. Of course, in embedded systems you don't want *any* exceptions, >no matter how cleanly you handle them! Sure you do, if there was a programmer error, or a hardware glitch, or a bad memory location, etc. These are the things you don't want. Given that you can't eliminate those, oh *boy* do you want exceptions, given the alternative (core dump at 30,000 feet -- how do I reboot my F-16?!?!?!?) >... I was just trying to point out that using Ada is no substitute >for good engineering practice in design and coding. > Very true. I'm pointing out that Ada provides tools for good engineering practice that are not available in C/C++ . > > >Bill Williams > Sam Mize - smize@starbase.neosoft.com ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: "Subtract C, add Ada" 1995-01-20 5:01 ` "Subtract C, add Ada" Samuel Mize @ 1995-01-20 22:07 ` Garlington KE 1995-01-24 5:02 ` R_Tim_Coslet 0 siblings, 1 reply; 85+ messages in thread From: Garlington KE @ 1995-01-20 22:07 UTC (permalink / raw) Samuel Mize (smize@Starbase.NeoSoft.COM) wrote: : Sure you do, if there was a programmer error, or a hardware glitch, : or a bad memory location, etc. These are the things you don't want. : Given that you can't eliminate those, oh *boy* do you want exceptions, : given the alternative (core dump at 30,000 feet -- how do I reboot : my F-16?!?!?!?) Actually, as one of the software engineers who developed the F-16 digital flight control system (as well as the YF-22A flight control system), I can say with confidence that you _don't_ want exceptions for a human programmer error, since no one has figured out an adequate response to them in a dynamic feedback system like a flight control system. It doesn't matter what happens in the other cases since there is physical redundancy and output monitoring as a part of the total system. However, for systems with the capability to degrade cleanly, exceptions are a very good thing and in fact are widely used in embedded avionics software. -------------------------------------------------------------------- Ken Garlington GarlingtonKE@lfwc.lockheed.com F-22 Computer Resources Lockheed Fort Worth Co. If LFWC or the F-22 program has any opinions, they aren't telling me. ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: "Subtract C, add Ada" 1995-01-20 22:07 ` Garlington KE @ 1995-01-24 5:02 ` R_Tim_Coslet 0 siblings, 0 replies; 85+ messages in thread From: R_Tim_Coslet @ 1995-01-24 5:02 UTC (permalink / raw) >Samuel Mize (smize@Starbase.NeoSoft.COM) wrote: >: Sure you do, if there was a programmer error, or a hardware glitch, >: or a bad memory location, etc. These are the things you don't want. >: Given that you can't eliminate those, oh *boy* do you want exceptions, >: given the alternative (core dump at 30,000 feet -- how do I reboot >: my F-16?!?!?!?) > >However, for systems with the capability to degrade cleanly, exceptions are >a very good thing and in fact are widely used in embedded avionics software. > >-------------------------------------------------------------------- The software I'm currently working on for a cockpit display system was specificly designed to USE exceptions to gracefully degrade the system functionality in the presence of serious hardware problems. Each 16ms display frame consists of a series of calls to the various CSCs controlling the sybsystems of the display. If no fatal hardware problems occur it runs completely without exceptions. But in the case of fatal hardware failures (e.g. inability to access a subsystem) an exception is raised within that CSC, terminating any further processing for that subsystem for that frame, letting the other CSCs have the "extra" unused time. Thus the system will gracefully degrade, mo matter how deep it had gotten into the CSC for a given subsystem when the hardware died. No exception is ever allowed to propagate outside of the top level CSC in which it occured to the main task. The exception processing is a little expensive (about 1ms/exception), but with several CSCs consuming 4 or 5ms in normal operation and the overall time budget a bit tight, the exception usually saves time making the remaining 3ms or more available to other CSCs immediately in that frame when such a failure occurs. Same thing with a serious programmer error that was not detected in test: the affected CSC dies gracefully and the system functionality degrades... BUT the REST of the system continues to function! Such graceful degradation in function would have been MUCH harder to implement in this system WITHOUT exceptions. R. Tim Coslet Usenet: R_Tim_Coslet@cup.portal.com technology, n. domesticated natural phenomena ^ permalink raw reply [flat|nested] 85+ messages in thread
* "Subtract C, add Ada" @ 1995-02-10 13:49 R.A.L Williams 0 siblings, 0 replies; 85+ messages in thread From: R.A.L Williams @ 1995-02-10 13:49 UTC (permalink / raw) In article <3h1lfl$lr4@Starbase.NeoSoft.COM> Samuel Mize wrote: : In article <3gsr0e$oin@miranda.gmrc.gecm.com>, : R.A.L Williams <bill@valiant> wrote: : >Never mind all that code, the main feature of the C code was that, at : >the termination of the loop, the variable 'c' contained the character : >which caused the loop to terminate. Are you suggesting a 'LastChar' : >function as well. : In the Ada rewrite I provided, "at the termination of the loop, the : variable 'c' contained the character which caused the loop to : terminate." However, it's contained in the package Files_Like_C. Yes, I'm sorry. You're absolutely write. In that case, I see nothing wrong with the code, but, are you suggesting that that much code is more 'readable' than the C equivalent. OK, this is a relatively trivial example. Anyone who can't understand your code probably shouldn't be reading it anyway! Nonetheless the point remains that Ada code is more verbose than C, and this can IMO obscure, rather than enhance, readability. : We're now discussing a difference in design philosophy in standard : I/O packages, not a difference in the languages. My point was that : you could implement either I/O design philosophy in Ada. Mr. Ichbia : et al picked a different design for their standard I/O package, : named Text_Io, so you will have to code your own replacement if you : want to use C-style I/O. Just as if you wanted to use C-style I/O : in PL/I or Fortran. You *can* do this. I wasn't particularly concerned in my original postings about specific features such as I/O libraries. I worry more about the structure of Ada giving me more 'hoops to jump through' to the extent that code is *less* readable. Having been involved in a fair number of code walkthroughs recently, 'reviewer fatigue' is an important issue. : Sam Mize - smize@starbase.neosoft.com Bill Williams ^ permalink raw reply [flat|nested] 85+ messages in thread
[parent not found: <3gsr0e$oin@miranda.gmrc.gecm.com>]
* Re: "Subtract C, add Ada" [not found] <3gsr0e$oin@miranda.gmrc.gecm.com> @ 1995-02-07 16:58 ` Mark S. Hathaway 1995-02-08 7:39 ` Travis C. Porco 0 siblings, 1 reply; 85+ messages in thread From: Mark S. Hathaway @ 1995-02-07 16:58 UTC (permalink / raw) > In article <3gsr0e$oin@miranda.gmrc.gecm.com>, > bill@valiant (R.A.L Williams) writes: > : In article <3gnnfk$bfa@Starbase.NeoSoft.COM> Samuel Mize wrote: > [summary of previous discussions...] > : >...The original > : >C code was: > : > while ( (c = getchar()) == ' ' ) { /* count spaces */ } > : To make truly equivalent Ada code, you would need a function, > : probably in a shared file package, that assigns and returns > : the next character from the file: > : > : package Files_Like_C is > : C: character; > : function Next_Char return character; > : end Files_Like_C; > : > : with Text_Io; use Text_Io; > : package body Files_Like_C is > : function Next_Char return character is > : begin > : if End_Of_File then > : C := Ascii.Nul; -- no EOF character so using NUL > : else -- to emulate the C string terminator > : Get (C); > : return C; > : end if; > : end Next_Char; > : end Files_Like_C; > : > : Once all this infrastructure has been set up, you can code: > : > : while (Next_Char = ' ') loop > : null; -- count spaces here if needed > : end loop; > : > : Before anyone says "but look at all that code!" remember, we > : are recoding the interface to the standard file package, on > : the assumption that there is a compelling reason to put > : Next_Char into expressions. > Never mind all that code, the main feature of the C code was that, at > the termination of the loop, the variable 'c' contained the character > which caused the loop to terminate. Are you suggesting a 'LastChar' > function as well. > > Look, Ada's a great language. Its got lots of innovative features: > built in tasking, compilable package specifications, etc. but, to me, > and, I suspect, to numerous others, the dedication with which 'unsafe' > constructs was eliminated went a little too far, to the detriment > of readability. I feel certain that the C example could be emulated in Ada or many other languages. What is painfully obvious now is that the author of the C code didn't comment it in any way to say precisely what he/she was trying to achieve with that code. If counting spaces was intended, as many of us thought, then the Ada "version" does quite nicely. If the character gotten on the last go around is needed for later then where is the C code which uses that character. Without some followup code it isn't obvious to anyone that that last character will be used in the future, and yet the poster says this was "the main feature of the C code". I can hardly agree. The C version doesn't check for an eof() condition before reading stdin. The author of the Ada code added that check. I'm not certain it's necessry or correct with the object in (standard input stream). Should it ever be at eof()? This is a design decision rather than a programmer's choice. proc count_chars () is var c is character := NUL; count is integer := 0; begin loop c := in.getch(); -- could also be written: c.assign(in.getch()); if c <> ' ' then exit; -- drops out of the loop else count.increment(1); end; end; end count_chars; Anyone can cram it into a smaller form if they like... loop c := in.getch(); if c <> ' ' then exit; else count.increment(1); end; end; but, that's hardly the point. Mark S. Hathaway <hathawa2@marshall.edu> ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: "Subtract C, add Ada" 1995-02-07 16:58 ` Mark S. Hathaway @ 1995-02-08 7:39 ` Travis C. Porco 1995-02-08 16:07 ` Fred J. McCall 0 siblings, 1 reply; 85+ messages in thread From: Travis C. Porco @ 1995-02-08 7:39 UTC (permalink / raw) hathawa2@marshall.edu (Mark S. Hathaway) writes: > Anyone can cram it into a smaller form if they like... > loop c := in.getch(); if c <> ' ' then exit; else > count.increment(1); end; end; > but, that's hardly the point. Oh no, terseness is the sine qua non of a programming language. Characters are very expensive and should never be wasted. I know of whole programming projects which have been late due to a shortage of "a"'s. When you add in the high import tariffs on expensive letters from abroad, you see that short terse syntax structures like that in C are clearly superior. Further, studies of programmer productivity have shown that slow typing speed is the single largest obstacle to being a good programmer. Terse languages help the typistically impaired compete in the dog-eat-dog world of programming. Terse languages often have a beautiful mathematical syntax which is very appealing and provides programmers a way to display their talents. For instance, while(++p = ++q) ; is clearly impressive, whereas copyString(destinationFileName,targetFileName) ; is so obvious that anyone could have done it. Similarly, cin>>a1>>a2; and z+=3; demonstrate the programmer's intellectual talents and good taste far better than the pedestrian get list(firstName, lastName) ; and add 3 to expectedTime Computers are easily able to count things with no error and to keep track of scoping rules, and a good programmer naturally will try to emulate the machine in this regard. "Whoever writes the function in the fewest characters wins!" Travis | "Before there were friendly operating system interfaces Porco | like the [OS/2] Workplace Shell, computer users | communicated with a computer using ... instructions | called *commands*." User's Guide to OS/2 Warp, p. 154 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: "Subtract C, add Ada" 1995-02-08 7:39 ` Travis C. Porco @ 1995-02-08 16:07 ` Fred J. McCall 1995-02-08 21:30 ` Garlington KE 0 siblings, 1 reply; 85+ messages in thread From: Fred J. McCall @ 1995-02-08 16:07 UTC (permalink / raw) You know, I've sat and read this thread for quite some time now and all the Ada advocates have convinced me of one thing: If you spent as much time bashing on Ada vendors about the quality and price of the tools as you spend bashing on languages that people prefer to Ada, more people might prefer Ada. ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: "Subtract C, add Ada" 1995-02-08 16:07 ` Fred J. McCall @ 1995-02-08 21:30 ` Garlington KE 0 siblings, 0 replies; 85+ messages in thread From: Garlington KE @ 1995-02-08 21:30 UTC (permalink / raw) Fred J. McCall (fjm@ti.com) wrote: : You know, I've sat and read this thread for quite some time now and all the : Ada advocates have convinced me of one thing: : If you spent as much time bashing on Ada vendors about the quality and price : of the tools as you spend bashing on languages that people prefer to Ada, more : people might prefer Ada. Some of us do. I get to go to Pittsburgh next week for just that reason. Oh joy. -------------------------------------------------------------------- Ken Garlington GarlingtonKE@lfwc.lockheed.com F-22 Computer Resources Lockheed Fort Worth Co. If LFWC or the F-22 program has any opinions, they aren't telling me. ^ permalink raw reply [flat|nested] 85+ messages in thread
* "Subtract C, add Ada" @ 1995-01-31 9:34 R.A.L Williams 1995-02-01 16:45 ` Charles H. Sampson 0 siblings, 1 reply; 85+ messages in thread From: R.A.L Williams @ 1995-01-31 9:34 UTC (permalink / raw) In article <1995Jan23.154631.6702@sei.cmu.edu> you wrote: : In article <3fo2ot$su2@miranda.gmrc.gecm.com> bill@valiant (R.A.L Williams) writes: : I guess I'm about to show my ignorance of C, but I'm very confused : bt this post. : > 1. It allows your code to be more compact. : > NB DONT confuse compactness with poor layout! I find that, for example: : > : > while ((c = getchar()) == ' ') : > { : > /* count spaces */ : > } : > : > is clearer than the 'expanded' alternative (to *me* :-). : Nope, I find this totally unclear. Who's counting? Unless I've missed : an invisible declaration, initialisation, and increment, the above : code *doesn't* count spaces, it skips them. And if that is its : purpose, what's the point of the variable 'c'? Why not just say OK, I'm sorry, I didn't think I needed to spell things out in gratuitous detail, so I just indicated the position and sort of code that might be used by a comment. I haven't shown code that replaces spaces in an output stream with text from the Koran either, sorry! : Note also that if there are *no more* non space characters, the C code : dies in an infinite loop, while the Ada code automatically does the : right thing, namely raises the END_ERROR exception. I'm afraid you *are* showing your ignorance of C. On each iteration of the loop if the next input character is not a space (and this includes EOF) then the loop terminates cleanly. : >[example deleted] : Again, I don't see it. The Ada code makes it clear that *corresponding* : elements of the array Q are being copied into P - though, of course, : a real Ada programmer (TM) would have written just P := Q. The C code : doesn't make that clear - you're going to have to ferret out the : initialisations of p and q to determine that. And if you worry about : the correctness of the copy - for instance, whether P and Q are the : same size - that's surely going to be a lot easier to establish in Ada. Again, a simplified example to illustrate a principle. The point is that the less I have to move my eyes, or flip over pages, when reading/reviewing code, the more likely I am to understand it and find any bugs. You're quite right, P := Q is an event more compact representation and I approve (the Bill Williams official statement of approval!). Bill Williams ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: "Subtract C, add Ada" 1995-01-31 9:34 R.A.L Williams @ 1995-02-01 16:45 ` Charles H. Sampson 0 siblings, 0 replies; 85+ messages in thread From: Charles H. Sampson @ 1995-02-01 16:45 UTC (permalink / raw) In article <3gl06i$s03@miranda.gmrc.gecm.com>, R.A.L Williams <bill@valiant> wrote: >In article <1995Jan23.154631.6702@sei.cmu.edu> you(?) wrote: >: >: Again, I don't see it. The Ada code makes it clear that *corresponding* >: elements of the array Q are being copied into P - though, of course, >: a real Ada programmer (TM) would have written just P := Q. The C code >: doesn't make that clear - you're going to have to ferret out the >: initialisations of p and q to determine that. And if you worry about >: the correctness of the copy - for instance, whether P and Q are the >: same size - that's surely going to be a lot easier to establish in Ada. > >Again, a simplified example to illustrate a principle. The point is that >the less I have to move my eyes, or flip over pages, when reading/reviewing ^^^ ^^^^ ^ ^^^^ ^^ ^^^^ ^^ ^^^^ ^^ ^^^^ ^^^^ ^^^^^ >code, the more likely I am to understand it and find any bugs. You're >quite right, P := Q is an event more compact representation and I approve >(the Bill Williams official statement of approval!). The marked phrases are what many of us Ada fans are talking about when we use the word _readability_. P := Q unambiguously shows that the value of Q is being assigned to P. To repeat you's statement, *p++ = *q++ simply says that whatever q was pointing to gets copied to whatever p is pointing to, after which both are modified to point to the "next" thing. Depending on the complexity of the code, it can take a tremendous amount of ferreting about, moving eyes and flipping pages, to discover what p and q are pointing to. Charlie ^ permalink raw reply [flat|nested] 85+ messages in thread
* "Subtract C, add Ada" @ 1995-01-23 8:49 R.A.L Williams 1995-01-25 23:18 ` Charles H. Sampson 0 siblings, 1 reply; 85+ messages in thread From: R.A.L Williams @ 1995-01-23 8:49 UTC (permalink / raw) In article <3feevh$615@gnat.cs.nyu.edu> Robert Dewar wrote: : "Dennis Ritchie once said in an interview that there is *nothing* in the : C language that keeps compiler writers from issuing stringent warnings : about stuff that most Ada people take for granted." : Dennis may have said this, but it is misleading. Yes, there is stuff that : Ada people take for granted that C compilers could (and in some compilers : *do*) check for. : But there are lots of things that Ada people take for granted that cannot : be checked in C, there just isn't enough information. C has no separation : of scalar types, no ranges on scalar types, and the ubquitous use of : pointers, and their similarity to arrays means that sophisticated aliasing : analysis is required to even approximate the type checking that occurs : in the context of access types in Ada. There are many other examples. Ranges - no, but my Microsoft C compiler certainly *does* warn me when I - mix signed and unsigned integers (of course, Ada83 doesn't have unsigned) - assign the result of 'long' expressions to shorts or chars etc. - perform 'unchecked conversion' between integers and pointers There are probably other things as well, but these are certainly some of the gripes it comes up with when I try to port typical UNIX C code to WIN32. I agree with Dennis Ritchie, If I go to the trouble of typedef'ing a new type, there is nothing to stop the compiler from griping at me if I do something inappropriate with it. This is mainly a compiler issue, not a language issue. Bill Williams ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: "Subtract C, add Ada" 1995-01-23 8:49 R.A.L Williams @ 1995-01-25 23:18 ` Charles H. Sampson 0 siblings, 0 replies; 85+ messages in thread From: Charles H. Sampson @ 1995-01-25 23:18 UTC (permalink / raw) In article <3fvqj5$ofr@miranda.gmrc.gecm.com>, R.A.L Williams <bill@valiant> wrote: >In article <3feevh$615@gnat.cs.nyu.edu> Robert Dewar wrote: >: ... there are lots of things that Ada people take for granted that cannot >: be checked in C, there just isn't enough information. C has no separation >: of scalar types, no ranges on scalar types, and the ubquitous use of >: pointers, and their similarity to arrays means that sophisticated aliasing >: analysis is required to even approximate the type checking that occurs >: in the context of access types in Ada. There are many other examples. > >Ranges - no, but my Microsoft C compiler certainly *does* warn me when I > - mix signed and unsigned integers (of course, Ada83 doesn't have unsigned) > - assign the result of 'long' expressions to shorts or chars etc. > - perform 'unchecked conversion' between integers and pointers What is it warning you about? All three of these are reasonable things to do (o. k., the third is a little shady), so is getting a warn- ing from the compiler about them really beneficial. Typically, a pro- liferation of such noisy warnings can cause the programmer to overlook an important compiler message. I'm not sure what you mean by "mixing" signed and unsigned integers, but if they come from the same base type, why shouldn't they be "mixed"? They are just integers, after all. If you mean assigning a value from a signed (sub)type to an object of an unsigned (sub)type, then Ada will warn you about it, by means of an exception, when you do it wrong but will be silent as long as you do it right. The same thing will happen if you assign a value from a (sub)type having a big range to an object of a (sub)type having a smaller range, or to an object of type Character (after you've done all the necessary ex- plicit conversions). Finally, if you want to perform an unchecked conversion from integer to pointer, or vice versa, in Ada you have to use a syntax that basically tells the compiler that you know what you're doing. I don't know about you, but I sure wouldn't look very kindly on a compiler that warns me in such a case that I might not know what I'm doing. ^ permalink raw reply [flat|nested] 85+ messages in thread
* "Subtract C, add Ada" @ 1995-01-20 10:20 R.A.L Williams 1995-01-20 13:22 ` Renaud HEBERT ` (3 more replies) 0 siblings, 4 replies; 85+ messages in thread From: R.A.L Williams @ 1995-01-20 10:20 UTC (permalink / raw) In article <3f5s92$3id@info.epfl.ch> you wrote: : In article <3f4mbe$rud@cronkite.seas.gwu.edu>, dobrien@seas.gwu.edu (David O'Brien) writes: : |> R.A.L Williams (bill@valiant) wrote: : |> : My experience of writing software and running software projects in C : |> : highlights four common low-level C errors: : |> : 1. = instead of == and vice versa : |> : |> I have to wonder. What if C defined the logical equals operator to be : |> "=" and the assignment operator to be ":=" just like Ada, Algol, Pascal, : |> Modula-x, etc? Would this error still exist??? : The problem is in the language definition, not in the choic of symbols. : C is one of the rare language I use to allow having an assignment after : the if statement. All other languages only allow for a boolean test. : I never saw a good reason for allowing this. I think there are three reasons: 1. It allows your code to be more compact. Many people think this is a disadvantage, and so it is if the code will be read by comparative novices, but it can improve readability to C experts who are expecting such tricks. NB DONT confuse compactness with poor layout! I find that, for example: while ((c = getchar()) == ' ') { /* count spaces */ } is clearer than the 'expanded' alternative (to *me* :-). 2. All expressions in C have a value. Conditional tests succeed on non-zero and fail on zero. Therefore, to maintain orthogonality, as far as possible, there is no reason to exclude an assignment expression from a condition. 3. Finally, I suspect, this can simplify the optimisation algorithms in the compiler. Personally, the lack of this sort of compactness in Ada, and things like pre- and post-increment/decrement are one of my minor gripes about the language. OK, its no big thing to write: P(I) := Q(I); I := I + 1; instead of *p++ = *q++; but I actually *do* find the C representation easier/better etc. (perhaps I'm wierd?) : -- : Laurent Gasser (gasser@dma.epfl.ch) : Computers do not solve problems, they execute solutions. : I know very few ideas worth dying for, none is worth killing. Very true, but quite a few are worth a pint in the pub. Bill Williams ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: "Subtract C, add Ada" 1995-01-20 10:20 R.A.L Williams @ 1995-01-20 13:22 ` Renaud HEBERT 1995-01-24 3:35 ` David Moore 1995-01-24 20:23 ` N. Mellor 1995-01-21 15:18 ` Robert Dewar ` (2 subsequent siblings) 3 siblings, 2 replies; 85+ messages in thread From: Renaud HEBERT @ 1995-01-20 13:22 UTC (permalink / raw) In article <3fo2ot$su2@miranda.gmrc.gecm.com>, bill@valiant (R.A.L Williams) writes: |> |> In article <3f5s92$3id@info.epfl.ch> you wrote: |> : In article <3f4mbe$rud@cronkite.seas.gwu.edu>, dobrien@seas.gwu.edu (David O'Brien) writes: |> : |> R.A.L Williams (bill@valiant) wrote: |> : |> : My experience of writing software and running software projects in C |> : |> : highlights four common low-level C errors: |> : |> : 1. = instead of == and vice versa |> : |> |> : |> I have to wonder. What if C defined the logical equals operator to be |> : |> "=" and the assignment operator to be ":=" just like Ada, Algol, Pascal, |> : |> Modula-x, etc? Would this error still exist??? |> |> : The problem is in the language definition, not in the choic of symbols. |> : C is one of the rare language I use to allow having an assignment after |> : the if statement. All other languages only allow for a boolean test. |> |> : I never saw a good reason for allowing this. |> |> I think there are three reasons: |> 1. It allows your code to be more compact. Many people think this is |> a disadvantage, and so it is if the code will be read by comparative |> novices, but it can improve readability to C experts who are |> expecting such tricks. |> |> NB DONT confuse compactness with poor layout! I find that, for example: |> |> while ((c = getchar()) == ' ') |> { |> /* count spaces */ |> } |> |> is clearer than the 'expanded' alternative (to *me* :-). |> |> 2. All expressions in C have a value. Conditional tests succeed on |> non-zero and fail on zero. Therefore, to maintain orthogonality, |> as far as possible, there is no reason to exclude an assignment |> expression from a condition. |> |> 3. Finally, I suspect, this can simplify the optimisation algorithms |> in the compiler. |> |> Personally, the lack of this sort of compactness in Ada, and things like |> pre- and post-increment/decrement are one of my minor gripes about the |> language. OK, its no big thing to write: |> |> P(I) := Q(I); |> I := I + 1; |> |> instead of |> |> *p++ = *q++; |> |> but I actually *do* find the C representation easier/better etc. (perhaps |> I'm wierd?) Even if I like C, I think that this ++ is ugly and I'm glad that there isn't such a thing in Ada. On the other hand what do you think about the operators += *= ... They make thing shorter AND easier to read, a += 5; means exactly add 5 to a. So don't you think that these construct have their place in Ada. |> |> : -- |> : Laurent Gasser (gasser@dma.epfl.ch) |> : Computers do not solve problems, they execute solutions. |> |> : I know very few ideas worth dying for, none is worth killing. |> |> Very true, but quite a few are worth a pint in the pub. |> |> Bill Williams |> -- Renaud HEBERT e-mail: Renaud.Hebert@prism.uvsq.fr ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: "Subtract C, add Ada" 1995-01-20 13:22 ` Renaud HEBERT @ 1995-01-24 3:35 ` David Moore 1995-01-25 5:38 ` Robert Dewar 1995-01-28 16:35 ` Jules 1995-01-24 20:23 ` N. Mellor 1 sibling, 2 replies; 85+ messages in thread From: David Moore @ 1995-01-24 3:35 UTC (permalink / raw) [somebody wrote] >|> Personally, the lack of this sort of compactness in Ada, and things like >|> pre- and post-increment/decrement are one of my minor gripes about the >|> language. OK, its no big thing to write: >|> >|> P(I) := Q(I); >|> I := I + 1; >|> >|> instead of >|> >|> *p++ = *q++; >|> >|> but I actually *do* find the C representation easier/better etc. (perhaps >|> I'm wierd?) >Even if I like C, I think that this ++ is ugly and I'm glad that there isn't such >a thing in Ada. On the other hand what do you think about the operators += *= ... >They make thing shorter AND easier to read, a += 5; means exactly add 5 to a. >So don't you think that these construct have their place in Ada. The short circuit forms are kind of useful. On the other hand, what does this do? int j=0; int f() { return j++; } main () { int a[10]; .... a[f()]+=1; Is it the same or different to: a[f()]=a[f()]+1; ? I believe f() gets called once. I would have to get out the standrd to be 100% sure. It is also easy to write abominations like: -- search the table while (a[i++]!=b); Whenever you use post-increment in a condition, you always have to stop and wonder about your post-condition - I find it easier to always write the loop out in full. Shorthand forms can be like a bathtub containing two inches of water - not enough to soak, but enough to drown. ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: "Subtract C, add Ada" 1995-01-24 3:35 ` David Moore @ 1995-01-25 5:38 ` Robert Dewar 1995-01-28 16:35 ` Jules 1 sibling, 0 replies; 85+ messages in thread From: Robert Dewar @ 1995-01-25 5:38 UTC (permalink / raw) Oh no! don't say that we are going to have this thread deteriorate into "look at this weird C code and tell me what it does". Surely there is some other newsgroup where people are happier to play this game. Incidentally, it is interesting that the typical Ada puzzler has the form: is this weird construct legal, rather than what does this weird code do? Of course I realize you can construct examples the other way round in both cases, but still I think typically this is the pattern (compare for example the C Puzzle book, with Exploring Ada) This somewhat goes along with the general experience that it is harder to get programs past an Ada compiler than past a C compiler, but once they are past, they hav a better chance of behaving as expected! ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: "Subtract C, add Ada" 1995-01-24 3:35 ` David Moore 1995-01-25 5:38 ` Robert Dewar @ 1995-01-28 16:35 ` Jules 1995-01-29 8:06 ` Matt Kennel 1995-01-30 5:31 ` Michael Feldman 1 sibling, 2 replies; 85+ messages in thread From: Jules @ 1995-01-28 16:35 UTC (permalink / raw) In article <3g1shu$ksc@rational.rational.com>, davidm@rational.com (David Moore) writes: >It is also easy to write abominations like: > > -- search the table > > while (a[i++]!=b); > >Whenever you use post-increment in a condition, you always have to stop and >wonder about your post-condition - I find it easier to always write the >loop out in full. It is also easy to write stupid code like this when NOT using shorthand code like this. Of course the correct version (and the version I still prefer) is: while (a[i++]!=b && i < ARRAYLIMIT); -- /* Julian R Hall csusb@csv.warwick.ac.uk Flames should be redirected to /dev/null - I don't know what I'm saying myself so don't expect it to make sense all the time! */ ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: "Subtract C, add Ada" 1995-01-28 16:35 ` Jules @ 1995-01-29 8:06 ` Matt Kennel 1995-01-30 5:31 ` Michael Feldman 1 sibling, 0 replies; 85+ messages in thread From: Matt Kennel @ 1995-01-29 8:06 UTC (permalink / raw) Jules (csusb@csv.warwick.ac.uk) wrote: : In article <3g1shu$ksc@rational.rational.com>, : davidm@rational.com (David Moore) writes: : >It is also easy to write abominations like: : > : > -- search the table : > : > while (a[i++]!=b); : > : >Whenever you use post-increment in a condition, you always have to stop and : >wonder about your post-condition - I find it easier to always write the : >loop out in full. : It is also easy to write stupid code like this when NOT using shorthand code : like this. : Of course the correct version (and the version I still prefer) is: : while (a[i++]!=b && i < ARRAYLIMIT); Better yet is to have a smart loop abstraction. For example: loop e := a.elt!; -- automagically step through elements of a. if (e = b) then break! end; -- otherwise do stuff here. end; Now isn't that what you really meant to say before? -- -Matt Kennel mbk@inls1.ucsd.edu -Institute for Nonlinear Science, University of California, San Diego -*** AD: Archive for nonlinear dynamics papers & programs: FTP to -*** lyapunov.ucsd.edu, username "anonymous". ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: "Subtract C, add Ada" 1995-01-28 16:35 ` Jules 1995-01-29 8:06 ` Matt Kennel @ 1995-01-30 5:31 ` Michael Feldman 1995-01-31 22:22 ` David O'Brien 1 sibling, 1 reply; 85+ messages in thread From: Michael Feldman @ 1995-01-30 5:31 UTC (permalink / raw) In article <3gdro9$aud@spam.csv.warwick.ac.uk>, Jules <csusb@csv.warwick.ac.uk> wrote: >Of course the correct version (and the version I still prefer) is: > >while (a[i++]!=b && i < ARRAYLIMIT); Hmmm - I think I learned somewhere that the && is short-circuit in C. So wouldn't you want to switch the two conditions, i.e. check the limit _before_ incrementing that index? (It's late at night; this comment may be off the wall.) Mike Feldman ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: "Subtract C, add Ada" 1995-01-30 5:31 ` Michael Feldman @ 1995-01-31 22:22 ` David O'Brien 0 siblings, 0 replies; 85+ messages in thread From: David O'Brien @ 1995-01-31 22:22 UTC (permalink / raw) Michael Feldman (mfeldman@seas.gwu.edu) wrote: : In article <3gdro9$aud@spam.csv.warwick.ac.uk>, : Jules <csusb@csv.warwick.ac.uk> wrote: : >Of course the correct version (and the version I still prefer) is: : > : >while (a[i++]!=b && i < ARRAYLIMIT); : Hmmm - I think I learned somewhere that the && is short-circuit in C. : So wouldn't you want to switch the two conditions, i.e. check the : limit _before_ incrementing that index? (It's late at night; this : comment may be off the wall.) Switching is required, and it would use the short-circuit idiom we love so much in C. But, the reason is that you skip that last element. Say we have: #define ARRAYLIMIT 3 foo a[ ARRAYLIMIT ]; When i == 2, the access ``a[ i++ ] != b'' is ok. However when we get to ``i < ARRAYLIMIT'', i == 3, and thus the statement is false and you stop the loop for the wrong reason. ``i <= ARRAYLIMIT'' would be needed, but it would cause you to access one element off the end of the array which is undefined. ANSI-C only says the *address* that points to one element beyond the end of an array must be valid. But accessing it is undefined behavior. [ANSI-C 3.3.6] Assuming we had: foo a[ ARRARYLIMIT + 1 ]; /* also very common way */ Doesn't help either, you also stop early. -- David (dobrien@seas.gwu.edu) ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: "Subtract C, add Ada" 1995-01-20 13:22 ` Renaud HEBERT 1995-01-24 3:35 ` David Moore @ 1995-01-24 20:23 ` N. Mellor 1995-01-25 8:50 ` Robb Nebbe ` (2 more replies) 1 sibling, 3 replies; 85+ messages in thread From: N. Mellor @ 1995-01-24 20:23 UTC (permalink / raw) In article <3fode9$dap@soleil.uvsq.fr> hebert@prism.uvsq.fr (Renaud HEBERT) writes: >|> Personally, the lack of this sort of compactness in Ada, and things like >|> pre- and post-increment/decrement are one of my minor gripes about the >|> language. OK, its no big thing to write: >|> >|> P(I) := Q(I); >|> I := I + 1; >|> >|> instead of >|> >|> *p++ = *q++; >|> >|> but I actually *do* find the C representation easier/better etc. (perhaps >|> I'm wierd?) >Even if I like C, I think that this ++ is ugly and I'm glad that there isn't such >a thing in Ada. On the other hand what do you think about the operators += *= ... >They make thing shorter AND easier to read, a += 5; means exactly add 5 to a. >So don't you think that these construct have their place in Ada. This seems a valid point to me, particularly because += simplifies and clarifies expressions, particularly complex ones. I don't think there'd be much disagreement over this one, for example: foo( bar( zot( element + 1))) = foo( bar(zot( element + 1))) + 1; foo( bar( zot(element + 1))) += 1; The second clearly saves on mistakes and makes the whole line more readable. To check the first, you need to do a mechanical, lexeme by lexeme comparison of the two array references to check that they're the same-- not a great score in the readability stakes. This is a clear example of C shorthand being superior, in some situations, in some respects, to Ada's straightforwardness. It isn't the whole story, of course. BUT...self-referencing assignments are a very common idiom in just about any language, and it's only right that we should at least discuss ways of expressing them elegantly. Though on the whole C/C++ haven't seen me for dust, I do miss +=, -= and algebraic ifs (the ?: operator pair). All of these can usefully reduce complexity in very busy and convoluted bits of code. Of course, there are other good reasons for not having these goodies. One is that they're not essential, and too many operators can increase the complexity of the language disastrously. One of the problems with C is its plethora of operators and the consequent complexity of the operator precedence rules. Add to that C's blurring of the distinction between statements and expressions and you have serious readability problems, whether for novices or experts. The bottom line is that it's simple to write an Ada procedure which safely adds or subtracts its second argument from its first, which can be defined as an in out parameter: procedure self-add(in out var, in expression) is var := var + expression; end self-add; and use it as in self-add( foo( bar( zot( element + 1))) , 1); Any other thoughts? Nick Mellor Leeds ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: "Subtract C, add Ada" 1995-01-24 20:23 ` N. Mellor @ 1995-01-25 8:50 ` Robb Nebbe 1995-01-25 14:19 ` John Volan 1995-01-26 5:07 ` Samuel Mize 2 siblings, 0 replies; 85+ messages in thread From: Robb Nebbe @ 1995-01-25 8:50 UTC (permalink / raw) In article <lawnm.33.00146988@leeds.ac.uk>, lawnm@leeds.ac.uk (N. Mellor) writes: |> |> This seems a valid point to me, particularly because += |> simplifies and clarifies expressions, particularly complex ones. I |> don't think there'd be much disagreement over this one, for example: |> |> foo( bar( zot( element + 1))) = foo( bar(zot( element + 1))) + 1; |> |> foo( bar( zot(element + 1))) += 1; |> |> The second clearly saves on mistakes and makes the whole line more readable. |> To check the first, you need to do a mechanical, lexeme by lexeme comparison |> of the two array references to check that they're the same-- not a great score |> in the readability stakes. This is a clear example of C shorthand being |> superior, in some situations, in some respects, to Ada's straightforwardness. |> It isn't the whole story, of course. For problems like this I would rename the foo term: declare Following_Element : Integer renames foo( bar( zot( element + 1 ))); begin if Following_Element < Limit then Following_Element := Following_Element + 1; else Following_Element := Following_Element + 10; end if; end; I don't really see the benefit of operators like += in a language. As an aside to no one in particular if you find you have lots of complicated terms like this in your code you should take it as a hint that there might be a problem with the design. Robb Nebbe ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: "Subtract C, add Ada" 1995-01-24 20:23 ` N. Mellor 1995-01-25 8:50 ` Robb Nebbe @ 1995-01-25 14:19 ` John Volan 1995-01-26 5:07 ` Samuel Mize 2 siblings, 0 replies; 85+ messages in thread From: John Volan @ 1995-01-25 14:19 UTC (permalink / raw) lawnm@leeds.ac.uk (N. Mellor) writes: >This seems a valid point to me, particularly because += >simplifies and clarifies expressions, particularly complex ones. I >don't think there'd be much disagreement over this one, for example: > >foo( bar( zot( element + 1))) = foo( bar(zot( element + 1))) + 1; > >foo( bar( zot(element + 1))) += 1; > >The second clearly saves on mistakes and makes the whole line more readable. >To check the first, you need to do a mechanical, lexeme by lexeme comparison >of the two array references to check that they're the same-- not a great score >in the readability stakes. This is a clear example of C shorthand being >superior, in some situations, in some respects, to Ada's straightforwardness. >It isn't the whole story, of course. Of course it isn't. One way of tackling this kind of situation without introducing new operators into the language is to exploit renaming declarations: declare Foobarzot : Whatever_Type renames Foo(Bar(Zot(Element+1))); begin Foobarzot := Foobarzot + 1; end; "Foobarzot" thus becomes a convenient local temporary alias for the object otherwise known by the more cumbersome name of "Foo(Bar(Zot(Element+1)))". This makes the incrementing assignment just as easy to read as any C-like alternative. It also makes it clear that the same object is being referenced on both sides of the assignment, without needing to duplicate "Foo(Bar(Zot(Element+1)))" (which is obviously error-prone). Additionally, it makes it clear that the computations that occur in "Foo(Bar(Zot(Element+1)))" should happen only once, before incrementing the resulting object. >BUT...self-referencing assignments are a very common idiom in just about any >language, and it's only right that we should at least discuss ways of >expressing them elegantly. Though on the whole C/C++ haven't seen me for dust, >I do miss +=, -= and algebraic ifs (the ?: operator pair). All of these can >usefully reduce complexity in very busy and convoluted bits of code. > >Of course, there are other good reasons for not having these goodies. >One is that they're not essential, and too many operators can increase the >complexity of the language disastrously. One of the problems with C is its >plethora of operators and the consequent complexity of the operator precedence >rules. Add to that C's blurring of the distinction between statements and >expressions and you have serious readability problems, whether for novices or >experts. I couldn't aggree with you more. >The bottom line is that it's simple to write an Ada procedure which safely >adds or subtracts its second argument from its first, which can be defined as >an in out parameter: > >procedure self-add(in out var, in expression) is > var := var + expression; >end self-add; > >and use it as in > >self-add( foo( bar( zot( element + 1))) , 1); Er, properly speaking, this should be something like: procedure Add (To : in out Whatever_Type; Addend : in Whatever_Type) is begin To := To + Addend; end Add; And then it could be used as in: Add (To => Foo(Bar(Zot(Element+1))), Addend => 1); In fact, the declare-block I wrote above could be viewed as an "inline" equivalent to this procedure call. >Any other thoughts? > >Nick Mellor >Leeds Hope this helps. -- John Volan -------------------------------------------------------------------------------- Me : Person := (Name => "John G. Volan", E_Mail_Address => "jgv@swl.msd.ray.com", Employer => "Raytheon", Affiliation => "Enthusiastic member of Team-Ada!", Shameless_Controversial_Marketing_Slogan_For_Favorite_Language => "<<<< Ada95: The World's *FIRST* Internationally-Standardized OOPL >>>>", Humorous_Language_Lawyerly_Disclaimer => "These opinions are undefined by my employer, so using them would be " & "totally erroneous ... or would that be a bounded error? :-) "); -------------------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: "Subtract C, add Ada" 1995-01-24 20:23 ` N. Mellor 1995-01-25 8:50 ` Robb Nebbe 1995-01-25 14:19 ` John Volan @ 1995-01-26 5:07 ` Samuel Mize 1995-01-26 18:51 ` Mark A Biggar 2 siblings, 1 reply; 85+ messages in thread From: Samuel Mize @ 1995-01-26 5:07 UTC (permalink / raw) The attached discussion of "self-referencing assignments" (I like the term -- is it a standard term?) raises some points for me. Yes, there should be a clearer method for self-referencing assignments. The usual argument (that I've seen) for the C operators +=, *=, etc., is that the code won't have to do the same dereference/index/etc. series twice. This is dumb; this is what the optimizer should do. BUT your point about readability is very true. The action "modify this value somehow" is a common task. Of course, the C operators are prone to typos. Also, you can only do a simple calculation (one multiply, one add...). It seems to me that something more general would be useful, along the lines (NOT THIS SYNTAX, THIS IDEA): foo( bar( zot( element + 1))) := <left> * ( <left> + 3 ); Question for the net: how much were self-referencing assignment operators, and and algebraic ifs (the ?: operator pair) considered for Ada83 and Ada95 (1). Are they discussed in the Rationales, or where would I find discussion of the reason for their omission from Ada? (I'll be looking through the Rationales for this, but if you know where to look it will help me.) Samuel Mize - smize@starbase.neosoft.com (1) YES! THAT'S RIGHT! NINETY-*FIVE*! I GOT THE RIGHT NUMBER THIS TIME, OK? :-) =8-p In article <lawnm.33.00146988@leeds.ac.uk>, N. Mellor <lawnm@leeds.ac.uk> wrote: >In article <3fode9$dap@soleil.uvsq.fr> hebert@prism.uvsq.fr (Renaud HEBERT) writes: ... >>... On the other hand what do you think about the operators += *= ... >>They make thing shorter AND easier to read, a += 5; means exactly add 5 to a. >>So don't you think that these construct have their place in Ada. > >This seems a valid point to me, particularly because += >simplifies and clarifies expressions, particularly complex ones. I >don't think there'd be much disagreement over this one, for example: > >foo( bar( zot( element + 1))) = foo( bar(zot( element + 1))) + 1; > >foo( bar( zot(element + 1))) += 1; > >The second clearly saves on mistakes and makes the whole line more readable. >To check the first, you need to do a mechanical, lexeme by lexeme comparison >of the two array references to check that they're the same-- not a great score >in the readability stakes. This is a clear example of C shorthand being >superior, in some situations, in some respects, to Ada's straightforwardness. >It isn't the whole story, of course. > >BUT...self-referencing assignments are a very common idiom in just about any >language, and it's only right that we should at least discuss ways of >expressing them elegantly. Though on the whole C/C++ haven't seen me for dust, >I do miss +=, -= and algebraic ifs (the ?: operator pair). All of these can >usefully reduce complexity in very busy and convoluted bits of code. > >Of course, there are other good reasons for not having these goodies. >One is that they're not essential, and too many operators can increase the >complexity of the language disastrously. One of the problems with C is its >plethora of operators and the consequent complexity of the operator precedence >rules. Add to that C's blurring of the distinction between statements and >expressions and you have serious readability problems, whether for novices or >experts. > >The bottom line is that it's simple to write an Ada procedure which safely >adds or subtracts its second argument from its first, which can be defined as >an in out parameter: > >procedure self-add(in out var, in expression) is > var := var + expression; >end self-add; > >and use it as in > >self-add( foo( bar( zot( element + 1))) , 1); > > >Any other thoughts? > >Nick Mellor >Leeds ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: "Subtract C, add Ada" 1995-01-26 5:07 ` Samuel Mize @ 1995-01-26 18:51 ` Mark A Biggar 0 siblings, 0 replies; 85+ messages in thread From: Mark A Biggar @ 1995-01-26 18:51 UTC (permalink / raw) In article <3g7ame$5d8@Starbase.NeoSoft.COM> smize@Starbase.NeoSoft.COM (Samuel Mize) writes: >It seems to me that something more general would be useful, >along the lines (NOT THIS SYNTAX, THIS IDEA): > > foo( bar( zot( element + 1))) := <left> * ( <left> + 3 ); That's what rename is for and it's more powerful to boot as you can choose exactly what parts of your expression get short names, For example: declare Left: Interger renames foo(bar(zot(element+1))); begin Left := Left * (Left + 3); end; but also: declare Index: Integer renames bar(zot(element+1)); begin foo(Index) := foo(Index) * ( foo(Index) + 3); end; You may well want to use the second case, if that documents your algorithm better. Note that a good compiler probably produces identical code for both examples assuming good common expression elimination. -- Mark Biggar mab@wdl.loral.com ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: "Subtract C, add Ada" 1995-01-20 10:20 R.A.L Williams 1995-01-20 13:22 ` Renaud HEBERT @ 1995-01-21 15:18 ` Robert Dewar 1995-01-21 21:03 ` David O'Brien 1995-01-23 20:46 ` Robert Firth 3 siblings, 0 replies; 85+ messages in thread From: Robert Dewar @ 1995-01-21 15:18 UTC (permalink / raw) Laurent Gasser says: >"Personally, the lack of this sort of compactness in Ada, and things like > pre- and post-increment/decrement are one of my minor gripes about the > language. OK, its no big thing to write: > > P(I) := Q(I); > I := I + 1; > > instead of > > *p++ = *q++; > > but I actually *do* find the C representation easier/better etc. (perhaps > I'm wierd?)" The trouble with these notations in C is that they work better with short variable names, as in the example above. This is reminiscent of typical mathematical notations (like ! for factorial) that also are predicated on typical mathematical style of one character variables like x. Now look at Next_Predicted_Value (Iteration_Index) := Previous_Calculated_Value (Iteration_Index); and *Next_Predicted_Value++ = *Previous_Calculated_Value++; There are two problems with the second form. First the * and ++ seem to get a bit lost with the long names. Second, we are missing the name Iteration_Index which may be quite helpful in understanding what is going on. Note also that the C style is implying the use of pointers, which are less comfortable than the use of arrays, because the pointers could be pointing to anything, while we know what is involved with the arrays. All in all, the Ada in the second example seems much clearer, and of course once you use long identifiers, the advantage of the compact notation is reduced. There is no rule saying use long identifiers in Ada, and use short identifiers in C (and I am sure we have all seen code with short identifiers in Ada, and long identifiers in C), but it is not an accident that even though there are no rules, there are effectively stylistic customs in these directions, and I think that the neat compact C syntax gizmos are at least partly responsible. ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: "Subtract C, add Ada" 1995-01-20 10:20 R.A.L Williams 1995-01-20 13:22 ` Renaud HEBERT 1995-01-21 15:18 ` Robert Dewar @ 1995-01-21 21:03 ` David O'Brien 1995-01-23 3:09 ` Jay Martin 1995-01-24 0:17 ` Bob Kitzberger 1995-01-23 20:46 ` Robert Firth 3 siblings, 2 replies; 85+ messages in thread From: David O'Brien @ 1995-01-21 21:03 UTC (permalink / raw) R.A.L Williams (bill@valiant) wrote: : I think there are three reasons: : 1. It allows your code to be more compact. Many people think this is : a disadvantage, and so it is if the code will be read by comparative : novices, but it can improve readability to C experts who are : expecting such tricks. : : NB DONT confuse compactness with poor layout! I find that, for example: : : while ((c = getchar()) == ' ') { /* count spaces */ } : : is clearer than the 'expanded' alternative (to *me* :-). BINGO!!! Readability, like beauty, is in the eye of the beholder. An instructor here made the statement "Pascal is easier to read then C". I don't think so. In fact I got a D on a midterm because of it. I was the only person in my soph intro CS class using C instead of Pascal, so all the code fragments were in Pascal. To this day, I still can't read Pascal's pointer syntax. Readability is what you are familiar with. Both of the C code fragments are very familiar to me and I find *very* easy to read (except for the lack of white space in the first one). The same is true for Natural language. I can speak/read/write some Vietnamese. Vietnamese is a very regular language, and the spelling rules are never broken. The language is purely phonetic, making it quick to learn to pronounce words. However, I find English easier to read/write because of my added familiarity with English. And, it has even more warts than people state here about C. :-)) I am tired of novice C users always saying this construct is bad, and that construct is bad. And I don't care to program in C using only constructs that a novice would understand at first glance. Ours is a professional environment and certain level of proficiency should be expected. If a high school kid off the street could program like an expert, then why are we getting degrees and such? Writing ``for (p = head; p; p = p->next) { /* process list */ }'' Is quite clear to me, but others will probably disagree. But I find the way of reading a file in Ada to quite idiomatic. At least I was taught to enclose the reading from the file in a loop with an exception handler w/in the loop. When the exception would be raised when an attempt to read past EOF, then close the file and process what ever your read in. -- David O'Brien (dobrien@seas.gwu.edu) ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: "Subtract C, add Ada" 1995-01-21 21:03 ` David O'Brien @ 1995-01-23 3:09 ` Jay Martin 1995-01-23 12:50 ` Andrew McConnell 1995-01-24 0:54 ` Matt Kennel 1995-01-24 0:17 ` Bob Kitzberger 1 sibling, 2 replies; 85+ messages in thread From: Jay Martin @ 1995-01-23 3:09 UTC (permalink / raw) >: The problem is in the language definition, not in the choic of symbols. >: C is one of the rare language I use to allow having an assignment after >: the if statement. All other languages only allow for a boolean test. >: I never saw a good reason for allowing this. Right! >I think there are three reasons: > 1. It allows your code to be more compact. Many people think this is > a disadvantage, and so it is if the code will be read by comparative > novices, but it can improve readability to C experts who are > expecting such tricks. > > NB DONT confuse compactness with poor layout! I find that, for example: > > while ((c = getchar()) == ' ') > { > /* count spaces */ > } > > is clearer than the 'expanded' alternative (to *me* :-). "C expert" does not equal professional programmer. Just because someone can read arcane poorly designed code does not mean he is competent software engineer. In fact, I would say that many C programmers are basically are very incompetent and undeciplined programmers. No one should write code to please idiots who want tricks. Yuck: -- We have a function that changes state "getchar()". -- We have an boolean expression that has a side-effect to c. -- We have to look twice at the expression to see that we are comparing the results of "getchar()" and not "c" (which is just there for the ride). How about: loop GetChar(C); exit when (C /= ' '); ... end loop; Sure it has an exit in the loop, it always cracks me up when programmers who have side-effects galore in their programs start whining about the "impurity" of having an exit in a loop > 2. All expressions in C have a value. Conditional tests succeed on > non-zero and fail on zero. Therefore, to maintain orthogonality, > as far as possible, there is no reason to exclude an assignment > expression from a condition. But we are arguing that languages should not have side-effects in expressions and thus an assignment should not an expression or sub- expression or return a value. So "All expressions in C have a value" is not gospal it is just another bad language design decision made by certain incompetent language designers (K&R). The reason to not to allow it is that it causes programming errors and terse garbage code. > 3. Finally, I suspect, this can simplify the optimisation algorithms > in the compiler. Ack! Compiler: Warning: Due to that you did not imbed your assignments in boolean expression on line 2432, this compiler cannot optimize that statement. Sorry about that. Again ignorance of compiler optimization abounds. From what I have seen the "too macho to trust the compiler" attitude dominates the industry. Processors have multiple processing units to schedule and pipelines filled to minimize stalls. I just don't see the "optimized C" computational model as being relevant any more. (4) >Personally, the lack of this sort of compactness in Ada, and things like >pre- and post-increment/decrement are one of my minor gripes about the >language. OK, its no big thing to write: > P(I) := Q(I); > I := I + 1; >instead of > *p++ = *q++; >but I actually *do* find the C representation easier/better etc. (perhaps >I'm wierd?) Yup, pretty weird. Compactness/terseness does not equal better readibility. Arrays are higher level than pointers and will be bounds checked by most adequate languages. Pointer arithmetic in my opinion is yet another crap idea from the K&R bozos. Another C guy: >BINGO!!! Readability, like beauty, is in the eye of the beholder. An >instructor here made the statement "Pascal is easier to read then C". I >don't think so. In fact I got a D on a midterm because of it. I was >the only person in my soph intro CS class using C instead of Pascal, so >all the code fragments were in Pascal. To this day, I still can't read >Pascal's pointer syntax. Readability is what you are familiar with. >Both of the C code fragments are very familiar to me and I find *very* >easy to read (except for the lack of white space in the first one). Yeah, all things are relative, all is a matter of opinion, all ideas are of equal merit, etc. (We don't want to upset anyone) Got a D, good, at least some instructors out there care about teaching programming / language design. Wow! so mentally rigid can't read Pascal's elegant pointer syntax. Gee, maybe the professor might just know more than you, maybe when you take a class you should try to learn something. Guess you didn't want to learn good program structure and clean language syntax and semantics. >I am tired of novice C users always saying this construct is bad, and >that construct is bad. And I don't care to program in C using only >constructs that a novice would understand at first glance. Ours is a >professional environment and certain level of proficiency should be >expected. If a high school kid off the street could program like an >expert, then why are we getting degrees and such? Again, we have a incorrect correlation here between "professional programmer" and C hacker. "Novices" here are equated with incompetent programmers when they may just be expert software engineers who fully understand good programming language and software design. Why should we want to become proficient in old poorly designed languages which is hard to learn when we can learn something that is well designed that we can learn quicker and also have better productivity in the long run. I can get no joy from becoming proficient in crap. In my opinion, no person should get a computer science degree with out understanding the flaws of C and other popular poorly designed languages and systems. Heh, (C Idiom == Idiotm) >Writing ``for (p = head; p; p = p->next) { /* process list */ }'' Ptr := Head; while (Ptr /= null) loop ... Ptr := Ptr.Next; end loop; (My Ada is rusty, I only program in C++ now) >Is quite clear to me, but others will probably disagree. But I find the >way of reading a file in Ada to quite idiomatic. At least I was >taught to enclose the reading from the file in a loop with an exception >handler w/in the loop. When the exception would be raised when an attempt >to read past EOF, then close the file and process what ever your read in. Actually, depending on exceptions to catch the EOF condition is bad Ada style as you are depending on an exception for normal program control. ---------- Okay I was harsh. But these "C" attitudes of programming are pretty much the norm in industry and I find this very distressing. In my opinion, the Computer Science community must admit their total failure to teach or even understand or form a consensus about good software construction and programming language design. ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: "Subtract C, add Ada" 1995-01-23 3:09 ` Jay Martin @ 1995-01-23 12:50 ` Andrew McConnell 1995-01-24 0:54 ` Matt Kennel 1 sibling, 0 replies; 85+ messages in thread From: Andrew McConnell @ 1995-01-23 12:50 UTC (permalink / raw) In article <3fv6lb$f4u@oahu.cs.ucla.edu>, Jay Martin <jmartin@oahu.cs.ucla.edu> wrote: > >Okay I was harsh. But these "C" attitudes of programming are pretty >much the norm in industry and I find this very distressing. In my >opinion, the Computer Science community must admit their total >failure to teach or even understand or form a consensus about >good software construction and programming language design. > Yes, that was pretty harsh.... I have to agree that the CS community has really dropped the ball. I've been reading many of the "jobs" newsgroups lately and see posting after posting for "Software Engineers" who have n years programming in language x. My question: If they're hiring software engineers why do they INSIST on experience in language x. Isn't computer science/software engineering language independent to a great extent? I feel that they are _some_ language factors that you have to take into account when doing S/W design, but a good SWE doesn't get hung up on language choice. -- Andrew R. McConnell mcconnel@source.asset.com ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: "Subtract C, add Ada" 1995-01-23 3:09 ` Jay Martin 1995-01-23 12:50 ` Andrew McConnell @ 1995-01-24 0:54 ` Matt Kennel 1995-01-25 17:03 ` Norman H. Cohen 1 sibling, 1 reply; 85+ messages in thread From: Matt Kennel @ 1995-01-24 0:54 UTC (permalink / raw) Jay Martin (jmartin@oahu.cs.ucla.edu) wrote: : Heh, (C Idiom == Idiotm) : >Writing ``for (p = head; p; p = p->next) { /* process list */ }'' : Ptr := Head; : while (Ptr /= null) loop : ... : Ptr := Ptr.Next; : end loop; : (My Ada is rusty, I only program in C++ now) "Think Globally, Act Locally." All these silly questions come down to the fact that control structures are hardwired into the language, but not easily reprogrammable. Real iterations in real problems come in many forms. You need a user-progammable construction that goes straight to the problem. C++ types 'iterators' are a good first step, but I don't feel super comfortable with them. What I think is even better is Sather's "iters". Instead of arguing over silly little details of various Pascal or C control structures or whatever their trivial variations, we should desire something much better and powerful among all the inventions that have been occured over the last 20 years. In particular I know about Sather's iters, which are practical and convenient. Example: -------- list,list2:LIST{BLAH}; loop list_element := list.elt!; -- iterate through elements of "list". process(list_element); while!(list_element /= special_gonzo); -- break out if we hit mr gonzo. list_element2 := list2.elt!; -- parallel (not nested) iteration through second list process2(list_element,list_element2); end; "elt!" is a feature in LIST{BLAH} which returns successive elements of the list, and breaks out if it hits the end. This fragment does exactly what it looks like it does. And the user of the "list" does not need to know whether it returns elements by dint of following successive pointers, stepping through arrays, or black magic. It eliminates stupid "off-by-one" errors and needless special boundary cases. cheers Matt -- -Matt Kennel mbk@inls1.ucsd.edu -Institute for Nonlinear Science, University of California, San Diego -*** AD: Archive for nonlinear dynamics papers & programs: FTP to -*** lyapunov.ucsd.edu, username "anonymous". ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: "Subtract C, add Ada" 1995-01-24 0:54 ` Matt Kennel @ 1995-01-25 17:03 ` Norman H. Cohen 1995-01-26 1:13 ` Dr. Richard Botting 1995-01-26 14:32 ` Anders Juul Munch 0 siblings, 2 replies; 85+ messages in thread From: Norman H. Cohen @ 1995-01-25 17:03 UTC (permalink / raw) |> Real iterations in real problems come in many forms. You need a |> user-progammable construction that goes straight to the problem. |> C++ types 'iterators' are a good first step, but I don't feel |> super comfortable with them. What I think is even better is |> Sather's "iters". Instead of arguing over silly little details |> of various Pascal or C control structures or whatever their trivial |> variations, we should desire something much better and powerful among |> all the inventions that have been occured over the last 20 years. I think CLU, circa 1979, still holds the prize for the best iteration abstraction. When defining a CLU abstract data type that represents some sort of collection, you can define one or more iterators among its operations. An iterator is like a procedure declared to take a value of the collection type as a parameter and to "yield" values of some element type. The iterator is executed as a coroutine during the execution of the loop. Values that are yielded by the iterator become the values of the loop parameter on successive iterations of the loop. My CLU syntax is rusty, but if you have the equivalent of a private type for doubly linked lists, you could define the following iterators for it: elements = iter(l: list_type) yields (element_type) next: cell_type = l; while next.forward_link ~= l do yield(next.item) end end reverse_elements = iter(l: list_type) yields (element_type) next: cell_type = l; while next.backward_link ~= l do yield(next.item) end end Then you could iterate over the private type as follows: for item in elements(my_list) do ... end for item in reverse_elements(my_list) do ... end Iterators could even be recursive: preorder_traversal = iter(t: tree_type) yields node_info_type yield(t.node_info); for ni in preorder_traversal(t.left_subtree) do yield(ni) end for ni in preorder_traversal(t.right_subtree) do yield(ni) end end (Breaking out of a loop terminates the iterator. Since CLU supported exceptions, I think it would have been better for the next yield statement to have raised an exception inside the iterator, thus giving the iterator the opportunity to perform cleanup actions.) -- Norman H. Cohen ncohen@watson.ibm.com ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: "Subtract C, add Ada" 1995-01-25 17:03 ` Norman H. Cohen @ 1995-01-26 1:13 ` Dr. Richard Botting 1995-01-26 14:32 ` Anders Juul Munch 1 sibling, 0 replies; 85+ messages in thread From: Dr. Richard Botting @ 1995-01-26 1:13 UTC (permalink / raw) Norman H. Cohen (ncohen@watson.ibm.com) wrote: : |> Real iterations in real problems come in many forms. You need a : |> user-progammable construction that goes straight to the problem. : |> C++ types 'iterators' are a good first step, but I don't feel : |> super comfortable with them. What I think is even better is : |> Sather's "iters". Instead of arguing over silly little details : |> of various Pascal or C control structures or whatever their trivial : |> variations, we should desire something much better and powerful among : |> all the inventions that have been occured over the last 20 years. : I think CLU, circa 1979, still holds the prize for the best iteration : abstraction. Well I just have to point out that iterators in Ada date back to January 1983 - "Studies in Ada Style" 2nd Eddition, By Hibbard,Hisgen,Rosenberg,shaw,sherman, Pub Springer Verlag..... Also: I agree that programming language loops are a special and restricted kind of itterator (in some sense or other), But, for me, iterators are a speical and restrictive case of a cooperating sequential processes... as are Ada Tasks, UNIX/C pipes, JSP inverted code/semin-co-routines, etc. (Yes, I have seen the C++ co-routine class library, :-( ) It would be so nice to write code like this int next(void) { .... release(c); ..... release(d); ... if(something) release(x); ... while(somcond){ release(c); make_next(&c); } release(EOF); } And, whenever you called 'next(...)' it finds/computes/fudges up the next char until your get the the end and it pops out the EOF.... This is easy to fake, but I would like it in my languages. The word RELEASE is from the COBOL sorting.... so why can't C++ keep up with COBOL? :-)} -- EMail: dick@csci.csusb.edu=rbotting@wiley.csusb.edu. ftp://ftp.csci.csusb.edu/dick <a href="http://www.csci.csusb.edu/dick/">WWW</a> Disclaimer::=`CSUSB may or may not agree with this message`. Copyright(1995)::=`Copy as long as you include this copyright and signature`. ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: "Subtract C, add Ada" 1995-01-25 17:03 ` Norman H. Cohen 1995-01-26 1:13 ` Dr. Richard Botting @ 1995-01-26 14:32 ` Anders Juul Munch 1 sibling, 0 replies; 85+ messages in thread From: Anders Juul Munch @ 1995-01-26 14:32 UTC (permalink / raw) ncohen@watson.ibm.com (Norman H. Cohen) writes: >I think CLU, circa 1979, still holds the prize for the best iteration >abstraction. When defining a CLU abstract data type that represents some >sort of collection, you can define one or more iterators among its >operations. An iterator is like a procedure declared to take a value of >the collection type as a parameter and to "yield" values of some element >type. The iterator is executed as a coroutine during the execution of >the loop. Values that are yielded by the iterator become the values of >the loop parameter on successive iterations of the loop. >My CLU syntax is rusty, but if you have the equivalent of a private type >for doubly linked lists, you could define the following iterators for it: > elements = > iter(l: list_type) yields (element_type) > next: cell_type = l; > while next.forward_link ~= l do > yield(next.item) > end > end >Then you could iterate over the private type as follows: > for item in elements(my_list) do > ... > end >[lotsa stuff omitted] Very nice. But how about the kind of parallel iteration over two lists, that other posters showed for Sather and ICON. Can you do that in CLU also? -Anders Munch, juul@diku.dk Still confused but at a higher level ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: "Subtract C, add Ada" 1995-01-21 21:03 ` David O'Brien 1995-01-23 3:09 ` Jay Martin @ 1995-01-24 0:17 ` Bob Kitzberger 1 sibling, 0 replies; 85+ messages in thread From: Bob Kitzberger @ 1995-01-24 0:17 UTC (permalink / raw) David O'Brien (dobrien@seas.gwu.edu) wrote: : I am tired of novice C users always saying this construct is bad, and : that construct is bad. And I don't care to program in C using only : constructs that a novice would understand at first glance. Ours is a : professional environment and certain level of proficiency should be : expected. If a high school kid off the street could program like an : expert, then why are we getting degrees and such? 1. Don't assume that those criticizing C constructs are novice C programmers. "The more I know C, the more I like my dog" ;-) 2. I would _hope_ that we are getting degrees in order to learn how to design systems, how to manage the development process, how to develop systems reliably, how to approach NP complete problems, how to test systems, how to avoid duplication of effort, how to estimate system size, etc. Learning language/programming idioms shouldn't be very high on the list! -- Bob Kitzberger +1 (916) 274-3075 rlk@rational.com Rational Software Corp., 10565 Brunswick Rd. #11, Grass Valley, CA 95945 "Though the boys throw stones at frogs in sport, yet the frogs do not die in sport but in earnest." - Plutarch ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: "Subtract C, add Ada" 1995-01-20 10:20 R.A.L Williams ` (2 preceding siblings ...) 1995-01-21 21:03 ` David O'Brien @ 1995-01-23 20:46 ` Robert Firth 1995-01-24 14:25 ` Samuel Mize 1995-01-25 5:57 ` David O'Brien 3 siblings, 2 replies; 85+ messages in thread From: Robert Firth @ 1995-01-23 20:46 UTC (permalink / raw) In article <3fo2ot$su2@miranda.gmrc.gecm.com> bill@valiant (R.A.L Williams) writes: I guess I'm about to show my ignorance of C, but I'm very confused bt this post. > 1. It allows your code to be more compact. > NB DONT confuse compactness with poor layout! I find that, for example: > > while ((c = getchar()) == ' ') > { > /* count spaces */ > } > > is clearer than the 'expanded' alternative (to *me* :-). Nope, I find this totally unclear. Who's counting? Unless I've missed an invisible declaration, initialisation, and increment, the above code *doesn't* count spaces, it skips them. And if that is its purpose, what's the point of the variable 'c'? Why not just say WHILE getchar = ASCII.SP LOOP null; END LOOP; Though, again, I'd much rather write this: LOOP get(c); EXIT WHEN c /= ASCII.SP; END LOOP; since the postcondition I almost certainly want to establish - that c holds the next non-space character - is written right there in the code. Note also that if there are *no more* non space characters, the C code dies in an infinite loop, while the Ada code automatically does the right thing, namely raises the END_ERROR exception. >OK, its no big thing to write: > > P(I) := Q(I); > I := I + 1; > >instead of > > *p++ = *q++; > >but I actually *do* find the C representation easier/better etc. (perhaps >I'm wierd?) Again, I don't see it. The Ada code makes it clear that *corresponding* elements of the array Q are being copied into P - though, of course, a real Ada programmer (TM) would have written just P := Q. The C code doesn't make that clear - you're going to have to ferret out the initialisations of p and q to determine that. And if you worry about the correctness of the copy - for instance, whether P and Q are the same size - that's surely going to be a lot easier to establish in Ada. ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: "Subtract C, add Ada" 1995-01-23 20:46 ` Robert Firth @ 1995-01-24 14:25 ` Samuel Mize 1995-01-25 7:27 ` David O'Brien 1995-01-25 12:14 ` Robert A Duff 1995-01-25 5:57 ` David O'Brien 1 sibling, 2 replies; 85+ messages in thread From: Samuel Mize @ 1995-01-24 14:25 UTC (permalink / raw) In article <1995Jan23.154631.6702@sei.cmu.edu>, Robert Firth <firth@sei.cmu.edu> wrote: >In article <3fo2ot$su2@miranda.gmrc.gecm.com> bill@valiant (R.A.L Williams) writes: > ... >> 1. It allows your code to be more compact. > >> NB DONT confuse compactness with poor layout! I find that, for example: >> >> while ((c = getchar()) == ' ') >> { >> /* count spaces */ >> } >> >> is clearer than the 'expanded' alternative (to *me* :-). > >Nope, I find this totally unclear. Who's counting? Unless I've missed >an invisible declaration, initialisation, and increment, the above >code *doesn't* count spaces, it skips them. I think he intended the comment to represent elided code. .. [good point about explicit exit condition not repeated] >Note also that if there are *no more* non space characters, the C code >dies in an infinite loop, while the Ada code automatically does the >right thing, namely raises the END_ERROR exception. Well "of course" we're assuming that there is no programmer error, this is C! ;-) This bit of code is based on the assumption that there is a null at the end of your string -- oh, but this is a file read. C guys: does C return a null if you getchar at EOF? Or is this a misplaced array idiom? Of course, we *never* see strings without nulls in C... Sam Mize - smize@starbase.neosoft.com ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: "Subtract C, add Ada" 1995-01-24 14:25 ` Samuel Mize @ 1995-01-25 7:27 ` David O'Brien 1995-01-25 12:14 ` Robert A Duff 1 sibling, 0 replies; 85+ messages in thread From: David O'Brien @ 1995-01-25 7:27 UTC (permalink / raw) Samuel Mize (smize@Starbase.NeoSoft.COM) wrote: : In article <1995Jan23.154631.6702@sei.cmu.edu>, : Robert Firth <firth@sei.cmu.edu> wrote: : >In article <3fo2ot$su2@miranda.gmrc.gecm.com> bill@valiant (R.A.L Williams) writes: : > : ... : >> 1. It allows your code to be more compact. : > : >> NB DONT confuse compactness with poor layout! I find that, for example: : >> : >> while ((c = getchar()) == ' ') : >> { : >> /* count spaces */ : >> } : >> : This bit of code is based on the assumption that there is a null at : the end of your string -- oh, but this is a file read. C guys: : does C return a null if you getchar at EOF? Or is this a misplaced : array idiom? This code is *not* based on the assumption that there is a ASCII NUL at the end of the string. There is nothing here that implies a string. A string being a series of characters terminated by an ASCII NUL character. Nor is this a file read. getchar reads from the standard input. This would be interactive input unless the input has been redirected to a file. C (what I believe you are actually asking is does getchar return a NUL at EOF), returns the EOF "character" at EOF. If the above code was reading from a file, the loop would terminate at EOF since EOF is not the same value as a space character. So the code fragment is still ok with redirected input. -- David O'Brien (dobrien@seas.gwu.edu) ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: "Subtract C, add Ada" 1995-01-24 14:25 ` Samuel Mize 1995-01-25 7:27 ` David O'Brien @ 1995-01-25 12:14 ` Robert A Duff 1 sibling, 0 replies; 85+ messages in thread From: Robert A Duff @ 1995-01-25 12:14 UTC (permalink / raw) In article <3g32li$5jd@Starbase.NeoSoft.COM>, Samuel Mize <smize@Starbase.NeoSoft.COM> wrote: >This bit of code is based on the assumption that there is a null at >the end of your string -- oh, but this is a file read. C guys: >does C return a null if you getchar at EOF? Or is this a misplaced >array idiom? I believe getchar returns -1 at eof. - Bob ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: "Subtract C, add Ada" 1995-01-23 20:46 ` Robert Firth 1995-01-24 14:25 ` Samuel Mize @ 1995-01-25 5:57 ` David O'Brien [not found] ` <3g9rf0$71k@Starbase.NeoSoft.COM> 1995-01-30 0:24 ` Mark S. Hathaway 1 sibling, 2 replies; 85+ messages in thread From: David O'Brien @ 1995-01-25 5:57 UTC (permalink / raw) Robert Firth (firth@sei.cmu.edu) wrote: : LOOP : get(c); : EXIT WHEN c /= ASCII.SP; : END LOOP; : Note also that if there are *no more* non space characters, the C code : dies in an infinite loop, while the Ada code automatically does the : right thing, namely raises the END_ERROR exception. Woa! Just how is it going to be determined that "enough" spaces have been processed before it is decided that we have an infinate loop? I'm not too sure I want some compiler/run-time to decide it has had enough and kill my program... -- David O'Brien (dobrien@seas.gwu.edu) : >OK, its no big thing to write: : > : > P(I) := Q(I); : > I := I + 1; : > : >instead of : > : > *p++ = *q++; : > : >but I actually *do* find the C representation easier/better etc. (perhaps : >I'm wierd?) : Again, I don't see it. The Ada code makes it clear that *corresponding* : elements of the array Q are being copied into P - though, of course, : a real Ada programmer (TM) would have written just P := Q. The C code : doesn't make that clear - you're going to have to ferret out the : initialisations of p and q to determine that. And if you worry about : the correctness of the copy - for instance, whether P and Q are the : same size - that's surely going to be a lot easier to establish in Ada. ^ permalink raw reply [flat|nested] 85+ messages in thread
[parent not found: <3g9rf0$71k@Starbase.NeoSoft.COM>]
* Re: "Subtract C, add Ada" [not found] ` <3g9rf0$71k@Starbase.NeoSoft.COM> @ 1995-01-28 21:08 ` David O'Brien 1995-01-31 18:07 ` Samuel Mize 1995-02-01 10:23 ` Samuel Mize 0 siblings, 2 replies; 85+ messages in thread From: David O'Brien @ 1995-01-28 21:08 UTC (permalink / raw) Samuel Mize (smize@Starbase.NeoSoft.COM) wrote: : In article <3g4p94$g07@cronkite.seas.gwu.edu>, : David O'Brien <dobrien@seas.gwu.edu> wrote: : >Robert Firth (firth@sei.cmu.edu) wrote: : > : >: LOOP : >: get(c); : >: EXIT WHEN c /= ASCII.SP; : >: END LOOP; : > : >: Note also that if there are *no more* non space characters, the C code : >: dies in an infinite loop, while the Ada code automatically does the : >: right thing, namely raises the END_ERROR exception. : > : If this is scanning a string that has no more spaces, Ada will : raise an exception at the end of the string. C will scan merrily : off the end of the array and through the memory following until it : hits a space or you get "segmentation error (core dumped)". Boy are we making assumptions about the processing that follows counting the number of spaces. Would you care to explain how C will core dump? The loop will stop when there are no more spaces IN A ROW. The original C code was: while ( (c = getchar()) == ' ' ) { /* count spaces */ } The Ada code and the C code ARE THE SAME. That being, both count the number of spaces in a sequence. Once the first non-space character is read (could be A thru Z, EOF, ASCII NUL, what ever), both of these code fragments will exit the while loop. There is nothing in these code fragments that may be used to complain about C's handling of strings. Code layout and where expressions may be used is what this thread was about. If you really want to get into it, the Ada way is worse. If the input string contained only spaces, Ada would exception when EOF was hit. C on the other hand would exit the loop cleanly and what ever came next would execute. In Ada I hope you wrapped the while loop with an exception handler. -- David O'Brien (dobrien@seas.gwu.edu) ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: "Subtract C, add Ada" 1995-01-28 21:08 ` David O'Brien @ 1995-01-31 18:07 ` Samuel Mize 1995-02-01 10:23 ` Samuel Mize 1 sibling, 0 replies; 85+ messages in thread From: Samuel Mize @ 1995-01-31 18:07 UTC (permalink / raw) Some of my earlier postings were not as clear as they should have been. Let me clarify. In article <3gebnq$7f3@cronkite.seas.gwu.edu>, David O'Brien <dobrien@seas.gwu.edu> wrote: >Samuel Mize (smize@Starbase.NeoSoft.COM) wrote: >: In article <3g4p94$g07@cronkite.seas.gwu.edu>, >: David O'Brien <dobrien@seas.gwu.edu> wrote: >: >Robert Firth (firth@sei.cmu.edu) wrote: >: > >: >: LOOP >: >: get(c); >: >: EXIT WHEN c /= ASCII.SP; >: >: END LOOP; >: > >: >: Note also that if there are *no more* non space characters, the C code >: >: dies in an infinite loop, while the Ada code automatically does the >: >: right thing, namely raises the END_ERROR exception. >: > [discussion in Mize post of reading from a file deleted] >: If this is scanning a string that has no more spaces, Ada will >: raise an exception at the end of the string. C will scan merrily >: off the end of the array and through the memory following until it >: hits a space or you get "segmentation error (core dumped)". > >Boy are we making assumptions about the processing that follows counting >the number of spaces. Would you care to explain how C will core dump? I meant, if the NUL at the end of a string was clobbered, or the array pointer was corrupted, and you started scanning the wrong part of memory. That isn't what I said, but is what I meant. I didn't clearly state that I was changing subject somewhat, and I also got the logic of the test backward. Sorry. If the end-marker of a string is missing, or the array pointer is corrupted, you can core dump right here. No further processing needed. > >The loop will stop when there are no more spaces IN A ROW. The original >C code was: > while ( (c = getchar()) == ' ' ) { /* count spaces */ } > >The Ada code and the C code ARE THE SAME. That being, both count the They aren't the same code lexically or logically. They ARE not THE SAME. Someone else said that the C would go into an infinite loop, and that this was the equivalent Ada code. They were wrong. The logically equivalent Ada (using text_io) would be while not end_of_file loop get (c); exit when c /= ' '; end loop; >number of spaces in a sequence. Once the first non-space character is >read (could be A thru Z, EOF, ASCII NUL, what ever), both of these code >fragments will exit the while loop. There is nothing in these code >fragments that may be used to complain about C's handling of strings. >Code layout and where expressions may be used is what this thread was >about. > >If you really want to get into it, the Ada way is worse. If the input >string contained only spaces, Ada would exception when EOF was hit. >C on the other hand would exit the loop cleanly and what ever came next >would execute. In Ada I hope you wrapped the while loop with an >exception handler. No, you just have to understand how EOF is handled in both languages, and write the Ada correctly. This was not your error originally, and since you're taking the pro-C side I won't dis you for not recognizing an Ada error. :-) The C code is more terse, but not necessarily more efficient; that depends on your compiler. The C getc is probably checking for EOF behind your back, instead of it being explicitly coded in. I am now switching topics back to strings. Someone in the thread brought up C going into an infinite loop. I thought that person may be confusing a file read with a string scan. (Yes, it *is* a file read; standard input is a file, as are standard output and standard error.) Anyway, on a string, you would ward the loop with a range check, probably using a "for" clause: for I in String'range loop exit when String(i) = ' '; end loop; or, if not starting at the start of the string: for I in Current_Pos .. String'last loop if String (I) = ' ' then Current_Pos := I; exit; end if; end loop; In C, with a string, most programmers would just look for a non-blank, including the NUL that is "always" at the end of a string. You can also explicitly code in a limit, as shown by a previous poster in this thread (I don't have it handy). In Ada, if you screw up and don't check the range, you can get an exception. In C, if you don't check the range, most people don't consider it an error, but if the data gets screwed up (no NUL or bad pointer) you can core dump. To bring this back to code layout: Ada provides a way to check the range as part of the loop construct, and a lexically-scoped way to handle the error case. In C, you *can* check for a bad array index but usually don't, and have no way to check whether the array pointer has been rewritten. You have to register a signal handler to deal gracefully with error cases. > >-- David O'Brien (dobrien@seas.gwu.edu) ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: "Subtract C, add Ada" 1995-01-28 21:08 ` David O'Brien 1995-01-31 18:07 ` Samuel Mize @ 1995-02-01 10:23 ` Samuel Mize 1 sibling, 0 replies; 85+ messages in thread From: Samuel Mize @ 1995-02-01 10:23 UTC (permalink / raw) In article <3gebnq$7f3@cronkite.seas.gwu.edu>, David O'Brien <dobrien@seas.gwu.edu> wrote: Several things that made me think harder before I wrote. Painful, but thanks. ;-) Specifically, he wrote >Code layout and where expressions may be used is what this thread was >about. True. To bring it back around: Ada was not designed to be hard to write per se, but it *was* explicitly designed to be easy to read accurately, even when that made it harder to write. Note also, not just easy to read, but easy to read *accurately.* The designer felt that assignments embedded in expressions were easy to miss, and easy to screw up. This opinion is based, in large part, on our collective experiences with debugging C. So, Ada does not let assignment return a value. However, if it really really (not just really) makes your code better somehow, Ada provides a construct with which you can "wrap" the assignment, to make it visible that this particular assignment returns a value. This construct is the function declaration. With pragma inline and a little attention to what you are doing, this should be as efficient as an embedded expression, and should also be clearer to the maintenance programmer. For example, >...The original >C code was: > while ( (c = getchar()) == ' ' ) { /* count spaces */ } To make truly equivalent Ada code, you would need a function, probably in a shared file package, that assigns and returns the next character from the file: package Files_Like_C is C: character; function Next_Char return character; end Files_Like_C; with Text_Io; use Text_Io; package body Files_Like_C is function Next_Char return character is begin if End_Of_File then C := Ascii.Nul; -- no EOF character so using NUL else -- to emulate the C string terminator Get (C); return C; end if; end Next_Char; end Files_Like_C; Once all this infrastructure has been set up, you can code: while (Next_Char = ' ') loop null; -- count spaces here if needed end loop; Before anyone says "but look at all that code!" remember, we are recoding the interface to the standard file package, on the assumption that there is a compelling reason to put Next_Char into expressions. Sam Mize - smize@starbase.neosoft.com ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: "Subtract C, add Ada" 1995-01-25 5:57 ` David O'Brien [not found] ` <3g9rf0$71k@Starbase.NeoSoft.COM> @ 1995-01-30 0:24 ` Mark S. Hathaway 1995-01-31 3:30 ` Jay Martin 1 sibling, 1 reply; 85+ messages in thread From: Mark S. Hathaway @ 1995-01-30 0:24 UTC (permalink / raw) > In article <3g4p94$g07@cronkite.seas.gwu.edu>, > dobrien@seas.gwu.edu (David O'Brien) writes: > : Robert Firth (firth@sei.cmu.edu) wrote: > : LOOP > : get(c); > : EXIT WHEN c /= ASCII.SP; > : END LOOP; > : > : Note also that if there are *no more* non space characters, the C code > : dies in an infinite loop, while the Ada code automatically does the > : right thing, namely raises the END_ERROR exception. > Woa! Just how is it going to be determined that "enough" spaces have > been processed before it is decided that we have an infinate loop? > I'm not too sure I want some compiler/run-time to decide it has had > enough and kill my program... > > -- David O'Brien (dobrien@seas.gwu.edu) Why should C code die in an infinite loop? Wouldn't that eventually be an end-of-file character, if not some other non-space character(s)? Mark S. Hathaway <hathawa2@marshall.edu> ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: "Subtract C, add Ada" 1995-01-30 0:24 ` Mark S. Hathaway @ 1995-01-31 3:30 ` Jay Martin 1995-02-01 13:25 ` Jesper Kaagaard 0 siblings, 1 reply; 85+ messages in thread From: Jay Martin @ 1995-01-31 3:30 UTC (permalink / raw) First there was: Newtons Principia.... then came: Einstein's Theory of Relativity... And Now.... G E T C H A R ()!!! BOM-BOM BOM-BOM BOM-BOM... --------------------------------- For some laughs lets look at the man page for getchar(): NAME getc, getchar, fgetc, getw - get character or integer from stream SYNOPSIS #include <stdio.h> int getc(stream) FILE *stream; int getchar() int fgetc(stream) FILE *stream; int getw(stream) FILE *stream; DESCRIPTION getc() returns the next character (that is, byte) from the named input stream, as an integer. It also moves the file pointer, if defined, ahead one character in stream. getchar() is defined as getc(stdin). getc() and getchar() are macros. >> Hee Hee, are we getting a char or an "int"? Well it returns >> an int and then we need to do an implicit conversion back into >> a char. Assuming c is a char in "c = getchar()" then we have >> just lost the ability to check for EOF since we may have read >> a char with value 255 (assuming EOF = -1). Implicit conversions >> rule!!! fgetc() behaves like getc(), but is a function rather than a macro. fgetc() runs more slowly than getc(), but it takes less space per invocation and its name can be passed as an argument to a function. > Macros, ZOOOOOOOM!!!!!! getw() returns the next C int (word) from the named input stream. getw() increments the associated file pointer, if defined, to point to the next word. The size of a word is the size of an integer and varies from machine to machine. getw() assumes no special alignment in the file. RETURN VALUES On success, getc(), getchar() and fgetc() return the next character from the named input stream as an integer. On failure, or on EOF, they return EOF. The EOF condition is remembered, even on a terminal, and all subsequent opera- tions which attempt to read from the stream will return EOF until the condition is cleared with clearerr() (see ferror(3V)). >> Hey, maybe we could use this ferror() thingy to tell the difference >> between EOF and char 255. Well we probably should anyway to detect >> the difference between EOF and failure. Oh, the elegance of it all! getw() returns the next C int from the named input stream on success. On failure, or on EOF, it returns EOF, but since EOF is a valid integer, use ferror(3V) to detect getw() errors. >> Oops! Sorry about that. SYSTEM V RETURN VALUES On failure, or on EOF, these functions return EOF. The EOF condition is remembered, even on a terminal, however, opera- tions which attempt to read from the stream will ignore the current state of the EOF indication and attempt to read from the file descriptor associated with the stream. >> Don't want to restrict the programmer! Damn the torpedos! Full >> steam ahead! Lets here it for SYSTEM V!! SEE ALSO ferror(3V), fopen(3V), fread(3S), gets(3S), putc(3S), scanf(3V), ungetc(3S) WARNINGS If the integer value returned by getc(), getchar(), or fgetc() is stored into a character variable and then com- pared against the integer constant EOF, the comparison may never succeed, because sign-extension of a character on widening to integer is machine-dependent. BUGS Because it is implemented as a macro, getc() treats a stream argument with side effects incorrectly. In particular, getc(*f++) does not work sensibly. fgetc() should be used instead. Because of possible differences in word length and byte ord- ering, files written using putw() are machine-dependent, and may not be readable using getw() on a different processor. >> We don't need these stinking warnings, they are obvious from the >> include file! ------------------------------------------------------------------ Well this is what happens when you let incompetent pinheads design operating system and languages. Of course the clowns in industry and academia standing around drooling at this shit with the look of adoration on their faces doesn't help either. I think I'll go punch a brick wall until my hands bleed. Jay ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: "Subtract C, add Ada" 1995-01-31 3:30 ` Jay Martin @ 1995-02-01 13:25 ` Jesper Kaagaard 0 siblings, 0 replies; 85+ messages in thread From: Jesper Kaagaard @ 1995-02-01 13:25 UTC (permalink / raw) Jay Martin (jmartin@oahu.cs.ucla.edu) wrote: : First there was: : Newtons Principia.... : then came: : Einstein's Theory of Relativity... : And Now.... : G E T C H A R ()!!! BOM-BOM BOM-BOM BOM-BOM... : --------------------------------- : For some laughs lets look at the man page for getchar(): ehh, how old are you Martin ?? --- peter (never mind the from field) ^ permalink raw reply [flat|nested] 85+ messages in thread
* "Subtract C, add Ada" @ 1995-01-20 9:33 R.A.L Williams 0 siblings, 0 replies; 85+ messages in thread From: R.A.L Williams @ 1995-01-20 9:33 UTC (permalink / raw) [Our news system broke down earlier this week so I don't know whether this message got out. If it did I apologise for the wasted bandwidth. Bill Williams] Robert Dewar wrote.. > Bill comments that for his points 3. and 4. > > 3. uninitialised pointer access > 4. pointer references to local variables in defunct procedures > > "The syntax of Ada .. does not really address 3. or 4." > > Taking point 3, it is impossible to have an uninitialized pointer in Ada, > all pointers are initialized to null, and any attempt to use a null pointer, > i.e. to dereference it, will cause a constraint error. Seems like pretty > complete protection to me. Yes, you're right, Ada *guarantees* a run time crash, in C/C++ it's just very likely. It's still not a compile time check so you're relying on the quality of your run time environment to tie down where the problem occurs. Of course, in embedded systems you don't want *any* exceptions, no matter how cleanly you handle them! I'm not saying that we necessarily want to go to a language which either doesn't allow pointers (yuck!) or constrains their use to such an extent that compile time checks are feasible; I was just trying to point out that using Ada is no substitute for good engineering practice in design and coding. > With regard to point 4, ther is no way to get pointer references to local > variables in Ada 83 (except use of 'Address, and non-portable maybe-works, > maybe-doesn't unchecked conversion of the address to an access type, which > really doesn't count). Certainly students (and most other Ada programmers) > should be forbidden from using such constructs (the use of 'Address, and > indeed of unchecked conversion of addresses to access types is permissible > in some situations, but taking the 'Address of locals in a subprogram is > pretty dubious). Again, you're right BUT, 'ADDRESS is something you need to do fairly often when interfacing to foreign languages. Sorry, don't want to start a religious argument about libraries etc. it's just a fact of life. I agree whole heartedly about restricting the constructs used by 'novice' programmers or those coding for `critical' environments. > In Ada 95, it is indeed possible to take the 'Access of local variables, > provided they are marked aliased, but the accessibility rules make it > impossible to have dangling pointers. Dangling pointers can be created > by the use of Unchecked_Access, but this is in the same category as > Unchecked_Conversion, to be used with great care in rare cases. I'm looking forward to trying out Ada95. Got GNAT 2.0 up and going on a SPARC station that I have occasional access to. I'm really looking forward to the HP700 port because that's what our local network is. Thanks for the feedback. Bill Williams ^ permalink raw reply [flat|nested] 85+ messages in thread
[parent not found: <3fgphd$sc3@rational.rational.com>]
* Re: "Subtract C, add Ada" [not found] <3fgphd$sc3@rational.rational.com> @ 1995-01-20 5:51 ` RonaldS60 1995-02-07 13:55 ` Robert C. Soong 0 siblings, 1 reply; 85+ messages in thread From: RonaldS60 @ 1995-01-20 5:51 UTC (permalink / raw) Gary Frankel (gfrankel@rational.com) wrote >As of late 1989, I was involved in a commerical Ada optimizing >compiler... We published results on a wide variety of benchmarks >(Hennessey,etc) that showed that the Ada compiler was producing >better code than any commercially available C compiler at that time >and far better than most C compilers. This was true for workstations >and cross compilers. > >I cant vouch to the same degree for the current state of the art >since I havent done the same studies recently, but I believe >that you will find tha the optimizing Ada compilers can produce >comparable or better code than C compilers. I have also noticed >that a number of C++ compilers produce poorer code - probably due >to the current level of maturity. About two years ago a IEEE article (in one of the s/w engineering journals) compared the percentages of dead code (I assume using some reachability algorithm) between Fortran, C, and C++. The numbers were suprising (to say the least) and indicated that while Fortran had the least dead code (followed by C) C++ could have upto 60%-75% dead code. The exact quantity being undecidable in a static analysis due to virtual function calls. This research hasn't had any obvious effect on the C++ crowd (or any of the OO people) that I have seen. >Generally, an optimizing Ada compiler is actually at an advantage over >C compilers due to Ada sources providing more useful type information >and the aliasing problems of C. Ada compilers will tend to >compile more slowly since they do considerably more checking than >C compilers. One of the problems with aliasing is covered in an article titled 'The Undecidability of Aliasing' by G. Ramalingam in ACM Transactions on Programming Languages and Systems, vol. 16 no. 5, September 1994. >So, I think that anyone who does a careful study will simply not >find that C has any advantages in code efficiency over Ada at all >(at least on any program more than a few short lines). Actually there was an article around 1989 to 1991 covering the difference between two programs (that did the same thing) written in C and Ada. They were both compiled on the best compilers that could be found. C won for overall speed, by less than 2% when runtime checking was disabled (as it could be when the program was validated.) A 1% to 2% difference in speed isn't much price to pay when the overall development cycle is shortened (especially in testing) as much as Ada allows (when compared to C.) Just think how nice it would have been if that company in Redmond had used Ada instead of C (oooh, software that actually works! and on time! ;{))). >-- Gary Frankel > > >Mitch Gart (mg@asp.camb.inmet.com) wrote: >: Jay Martin (jmartin@oahu.cs.ucla.edu) wrote: > >: : I read the abstracts to these papers before I posted, there is not >: : one peep about the relative efficiency between C and Ada which >: : should be the central topic of discussion in my opinion. > >: I wrote a paper on this, which is now pretty dated, but still might >: possibly be of interest: > >: "Benchmarking Ada, C, and Pascal", SigAda conference, July 1986, >: Pittsburgh. > >: Mitch Gart Ron ====================================================== Computers now make it possible to make more mistakes more efficiently than ever before possible. ====================================================== ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: "Subtract C, add Ada" 1995-01-20 5:51 ` RonaldS60 @ 1995-02-07 13:55 ` Robert C. Soong 0 siblings, 0 replies; 85+ messages in thread From: Robert C. Soong @ 1995-02-07 13:55 UTC (permalink / raw) RonaldS60 (ronalds60@aol.com) wrote: : Gary Frankel (gfrankel@rational.com) wrote : >As of late 1989, I was involved in a commerical Ada optimizing : >compiler... We published results on a wide variety of benchmarks : >(Hennessey,etc) that showed that the Ada compiler was producing : >better code than any commercially available C compiler at that time : >and far better than most C compilers. This was true for workstations : >and cross compilers. : > : >I cant vouch to the same degree for the current state of the art : >since I havent done the same studies recently, but I believe : >that you will find tha the optimizing Ada compilers can produce : >comparable or better code than C compilers. I have also noticed : >that a number of C++ compilers produce poorer code - probably due : >to the current level of maturity. : About two years ago a IEEE article (in one of the s/w engineering : journals) compared the percentages of dead code (I assume using some : reachability algorithm) between Fortran, C, and C++. The numbers : were suprising (to say the least) and indicated that while Fortran : had the least dead code (followed by C) C++ could have upto 60%-75% : dead code. The exact quantity being undecidable in a static analysis : due to virtual function calls. This research hasn't had any obvious : effect on the C++ crowd (or any of the OO people) that I have seen. : >Generally, an optimizing Ada compiler is actually at an advantage over : >C compilers due to Ada sources providing more useful type information : >and the aliasing problems of C. Ada compilers will tend to : >compile more slowly since they do considerably more checking than : >C compilers. : One of the problems with aliasing is covered in an article titled : 'The Undecidability of Aliasing' by G. Ramalingam in ACM Transactions : on Programming Languages and Systems, vol. 16 no. 5, September 1994. : >So, I think that anyone who does a careful study will simply not : >find that C has any advantages in code efficiency over Ada at all : >(at least on any program more than a few short lines). : Actually there was an article around 1989 to 1991 covering the : difference between two programs (that did the same thing) written in : C and Ada. They were both compiled on the best compilers that could : be found. C won for overall speed, by less than 2% when runtime : checking was disabled (as it could be when the program was validated.) : A 1% to 2% difference in speed isn't much price to pay when the : overall development cycle is shortened (especially in testing) as : much as Ada allows (when compared to C.) Just think how nice it : would have been if that company in Redmond had used Ada instead of : C (oooh, software that actually works! and on time! ;{))). : >-- Gary Frankel : > : > : >Mitch Gart (mg@asp.camb.inmet.com) wrote: : >: Jay Martin (jmartin@oahu.cs.ucla.edu) wrote: : > : >: : I read the abstracts to these papers before I posted, there is not : >: : one peep about the relative efficiency between C and Ada which : >: : should be the central topic of discussion in my opinion. : > : >: I wrote a paper on this, which is now pretty dated, but still might : >: possibly be of interest: : > : >: "Benchmarking Ada, C, and Pascal", SigAda conference, July 1986, : >: Pittsburgh. : > : >: Mitch Gart : Ron : ====================================================== : Computers now make it possible to make more mistakes : more efficiently than ever before possible. : ====================================================== ^ permalink raw reply [flat|nested] 85+ messages in thread
[parent not found: <3etund$hnr@miranda.gmrc.gecm.com>]
* Re: "Subtract C, add Ada" [not found] <3etund$hnr@miranda.gmrc.gecm.com> @ 1995-01-12 9:56 ` Erik Svensson 1995-01-12 14:44 ` Norman H. Cohen 1995-01-13 1:51 ` David O'Brien 2 siblings, 0 replies; 85+ messages in thread From: Erik Svensson @ 1995-01-12 9:56 UTC (permalink / raw) > 3. uninitialised pointer access > 4. pointer references to local variables in defunct procedures >The syntax of Ada removes or reduces errors like 1. and 2. but does >not really address 3. or 4. (admitedly, 4. is an unnatural practice in >Ada and would be pretty rare anyway). Since Ada inititalizes (Sp?) all access variables to Null 3, would seem to be handled as well, or at least easily handled. ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: "Subtract C, add Ada" [not found] <3etund$hnr@miranda.gmrc.gecm.com> 1995-01-12 9:56 ` Erik Svensson @ 1995-01-12 14:44 ` Norman H. Cohen 1995-01-13 1:51 ` David O'Brien 2 siblings, 0 replies; 85+ messages in thread From: Norman H. Cohen @ 1995-01-12 14:44 UTC (permalink / raw) In article <3etund$hnr@miranda.gmrc.gecm.com>, bill@valiant (R.A.L Williams) writes: |> My experience of writing software and running software projects in C |> highlights four common low-level C errors: |> 1. = instead of == and vice versa |> 2. spurious ; after for(...) or while(...) |> 3. uninitialised pointer access |> 4. pointer references to local variables in defunct procedures |> The syntax of Ada removes or reduces errors like 1. and 2. but does |> not really address 3. or 4. (admitedly, 4. is an unnatural practice in |> Ada and would be pretty rare anyway). No, Ada helps to eliminate all four kinds of errors. #3: In Ada, all pointers are initialized by default to null. An attempt to dereference a null pointer IMMEDIATELY raises Constraint_Error, so these errors are generally discovered during testing. (The only way they could fail to be discovered is if the testing failed to exercise the path along which the dereference is reached without a prior assignment of a nonnull value.) In C such an error could remain undiscovered even if the tests exercise the relevant path. The arbitrary contents of the uninitialized pointer might happen not to generate an invalid memory reference; or the error could occur sporadically and irreproducibly, but manifest itself only indirectly, much later in the execution of the program, because of some datum clobbered by assignment to the variable "pointed to" by an uninitialized pointer. Then the error might never be properly attributed to the dereference of an uninitialized pointer. #4: In Ada 83, access values point only to dynamically allocated variables, not to declared variables, so the issue does not arise. In Ada 95, access values can pointed to variables declared aliased, but a pointer to a local variable of a subprogram can only belong to an access type that is itself declared inside the subprogram, so the pointer cannot outlive the variable to which it was pointing. |> The really strong point about Ada, especially where large teams, or |> inexperienced coders, are involved is that it strongly encourages |> the separation of SPECIFICATION from IMPLEMENTATION, and provides |> a language enforced formalisation of the mechanism. Never mind the |> commonly expressed rationale behind this, ie. information hiding: |> forcing the interfaces between components to be *designed* before |> attempting to write the implementation, and then encouraging (because |> of the sheer hassle of not doing it) some sort of formal mechanism |> if the interfaces have to be changed has got to be the main factor in |> the success of a project. I agree. I also agree with you that it is not hard for programmers who understand the Ada philosophy to use C in a disciplined way to simulate Ada packages. However, violations of the discipline are not easily recognized or enforced. (The discipline involves, among other things, remembering to override the inexcusable C default that functions are extern rather than static; and always #include'ing a header file with the declarations of a file's external functions both in the file defining those functions--to ensure consistency as the file is modified--and in all files calling such functions.) But don't underestimate the power of the stupid little errors--the ones that occur and persist in C programs, but never occur or are eliminated immediately in Ada programs--to slow a project down or even cause its failure. -- Norman H. Cohen ncohen@watson.ibm.com ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: "Subtract C, add Ada" [not found] <3etund$hnr@miranda.gmrc.gecm.com> 1995-01-12 9:56 ` Erik Svensson 1995-01-12 14:44 ` Norman H. Cohen @ 1995-01-13 1:51 ` David O'Brien 1995-01-13 12:38 ` Laurent Gasser ` (2 more replies) 2 siblings, 3 replies; 85+ messages in thread From: David O'Brien @ 1995-01-13 1:51 UTC (permalink / raw) R.A.L Williams (bill@valiant) wrote: : My experience of writing software and running software projects in C : highlights four common low-level C errors: : 1. = instead of == and vice versa I have to wonder. What if C defined the logical equals operator to be "=" and the assignment operator to be ":=" just like Ada, Algol, Pascal, Modula-x, etc? Would this error still exist??? Quickly thinking about it, I feel that I write a lot more assignment statements than local statements, couldn't I be in the habit of typing ":=" and thus accidently type that when I meant logical comparison? Since that would still be a perfectly valid, conforming C program, the compiler is not required to give any warnings (just like current practice). Thus, I would still have the same logic error in my program. Chances of happening??? Any bodies guess. So is the problem really one of symbol choice, or program semantics? : 2. spurious ; after for(...) or while(...) This is one area I *really* like about Ada. However, I feel there is a much more common programming error (occurs in Pascal too): for (...) first_action(); second_action(); The indenting implies that "second_action()" should be part of the the loop body. But it isn't. :-)) So many times I've seen this in industry. Every new programmer I work with I try to drill into their head's "*always* use braces with your if, while, for statements, even when you have only one thing in your loop body. For one day a maintainer will need to add that second thing, and indent like the above -- forgetting to add the braces." Many will not listen thinking they know better. Tisk, tisk, tisk. Usually it doesn't take long for them to get bitten and remember. Same for Pascal. I really don't understand why most languages are designed the Pascal/C way rather than the Ada way. Especially since it removes the common ambiguity of nested if statements. -- David O'Brien (dobrien@seas.gwu.edu) ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: "Subtract C, add Ada" 1995-01-13 1:51 ` David O'Brien @ 1995-01-13 12:38 ` Laurent Gasser 1995-01-13 20:53 ` John DiCamillo ` (2 more replies) 1995-01-14 10:37 ` Keith Thompson [not found] ` <D2It0r.4rp@inmet.camb.inmet.com> 2 siblings, 3 replies; 85+ messages in thread From: Laurent Gasser @ 1995-01-13 12:38 UTC (permalink / raw) In article <3f4mbe$rud@cronkite.seas.gwu.edu>, dobrien@seas.gwu.edu (David O'Brien) writes: |> R.A.L Williams (bill@valiant) wrote: |> : My experience of writing software and running software projects in C |> : highlights four common low-level C errors: |> : 1. = instead of == and vice versa |> |> I have to wonder. What if C defined the logical equals operator to be |> "=" and the assignment operator to be ":=" just like Ada, Algol, Pascal, |> Modula-x, etc? Would this error still exist??? The problem is in the language definition, not in the choic of symbols. C is one of the rare language I use to allow having an assignment after the if statement. All other languages only allow for a boolean test. I never saw a good reason for allowing this. -- Laurent Gasser (gasser@dma.epfl.ch) Computers do not solve problems, they execute solutions. I know very few ideas worth dying for, none is worth killing. ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: "Subtract C, add Ada" 1995-01-13 12:38 ` Laurent Gasser @ 1995-01-13 20:53 ` John DiCamillo [not found] ` <3f8fnf$c8p@gamma.ois.com> [not found] ` <3fa11q$sdh@gnat.cs.nyu.edu> 1995-01-14 0:24 ` David O'Brien 1995-01-20 4:43 ` Samuel Mize 2 siblings, 2 replies; 85+ messages in thread From: John DiCamillo @ 1995-01-13 20:53 UTC (permalink / raw) gasser@masg1.epfl.ch (Laurent Gasser) writes: >In article <3f4mbe$rud@cronkite.seas.gwu.edu>, dobrien@seas.gwu.edu (David O'Brien) writes: >|> R.A.L Williams (bill@valiant) wrote: >|> : My experience of writing software and running software projects in C >|> : highlights four common low-level C errors: >|> : 1. = instead of == and vice versa >|> >|> I have to wonder. What if C defined the logical equals operator to be >|> "=" and the assignment operator to be ":=" just like Ada, Algol, Pascal, >|> Modula-x, etc? Would this error still exist??? >The problem is in the language definition, not in the choic of symbols. >C is one of the rare language I use to allow having an assignment after >the if statement. All other languages only allow for a boolean test. >I never saw a good reason for allowing this. Huh? It falls naturally out of two other C rules: 1) an assignment is an expression whose value is equal to that of the thing being assigned, 2) any expression that evaluates to integer 0 is false, all other expressions are true. C would have required a special restriction to prevent assignment in an if-test. (Note that assignment in a loop-test is a useful and common idiom in C.) That said, if this error is anyone's biggest concern about developing software in C, then that person has not really tried to develop software in C. All lan- guages have warts, even Ada. -- ciao, milo ================================================================ John DiCamillo Pinin' for the fjords? milod@netcom.com What kind of talk is that? ^ permalink raw reply [flat|nested] 85+ messages in thread
[parent not found: <3f8fnf$c8p@gamma.ois.com>]
* Re: "Subtract C, add Ada" [not found] ` <3f8fnf$c8p@gamma.ois.com> @ 1995-01-16 11:02 ` Matt Kennel [not found] ` <milodD2IFpG.329@netcom.com> 1 sibling, 0 replies; 85+ messages in thread From: Matt Kennel @ 1995-01-16 11:02 UTC (permalink / raw) R. William Beckwith (beckwb@ois.com) wrote: : John DiCamillo (milod@netcom.com) wrote: : : That said, if this error is anyone's biggest concern : : about developing software in C, then that person has : : not really tried to develop software in C. All lan- : : guages have warts, even Ada. : Some languages' warts are really malignant tumors. ;-) So, all languages have warts, but only in bad ones do they metastasize? ;-) -- -Matt Kennel mbk@inls1.ucsd.edu -Institute for Nonlinear Science, University of California, San Diego -*** AD: Archive for nonlinear dynamics papers & programs: FTP to -*** lyapunov.ucsd.edu, username "anonymous". ^ permalink raw reply [flat|nested] 85+ messages in thread
[parent not found: <milodD2IFpG.329@netcom.com>]
* Re: "Subtract C, add Ada" [not found] ` <milodD2IFpG.329@netcom.com> @ 1995-01-17 21:39 ` R. William Beckwith 0 siblings, 0 replies; 85+ messages in thread From: R. William Beckwith @ 1995-01-17 21:39 UTC (permalink / raw) John DiCamillo (milod@netcom.com) wrote: : beckwb@ois.com (R. William Beckwith) writes: : >John DiCamillo (milod@netcom.com) wrote: : >: That said, if this error is anyone's biggest concern : >: about developing software in C, then that person has : >: not really tried to develop software in C. All lan- : >: guages have warts, even Ada. : >Some languages' warts are really malignant tumors. ;-) : Did you have something useful to follow that up with? No, but I'll make the attempt since you're interested. : Do you disagree with either of the sentences you were : responding to? Do you feel that I am misrepresenting : the relative quality of the two languages in question? Not really and yes. I agree everything has warts. It has been my experience that while Ada's occasional warts can be annoying, C's occasional warts can be deadly. ... Bill ^ permalink raw reply [flat|nested] 85+ messages in thread
[parent not found: <3fa11q$sdh@gnat.cs.nyu.edu>]
* Re: "Subtract C, add Ada" [not found] ` <3fa11q$sdh@gnat.cs.nyu.edu> @ 1995-01-16 20:20 ` David Moore 0 siblings, 0 replies; 85+ messages in thread From: David Moore @ 1995-01-16 20:20 UTC (permalink / raw) dewar@cs.nyu.edu (Robert Dewar) writes: >For another example of UNIFY/CONFUSE, does Algol-68 confuse or unify the >concepts of pointers and variables. My vote would be for UNIFY. Algol-68 clarified many things that were implicit in other languages. For example, Algol 68 made it clear that in the expression: A:=A; The type of A on the left has one more "ref" than the A on the right. I have found that being cavalier about ref's is a good way to get in a horrible mess when writing a compiler or debugger. Hence, I believe anyone who intends to be a language implementor or lawyer should be familiar with Algol 68. Unfortunately, it also introduced W-Grammars which I find almost impossible to manipulate. They belong to level 3, or perhaps 4 in the complexity heirarchy of formalisms: Level 1 Formalism. You can push instances (eg simple sentences in the language) through the formalism in your head. Level 2 Formalism. You can push through instances on a piece of foolscap while sitting at your desk. Level 3 Formalism. You have to get up and clean off the whiteboard before starting. Level 4 Formalism. You and your colleagues have to go into a conference room and clean off the whiteboards. You first have to argue that the phrase "Do not erase" has a scope no larger than the phrase itself. Fortunately, there is also an "informal" report on Algol 68 which is very readable. ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: "Subtract C, add Ada" 1995-01-13 12:38 ` Laurent Gasser 1995-01-13 20:53 ` John DiCamillo @ 1995-01-14 0:24 ` David O'Brien 1995-01-20 4:43 ` Samuel Mize 2 siblings, 0 replies; 85+ messages in thread From: David O'Brien @ 1995-01-14 0:24 UTC (permalink / raw) Laurent Gasser (gasser@masg1.epfl.ch) wrote: : In article <3f4mbe$rud@cronkite.seas.gwu.edu>, dobrien@seas.gwu.edu (David O'Brien) writes: : |> R.A.L Williams (bill@valiant) wrote: : |> : My experience of writing software and running software projects in C : |> : highlights four common low-level C errors: : |> : 1. = instead of == and vice versa : |> : |> I have to wonder. What if C defined the logical equals operator to be : |> "=" and the assignment operator to be ":=" just like Ada, Algol, Pascal, : |> Modula-x, etc? Would this error still exist??? : The problem is in the language definition, not in the choice of symbols. : C is one of the rare language I use to allow having an assignment after : the if statement. All other languages only allow for a boolean test. Yep, that's my point. The argument of character choice really isn't what is at the essence of the problem. Rather it is the language definition. : I never saw a good reason for allowing this. Simply the paradigm of C that *every* statement has a value. And C has no special logical values. So C has "values are values" akin to Ford's offering of the Model-T, "any colour you want, as long as it's black". I'm guessing Ritchie did this for the same reason as Henry Ford - to simply things. Which gave us the situation we have. In most languages the grammar would be: conditional_statement ::= if <logical_expression> then Which in C becomes: conditional_statement ::= if ( <expression> ) <statement> and thus ``<expression>'' must include ``<lvalue> = <expression>''. -- David O'Brien (dobrien@seas.gwu.edu) ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: "Subtract C, add Ada" 1995-01-13 12:38 ` Laurent Gasser 1995-01-13 20:53 ` John DiCamillo 1995-01-14 0:24 ` David O'Brien @ 1995-01-20 4:43 ` Samuel Mize 1995-01-21 20:28 ` David O'Brien 2 siblings, 1 reply; 85+ messages in thread From: Samuel Mize @ 1995-01-20 4:43 UTC (permalink / raw) In article <3f5s92$3id@info.epfl.ch>, Laurent Gasser <gasser@masg1.epfl.ch> wrote: > >The problem is in the language definition, not in the choic of symbols. >C is one of the rare language I use to allow having an assignment after >the if statement. All other languages only allow for a boolean test. > >I never saw a good reason for allowing this. > It's a question of who optimizes your code. In the 60s, when C was developed, compilers *couldn't* optimize code, so the programmer had to. Many apparently-bizarre C capabilities are there to support optimization level -1 (programmer does the optimizations). Consider the common C idiom to copy a null-terminated array, usually a string [syntax may not be quite right]: while (*a++=*b++); Recall that C considers 0 false, a null character is integer 0, and an assignment returns what was assigned. This loop condition copies the character at address b to address a, increments both, and exits when a null was copied. There is no statement inside the loop. This is more efficient, with a non-optimizing compiler, than while (*a) { *a = *b; a=a+1; b=b+1}; /*or whatever is right syntax*/ because * The operator ++ increments the value of while it's still in a register. The second code reads a from memory to do the character assign, reads it again to increment it. * ++ can use the assembler's increment instruction. a=a+1 could not. * Using the assignment as the loop expression indirectly directs the compiler to keep the result of the assignment in a register for reuse in the expression, instead of writing it to memory, then reading it. Thus, with a lot of man-hours, expertise and skull-sweat, someone using a basic C compiler can come within an order of magnitude of the efficiency of someone using a half-good optimizing Ada compiler. Often. Of course, if you only *read* the code, and don't *run* it, it looks like the C is more optimized, because you can *see* the optimizations. With Ada you write less-optimized-looking code, and trust the compiler. (But verify.) >-- >Laurent Gasser (gasser@dma.epfl.ch) >Computers do not solve problems, they execute solutions. > >I know very few ideas worth dying for, none is worth killing. I dunno, I've killed quite a few ideas in my time :-) Sam Mize - smize@starbase.neosoft.com ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: "Subtract C, add Ada" 1995-01-20 4:43 ` Samuel Mize @ 1995-01-21 20:28 ` David O'Brien 1995-01-22 21:12 ` Robert Dewar ` (3 more replies) 0 siblings, 4 replies; 85+ messages in thread From: David O'Brien @ 1995-01-21 20:28 UTC (permalink / raw) In article <3fnf28$s3f@Starbase.NeoSoft.COM> you wrote: : It's a question of who optimizes your code. In the 60s, : when C was developed, compilers *couldn't* optimize code, : so the programmer had to. Many apparently-bizarre C : capabilities are there to support optimization level -1 : (programmer does the optimizations). C was designed in the 70's. The earliest reference I could find to it is the cc(1) UNIX 3rd Edition man page dated 3/15/72 from "A Quarter Century of Unix". The language from which C developed, B, was created in 1970. And the only published document on the B language, "CSTR #8 - The Programming Language B", is dated Jan 1973. BCPL, which B came from, is from 1969. So, I think that "compilers *couldn't* optimize code" may be an over generalization. Is this _really_ the case for 1970's compiler technology? : Consider the common C idiom to copy a null-terminated : array, usually a string [syntax may not be quite right]: : while (*a++=*b++); I am curious about programming culture. Notice that when someone writes something in C they feel they have to remove all white space. When they write in Ada they put in plenty and use [very] long names for every thing. Why is that??? No wonder people say C is hard to read. : This is more efficient, with a non-optimizing compiler, than : while (*a) : { *a = *b; a=a+1; b=b+1}; /*or whatever is right syntax*/ : because : * The operator ++ increments the value of while it's still : in a register. The second code reads a from memory to : do the character assign, reads it again to increment it. You are making a *major* assumption about the CPU this is running on. On many smaller uP's there isn't that many registers. : * ++ can use the assembler's increment instruction. a=a+1 : could not. Since adding 1 to variable is so common place, it is trivial to add this type of optimization (even in your parser). : * Using the assignment as the loop expression indirectly : directs the compiler to keep the result of the assignment : in a register for reuse in the expression, instead : of writing it to memory, then reading it. Again, you really are thinking with a preconceived notion of your hardware. -- David O'Brien (dobrien@sea.gwu.edu) ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: "Subtract C, add Ada" 1995-01-21 20:28 ` David O'Brien @ 1995-01-22 21:12 ` Robert Dewar 1995-01-23 18:35 ` Norman H. Cohen ` (2 subsequent siblings) 3 siblings, 0 replies; 85+ messages in thread From: Robert Dewar @ 1995-01-22 21:12 UTC (permalink / raw) "compilers couldn't optimize code" what is meant here is "C compilers didn't optimize code", and this was partly a matter of philosophy, the idea that C compilers should be simple and do what you say, and NOT rely on optimization. Optimization technology was well developed even in the late 60's. Fortran-2 for the 7094 did a remarkably good job of optimizing loops. Fortran-H was contemporary with early C compilers, and was very aggressive in optimizing typical Fortran code. ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: "Subtract C, add Ada" 1995-01-21 20:28 ` David O'Brien 1995-01-22 21:12 ` Robert Dewar @ 1995-01-23 18:35 ` Norman H. Cohen 1995-01-23 19:18 ` John Cosby - The Coz 1995-01-24 14:11 ` Samuel Mize 3 siblings, 0 replies; 85+ messages in thread From: Norman H. Cohen @ 1995-01-23 18:35 UTC (permalink / raw) In article <3frqpg$re5@cronkite.seas.gwu.edu>, dobrien@seas.gwu.edu (David O'Brien) writes: |> In article <3fnf28$s3f@Starbase.NeoSoft.COM> you wrote: |> : It's a question of who optimizes your code. In the 60s, |> : when C was developed, compilers *couldn't* optimize code, |> : so the programmer had to. Many apparently-bizarre C |> : capabilities are there to support optimization level -1 |> : (programmer does the optimizations). ... |> : Consider the common C idiom to copy a null-terminated |> : array, usually a string [syntax may not be quite right]: |> |> : while (*a++=*b++); |> |> I am curious about programming culture. Notice that when someone writes |> something in C they feel they have to remove all white space. When they |> write in Ada they put in plenty and use [very] long names for every |> thing. Why is that??? No wonder people say C is hard to read. It's because the primitive compilers of the 1970's were incapable of optimizing away the whitespace. ;-) -- Norman H. Cohen ncohen@watson.ibm.com ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: "Subtract C, add Ada" 1995-01-21 20:28 ` David O'Brien 1995-01-22 21:12 ` Robert Dewar 1995-01-23 18:35 ` Norman H. Cohen @ 1995-01-23 19:18 ` John Cosby - The Coz 1995-01-24 14:11 ` Samuel Mize 3 siblings, 0 replies; 85+ messages in thread From: John Cosby - The Coz @ 1995-01-23 19:18 UTC (permalink / raw) David O'Brien (dobrien@seas.gwu.edu) wrote: : In article <3fnf28$s3f@Starbase.NeoSoft.COM> you wrote: : : It's a question of who optimizes your code. In the 60s, : : when C was developed, compilers *couldn't* optimize code, : : so the programmer had to. Many apparently-bizarre C : : capabilities are there to support optimization level -1 : : (programmer does the optimizations). : C was designed in the 70's. The earliest reference I could find to it : is the cc(1) UNIX 3rd Edition man page dated 3/15/72 from "A Quarter : Century of Unix". The language from which C developed, B, was created : in 1970. And the only published document on the B language, "CSTR #8 - : The Programming Language B", is dated Jan 1973. BCPL, which B came : from, is from 1969. The July-August 1978 edition of "The Bell System Technical Journal" contains an article by Ritchie, Johnson, Lesk, and Kernughan entitled "The C Programming Language." In this article they state that B was written in 1970 by Ken Thompson "for the first UNIX system on the PDP-11." They go on to discuss how the introduction of types was a major departure from BCPL and B and mention in passing that C was created "circa 1972." An interesting article, which discusses many of the issues debated during the evolution of Ada into Ada95 from a much "earlier" point of view. Fun to see how far we've come. John ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: "Subtract C, add Ada" 1995-01-21 20:28 ` David O'Brien ` (2 preceding siblings ...) 1995-01-23 19:18 ` John Cosby - The Coz @ 1995-01-24 14:11 ` Samuel Mize 3 siblings, 0 replies; 85+ messages in thread From: Samuel Mize @ 1995-01-24 14:11 UTC (permalink / raw) In article <3frqpg$re5@cronkite.seas.gwu.edu>, David O'Brien <dobrien@seas.gwu.edu> wrote: ... >C was designed in the 70's. ... >So, I think that "compilers *couldn't* optimize code" may be an over >generalization. My apologies for a loose statement. I meant to address the observed beliefs of people who feel that they can write more-efficient code in C. Generally, they hand-write code-level optimizations; they can see it, so they believe in it. They don't expect the compiler to optimize much. Some of them don't *want* the compiler to optimize; they're using side effects and "slick tricks" to save three instructions per hundred. Of course, a good optimizer would do far better for them, but they can't see that unless they meter their program, optimize it, and meter it again. Why bother with what when they *know* that it's more efficient code... Of course, the source code doesn't run. The object code runs. ... >You are making a *major* assumption ... >Again, you really are thinking with ... Your entire post is right, except for attributing these beliefs to *me*. I was unclear. These are beliefs that C programmers have stated to me, as to why C is "more efficient" than Ada. Of course, if a programmer is manually optimizing, he/she must have assumptions about, and a model of, the machine on which the code will run. Sometimes, these will be wrong. Another argument for machine optimization, which Ada better supports. >-- David O'Brien (dobrien@sea.gwu.edu) Yours in agreement, Sam Mize - smize@starbase.neosoft.com ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: "Subtract C, add Ada" 1995-01-13 1:51 ` David O'Brien 1995-01-13 12:38 ` Laurent Gasser @ 1995-01-14 10:37 ` Keith Thompson [not found] ` <3fcjgt$b0v@cronkite.seas.gwu.edu> [not found] ` <D2It0r.4rp@inmet.camb.inmet.com> 2 siblings, 1 reply; 85+ messages in thread From: Keith Thompson @ 1995-01-14 10:37 UTC (permalink / raw) In <3f4mbe$rud@cronkite.seas.gwu.edu> dobrien@seas.gwu.edu (David O'Brien) writes: > I have to wonder. What if C defined the logical equals operator to be > "=" and the assignment operator to be ":=" just like Ada, Algol, Pascal, > Modula-x, etc? Would this error still exist??? > > Quickly thinking about it, I feel that I write a lot more assignment > statements than local statements, couldn't I be in the habit of typing > ":=" and thus accidently type that when I meant logical comparison? > Since that would still be a perfectly valid, conforming C program, > the compiler is not required to give any warnings (just like current > practice). Thus, I would still have the same logic error in my program. > Chances of happening??? Any bodies guess. So is the problem really > one of symbol choice, or program semantics? I suspect this error would be rarer if C used ":=" for assignment. The symbol "=" is used for equality in some languages (Pascal, standard mathethematical notation, etc.) and assignment in others (Fortran, C, etc.). The symbol ":=" is used only for assignment. I don't think I've ever accidentally typed ":=" for a comparison in Ada. Digression: I once heard about a relatively obscure language that used ":" as a catenation operator. It also had C-style assignment operators. So, naturally, the statement "x := y;" assigned to x the result of catenating x and y. end Digression; Of course, if C used ":=" for assignment and "=" for comparison, the opposite error would be likely to occur; people would commonly type x = y; which, instead of assigning the value of y to x, would compare them and discard the result. This could be caught by a compiler warning; an assignment in an expression context sometimes makes sense, but a comparison in a statement context never does. It could even be forbidden, but I suppose that would violate the spirit of C. Hmm. How about ":=" and ".EQ."? 8-)} Please note that this article is not an anti-C flame; it's a theoretical discussion about programming language syntax design. Yeah, there's the ticket. -- Keith Thompson (The_Other_Keith) kst@thomsoft.com (kst@alsys.com still works) TeleSoft^H^H^H^H^H^H^H^H Alsys^H^H^H^H^H Thomson Software Products 10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2718 When you're a nail, every problem looks like a hammer. ^ permalink raw reply [flat|nested] 85+ messages in thread
[parent not found: <3fcjgt$b0v@cronkite.seas.gwu.edu>]
* Re: "Subtract C, add Ada" [not found] ` <3fcjgt$b0v@cronkite.seas.gwu.edu> @ 1995-01-16 18:47 ` Robert Dewar 0 siblings, 0 replies; 85+ messages in thread From: Robert Dewar @ 1995-01-16 18:47 UTC (permalink / raw) "Dennis Ritchie once said in an interview that there is *nothing* in the C language that keeps compiler writers from issuing stringent warnings about stuff that most Ada people take for granted." Dennis may have said this, but it is misleading. Yes, there is stuff that Ada people take for granted that C compilers could (and in some compilers *do*) check for. But there are lots of things that Ada people take for granted that cannot be checked in C, there just isn't enough information. C has no separation of scalar types, no ranges on scalar types, and the ubquitous use of pointers, and their similarity to arrays means that sophisticated aliasing analysis is required to even approximate the type checking that occurs in the context of access types in Ada. There are many other examples. ^ permalink raw reply [flat|nested] 85+ messages in thread
[parent not found: <D2It0r.4rp@inmet.camb.inmet.com>]
* Re: "Subtract C, add Ada" [not found] ` <D2It0r.4rp@inmet.camb.inmet.com> @ 1995-01-17 14:11 ` Norman H. Cohen 0 siblings, 0 replies; 85+ messages in thread From: Norman H. Cohen @ 1995-01-17 14:11 UTC (permalink / raw) Just yesterday I made a one-character typo in a C program (don't ask; it puts food on the table) that preserved the legality of the program but rather radically altered its behavior. I meant to type for (i=0; i<10; i++) but my finger slipped off the shift key when I was typing "<", so it came out for (i=0; i,10; i++) which tests for loop termination by evaluating i, discarding that value, evaluating 10, and leaving the loop when 10 equals zero (i.e., never). What a language! -- Norman H. Cohen ncohen@watson.ibm.com ^ permalink raw reply [flat|nested] 85+ messages in thread
* "Subtract C, add Ada" @ 1994-12-30 16:06 Mitch Gart 1995-01-03 19:04 ` whiting_ms@corning.com (Matt Whiting) ` (2 more replies) 0 siblings, 3 replies; 85+ messages in thread From: Mitch Gart @ 1994-12-30 16:06 UTC (permalink / raw) In the Dec. 12 PC Week, next to the review of Alsys ActivAda, was this sidebar by Peter Coffee: Subtract C, add Ada: Results multiply ------------------------------------- Few managers can afford to do a software project several times, using teams with similar experience but different programming tools, to see if anything yields consistent improvements in speed or quality of work. At the State University of New York, Plattsburgh, though, Professor John McCormick has assigned the same project to each of his classes for about nine years, but switched languages in mid-decade. Working in teams of three or four, McCormick's real-time-programming students must write 15,000 lines of code to control a system that would need about 150 switches to operate using hardware alone. In the five years students used C, no team completed the project - even when more than half of the code was provided. With Ada, however, half of the teams completed the project before any support code had even been written. With some support code now provided, three out of four teams finish the project. Specific factors in this improvement, according to McCormick, include both syntax and semantics. Ada leaves less room for single-keystroke errors, such as the common C error of using = (assignment) instead of == (comparison); its type-abstraction facilities reduce the need for error-prone pointer manipulation; and its modular facilities improve teams' coordination of effort. This experience, McCormick notes, "has convinced all my faculty colleagues to support teaching Ada in our beginning courses. This spring semester, the first studentw with Ada as their mother tongue will enroll in my course. I can only imagine what these teams will accomplish". ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: "Subtract C, add Ada" 1994-12-30 16:06 Mitch Gart @ 1995-01-03 19:04 ` whiting_ms@corning.com (Matt Whiting) 1995-01-05 4:31 ` Michael Feldman 1995-01-04 21:40 ` Fred McCall 1995-01-04 22:45 ` Jay M. Martin 2 siblings, 1 reply; 85+ messages in thread From: whiting_ms@corning.com (Matt Whiting) @ 1995-01-03 19:04 UTC (permalink / raw) In article <D1Msq8.4Hs@inmet.camb.inmet.com>, mg@asp.camb.inmet.com (Mitch Gart) writes: > In the Dec. 12 PC Week, next to the review of Alsys ActivAda, > was this sidebar by Peter Coffee: > > > Subtract C, add Ada: Results multiply > ------------------------------------- > > Few managers can afford to do a software project several times, > using teams with similar experience but different programming > tools, to see if anything yields consistent improvements in speed > or quality of work. At the State University of New York, Plattsburgh, > though, Professor John McCormick has assigned the same project to > each of his classes for about nine years, but switched languages > in mid-decade. > . > . > . -- I read the PC Week article, but found no contact information for professor McCormick. I searched via InterNIC and found a listing for a John McCormick, but it gave only a telephone number and didn't indicate a location or an email address. Does anyone know professor McCormick and know if he has an email address? I can call the McCormick listed, but I'd like to have some idea if this is the right person beforehand. ------------------------------------------------------------------------------- Matthew S. Whiting, P.E. | Corning Incorporated | (607) 974-6317 phone Sr. Project Engineer | HP-ME-03-073 | (607) 974-6752 fax whiting_ms@corning.com | Corning, NY 14831 | ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: "Subtract C, add Ada" 1995-01-03 19:04 ` whiting_ms@corning.com (Matt Whiting) @ 1995-01-05 4:31 ` Michael Feldman 0 siblings, 0 replies; 85+ messages in thread From: Michael Feldman @ 1995-01-05 4:31 UTC (permalink / raw) In article <1995Jan3.140431.1@corning.com>, whiting_ms@corning.com (Matt Whiting) <whiting_ms@corning.com> wrote: >I read the PC Week article, but found no contact information for professor >McCormick. I searched via InterNIC and found a listing for a John McCormick, >but it gave only a telephone number and didn't indicate a location or an email >address. Does anyone know professor McCormick and know if he has an email >address? I can call the McCormick listed, but I'd like to have some idea if >this is the right person beforehand. John's address is MCCORMJW@splava.cc.plattsburgh.edu. A TRI-Ada '91 paper on this project at Plattsburgh won the Best Paper award at that conference. What the PC Week story left out is that the real-time system they build in that course controls an HO train setup. It's a really nice piece of work. Mike Feldman ------------------------------------------------------------------------ Michael B. Feldman - chair, SIGAda Education Working Group Professor, Dept. of Electrical Engineering and Computer Science The George Washington University - Washington, DC 20052 USA 202-994-5919 (voice) - 202-994-0227 (fax) - mfeldman@seas.gwu.edu (Internet) ------------------------------------------------------------------------ One, two, three ways an underdog: Ada fan, Mac fan, Old Liberal Democrat ------------------------------------------------------------------------ Ada on the World-Wide Web: http://lglwww.epfl.ch/Ada/ ------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: "Subtract C, add Ada" 1994-12-30 16:06 Mitch Gart 1995-01-03 19:04 ` whiting_ms@corning.com (Matt Whiting) @ 1995-01-04 21:40 ` Fred McCall 1995-01-05 4:30 ` Richard Pattis ` (3 more replies) 1995-01-04 22:45 ` Jay M. Martin 2 siblings, 4 replies; 85+ messages in thread From: Fred McCall @ 1995-01-04 21:40 UTC (permalink / raw) In <D1Msq8.4Hs@inmet.camb.inmet.com> mg@asp.camb.inmet.com Mitch Gart writes: >Ada leaves less room for single-keystroke >errors, such as the common C error of using = (assignment) instead of >== (comparison); I've always been curious. Just *where* is this a "common C error"? I've seen lots of beginners and non-C programmers claim it is, but I don't recall ever hearing of anyone who knew what they were doing (and who was using a real tool -- say, lint -- to check their code) making it. >its type-abstraction facilities reduce the need for >error-prone pointer manipulation; Afraid this one doesn't seem to make sense. How does being able to define a dozen incompatible types of integer "reduce the need for error-prone pointer manipulation"? >and its modular facilities improve >teams' coordination of effort. Both languages are modular. I'm not sure how this is a 'win' unless we're talking about totally inexperienced teams. > >This experience, McCormick notes, "has convinced all my faculty >colleagues to support teaching Ada in our beginning courses. This >spring semester, the first studentw with Ada as their mother tongue >will enroll in my course. I can only imagine what these teams will >accomplish". Well, Ada is certainly a better choice than C for a beginning language to teach design concepts, etc. However, that isn't necessarily saying a whole lot, since that wasn't what C was intended for. I'm also not sure why that would be considered a 'plus', unless the idea behind Ada was to come up with a good language for beginners; that wasn't the idea behind it. -- "Insisting on perfect safety is for people who don't have the balls to live in the real world." -- Mary Shafer, NASA Ames Dryden --------------------------------------------------------------------------- merlin@annwfn.com -- I don't speak for others and they don't speak for me. ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: "Subtract C, add Ada" 1995-01-04 21:40 ` Fred McCall @ 1995-01-05 4:30 ` Richard Pattis 1995-01-05 16:07 ` Kevin Weise ` (2 subsequent siblings) 3 siblings, 0 replies; 85+ messages in thread From: Richard Pattis @ 1995-01-05 4:30 UTC (permalink / raw) In article <862035D1F1C@annwfn.com> merlin@annwfn.com (Fred McCall) writes: >In <D1Msq8.4Hs@inmet.camb.inmet.com> mg@asp.camb.inmet.com Mitch Gart writes: > >>Ada leaves less room for single-keystroke >>errors, such as the common C error of using = (assignment) instead of >>== (comparison); > >I've always been curious. Just *where* is this a "common C error"? >I've seen lots of beginners and non-C programmers claim it is, but I >don't recall ever hearing of anyone who knew what they were doing (and >who was using a real tool -- say, lint -- to check their code) making >it. In Peter van der Linden's excellent book, "Expert C Programming: Deep C Secrets", Prentice Hall, on page xx (that's 20 in the preface) he describes a problem from 1993 in the Operating System development group at SunSoft (he works at Sun and was part of the debugging effort he describes). A bug in the asynchronous I/O libary was holding up a $20million dollar sale - the customer needed the library to work. It turns out that someone had written x==2 by accident. As van der Linden states "Some versions of the lint program would have detected this problem, but it's all too easy to avoid the automatic use of this essential tool." Rich -- ------------------------------------------------------------------------------ Richard E. Pattis "Programming languages are like Looking for a Job pizzas - they come in only "too" size: too big and too small. ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: "Subtract C, add Ada" 1995-01-04 21:40 ` Fred McCall 1995-01-05 4:30 ` Richard Pattis @ 1995-01-05 16:07 ` Kevin Weise 1995-01-06 13:06 ` Jahn Rentmeister 1995-01-06 23:36 ` Kenneth Almquist 3 siblings, 0 replies; 85+ messages in thread From: Kevin Weise @ 1995-01-05 16:07 UTC (permalink / raw) In article <862035D1F1C@annwfn.com>, Fred McCall <merlin@annwfn.com> wrote: >In <D1Msq8.4Hs@inmet.camb.inmet.com> mg@asp.camb.inmet.com Mitch Gart writes: > >>Ada leaves less room for single-keystroke >>errors, such as the common C error of using = (assignment) instead of >>== (comparison); > >I've always been curious. Just *where* is this a "common C error"? >I've seen lots of beginners and non-C programmers claim it is, but I >don't recall ever hearing of anyone who knew what they were doing (and >who was using a real tool -- say, lint -- to check their code) making >it. Well, Mr. McCall, I will attempt to respond to this in a fashion that does not violate netiquette. However, from previous threads here on CLA, I believe this is one of your hot buttons. The fact is, I know lots of C/C++ people, and quite a few of them agree that this is a common error they make {e.g., if (var = expr), rather than if (var == expr)}. These people are not beginners; but some of them are certainly hackers. Nonetheless, as far as I've seen, this is a well-known recognized source of common errors. Certainly a good lint program will question this usage; that's not at issue. But I believe that = vs. == was used as an example of single character errors that make it through the compiler; certainly it is not the only one. > >>its type-abstraction facilities reduce the need for >>error-prone pointer manipulation; > >Afraid this one doesn't seem to make sense. How does being able to >define a dozen incompatible types of integer "reduce the need for >error-prone pointer manipulation"? While I agree with you that the introduction of multiple scalar types in Ada programs can be abused, I don't think that is what was being referred to. Two examples that come to my mind are the common practice of equating ints with pointers (although thankfully this is becoming less common these days) and the practice of passing non-scalar data by reference with the concommitant possible type mismatch between subprograms. Thus, there is a point of view that makes sense. > >>and its modular facilities improve >>teams' coordination of effort. > >Both languages are modular. I'm not sure how this is a 'win' unless >we're talking about totally inexperienced teams. > Agreed, both languages are modular. But I think that the author may have meant that strong typing is too easily circumvented in C; this degrades coordination between teams. This is not to say that circumventing strong typing is unnecessary; I agree that it is necessary sometimes. I just prefer being better able to recognize when its being done in code that I'm reading. >> >>This experience, McCormick notes, "has convinced all my faculty >>colleagues to support teaching Ada in our beginning courses. This >>spring semester, the first studentw with Ada as their mother tongue >>will enroll in my course. I can only imagine what these teams will >>accomplish". > >Well, Ada is certainly a better choice than C for a beginning language >to teach design concepts, etc. However, that isn't necessarily saying a >whole lot, since that wasn't what C was intended for. I'm also not sure >why that would be considered a 'plus', unless the idea behind Ada was to >come up with a good language for beginners; that wasn't the idea behind >it. Well, I think it says alot. There's a belief that the way we think about problem solving is directly related to the language(s) we know. This is because language provides structure to the concepts and ideas we use for thinking. (This belief did not come out of computer science or engineering, either.) It only makes sense that a programming language that provides good direct support for design issues as well should be of great benefit. Projects that I've seen that used Ada & failed did so for a variety of reasons; but a frequent one was that it was designed with a (FORTRAN, asembly, whatever) mindset but coded in Ada. It shouldn't take a rocket scientist to figure out that the effect is the same if you do a literal translation from any other natural language into English. However, for me, what really said a lot is that *none* of the teams that used C finished the project, whereas one half to three fourths of the teams that used Ada did. Undoubtedly, you are a good software developer and/or maintainer (even designer!); but perhaps there's more to the assertions about language problems with C than you are willing to accept. ---------------------------------------------------------------- Kevin J. Weise weisek@source.asset.com COLSA Corporation Voice - (205) 922-1512 ext. 2115 6726 Odyssey Drive FAX - (205) 971-0002 Huntsville, AL 35806 {Standard Disclaimers about my opinions & my employer's opinions} {... which are in conflict often enough} ---------------------------------------------------------------- "Admire those who seek the truth; avoid those who find it." Marcel Proust ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: "Subtract C, add Ada" 1995-01-04 21:40 ` Fred McCall 1995-01-05 4:30 ` Richard Pattis 1995-01-05 16:07 ` Kevin Weise @ 1995-01-06 13:06 ` Jahn Rentmeister 1995-01-06 16:47 ` Laurent Gasser 1995-01-06 23:36 ` Kenneth Almquist 3 siblings, 1 reply; 85+ messages in thread From: Jahn Rentmeister @ 1995-01-06 13:06 UTC (permalink / raw) Fred McCall (merlin@annwfn.com) wrote: : In <D1Msq8.4Hs@inmet.camb.inmet.com> mg@asp.camb.inmet.com Mitch Gart writes: : >Ada leaves less room for single-keystroke : >errors, such as the common C error of using = (assignment) instead of : >== (comparison); : I've always been curious. Just *where* is this a "common C error"? : I've seen lots of beginners and non-C programmers claim it is, but I : don't recall ever hearing of anyone who knew what they were doing (and : who was using a real tool -- say, lint -- to check their code) making : it. But you surely know about people who - at one time - wrote things like for (i=0; i < MAX_LOOP; i++); field[i]=GetFieldValue(i); The original statement you were criticizing says "single-keystroke errors, such as...". There are more of them than just assignment and empty loops. My golden C rule says "any sufficiently obscure error is due to a missing or superfluos semicolon". : >its type-abstraction facilities reduce the need for : >error-prone pointer manipulation; : Afraid this one doesn't seem to make sense. How does being able to : define a dozen incompatible types of integer "reduce the need for : error-prone pointer manipulation"? Afraid your answer doesn't seem to make sense. Read it again: He is talking about type-abstraction, i.e. abstract Data Types such as bags, stacks, linked lists, Bayer-Trees etc. In C, people do this using void pointers - this means no type checking at all. Even lint can't check anything there. This _is_ error-prone. In Ada, you may encapsulate a pointer (or whatever) into a limited private type, only allowing very few things to be done with the pointer/file/whatever. In C, this is not possible. (We're not talking about C++ right now.) : >and its modular facilities improve : >teams' coordination of effort. : Both languages are modular. I'm not sure how this is a 'win' unless : we're talking about totally inexperienced teams. We are talking about totally inexperienced teams here. And - again - read carefully: "Modular facilities", not "modularity" as such. The statement is that Ada provides some modular facilities that C does not provide, not that C isn't modular. Just two examples: In Ada, you can't use an obsolete package, because the compiler knows from the library it's obsolete. In C, it can become quite tricky to ensure this via make. Of course, you can do it, but you can't force people to use make neither to only produce correct makefiles. Private and limited private types are a "modular facility", too. With them, you know you don't rely upon internals of a module, because you know you can't even access them. : Well, Ada is certainly a better choice than C for a beginning language : to teach design concepts, etc. However, that isn't necessarily saying a : whole lot, since that wasn't what C was intended for. No one claimed that it is saying a lot. The statement was "look, Ada makes a success of a course where C failed. Let us teach Ada in beginning courses." : I'm also not sure : why that would be considered a 'plus', I'm sure it is a 'plus' for the students, for the teachers and for the university. Well-trained personnel is a 'plus' for the companies that hire them. That's why. : unless the idea behind Ada was to : come up with a good language for beginners; that wasn't the idea behind : it. The idea behind Ada was to come up with a perfect language, which did not at all work. (Nevertheless, it's the best try I've seen so far.) -Jahn -- ## PsionCrosspoint 3a Series V 0.99 B ## ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: "Subtract C, add Ada" 1995-01-06 13:06 ` Jahn Rentmeister @ 1995-01-06 16:47 ` Laurent Gasser 1995-01-06 17:29 ` David Weller 1995-01-10 18:28 ` Bob Kitzberger 0 siblings, 2 replies; 85+ messages in thread From: Laurent Gasser @ 1995-01-06 16:47 UTC (permalink / raw) I am a happy user of Think Pascal for Macintosh. This defunct compiler had two great (innovative?) tools: its debugger and an automatic text formatter in the editor. You just type if mytest then begin end else begin end; and at the ; the automatic formatter gives IF mytest THEN BEGIN END ELSE BEGIN END; where capitals may be bold (this is somehow parametable). This avoids many many typos (in which case the formatter scrambles the mistyped word) and makes it easy to move up or down with respect to nesting. All this is done without compiling. Surprisingly, this feature has not caught on in other environments I know... !? Is this part of GNAT? In article <3ejf9b$hbg@majestix.uni-muenster.de>, rentmei@asterix.uni-muenster.de (Jahn Rentmeister) writes: |> But you surely know about people who - at one time - wrote things like |> |> for (i=0; i < MAX_LOOP; i++); |> field[i]=GetFieldValue(i); |> |> The original statement you were criticizing says "single-keystroke errors, |> such as...". There are more of them than just assignment and empty loops. |> My golden C rule says "any sufficiently obscure error is due to a missing or |> superfluos semicolon". -- Laurent Gasser (gasser@dma.epfl.ch) Computers do not solve problems, they execute solutions. I know very few ideas worth dying for, none is worth killing. ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: "Subtract C, add Ada" 1995-01-06 16:47 ` Laurent Gasser @ 1995-01-06 17:29 ` David Weller 1995-01-06 17:30 ` David Weller 1995-01-10 18:28 ` Bob Kitzberger 1 sibling, 1 reply; 85+ messages in thread From: David Weller @ 1995-01-06 17:29 UTC (permalink / raw) In article <3ejs70$dd8@info.epfl.ch>, Laurent Gasser <gasser@masg1.epfl.ch> wrote: >I am a happy user of Think Pascal for Macintosh. This defunct >compiler had two great (innovative?) tools: its debugger and an >automatic text formatter in the editor. You just type > >if mytest then begin end else begin end; >and at the ; the automatic formatter gives > >[example deleted] >where capitals may be bold (this is somehow parametable). This avoids >many many typos (in which case the formatter scrambles the mistyped >word) and makes it easy to move up or down with respect to nesting. >All this is done without compiling. Surprisingly, this feature has >not caught on in other environments I know... !? > >Is this part of GNAT? > Not at all. GNAT is a compiler, not an environment. To get such a behavior, you will need to use the GNU Emacs editor/environment and get the Ada-mode additions from cs.nyu.edu. It will do something very much like you're looking for (much more, to be honest). There are other editors out there that will support this mode, but none that I know of (currently) work with GNAT or Ada95. >In article <3ejf9b$hbg@majestix.uni-muenster.de>, rentmei@asterix.uni-muenster.de (Jahn Rentmeister) writes: >|> But you surely know about people who - at one time - wrote things like >|> >|> for (i=0; i < MAX_LOOP; i++); >|> field[i]=GetFieldValue(i); >|> >|> The original statement you were criticizing says "single-keystroke errors, >|> such as...". There are more of them than just assignment and empty loops. >|> My golden C rule says "any sufficiently obscure error is due to a missing or >|> superfluos semicolon". > >-- >Laurent Gasser (gasser@dma.epfl.ch) >Computers do not solve problems, they execute solutions. > >I know very few ideas worth dying for, none is worth killing. -- Frustrated with C/C++, Pascal, Fortran? Ada95 _might_ be for you! For all sorts of interesting Ada95 tidbits, run the command: "finger dweller@starbase.neosoft.com | more" (or e-mail with "finger" as subj.) ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: "Subtract C, add Ada" 1995-01-06 17:29 ` David Weller @ 1995-01-06 17:30 ` David Weller 0 siblings, 0 replies; 85+ messages in thread From: David Weller @ 1995-01-06 17:30 UTC (permalink / raw) SOrry about not trimming down my reply -- I'm trying to answer all this stuff doring my (almost over) lunch break. -- Frustrated with C/C++, Pascal, Fortran? Ada95 _might_ be for you! For all sorts of interesting Ada95 tidbits, run the command: "finger dweller@starbase.neosoft.com | more" (or e-mail with "finger" as subj.) ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: "Subtract C, add Ada" 1995-01-06 16:47 ` Laurent Gasser 1995-01-06 17:29 ` David Weller @ 1995-01-10 18:28 ` Bob Kitzberger 1 sibling, 0 replies; 85+ messages in thread From: Bob Kitzberger @ 1995-01-10 18:28 UTC (permalink / raw) Laurent Gasser (gasser@masg1.epfl.ch) wrote: [describes Think Pascal's language-aware editor...] : All this is done without compiling. Surprisingly, this feature has : not caught on in other environments I know... !? Rational Apex (and adds semantic browsing, etc...) -- Bob Kitzberger +1 (916) 274-3075 rlk@rational.com Rational Software Corp., 10565 Brunswick Rd. #11, Grass Valley, CA 95945 "Though the boys throw stones at frogs in sport, yet the frogs do not die in sport but in earnest." - Plutarch ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: "Subtract C, add Ada" 1995-01-04 21:40 ` Fred McCall ` (2 preceding siblings ...) 1995-01-06 13:06 ` Jahn Rentmeister @ 1995-01-06 23:36 ` Kenneth Almquist 3 siblings, 0 replies; 85+ messages in thread From: Kenneth Almquist @ 1995-01-06 23:36 UTC (permalink / raw) In article <862035D1F1C@annwfn.com>, Fred McCall <merlin@annwfn.com> wrote: > In <D1Msq8.4Hs@inmet.camb.inmet.com> mg@asp.camb.inmet.com Mitch Gart writes: > >> Ada leaves less room for single-keystroke >> errors, such as the common C error of using = (assignment) instead of >> == (comparison); > > I've always been curious. Just *where* is this a "common C error"? > I've seen lots of beginners and non-C programmers claim it is, but I > don't recall ever hearing of anyone who knew what they were doing (and > who was using a real tool -- say, lint -- to check their code) making > it. I confuse "=" and "==" periodically even though I've used C for years. I generally don't use lint. I just ran this "real tool" on the program: #include <stdio.h> #include <stdlib.h> main(int argc, char **argv) { printf("hello, world\n"); exit(0); } The result is four useless messages: hello.c(4): syntax error at or near type word "int" hello.c(7): warning: main() returns random value to invocation environment exit value declared inconsistently llib-lc(236) :: hello.c(6) printf returns value which is always ignored >> its type-abstraction facilities reduce the need for >> error-prone pointer manipulation; > > Afraid this one doesn't seem to make sense. How does being able to > define a dozen incompatible types of integer "reduce the need for > error-prone pointer manipulation"? I'm not sure what was intended here either. Ada has generic packages and procedures, which makes it easier to write type-safe library routines which manipulate pointers. >> and its modular facilities improve >> teams' coordination of effort. > > Both languages are modular. I'm not sure how this is a 'win' unless > we're talking about totally inexperienced teams. I took a software engineering course in which included a group project. The group I was in defined all of the interfaces in Modula 2. Some of the code was written in C because nobody on the project knew Modula 2 well, but I don't think we would have had a chance of completing the project in the ten weeks allotted if we hadn't used Modula 2 for the interfaces. >> This experience, McCormick notes, "has convinced all my faculty >> colleagues to support teaching Ada in our beginning courses. This >> spring semester, the first student with Ada as their mother tongue >> will enroll in my course. I can only imagine what these teams will >> accomplish". > > Well, Ada is certainly a better choice than C for a beginning language > to teach design concepts, etc. However, that isn't necessarily saying a > whole lot, since that wasn't what C was intended for. I'm also not sure > why that would be considered a 'plus', unless the idea behind Ada was to > come up with a good language for beginners; that wasn't the idea behind > it. C was intended for (or at least the early feedback on its design came from) programmers writing individual programs. In contrast, Ada was explicitly designed to support multi-person projects. It is nice to see that the relative usefulness of these languages for group projects reflects the intentions of the language designers. Kenneth Almquist ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: "Subtract C, add Ada" 1994-12-30 16:06 Mitch Gart 1995-01-03 19:04 ` whiting_ms@corning.com (Matt Whiting) 1995-01-04 21:40 ` Fred McCall @ 1995-01-04 22:45 ` Jay M. Martin 1995-01-05 4:37 ` Michael Feldman 2 siblings, 1 reply; 85+ messages in thread From: Jay M. Martin @ 1995-01-04 22:45 UTC (permalink / raw) Mitch Gart (mg@asp.camb.inmet.com) wrote: About a Professor John McCormick who did some language efficiency studies Ada vs C. Why doesn't he publish his results? Such data points need to be collected in journals even though they may not be overwhelming evidence by themselves. With enough data points "facts" about the efficiency of different methods of software development can be derived. Unfortunately, I have never seen the Computer Science community do this . Jay ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: "Subtract C, add Ada" 1995-01-04 22:45 ` Jay M. Martin @ 1995-01-05 4:37 ` Michael Feldman 1995-01-05 18:08 ` Jay Martin 0 siblings, 1 reply; 85+ messages in thread From: Michael Feldman @ 1995-01-05 4:37 UTC (permalink / raw) In article <D1wKJn.HAu@seas.ucla.edu>, Jay M. Martin <jaym@breeze.seas.ucla.edu> wrote: > >Why doesn't he publish his results? Such data points need to be >collected in journals even though they may not be overwhelming >evidence by themselves. With enough data points "facts" about >the efficiency of different methods of software development can >be derived. Unfortunately, I have never seen the Computer Science >community do this . Jay Actually, he published it twice. One paper was in TRI-Ada '91, which got the Best Paper award in that conference; the other was in Communications of the ACM, in the Ada section of the November 1992 issue. You really ought to check your facts before making these generalizations. Maybe _ask_ first whether John published anything on this. He's also discussed it in numerous panels in both SIGCSE and SIGAda circles. Mike Feldman ------------------------------------------------------------------------ Michael B. Feldman - chair, SIGAda Education Working Group Professor, Dept. of Electrical Engineering and Computer Science The George Washington University - Washington, DC 20052 USA 202-994-5919 (voice) - 202-994-0227 (fax) - mfeldman@seas.gwu.edu (Internet) ------------------------------------------------------------------------ One, two, three ways an underdog: Ada fan, Mac fan, Old Liberal Democrat ------------------------------------------------------------------------ Ada on the World-Wide Web: http://lglwww.epfl.ch/Ada/ ------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: "Subtract C, add Ada" 1995-01-05 4:37 ` Michael Feldman @ 1995-01-05 18:08 ` Jay Martin 1995-01-05 23:56 ` Robert Dewar 1995-01-06 0:07 ` Michael M. Bishop 0 siblings, 2 replies; 85+ messages in thread From: Jay Martin @ 1995-01-05 18:08 UTC (permalink / raw) mfeldman@seas.gwu.edu (Michael Feldman) writes: >In article <D1wKJn.HAu@seas.ucla.edu>, >Jay M. Martin <jaym@breeze.seas.ucla.edu> wrote: >> >>Why doesn't he publish his results? Such data points need to be >>collected in journals even though they may not be overwhelming >>evidence by themselves. With enough data points "facts" about >>the efficiency of different methods of software development can >>be derived. Unfortunately, I have never seen the Computer Science >>community do this . Jay >Actually, he published it twice. One paper was in TRI-Ada '91, which >got the Best Paper award in that conference; the other was in Communications >of the ACM, in the Ada section of the November 1992 issue. >You really ought to check your facts before making these generalizations. >Maybe _ask_ first whether John published anything on this. He's also >discussed it in numerous panels in both SIGCSE and SIGAda circles. >Mike Feldman I read the abstracts to these papers before I posted, there is not one peep about the relative efficiency between C and Ada which should be the central topic of discussion in my opinion. Here are the abs: 1. CONFERENCE PAPER McCormick, J.W. Using a model railroad to teach Ada and software engineering. IN: TRI-Ada '91 Proceedings. (TRI-Ada '91 Proceedings, San Jose, CA, USA, 21-25 Oct. 1991). New York, NY, USA: ACM, 1991. p. 511-14. Pub type: Practical. Abstract: This paper describes a successful course for teaching the development of Ada software systems. A computer controlled model railroad provides realistic small problems that give students experience with Ada's unique aspects and larger problems that require software engineering skills. 3. McCormick, J.W. A model railroad for Ada and software engineering. Communications of the ACM, Nov. 1992, vol.35, (no.11):68-70. Pub type: Practical. Abstract: The Computer Science Department at SUNY Plattsburgh has developed a study option in computer controlled systems. This study option was created especially for undergraduate students interested in the engineering of embedded and real-time software systems. Besides the core courses required in all study options, students in the computer controlled systems study option takes courses in physics (including electronics), additional courses in continuous mathematics and a selection of upper division computer science courses. The capstone course in the computer controlled systems option is real-time systems. As part of the real-time systems course, students work in teams to develop Ada software to control a model railroad. The computer-controlled model railroad is a successful tool for teaching the development of Ada software systems to undergraduate students. Because of their interest in writing software to control trains, students are highly motivated to learn Ada. The railroad is an excellent platform for demonstrating Ada's capabilities. In particular, Ada's tasking, exception handling and hardware-dependent features are utilized frequently by students writing railroad control software. 5. CONFERENCE PAPER McCormick, J.W. A laboratory for teaching the development of real-time software systems. (22nd SIGCSE Technical Symposium on Computer Science Education, San Antonio, TX, USA, 7-8 March 1991). SIGCSE Bulletin, March 1991, vol.23, (no.1):260-4. Pub type: Practical. Abstract: A major problem with teaching real-time software development to undergraduate students is finding suitable equipment for assignments and projects. Such equipment must provide problems that are exciting, challenging, cover a broad range of real-time topics, and yet have solutions that can be completed within the time constraints of the semester. The paper describes a successful laboratory for an undergraduate course in real-time software development based on a computer controlled model railroad. Where is C sucks! Ada rules! I reiterate, I have never seen (recent) a study done by Computer Science Researchers on the relative efficiency of software tools. Jay ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: "Subtract C, add Ada" 1995-01-05 18:08 ` Jay Martin @ 1995-01-05 23:56 ` Robert Dewar 1995-01-08 8:04 ` Jay Martin 1995-01-06 0:07 ` Michael M. Bishop 1 sibling, 1 reply; 85+ messages in thread From: Robert Dewar @ 1995-01-05 23:56 UTC (permalink / raw) "Where is C sucks, Ada rules" I'll tell you where, in inappropriate posts to comp.lang.ada, that's where! John's papres are excellently presented, and I think giving them more of a langauge wars slant would be a big mistake. Yes, if you read the papers you will get an important message if you are not deaf, but the critical issue here is not simple us vs them language comparisons. ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: "Subtract C, add Ada" 1995-01-05 23:56 ` Robert Dewar @ 1995-01-08 8:04 ` Jay Martin 0 siblings, 0 replies; 85+ messages in thread From: Jay Martin @ 1995-01-08 8:04 UTC (permalink / raw) >From: dewar@cs.nyu.edu (Robert Dewar) >>"Where is C sucks, Ada rules" >I'll tell you where, in inappropriate posts to comp.lang.ada, that's where! >John's papres are excellently presented, and I think giving them more of a >langauge wars slant would be a big mistake. Yes, if you read the papers >you will get an important message if you are not deaf, but the critical >issue here is not simple us vs them language comparisons. To start I'll quote from an paper abstract that I included below: The selection of a convenient programming language is one of the most important decisions to be made prior to the implementation of any software project and it may greatly affect its development and maintenance costs. I am just a crackpot, but I think it is reasonable that some people somewhere on this planet should be studying the efficiency of software construction, programming language design and the interaction between the two. Unfortunately, I don't see anybody doing it. Industry doesn't have the time (I can just see efficiency studies from Microsoft saying MSDOS is 100X easier to learn than the Mac) which leaves academia. But from what I have seen Computer Science has declared the field "not worthy of study" and there is no other academic field that can do the work (There doesn't seem that very many Software Engineering departments around). I believe that this is because of some vain effort at scientifization of the field (Physics Envy). Language comparisons involve heated debate and instead of putting up with chaos the Computer Science field has just punted on the whole subject. "Can't we all just get along?", "We will just agree to disagree" and other efforts to sweep these important issues under a rug has made Computer Science pretty worthless/spine-less. Computer Scientists seem to have declared programming,etc as trivial and not worthy of their concern. How can we expect them to be motivated to learn about and then teach the latest in programming, language understanding and design. Its really not their field, why should they give a rats ass. The legions of incompetent college graduage programmers are the result. Who will answer the "The Fundamental Question of Computer Science": "Which tool/language should I use?". Maybe Computer Science should just stop teaching programming since it really doesn't have much do with the field. Maybe Computer Science needs to be destroyed, yeah we can shove architecture into EE/Computer Engineering, Theory/Algorithms/Analysis into Applied Math/Operations Research, AI into Cignus-X1 (a black hole) (no loss), Networking into a new telecommunications field, Databases into Novell(etc). Since no one studies software systems/programming languages, the destruction of CS is complete. More constructively, maybe all Computer Science professors should be required to be certified Software Engineers participating in continuing education seminars and the requirement to have be part of a non-trivial software projects that uses state of the art software techniques every few years (with their programming reviewed). >John's papres are excellently presented, and I think giving them more of a >langauge wars slant would be a big mistake. Yes, if you read the papers >you will get an important message if you are not deaf, but the critical >issue here is not simple us vs them language comparisons. Going back to my point. No one is spending any effort doing reasonable language comparison studies, thus all discussions comparing languages/tools are called "religious", "inappropriate", "language wars". "Language comparisons are religions due to the absence of studies, thus doing studies on language comparison is religious" (circular logic). I understand why Prof McCormick can't be too aggressive in declaring Ada the winner over C in a study or make language comparison the centerstone of a paper. The Computer Science community and others will stone him to death for blaspheme. I am just saddened that one of the few people on the planet that may have language comparison data can't make it widely available in a highly visable way. I leave you with the abstracts to all the recent articles on language comparisons I could find by searching a reference database: Jay -------------------------------------------------------------------- -- Wiener, R. Comparing OOP languages. IN: Object EXPO Europe Conference Proceedings. (Object EXPO Europe Conference Proceedings, London, UK, 12-16 July 1993). New York, NY, USA: SIGS Publications, 1993. p. 7-8. Pub type: Practical. Abstract: Summary form only given. The author critically examines and compares significant features of C++, Smalltalk, and Eiffel. There are three broad areas that are used as the basis for comparison: software development issues, technical issues, and performance issues. Under software development issues, a comparison is made regarding how easy it is to map object-oriented design to each language. Under technical issues, each language is compared with respect to static versus dynamic type checking, early versus late binding, and support for generic classes. Under performance issues, each language is compared in terms of size and speed for some typical code and compilation speed, if appropriate. -- Cullyer, W.J.; Wickmann, B.A. The choice of computer languages for use in safety-critical systems. Software Engineering Journal, March 1991, vol.6, (no.2):51-8. Pub type: Practical. Abstract: The paper reviews the choice of computer language for use in safety-critical systems. The advice given reflects both civil and military requirements. A comparison is made between assembly-level languages, the language C, CORAL 66, Pascal, Modula-2 and Ada. It is concluded that a well defined sub-language is essential for use in safety-critical projects, and a guide is provided for project managers and designers on the characteristics which such a subset should possess. -- Plauger, P.J. Programming language guessing games. Dr. Dobb's Journal, Oct. 1993, vol.18, (no.11):16-22. Pub type: General or Review. Abstract: For all its promise, C++ is, unequivocally, a complex language-and history has not been kind to complex programming languages. Three that spring to mind are PL/I, Algol 68, and Ada. Each is a product of a different decade and a different (potential) user community, but each has followed a similar trajectory. So where does that leave C++? If it's following the inevitable fate of complex languages, then it's arguably still in the 'rising tide' stage. We can trust that its popularity and importance are both still growing. But we can also trust that it will not be the programming language of choice in the year 2000. -- Floyd, M. Comparing object-oriented languages. Dr. Dobb's Journal, Oct. 1993, vol.18, (no.11):104-18. Pub type: Practical. Abstract: In this article, a number of programmers were invited to implement a simple linked-list class in their favorite objected-oriented language. The linked-list was chosen because it's widely used and understood, making it easier to compare how different languages approach a given problem. This, in effect, allows the code to speak for itself. To this end, one can examine and compare approaches in C++, Smalltalk, Eiffel, Sather, Objective-C, Parasol, Beta, Turbo Pascal, C+@, Liana, Ada, and Drool. -- Wild, F.H., III. A comparison of experiences with the maintenance of object-oriented systems: Ada vs. C++. IN: Proceedings TRI-Ada '90. (Proceedings TRI-Ada '90, Baltimore, MD, USA, 3-7 Dec. 1990). New York, NY, USA: ACM, 1990. p. 66-73. Pub type: Practical. Abstract: A discussion is given on the relative ease with which systems are maintained using the mechanisms supported by Ada versus those supported by C++. The author opens with a discussion of significant aspects of object-oriented development, followed by comments about relevant support mechanisms supplied by each language. Qualitative comments are used freely regarding issues of object inter-relationship complexities, object construction and reuse paradigms, readability aspects, and others. -- Overview of US Air Force report 'Ada and C++: a business case analysis'. Ada Information Clearinghouse Newsletter, Sept. 1991, vol.9, (no.3):22-6. Pub type: Practical. Abstract: On July 9, 1991, the US Air Force released to the public a report of a business-case study they had conducted to determine under what circumstances a waiver to DoD's Ada requirement might be warranted in order to allow the use of C++, particularly in DoD's corporate information management (CIM) program. The report is titled, 'Ada and C++: A Business Case Analysis.' An overview is given of the study. -- Campbell, R.A.; Jones, S.; Cottle, R. A comparison of object oriented simulation languages. IN: Cooperation. 1990 ACM Eighteenth Annual Computer Science Conference Proceedings. (Cooperation. 1990 ACM Eighteenth Annual Computer Science Conference Proceedings, Washington, DC, USA, 20-22 Feb. 1990). New York, NY, USA: ACM, 1990. p. 412. Pub type: Practical. Abstract: A network computer system was simulated as a single server queuing system using several computer languages including two object oriented languages. An initial simulation using Smalltalk-V was implemented on a Macintosh II microcomputer. A procedure oriented Pascal program was then implemented on the Mac II machine. A HP Vectra PC was then used to implement the same problem in Pascal, with and without an object oriented option on Turbo Pascal 5.5. The programming was performed by two undergraduate computer science students with considerable programming experience, but who were using object oriented concepts for the first time. Both students found that using an object oriented system in a programming environment supplied by Smalltalk V was a little different than programming in a procedure oriented language such as Pascal. Once they became familiar with the Smalltalk environment, they both felt that they would prefer to develop simulation systems in Smalltalk. -- Yatim, D.; Sygenda, S.A. Performance comparison between C and Modula-2 in the context of gate level, table driven concurrent fault simulation. IN: Proceedings of the 1990 Summer Computer Simulation Conference. (Proceedings of the 1990 Summer Computer Simulation Conference, Calgary, Alta., Canada, 16-18 July 1990). Edited by: Svrcek, B.; McRae, J. San Diego, CA, USA: SCS, 1990. p. 116-22. Pub type: Practical. Abstract: The selection of a convenient programming language is one of the most important decisions to be made prior to the implementation of any software project and it may greatly affect its development and maintenance costs. The authors compare two popular general-purpose programming languages, C and Modula-2, in the context of: gate level, table driven, concurrent fault simulation in a time sharing multi-user environment. Both static and dynamic software metrics are considered. -- English, J. Object-oriented programming and Ada 9X: what can we learn from C++?. IN: ADA: towards maturity. Edited by: Collingbourne, L. Amsterdam, Netherlands: IOS Press, 1993. p. 71-94. Pub type: Practical. Abstract: One of the most important new features proposed for Ada 9X is the inclusion of support for object-oriented programming. C++ is a descendant of C which supports object-oriented programming and which is now established as one of the major object-oriented languages. Like Ada 9X, C++ is a development of an existing procedural language which imposes the need for it to provide backward compatibility. Unlike Ada 9X, C++ has been available now for a number of years and a great deal of experience of its usefulness in practice has been acquired. This paper presents a comparison of the features of Ada 9X and C++ which are intended to support object-oriented programming. It examines the object-oriented features of C++ and considers whether the features proposed for Ada 9X can provide the expressive power of C++ while at the same time avoiding the complexities arising from C++'s incremental evolution. In addition, it describes some of the problems encountered with C++ in practice and explains how the practical lessons learnt from C++ might be applied to the future use of Ada 9X. -- Sakkinen, M. The darker side of C++ revisited. Structured Programming, 1992, vol.13, (no.4):155-77. Pub type: Bibliography; Practical. Abstract: The C++ language is to a high degree a faithful follower of Simula as an object-oriented language geared more toward software engineering than exploratory programming. The author highlights several of its noteworthy good ideas. Like Simula, C++ is designed to be a general-purpose procedural language and not 'purely' object-oriented; this is not counted as a mortal sin. However, taking the weakly typed and weakly structured language C as a base has become an irremediable handicap. Low-level concerns have also caused at least one crucial flaw in the object-oriented properties of C++. These basic defects have not changed since the author first explored the darker side four years ago (M. Sakinnen, 1988). Most, although not all, of the numerous features and facilities that have since been added to the language are obvious improvements. At the same time, they have increased the complexity of C++ so that it is now easily comparable to Ada. (Some new features are suggested, nevertheless.) It would be regrettable indeed if C++ became the de facto standard of object-oriented programming, but this danger looks imminent today. -- Rosen, J.P. What orientation should Ada objects take?. Communications of the ACM, Nov. 1992, vol.35, (no.11):71-6. Pub type: Practical. Abstract: Ada has often been blamed for not being really object oriented, in the sense that it provides only static inheritance (through derived types), but not a full inheritance mechanism. The 9X revision of the Ada standard will introduce inheritance into Ada, but not in the same ways as pure OOLs; Ada opponents will certainly take this opportunity to claim that the magic label object oriented still does not apply to Ada. The author discusses various forms of object orientation and how they apply to Ada, and sees how the new features of Ada 9X will impact the design of Ada programs. He addresses the issue only from the point of view of a language that is directed toward software engineering. He compares Ada mainly to two challengers C++ because it is a language that is currently attracting considerable attention, and Eiffel because it is a language that has specifically been designed to embody the concepts of inheritance in a software engineering approach. -- McCracken, D.D. Programming languages in the computer science curriculum. (Twenty-Third SIGCSE Technical Symposium on Computer Science Education, Kansas City, MO, USA, 5-6 March 1992). SIGCSE Bulletin, March 1992, vol.24, (no.1):1-4. Pub type: General or Review. Abstract: It is important that students understand several programming paradigms: imperative (procedural), functional, logic, concurrent, object-oriented, fetch/execute machine level. The author discusses some programming languages which he feels should be taught in the computer science curriculum. These include Pascal, Modula-2, Ada, C, C++ and Scheme. He considers their current use in schools. -- Tang, L.S. A CPU scheduling simulation from structured programming to object-oriented design. (Twenty-Third SIGCSE Technical Symposium on Computer Science Education, Kansas City, MO, USA, 5-6 March 1992). SIGCSE Bulletin, March 1992, vol.24, (no.1):129-33. Pub type: Practical. Abstract: Object-oriented programming has become increasingly popular. The author presents a CPU scheduling simulation project that he feels can convince students of the benefits of object-oriented design and spur their interest. He describes the project and discusses its solutions in three levels of abstraction: structured programming using Pascal, object-based programming using Ada, and object-oriented programming using C++. He presents his experiences in this assignment and explains why the object-oriented design is the best approach. This is intended to serve as a case study in an object-oriented language course or a programming languages course. -- Harbison, S. Safe programming with Modula-3. Dr. Dobb's Journal, Oct. 1992, vol.17, (no.10):88-96, 126-7. Pub type: Practical; Product Review (1985- ). Abstract: Modula-3 is a full-featured language for software engineering and object-oriented programming. Feature-for-feature, Modula-3 is on a par with Ada and C++, but avoids complexity by simplifying individual features like inheritance and generics. Furthermore, Modula-3 is less of a moving target because it already has features only now being added to those other languages. -- Bohm, W.; Browne, J.C.; Forslund, D.W.; Goforth, A.; and others. Politically incorrect languages for supercomputing-a panel discussion. IN: Proceedings. Supercomputing '92. (Cat. No.92CH3216-9). (Proceedings. Supercomputing '92. (Cat. No.92CH3216-9), Minneapolis, MN, USA, 16-20 Nov. 1992). Los Alamitos, CA, USA: IEEE Comput. Soc. Press, 1992. p. 704-6. Pub type: General or Review; Practical. Abstract: It is pointed out that the set of languages used to program supercomputers has evolved from hand-coded assembler and partially vectorized Fortran to include such diverse possibilities as C++, Sisal, and even Ada. It is noted that proponents of these languages are often fanatical in their support, attempting to share the obvious advantages of a particular language with their skeptical colleagues. This paper brings together a diverse group of supercomputer and parallel programming experts to advocate and debate the merits of several current and emerging programming languages and paradigms being used in the supercomputing arena. The intent of the panel is not to arrive at a determination of 'best', but to expand the awareness of the audience that there is a new generation of programming languages and techniques emerging that is applicable to the supercomputing domain. -- Baker, H.G. Object-oriented programming in Ada83-genericity rehabilitated. Ada Letters, Nov.-Dec. 1991, vol.11, (no.9):116-27. Pub type: Practical. Abstract: A scheme for single-inheritance object-oriented programming in Ada83 is presented in which many methods are determined at compile time using 'generic' subprogram overloading. Unlike previous schemes for object-oriented programming in Ada83, which rely exclusively on derived types for inheritance, the scheme utilizes both derived types and generic units, and hence is more powerful. In particular, inheritance schemes based on derived types cannot handle the C++ concept of 'virtual function', while this scheme determines many of these methods at compile time. The results call into question B. Meyer's (1986) conclusions regarding the weakness of generic units. ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: "Subtract C, add Ada" 1995-01-05 18:08 ` Jay Martin 1995-01-05 23:56 ` Robert Dewar @ 1995-01-06 0:07 ` Michael M. Bishop 1995-01-10 21:30 ` Jay Martin 1 sibling, 1 reply; 85+ messages in thread From: Michael M. Bishop @ 1995-01-06 0:07 UTC (permalink / raw) In article <3ehcik$lc0@oahu.cs.ucla.edu>, Jay Martin <jmartin@oahu.cs.ucla.edu> wrote: >mfeldman@seas.gwu.edu (Michael Feldman) writes: > >>In article <D1wKJn.HAu@seas.ucla.edu>, >>Jay M. Martin <jaym@breeze.seas.ucla.edu> wrote: >>>[snip] > >>Actually, he published it twice. One paper was in TRI-Ada '91, which >>got the Best Paper award in that conference; the other was in Communications >>of the ACM, in the Ada section of the November 1992 issue. > >>You really ought to check your facts before making these generalizations. >>Maybe _ask_ first whether John published anything on this. He's also >>discussed it in numerous panels in both SIGCSE and SIGAda circles. > >>Mike Feldman > >I read the abstracts to these papers before I posted, there is not >one peep about the relative efficiency between C and Ada which >should be the central topic of discussion in my opinion. [snip] Why should the relative efficiency between C and Ada be a central topic of discussion? (I assume you mean run-time efficiency.) With today's advanced hardware and improved code-generation techniques, run-time efficiency is, IMHO, an overrated issue. If this was a pertinent issue, there should be numerous examples of how using Ada caused a development team to fail to meet real-time requirements. I haven't see any. (Perhaps the perception that Ada compilers don't generate efficient code scares developers away from using Ada for real-time applications.) The topic of discussion in this thread is that the use of Ada enabled more of John's students to complete their assignments than the use of C did. That should be the central topic of discussion. If software can't be delivered on time or delivered at all, efficiency is the least of the problems. Having developed Motif applications in both C and Ada, I can honestly say that I've noticed no differences in run-time efficiency between the two languages. (And this is without removing the run-time checks from the Ada system.) Having said this, I must add that I haven't gathered any statistics to support the above claim. But then, I've got better things to do than collecting run-time statistics. -- | Mike Bishop | The opinions expressed here reflect | | bishopm@source.asset.com | those of this station, its management, | | Member: Team Ada | and the entire world. | ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: "Subtract C, add Ada" 1995-01-06 0:07 ` Michael M. Bishop @ 1995-01-10 21:30 ` Jay Martin 0 siblings, 0 replies; 85+ messages in thread From: Jay Martin @ 1995-01-10 21:30 UTC (permalink / raw) bishopm@source.asset.com (Michael M. Bishop) writes: >Why should the relative efficiency between C and Ada be a central topic >of discussion? (I assume you mean run-time efficiency.) I was talking about software development/mantainance efficiency (which was unclear if you didn't get the whole thread). And you are totally right the difference in run-time efficiency between Ada and C negligable. This is a hot button with me, with some "hardcore" C types who write shit code because they are too macho and/or ignorant to let the compiler do the necessary optimizations. Jay ^ permalink raw reply [flat|nested] 85+ messages in thread
end of thread, other threads:[~1995-02-10 13:49 UTC | newest] Thread overview: 85+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <3fdcoi$chn@miranda.gmrc.gecm.com> 1995-01-20 5:01 ` "Subtract C, add Ada" Samuel Mize 1995-01-20 22:07 ` Garlington KE 1995-01-24 5:02 ` R_Tim_Coslet 1995-02-10 13:49 R.A.L Williams [not found] <3gsr0e$oin@miranda.gmrc.gecm.com> 1995-02-07 16:58 ` Mark S. Hathaway 1995-02-08 7:39 ` Travis C. Porco 1995-02-08 16:07 ` Fred J. McCall 1995-02-08 21:30 ` Garlington KE -- strict thread matches above, loose matches on Subject: below -- 1995-01-31 9:34 R.A.L Williams 1995-02-01 16:45 ` Charles H. Sampson 1995-01-23 8:49 R.A.L Williams 1995-01-25 23:18 ` Charles H. Sampson 1995-01-20 10:20 R.A.L Williams 1995-01-20 13:22 ` Renaud HEBERT 1995-01-24 3:35 ` David Moore 1995-01-25 5:38 ` Robert Dewar 1995-01-28 16:35 ` Jules 1995-01-29 8:06 ` Matt Kennel 1995-01-30 5:31 ` Michael Feldman 1995-01-31 22:22 ` David O'Brien 1995-01-24 20:23 ` N. Mellor 1995-01-25 8:50 ` Robb Nebbe 1995-01-25 14:19 ` John Volan 1995-01-26 5:07 ` Samuel Mize 1995-01-26 18:51 ` Mark A Biggar 1995-01-21 15:18 ` Robert Dewar 1995-01-21 21:03 ` David O'Brien 1995-01-23 3:09 ` Jay Martin 1995-01-23 12:50 ` Andrew McConnell 1995-01-24 0:54 ` Matt Kennel 1995-01-25 17:03 ` Norman H. Cohen 1995-01-26 1:13 ` Dr. Richard Botting 1995-01-26 14:32 ` Anders Juul Munch 1995-01-24 0:17 ` Bob Kitzberger 1995-01-23 20:46 ` Robert Firth 1995-01-24 14:25 ` Samuel Mize 1995-01-25 7:27 ` David O'Brien 1995-01-25 12:14 ` Robert A Duff 1995-01-25 5:57 ` David O'Brien [not found] ` <3g9rf0$71k@Starbase.NeoSoft.COM> 1995-01-28 21:08 ` David O'Brien 1995-01-31 18:07 ` Samuel Mize 1995-02-01 10:23 ` Samuel Mize 1995-01-30 0:24 ` Mark S. Hathaway 1995-01-31 3:30 ` Jay Martin 1995-02-01 13:25 ` Jesper Kaagaard 1995-01-20 9:33 R.A.L Williams [not found] <3fgphd$sc3@rational.rational.com> 1995-01-20 5:51 ` RonaldS60 1995-02-07 13:55 ` Robert C. Soong [not found] <3etund$hnr@miranda.gmrc.gecm.com> 1995-01-12 9:56 ` Erik Svensson 1995-01-12 14:44 ` Norman H. Cohen 1995-01-13 1:51 ` David O'Brien 1995-01-13 12:38 ` Laurent Gasser 1995-01-13 20:53 ` John DiCamillo [not found] ` <3f8fnf$c8p@gamma.ois.com> 1995-01-16 11:02 ` Matt Kennel [not found] ` <milodD2IFpG.329@netcom.com> 1995-01-17 21:39 ` R. William Beckwith [not found] ` <3fa11q$sdh@gnat.cs.nyu.edu> 1995-01-16 20:20 ` David Moore 1995-01-14 0:24 ` David O'Brien 1995-01-20 4:43 ` Samuel Mize 1995-01-21 20:28 ` David O'Brien 1995-01-22 21:12 ` Robert Dewar 1995-01-23 18:35 ` Norman H. Cohen 1995-01-23 19:18 ` John Cosby - The Coz 1995-01-24 14:11 ` Samuel Mize 1995-01-14 10:37 ` Keith Thompson [not found] ` <3fcjgt$b0v@cronkite.seas.gwu.edu> 1995-01-16 18:47 ` Robert Dewar [not found] ` <D2It0r.4rp@inmet.camb.inmet.com> 1995-01-17 14:11 ` Norman H. Cohen 1994-12-30 16:06 Mitch Gart 1995-01-03 19:04 ` whiting_ms@corning.com (Matt Whiting) 1995-01-05 4:31 ` Michael Feldman 1995-01-04 21:40 ` Fred McCall 1995-01-05 4:30 ` Richard Pattis 1995-01-05 16:07 ` Kevin Weise 1995-01-06 13:06 ` Jahn Rentmeister 1995-01-06 16:47 ` Laurent Gasser 1995-01-06 17:29 ` David Weller 1995-01-06 17:30 ` David Weller 1995-01-10 18:28 ` Bob Kitzberger 1995-01-06 23:36 ` Kenneth Almquist 1995-01-04 22:45 ` Jay M. Martin 1995-01-05 4:37 ` Michael Feldman 1995-01-05 18:08 ` Jay Martin 1995-01-05 23:56 ` Robert Dewar 1995-01-08 8:04 ` Jay Martin 1995-01-06 0:07 ` Michael M. Bishop 1995-01-10 21:30 ` Jay Martin
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox