Advice on selling Ada to a C shop
in [ADA]
|
From: BrianG on 23 Jun 2010 20:04 Nasser M. Abbasi wrote: > On 6/20/2010 5:29 PM, Ludovic Brenta wrote: > >> Show them that no, C is not "good enough". >> > > This is what I said earlier. show them, but with small clear code > examples, side-by-side, Ada vs. C, show why in each example, Ada is > better. > As others have said, larger examples are better for showing the advantages of Ada. However, this may make for a less practical demonstration. In this case, another way is to use examples from your (the OP's) actual code. Show areas that have been the source of problems, and how Ada could avoid those problems. More generally, I would (in an ideal world) look at the problems that occur in the entire development process and what changes would avoid them. > Making lectures to C programmer about how much better Ada is in the > abstract, will not work, it will sound like a politician making a > typical speech about how good a job they will do if elected. > > btw, if someone is really good in C, and very careful, and stick to the > standard, they can produce solid code. > > Many large applications are written in C all the time, the problem I > think, is that it takes more skill and effort to produce as reliable > code in C as with Ada, but it can be done, given more effort, skill, > time and money, and lots of coffee. > Coffee? Coffee? I thought "real coders" always relied on Mt.Dew, or Jolt. Or today maybe Red Bull, etc. :-) The other problem is that the time is usually spent at the tail end of development (testing) rather than at the front end. > --Nasser > > --Bg
From: Maciej Sobczak on 24 Jun 2010 03:48 On 23 Cze, 21:57, "Peter C. Chapin" <pcc482...(a)gmail.com> wrote: > My understanding is that Ada is primarily a "systems" programming language. It > supports embedded programming, real time programming, and other "low level" > applications. People writing such programs are not particularly concerned > about GUI packages. Well... I can't speak for everyone, but I'm using Ada in > an embedded application and I'm certainly not worried about the lack of GUI > support. The reason for why GUI is not (and will not be) in the Ada standard library is the same as in C++ - there are too many ways to do it and the cost of prototyping is too high to attract attention of individuals who are usually *volunteers* in standardization efforts. Especially when the already acceptable solution is to live with existing third-party library or libraries. > I wasn't involved in the discussion that lead to the decision to include > conditional expressions in Ada Again similarity to C++ - conditional expressions are *essential* for initializing constants. Without them programmers are forced to either use modifiable variables where constants would be more natural (this is unsafe) or to write local or helper functions, which destroys the locality of reference for code entities (this is less readable -> unsafe). I'm glad that Ada is going to adopt them. -- Maciej Sobczak * http://www.inspirel.com YAMI4 - Messaging Solution for Distributed Systems http://www.inspirel.com/yami4
From: anon on 24 Jun 2010 13:24 In <9b5af9c0-43a3-4a9d-9a03-5b6c794f611e(a)e5g2000yqn.googlegroups.com>, Maciej Sobczak <see.my.homepage(a)gmail.com> writes: >On 23 Cze, 21:57, "Peter C. Chapin" <pcc482...(a)gmail.com> wrote: > >> My understanding is that Ada is primarily a "systems" programming language. It >> supports embedded programming, real time programming, and other "low level" >> applications. People writing such programs are not particularly concerned >> about GUI packages. Well... I can't speak for everyone, but I'm using Ada in >> an embedded application and I'm certainly not worried about the lack of GUI >> support. > >The reason for why GUI is not (and will not be) in the Ada standard >library is the same as in C++ - there are too many ways to do it and >the cost of prototyping is too high to attract attention of >individuals who are usually *volunteers* in standardization efforts. >Especially when the already acceptable solution is to live with >existing third-party library or libraries. > >> I wasn't involved in the discussion that lead to the decision to include >> conditional expressions in Ada > >Again similarity to C++ - conditional expressions are *essential* for >initializing constants. Without them programmers are forced to either >use modifiable variables where constants would be more natural (this >is unsafe) or to write local or helper functions, which destroys the >locality of reference for code entities (this is less readable -> >unsafe). > >I'm glad that Ada is going to adopt them. > >-- >Maciej Sobczak * http://www.inspirel.com > >YAMI4 - Messaging Solution for Distributed Systems >http://www.inspirel.com/yami4 Now, except for "GNAT.Sockets.*" and the outdate "pragma No_Rum_Time" GNAT has side-step the following design concept. "The language must also be "complete" in the sense of the user being able to write all usual programs without having to resort to assembly language or local extensions. It had to have real-time capability and it had to be set up to produce programs for the bare machine in a missile, without support of an operating system. It also was required to support large Command and Control systems, so it had to have a file input/output system, however messy that might be." This paragraph suggest that they should be packages under Ada.* or System.* that would control the hardware such as the Serial (both UART and USB), parallel ports. And all connection types (bus, serial, usb, and parallel, etc) for the keyboard and mouse devices. Plus, it should have routine to control network cards and other standard I/O, such as direct video control and disk while bypassing the OS. But no Ada 83 system every used the RM defined Low_Level_IO package. And in Ada 95 and Ada 2005 there is no packages that are defined in the RM that control any group of hardware directly, bare machine or not. The Ada package mostly just linked to a precompiled library (aka local extensions) that connected to the OS. So, where are these packages? Note: Allowing Ada to be written without using "Local Extension" can mean that Ada needs a "Universal Windows/Graphics" package groups that in one version links to the OS, as well as having another directly control the graphics of a group of common GPU cards. Where is the package or packages, without the programmer using assembly language or the Machine_Code package? Plus, the file system in some case needs to be self-contained without the OS. So where are the System.File_System.* packages like fat, ext2, ext3, etc. ? Or may be a generic package for creating file systems.
From: anon on 24 Jun 2010 13:25 In <wcc63198mdn.fsf(a)shell01.TheWorld.com>, Robert A Duff <bobduff(a)shell01.TheWorld.com> writes: >"Peter C. Chapin" <pcc482719(a)gmail.com> writes: > >> I wasn't involved in the discussion that lead to the decision to include >> conditional expressions in Ada, but my impression is that they were >> introduced in large measure to make the new pre- and post-conditions more >> expressive. > >Yes, that's a big part of the reason. One use for them is to express >logical implication. ARG considered, and rejected, the idea of >adding an "implies" operator. Instead, you can say something like: > > procedure P (...) with > Pre => (if X > 10 then Y > 10); > >The "else True" is implied here. So it means the same >as what "X > 10 implies Y > 10" would mean if "implies" >were in the language. > >This is not (yet) Ada! It is proposed for Ada 2012. > >> In any case conditional expressions are entirely normal in functional >> languages and widely implemented by such languages. They are not some sort of >> C quirk as you seem to suggest. I'm not suggesting that Ada should become a >> functional language (lambdas, anyone?) but to a person fluent with functional >> programming such expressions are very natural. > >Lambdas should indeed be added to Ada, IMHO, and they have been >discussed by ARG. I forget the status, but I don't think they'll >make it in. We had a lot of trouble coming up with a readable >syntax, for one thing. (And nobody proposed any syntax involving >a "lambda" keyword.) > >But to be a true functional language Ada would need more than that. >Full closures, for example. And those pretty much require >garbage collection. > >- Bob From a Read Only web site: "Ada - The Project The DoD High Order Language Working Group" William A. Whitaker, Colonel USAF, Retired PO Box 3036, McLean VA 22103 Typo in the quoted work come from the document. "Without exception, the following languages were found by the evaluators to be inappropriate to serve as base languages for a development of the common language: FORTRAN, COBOL, TACPOL, CMS-2, JOVIAL J-73, JOVIAL J-3B, SIMULA 67, ALGOL 60, and CORAL 66." That statement alone shows that Algol had no influence on the design of common language (later named Ada). Later in the paper it states a reason for Algol's dismissal: "There were other common language meta-requirements. For example, the language must be an applications user language. This went against certain academic concepts of a mathematically minimalistic formulation, like ALGOL 68." Since, the designers were against mathematically minimalistic formulation, this suggest that "Lambda" might need to be classified as forbidden fruit as well. Sorry, Robert Duff. But then again "Lambda" might be able to find itself as a separate set of math packages. Especially, if you created the blueprint for Adacore's GNAT. Because it seams like anything that GNAT adds to its design is adopted by the language. Later the "Base" language of the Ada came from the four languages. But since the DoD had a long-term commitment for Fortran and Cobol, the set became: "FORTRAN was significant because that was the successful language - we are still apologizing for FORTRAN features not in Ada (intrinsic math functions (e.g., SQRT, SIN, etc.), interpretive I/O (i.e., with dynamic formatting)), no matter how proper the exclusion; COBOL pioneered validation - made sure we did not allow the subsets that in 1976 made COBOL systems difficult to validate and compare (may be right for COBOL but not for the purposes of Ada) - data handling, and readability; JOVIAL and CORAL were languages of major military users whose experiences made considerable contribution to the requirements; Pascal contributed mostly its syntactic form." Algol did not make the cut! Now, except for "GNAT.Sockets.*" and the outdate "pragma No_Rum_Time" GNAT has side-step the following design concept. "The language must also be "complete" in the sense of the user being able to write all usual programs without having to resort to assembly language or local extensions. It had to have real-time capability and it had to be set up to produce programs for the bare machine in a missile, without support of an operating system. It also was required to support large Command and Control systems, so it had to have a file input/output system, however messy that might be." This paragraph suggest that they should be packages under Ada.* or System.* that would control the hardware such as the Serial (both UART and USB), parallel ports. And all connection types (bus, serial, usb, and parallel, etc) for the keyboard and mouse devices. Plus, it should have routine to control network cards and other standard I/O, such as direct video control and disk while bypassing the OS. But no Ada 83 system every used the RM defined Low_Level_IO package. And in Ada 95 and Ada 2005 there is no packages that are defined in the RM that control any group of hardware directly, bare machine or not. The Ada package mostly just linked to a precompiled library (aka local extensions) that connected to the OS. So, where are these packages? Note: Allowing Ada to be written without using "Local Extension" can mean that Ada needs a "Universal Windows/Graphics" package groups that in one version links to the OS, as well as having another directly control the graphics of a group of common GPU cards. Where is the package or packages, without the programmer using assembly language or the Machine_Code package. Plus, the file system in some case needs to be self-contained without the OS. So where are the System.File_System.* packages like fat, ext2, ext3, etc. ? Or may be a generic package for creating file systems. We needs there package before adding any type of C-Like conditional operators. Now what did the DoD and the Ada creating teams think of C. "Since the developed systems were to be long-lived, maintenance and modification of the software would cost several times as much as initial development. Readability was much more important than writability, a requirement contrary to those advocating the "economy of expression" that leads to incomprehensible C and APL code. Maintainability also argued for rigid interfaces and powerful compiler checking." Being that the team thought C leads to incomprehensible coding. This also include the C-like "Conditional operators"! Like : C: Variable := <logical expression> ? <true value> : <false value> Ada: Variable := <logical expression> then <true value> else <false value> As for "powerful compiler checking", GNAT sometimes overdoes the checking even when the programmer turns off all checking. That is, just try to use the statement like "Z := X / 0;" the GNAT compiler will never allow that statement, even if one disable all checking, exceptions and exceptions handlers, the compiler will still block this statement by inserting exception coding at that point. A friend spent a month last year talking to Adacore on this one. As for "rigid interfaces" GNAT could use a few adjustments, like making sure an item can not be altered if the address to that item is passed as an "in" only parameter. like access referenced variables. Example: type String_Record; type String_Access is access all String_Record; type String_Pointer is access all String; type String_Record id record Index : Natural; -- 0 = empty string Value : String_Pointer; end record ; A : Character ; Buffer : String_Access ; function Get ( B : in String_Access ) returns Character ; -- The compiler should make sure that this function -- does not directly alter the "Index" or "Value" in -- the record "String_Record" referenced by Buffer, -- if this routine is written in Ada. ... A := Get ( Buffer ) ;
From: Maciej Sobczak on 24 Jun 2010 15:34
On 24 Cze, 19:24, a...(a)att.net wrote: > "The language must also be "complete" in the sense of the user being > able to write all usual programs without having to resort to assembly > language or local extensions. You are confusing "local extensions" with "third party libraries". Local extensions are things like 'Img. Third party libraries are things like QtAda (or YAMI4, for that matter). That is, there is no reason to expect standard authors to define packages for all possible language uses or all possible ways for creating external program interfaces. For example, I don't think that standard Ada.iPad package would make sense at all. > Note: Allowing Ada to be written without using "Local Extension" can > mean that Ada needs a "Universal Windows/Graphics" package > groups Well, no. Your conclusions are completely wrong. -- Maciej Sobczak * http://www.inspirel.com YAMI4 - Messaging Solution for Distributed Systems http://www.inspirel.com/yami4 |