From: Georg Bauhaus on
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
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
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
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
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