Advice on selling Ada to a C shop
in [ADA]
|
From: Georg Bauhaus on 23 Jun 2010 07:17 On 23.06.10 09:40, Gautier write-only wrote: > On 23 juin, 09:17, Maciej Sobczak <see.my.homep...(a)gmail.com> wrote: > >> Do you think that 'end if' at the wrong place and a misleading >> indentation would produce much better results? > > Of course not, but the point is that > - the "end if" was *not* at the wrong place, probably because it would > have (or had) pooped to the eye very quickly > - in the C code, two people read and re-read and did not notice > anything wrong; the bug was detected only by examining results closely > This on only ~15 lines... A frequent argument brought forth by practical programmers is that you know how to diligently use {}. Experienced programmers don't have trouble with brackets (at least not in tie sizing discussions). Bracket problem avoidance techniques are easy to learn, hence everyone can demonstrate their competence proudly and with an air of knowledge. There are more important problems in life than brackets. How often do they create trouble? Why do you employ programmers who cannot properly use brackets? Etc.
From: Brian Drummond on 23 Jun 2010 11:36 On Mon, 21 Jun 2010 01:29:50 -0700 (PDT), Maciej Sobczak <see.my.homepage(a)gmail.com> wrote: >On 20 Cze, 01:01, use...(a)scriptoriumdesigns.com wrote: > >> So, what points would you emphasize to each (manager, programmers) to >> make the Ada sale? > >Contrary to what was already said in this thread, I would advice *not* >to do it via comparisons of little code examples. I think you're probably right. Little code examples have their uses : once the basic message is accepted they can have communicative powers : here's how this bug occurred - here's how Ada would have eliminated it. >I think that the only way to sell Ada in a C shop is to forget about >source code altogether and instead refer to the costs of whole >production cycle. If you do not have any data points internally (and >you don't), refer to others. I find John McCormick's student project >statistics particularly relevant. One possible approach : look at the published information for a large real project, and infer what we can about the implications had it been in Ada. For example : this just popped up in another window... http://www.mozilla.org/security/known-vulnerabilities/firefox36.html#firefox3.6.4 Fixed in Firefox 3.6.4 [mild] MFSA 2010-33 User tracking across sites using Math.random() [moderate] MFSA 2010-32 Content-Disposition: attachment ignored if Content-Type: multipart also present [moderate] MFSA 2010-31 focus() behavior can be used to inject or steal keystrokes [critical] MFSA 2010-30 Integer Overflow in XSLT Node Sorting [critical] MFSA 2010-29 Heap buffer overflow in nsGenericDOMDataNode::SetTextInternal [critical] MFSA 2010-28 Freed object reuse across plugin instances [critical] MFSA 2010-26 Crashes with evidence of memory corruption (rv:1.9.2.4/ 1.9.1.10) Fixed in Firefox 3.6.3 [critical] MFSA 2010-25 Re-use of freed object due to scope confusion Now I think you could make a case that most of those entries labelled "critical" wouldn't be there in an Ada project and any remaining would appear as exceptions pointing at the problem occurrence rather than manifesting as mysterious behaviour somewhere else. True this is a C++ project; it just happens to be a convenient example. I suspect a similar case could be made from a published C project (or even an internal project at the original poster's company ). Apologies for snipping your other good points. - Brian
From: anon on 23 Jun 2010 12:20 In <hvr1j8$f1k$1(a)speranza.aioe.org>, "Nasser M. Abbasi" <nma(a)12000.org> writes: >On 6/22/2010 11:01 AM, anon(a)anon.org wrote: > >> In<774c25c4-3270-4ffb-ad19-366a0ab16659(a)i31g2000yqm.googlegroups.com>, Lucretia<Lucretia9000(a)yahoo.co.uk> writes: >>> Ask them what they don't like about C and developing in C (via a >>> questionnaire if necessary), then show them how to do it in Ada, >>> showing the benefits. >>> >>> This might help get the point across. >>> >>> Luke. >> > >> >> That might be true until Ada 2012! With C like structure being added >> people will say why switch. >> > >any link for someone to find what does "C like structure being added" >mean and how can that provide something that Ada record does't provide? > >--Nasser For Ada, to pull ahead of the language fight, Ada 2012 needs to forget the conditional C-Like structures (see below) and define a true portable Window and Graphic packages in the RM. These two packages should allow any Ada programmer to create a program that controls a set of Windows with Graphics without concerns of the OS or the processor used. Like in the Window packages, a set of common routines to control and maintain a gui window regardless of the system used, But the actually routines would not be just a binder but would enhance the ability of the operation of the window. Like using tasks or event handlers to monitor and control the function of the window. Such as monitoring when the windows is active and needs to monitor all assigned I/O devices as well as make changes to the windows when requested. Or in another case the routines could simply sleep as long as the windows is invisible and only wake-up to update the windows's screen buffer when screen output is requested. As for the graphics package. Those routines and values are mostly commonly define with a few exceptions though out the different OSs and GPU cards that could be handle in an Ada graphics interface and binder package. Of course, the package routines might handle a series of commands which could free the main Ada partition to do other things. These two packages and their sub-packages should of been introduced to Ada's RM a back in 2000 or earlier but the powers that be preferred unions and "oops" and now conditional structures instead. None of which truly aid Ada. These ideas are slowly causes the death of Ada because without graphics and windows routine Ada is limited in it scope of partitions that people want. The powers that maintain and updates Ada are not listening to the right programmers. Some here in this newsgroup would like to see Ada include these two packages group, because it would allow a programmer to create a portable gui Ada project not found even in C. This would be an advantage over C or MS .net system and give Ada the functionality of the graphics that in found in Java but with the performance of a true native language. C like Structures: Unions are one thing, but non Ada conditional structures are another! AT&T create C and the first C compiler then licensed the primary design to IBM, NCR, Univac (unisys), DEC, etc, as well as a number colleges and universities but no control or RM was given for that design. So, each license holder created their own version of the language. A "put" in one system might be define as a "putch" in another. Also constants like "NULL" may be define as a "0x0" in one system and the next system could define the value as either upper or lower limit of a integer while others it a user definable constant. Also, even a logical statement may result in a true value for one system while being false in another. So, to solve some of these and others problems conditional structures were added to C instead of defining and enforcing a C RM. But all full Ada compilers are required to follow the RM and any alteration of the Ada system must be defined and allowed in the RM. Like, the System.Machine_Code package is defined as optional. DEC preferred to use other languages like an assembler or other high level languages instead of providing the System.Machine_Code package. While IBM and SUN version of Ada mostly followed the Ada RM example design. And Adacore programmers using gcc kind of created their own version of this package. If one looks at the Ada RM 13.8 section for the System.Machine_Code package one will see that that all three ways this package is handle are legal. Now, with the release of GNAT 2009, Adacore started including "Conditional Structures". In GNAT 2009, the "If" conditional structure was added. <Variable> := (if ... then ... else ... ); Not sure if you can use add the "elsif .... then" clause. This is too close to C like structures for any Ada purist to approve of. It is better and more portable to have two or more packages instead. An example of this type of structure come from Ada.Text_IO.adb line 568: Item := (if not Is_Start_Of_Encoding (Character'Val (ch), File.WC_Method) then Character'Val (ch) else Get_Upper_Half_Char_Immed (Character'Val (ch), File)); The C version would be: /* * #define CharacterVal (c) c // definition is not needed */ Item = (!Is_Start_Of_Encoding (ch, File.WC_Method) ? ch : Get_Upper_Half_Char_Immed (ch, File) ); Does this improve coding. No! It only allows a small group of C coded routines to be ported directly to Ada code, instead of just using the "Interfaces.C.*" packages and the "pragma Import" or "pragma Export" statements. Why should any programmer spend their time in rewriting the code from one language to another, if the code works. And if the code does not work then simply translating the code into Ada may not correct the problem, but trashing the bad C code and starting from scratch could. So, its better to just compile and use the C code if it works as a small external library routine. Also, if you ask, most programmers do not want to spend their time in transferring a C or any library like the vast Fortran libraries to Ada just to use that routine or library in Ada. They prefer write pure Ada and just link to the libraries or routine written in other languages when needed.
From: (see below) on 23 Jun 2010 14:19 On 23/06/2010 17:20, in article hvtc8u$rpp$1(a)speranza.aioe.org, "anon(a)anon.org" <anon(a)anon.org> wrote: > Unions are one thing, but non Ada conditional structures are another! > > AT&T create C and the first C compiler then ... > Also, even a logical statement may result in a true value for one > system while being false in another. So, to solve some of these > and others problems conditional structures were added to C instead > of defining and enforcing a C RM. This is nonsense C history and nonsense Ada language genealogy. Conditional expressions originated in Ada's direct ancestor, Algol. I'm delighted to see their reappearance in Ada. -- Bill Findlay <surname><forename> chez blueyonder.co.uk
From: Jeffrey R. Carter on 23 Jun 2010 14:38
Georg Bauhaus wrote: > > A frequent argument brought forth by practical programmers > is that you know how to diligently use {}. Experienced > programmers don't have trouble with brackets (at least not > in tie sizing discussions). Bracket problem avoidance > techniques are easy to learn, hence everyone can demonstrate > their competence proudly and with an air of knowledge. > There are more important problems in life than brackets. > How often do they create trouble? Why do you employ programmers > who cannot properly use brackets? Etc. And the answer is the same as to similar arguments about buffer overflows, integer overflows, "=" instead of "==", and so on: In practice, they occur commonly, even though they are well known and no one wants to be the next person to create the next instance. -- Jeff Carter "C's solution to this [variable-sized array parameters] has real problems, and people who are complaining about safety definitely have a point." Dennis Ritchie 25 |