Advice on selling Ada to a C shop

Advice on selling Ada to a C shop

[usenet]

I may have the opportunity to pitch Ada for use in some new projects
(industrial equipment) at work.  The place has been using C by
default, not by any conscious choice, and of course they've been
paying a typical price for that default.  The head of engineering (who
is not a software guy) MAY be open to trying Ada if presented with a
compelling case.  The programmers are another question - they may
resist or they may be intrigued by some of Ada's features e.g.
concurrency.  They may also be open to improving the very ad-hoc
software culture now in place, and the idea of having fewer bugs, and
those caught sooner and less painfully.

So, what points would you emphasize to each (manager, programmers) to
make the Ada sale?  I've read a lot of the advocacy and I think I have
a fair handle on it, but I'd still like other viewpoints, and perhaps
even examples of such a successful switch.

In the end, it seems, it all comes down to money.  Money saved in
greater productivity and less debugging, money saved in lower
liability and maintenance, money gained from satisfied customers who
get a robust product, and maybe even money saved in having programmers
who have a more powerful and safer tool at their disposal.

I know that language choice is not the be-all-and-end-all of better
software, but I'm convinced it's a key component, and I'm also
convinced that the sooner we leave C and its baggage behind the better
we can become.

Re: Advice on selling Ada to a C shop

[Jeffrey R. Carter]

usenet@scriptoriumdesigns.com wrote:
> 
> In the end, it seems, it all comes down to money.  Money saved in
> greater productivity and less debugging, money saved in lower
> liability and maintenance, money gained from satisfied customers who
> get a robust product, and maybe even money saved in having programmers
> who have a more powerful and safer tool at their disposal.

Where we have hard data, they show that Ada reaches deployment at half the cost 
of C, with a quarter as many post-deployment errors which cost a tenth as much 
to fix (factor of 40 reduction in post-deployment error fix cost).

The hard data include the Rational assessment for compiler development:

http://adaic.org/whyada/ada-vs-c/cada_art.html

and a study by Pratt and Whitney reported here on jet-engine control SW (I'm not 
aware of any link to this).

There's also McCormick's academic results, in which no students familiar with C 
were able to complete a real-time project in C controlling a model railway, even 
when given 60% of the solution, while 75% of students familiar with C but not 
Ada were able to complete the same project in Ada when given < 20%:

http://www.stsc.hill.af.mil/crosstalk/2000/08/mccormick.html

http://adaic.org/whyada/ada-vs-c.html is a good overall reference.

-- 
Jeff Carter
"Perfidious English mouse-dropping hoarders."
Monty Python & the Holy Grail
10

Re: Advice on selling Ada to a C shop

[Jeffrey R. Carter]

usenet@scriptoriumdesigns.com wrote:
> 
> So, what points would you emphasize to each (manager, programmers) to
> make the Ada sale?  I've read a lot of the advocacy and I think I have
> a fair handle on it, but I'd still like other viewpoints, and perhaps
> even examples of such a successful switch.

I think there is no way to sell Ada to developers. Ada is a SW-engineering 
language; coders don't like it. In my experience, 98% of developers are coders. 
SW engineers generally like Ada once they become aware of it. So if your people 
are SW engineers, Ada will sell itself; if they're coders, there's no way to 
sell it to them.

Proposing a switch to Ada may however, be a mechanism to tell which of your 
people are coders and which are SW engineers. That may be useful in deciding 
whom to retain and whom to let go.

-- 
Jeff Carter
"Perfidious English mouse-dropping hoarders."
Monty Python & the Holy Grail
10

Re: Advice on selling Ada to a C shop

[Warren]

Jeffrey R. Carter expounded in news:hvkcf6$auo$1@tornado.tornevall.net:

> usenet@scriptoriumdesigns.com wrote:
>> 
>> So, what points would you emphasize to each (manager, programmers) to
>> make the Ada sale?  I've read a lot of the advocacy and I think I
>> have a fair handle on it, but I'd still like other viewpoints, and
>> perhaps even examples of such a successful switch.
> 
> I think there is no way to sell Ada to developers. Ada is a
> SW-engineering language; coders don't like it. In my experience, 98%
> of developers are coders. SW engineers generally like Ada once they
> become aware of it. So if your people are SW engineers, Ada will sell
> itself; if they're coders, there's no way to sell it to them.

This is why I suggest that they try it with GNAT 2010 with
the ATMEGA chips.  But even this might be a hard place
to start from (learning the Ada language).  But if they
have Linux and some free time with GNAT first, then an
AVR project should not be a big leap from there.

If you have to sell the developers, you got to get them to
"want" it.  They need to sell themselves somehow. That
is where a pilot project or proof of concept comes in.  

Learning Ada is an uphill climb at first and many may 
only climb it kicking and screaming ;-)  If they are to
be self taught, then I'd also plan on providing some 
good texts for them.

Warren

Re: Advice on selling Ada to a C shop

[J-P. Rosen]

usenet@scriptoriumdesigns.com a �crit :
> So, what points would you emphasize to each (manager, programmers) to
> make the Ada sale?  I've read a lot of the advocacy and I think I have
> a fair handle on it, but I'd still like other viewpoints, and perhaps
> even examples of such a successful switch.
> 
Theory will never impress a manager. Examples will. For example, it has
recently been quoted here the case of Meteor (parisian metro), in use
since 1998, and whose software is still in version 1.0: no problem
discovered in 12 years of usage.

I also remember an example from a SIGAda conference (no reference at
hand, does someone remember?) about a system in a Boeing airplane, which
was doubly written in C and Ada for reasons of diversification. The C
system had several major upgrades, while the Ada one worked flawlessly.
-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Advice on selling Ada to a C shop

[Nasser M. Abbasi]

On 6/20/2010 12:00 AM, J-P. Rosen wrote:

> usenet@scriptoriumdesigns.com a �crit :
>> So, what points would you emphasize to each (manager, programmers) to
>> make the Ada sale?  I've read a lot of the advocacy and I think I have
>> a fair handle on it, but I'd still like other viewpoints, and perhaps
>> even examples of such a successful switch.
>>

> Theory will never impress a manager. Examples will. For example, it has
> recently been quoted here the case of Meteor (parisian metro), in use
> since 1998, and whose software is still in version 1.0: no problem
> discovered in 12 years of usage.
>
> I also remember an example from a SIGAda conference (no reference at
> hand, does someone remember?) about a system in a Boeing airplane, which
> was doubly written in C and Ada for reasons of diversification. The C
> system had several major upgrades, while the Ada one worked flawlessly.

Showing examples are one excellent way to illustrate Ada advantage over C.

But I think what is needed are small coding examples, where each case 
shows clearly an advantage of Ada over C.

Coders like to see code. Seeing small actual code examples, 
side-by-side, showing clearly that the Ada way is better than the C way, 
and why that is, will let the code speak for itself.

But these examples have to be written by someone who is both an expert 
in Ada and C to be fair.

There is another thing to overcome: many of the Ada advantages starts to 
show up when one is doing programming in-the-large, and this is hard to 
sell to someone who mostly thinks at the function level (the so called 
coders here?) instead of at the system level as well.

--Nasser

Re: Advice on selling Ada to a C shop

[Peter C. Chapin]

Nasser M. Abbasi wrote:

> Showing examples are one excellent way to illustrate Ada advantage over C.

Putting Ada up against C seems so unfair... like kicking a man when he's down!
A comparison of Ada and C++ seems more appropriate. I realize that's not what
the original poster is talking about.

For myself personally I became a believer when I realized Ada's various rules
and restrictions were forcing my programs into a better design. In order
to "work around" the Ada compiler's "annoying" messages I often had to
refactor my design... sometimes more than once while I was learning the
basics of the language. The funny thing... once that refactoring was complete
I was left with a program that was far superior to what I was originally
trying to write. As an added bonus it worked too!

It didn't take too many experiences like that to convince me that Ada is good
language. These days I regard the language as a kind of automated expert
looking over my shoulder and helping to keep me from wandering off into the
tall weeds. Unfortunately it's probably hard to demonstrate that sort of
thing. One really needs to build some Ada programs. The key is convincing the
team to keep an open mind during their initial experimentation with the
language. If they jump to the conclusion that Ada is pointlessly fussy
("typical military language" etc), all might be lost.

Peter

Re: Advice on selling Ada to a C shop

[Warren]

Peter C. Chapin expounded in
news:4c1e0d26$0$2393$4d3efbfe@news.sover.net: 

> Nasser M. Abbasi wrote:
> 
>> Showing examples are one excellent way to illustrate Ada advantage
>> over C. 
> 
> Putting Ada up against C seems so unfair... like kicking a man when
> he's down! A comparison of Ada and C++ seems more appropriate. I
> realize that's not what the original poster is talking about.

Talking about C++ is only appropriate if these developers
already know/use C++ for other projects. Otherwise, it 
seems to me rather pointless to bring in another variable.

But I think one practical selling point, to achieve a
"comfort level", is to show them examples of how Ada can
interface with C.  This way, whether they actually
need to call C routines or not, they will have the confort
of knowing that they can, with little difficulty.

Warren

Re: Advice on selling Ada to a C shop

[Marco]

On Jun 21, 7:23 am, Warren <ve3...@gmail.com> wrote:

> But I think one practical selling point, to achieve a
> "comfort level", is to show them examples of how Ada can
> interface with C.  This way, whether they actually
> need to call C routines or not, they will have the comfort
> of knowing that they can, with little difficulty.

Hopefully this won't sound like heresy to Ada folks.

 May I suggest you start your design in Ada. Start with Ada as the
programming-in-the-large model and show how you can easily reuse
existing C functions when necessary or have some components developed
in C for those not willing to learn a new language.

Finding inexpensive Ada combined with C cross-compilers for certain
CPU targets may be an issue.

Re: Advice on selling Ada to a C shop

[Warren]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1381 bytes --]

Marco expounded in news:aedaa685-813d-4f46-8ad3-
3a42affa14df@q12g2000yqj.googlegroups.com:

> On Jun 21, 7:23�am, Warren <ve3...@gmail.com> wrote:
> 
>> But I think one practical selling point, to achieve a
>> "comfort level", is to show them examples of how Ada can
>> interface with C. �This way, whether they actually
>> need to call C routines or not, they will have the comfort
>> of knowing that they can, with little difficulty.
> 
> Hopefully this won't sound like heresy to Ada folks.
> 
>  May I suggest you start your design in Ada. Start with Ada as the
> programming-in-the-large model and show how you can easily reuse
> existing C functions when necessary or have some components developed
> in C for those not willing to learn a new language.
> 
> Finding inexpensive Ada combined with C cross-compilers for certain
> CPU targets may be an issue.

It's not just that, but in a given company, where many
similar projects are done, you may have large bodies
of existing library code. It's a tough sell to say
"rewrite _everything_ in Ada". 

Conversely, it's much easier to sell "reuse what we 
don't want to rewrite at the moment, but let's write 
the new 'stuff' in Ada". Once everyone get's hooked
on that, then other portions can be migrated to Ada
over time.

With this approach, you can avoid the "aw, it's 
just too much work(/cost)" objection.

Warren

Re: Advice on selling Ada to a C shop

[Stephen Leake]

Warren <ve3wwg@gmail.com> writes:

> ... in a given company, where many
> similar projects are done, you may have large bodies
> of existing library code. It's a tough sell to say
> "rewrite _everything_ in Ada". 

Yes, that's a non-starter.

Be sure to mention GNAT's -fdump-ada-spec, which generates Ada package
specs from C code. That makes it _much_ easier to import C correctly.

-- 
-- Stephe

Re: Advice on selling Ada to a C shop

[Per Sandberg]

I could not more then agree on that on Stephen's  comment, I did a major 
binding to a C-library using -fdump-ada-spec where the library interface 
  contained aprox 150  header files.
Never the less I had to write a higher level interface as well to get 
the API:s in a more reasonable shape from an Ada perspective (there was 
other requirements as well that mandated the look and feel of the Ada 
API:s), but that was fairly simple and it was most boring.
But to get that amount of validated functionality in a high level 
language for such a cheap price -:) -:)
Of course the amount of work to do this depends on the design and 
structure of the underlying C API.

/P

On 06/29/2010 10:42 AM, Stephen Leake wrote:
> Warren<ve3wwg@gmail.com>  writes:
>
>> ... in a given company, where many
>> similar projects are done, you may have large bodies
>> of existing library code. It's a tough sell to say
>> "rewrite _everything_ in Ada".
>
> Yes, that's a non-starter.
>
> Be sure to mention GNAT's -fdump-ada-spec, which generates Ada package
> specs from C code. That makes it _much_ easier to import C correctly.
>

Re: Advice on selling Ada to a C shop

[Yannick Duchêne (Hibou57)]

Le Tue, 29 Jun 2010 10:42:18 +0200, Stephen Leake  
<stephen_leake@stephe-leake.org> a écrit:
> Yes, that's a non-starter.
>
> Be sure to mention GNAT's -fdump-ada-spec, which generates Ada package
> specs from C code. That makes it _much_ easier to import C correctly.

Is it a standard GCC option or does it requires a patched GCC ? I have  
built GCC and GNAT for a cross compiler some time ago, and do not remember  
there was such an option in the configuration choices. This may suggest  
“standard option”, but on the other hand, I cannot suppose this is a  
standard GCC option as it is Ada related and GNAT specific.

Thanks to have mentioned this.

Re: Advice on selling Ada to a C shop

[Ludovic Brenta]

"Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr> writes:
> Le Tue, 29 Jun 2010 10:42:18 +0200, Stephen Leake
> <stephen_leake@stephe-leake.org> a écrit:
>> Yes, that's a non-starter.
>>
>> Be sure to mention GNAT's -fdump-ada-spec, which generates Ada package
>> specs from C code. That makes it _much_ easier to import C correctly.
>
> Is it a standard GCC option or does it requires a patched GCC ? I have
> built GCC and GNAT for a cross compiler some time ago, and do not
> remember  there was such an option in the configuration choices. This
> may suggest  “standard option”, but on the other hand, I cannot
> suppose this is a  standard GCC option as it is Ada related and GNAT
> specific.
>
> Thanks to have mentioned this.

It is a non-standard option insofar as it is not defined in the standard
(ARM).

AFAICT, this feature is present in GCC >= 4.5 and in GNAT GPL Edition >=
2010.

-- 
Ludovic Brenta.

Re: Advice on selling Ada to a C shop

[Simon Wright]

Ludovic Brenta <ludovic@ludovic-brenta.org> writes:

> "Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr> writes:
>> Le Tue, 29 Jun 2010 10:42:18 +0200, Stephen Leake
>> <stephen_leake@stephe-leake.org> a écrit:
>>> Yes, that's a non-starter.
>>>
>>> Be sure to mention GNAT's -fdump-ada-spec, which generates Ada package
>>> specs from C code. That makes it _much_ easier to import C correctly.
>>
>> Is it a standard GCC option or does it requires a patched GCC ? I have
>> built GCC and GNAT for a cross compiler some time ago, and do not
>> remember  there was such an option in the configuration choices. This
>> may suggest  “standard option”, but on the other hand, I cannot
>> suppose this is a  standard GCC option as it is Ada related and GNAT
>> specific.
>>
>> Thanks to have mentioned this.
>
> It is a non-standard option insofar as it is not defined in the standard
> (ARM).
>
> AFAICT, this feature is present in GCC >= 4.5 and in GNAT GPL Edition >=
> 2010.

Not in 4.5.0.

Re: Advice on selling Ada to a C shop

[Brian Drummond]

On Sat, 21 Aug 2010 11:22:39 +0200, Ludovic Brenta <ludovic@ludovic-brenta.org>
wrote:

>"Yannick Duch�ne (Hibou57)" <yannick_duchene@yahoo.fr> writes:
>> Le Tue, 29 Jun 2010 10:42:18 +0200, Stephen Leake
>> <stephen_leake@stephe-leake.org> a �crit:
>>> Yes, that's a non-starter.
>>>
>>> Be sure to mention GNAT's -fdump-ada-spec, which generates Ada package
>>> specs from C code. That makes it _much_ easier to import C correctly.
>>
>> Is it a standard GCC option or does it requires a patched GCC ? I have
>> built GCC and GNAT for a cross compiler some time ago, and do not
>> remember  there was such an option in the configuration choices. This
>> may suggest  �standard option�, but on the other hand, I cannot
>> suppose this is a  standard GCC option as it is Ada related and GNAT
>> specific.
>>
>> Thanks to have mentioned this.
>
>It is a non-standard option insofar as it is not defined in the standard
>(ARM).

I suppose, because it's a C/C++ compiler feature, not really an Ada feature.

>AFAICT, this feature is present in GCC >= 4.5 and in GNAT GPL Edition >=
>2010.

Doesn't seem to be present in 4.5.0-20100604 (on OpenSuse 11.3) 
but I'll welcome it in a near future version.

It was in Gnat GPL 2009 where it had some problems but in Gnat 2010 it is
significantly improved.

It still doesn't make a very good job of translating templated classes and their
instantiations; some hand editing of the prototypes is required. 

(a) If the base type was templated, look for missing base types in the derived
type definition... occasional error I can't pin down concisely.

(b) You may have to qualify references to a templated class with the name of the
Ada package created to respect a templated type's instantiation. 

If you forgive the unchecked syntax fragments:

template <class T> class Array2d 
public:
  ...

instantiated with T=Mytype, gives

package Array2d_Mytype
   type Array2d is ...

but any generated references to this class will not be qualified by the package
name.

(c) if the C++ code doesn't call a templated function (including constructors),
the C++ compiler won't instantiate it, so the linker will fail to find it for
the Ada code to use.
I worked around that with some  C++ code that just made dummy calls to the
functions I needed (or created dummy objects), but I expect there's a G++
compiler flag I overlooked to do that for me. Anyone know such a thing?

All that being said, it never claimed to do the job completely. It's a very good
start on automatic package spec definition, and beats the hell out of creating
the specs by hand

- Brian

Re: Advice on selling Ada to a C shop

[Ludovic Brenta]

usenet@scriptoriumdesigns.com writes:
> So, what points would you emphasize to each (manager, programmers) to
> make the Ada sale?  I've read a lot of the advocacy and I think I have
> a fair handle on it, but I'd still like other viewpoints, and perhaps
> even examples of such a successful switch.

People with a prejudice against Ada will try to find any excuse to
justify their rejection.  I think the main excuse they will try is "we
cannot find Ada programmers".  To remove this excuse, it is of paramount
importance that you show that (a) you know Ada and have experience with
it, so you can be the "in-house expert" and (b) there is a wide offering
of books, training courses, compilers, libraries and commercial support
for the language.

For (a), you must have some knowledge and experience beyond the theory;
you must at least have written a couple programs that are more than 300
lines long; then explain how much you enjoyed writing those programs and
watching them run the first time with no bugs :)

For (b), you must do some market research up-front before you can pitch
the language to your company.  This is because, in many developers'
minds, a language is only as good as the IDE (*not* the compiler,
unfortunately); so you should be prepared to demo GPS and ObjectAda to
them.  Also, your should reassure them that there exists at least one
cross-compiler that targets your particular environment.  (hint:
SofCheck offers a Ada-to-C translator which allows you to then use your
existing C cross-toolchain).  Maybe you want to contact the various
vendors informally, they may be able to help you convince your
colleagues.

The fact that you do your homework before talking about Ada will go a
long way towards convincing others: if Ada weren't so good, you wouldn't
spend so much time with it would you?

Good luck.

-- 
Ludovic Brenta.

Re: Advice on selling Ada to a C shop

[Peter C. Chapin]

Ludovic Brenta wrote:

> For (b), you must do some market research up-front before you can pitch
> the language to your company.  This is because, in many developers'
> minds, a language is only as good as the IDE (*not* the compiler,
> unfortunately); so you should be prepared to demo GPS and ObjectAda to
> them.

There is also gnatbench. If you are an Eclipse shop that might be the most
important IDE to demonstrate.

In general AdaCore does a great job at giving the impression that Ada is alive
and developing. They either produce or are involved with a steady stream of
new tools and targets. I'm not saying that other Ada vendors are doing
nothing to develop and promote Ada, but from where I sit (admittedly an
academic viewpoint), AdaCore seems the most visible.

Peter

Re: Advice on selling Ada to a C shop

[Fritz Wuehler]

> People with a prejudice against Ada will try to find any excuse to
> justify their rejection.  I think the main excuse they will try is "we
> cannot find Ada programmers".  To remove this excuse, it is of paramount
> importance that you show that (a) you know Ada and have experience with
> it, so you can be the "in-house expert" and (b) there is a wide offering
> of books, training courses, compilers, libraries and commercial support
> for the language.

If so, then the game is already over. There were days when the best tool
won, if after a little competition. Unfortunately now we are in the days of
software ruled by idiot bean counters and MBAs, and worse, the stock
market.

There is no such thing as vision that goes past the end of this quarter.

You can't sell a product, or a technology, or an employee who will save you
millions or hundreds of millions of dollars in the long run even if that
return on investments starts within a year or two. But you can sell a
cheaper anything this quarter.

The industry and academia killed Ada in commercial programming before it
ever got a chance. And now it's too late for anything that requires
changing a mindset or paying top dollar for a toolchain (look at GHS
prices!) or a high wage for Ada programmers, when Java and C++ jockeys are a
commodity labor item.

Unless you can come up with a programming platform/language/system that
costs you less right now, in people, in hardware, in software, you have the
snowball's chance in Hell of making it happen. Good doesn't matter, cheap
wins every time.

Re: Advice on selling Ada to a C shop

[Ludovic Brenta]

Fritz Wuehler writes:
>> People with a prejudice against Ada will try to find any excuse to
>> justify their rejection.  I think the main excuse they will try is "we
>> cannot find Ada programmers".  To remove this excuse, it is of paramount
>> importance that you show that (a) you know Ada and have experience with
>> it, so you can be the "in-house expert" and (b) there is a wide offering
>> of books, training courses, compilers, libraries and commercial support
>> for the language.
>
> If so, then the game is already over. There were days when the best tool
> won, if after a little competition. Unfortunately now we are in the days of
> software ruled by idiot bean counters and MBAs, and worse, the stock
> market.
>
> There is no such thing as vision that goes past the end of this quarter.
>
> You can't sell a product, or a technology, or an employee who will save you
> millions or hundreds of millions of dollars in the long run even if that
> return on investments starts within a year or two. But you can sell a
> cheaper anything this quarter.
>
> The industry and academia killed Ada in commercial programming before it
> ever got a chance. And now it's too late for anything that requires
> changing a mindset or paying top dollar for a toolchain (look at GHS
> prices!) or a high wage for Ada programmers, when Java and C++ jockeys are a
> commodity labor item.
>
> Unless you can come up with a programming platform/language/system that
> costs you less right now, in people, in hardware, in software, you have the
> snowball's chance in Hell of making it happen. Good doesn't matter, cheap
> wins every time.

I'm not so pessimistic, at least I will not give in without a fight :)

If you already know Ada, then to the evil bean counters, the training
costs zero; you can offer to give introductory training to a couple of
your colleagues yourself, reducing the immediate cost of training.  If
you explain that your use of Ada saves you 20% of the development cost
*this quarter* and 50% the next quarter, you can win.

-- 
Ludovic Brenta.

Re: Advice on selling Ada to a C shop

[Georg Bauhaus]

On 6/20/10 8:06 PM, Ludovic Brenta wrote:

>> Unless you can come up with a programming platform/language/system that
>> costs you less right now, in people, in hardware, in software, you have the
>> snowball's chance in Hell of making it happen. Good doesn't matter, cheap
>> wins every time.
>
> I'm not so pessimistic, at least I will not give in without a fight :)
>
> If you already know Ada, then to the evil bean counters, the training
> costs zero; you can offer to give introductory training to a couple of
> your colleagues yourself, reducing the immediate cost of training.  If
> you explain that your use of Ada saves you 20% of the development cost
> *this quarter* and 50% the next quarter, you can win.

Speaking of cost of training, what exactly is the substance
of the arguments that try to relate cost to language choice?

Java, C#, C, C++, and other favored "standard technologies"
have grown reasonably complex.  Mastering complexity is
not a skill you can pick up next week end, can you?
It needs to be learned, and exercised.

Complex things simply cannot be easy to learn without effort.

The "canonical" repertoire associated with a language
is insufficient for productive work when the problem is
non-trivial, as is usually the case:
   If you know C, you do not necessarily know p-threads
or similar.  Or libraries.  Or your compiler docs.
   If you know Java, you do not yet known enterprise
style Java, nor the concurrency construction library
classes, nor the details of Java generics, nor
annotations.
   If you know C# 2.0, there is news for you in C# 3.0
and C# 4.0 (LINQ syntax, parallelism in certain loops,
task libraries, more syntax ...).
   If you know O-O C++, and possibly templates, you do
not know the STL yet, nor Boost, nor advanced techniques
that rely on compile time resolution mechanism of C++,
I'd think.

All of these skills need to be learned in order to to achieve
proficiency in problem solving.  Learning them is a time consuming
process.  But prior knowledge of core Java, C#, C, C++ cannot
include the extra skills automatically, can it?

What is the respective cost in all these cases?
Does knowing the language actually save a substantial
amount of time or money?


Seen in this light, suppose someone insists on relatively
low cost of a language.  It is low allegedly, because
inexpensive wage labor seems so easily available.
This person must fear being exposed by the accountants!
They might calculate the actual cost of training.


Georg

Re: Advice on selling Ada to a C shop

[Ludovic Brenta]

Georg Bauhaus writes on comp.lang.ada:
> On 6/20/10 8:06 PM, Ludovic Brenta wrote:
>
>>> Unless you can come up with a programming platform/language/system
>>> that costs you less right now, in people, in hardware, in software,
>>> you have the snowball's chance in Hell of making it happen. Good
>>> doesn't matter, cheap wins every time.
>>
>> I'm not so pessimistic, at least I will not give in without a fight
>> :)
>>
>> If you already know Ada, then to the evil bean counters, the training
>> costs zero; you can offer to give introductory training to a couple
>> of your colleagues yourself, reducing the immediate cost of training.
>> If you explain that your use of Ada saves you 20% of the development
>> cost *this quarter* and 50% the next quarter, you can win.
>
> Speaking of cost of training, what exactly is the substance of the
> arguments that try to relate cost to language choice?
>
> Java, C#, C, C++, and other favored "standard technologies" have grown
> reasonably complex.  Mastering complexity is not a skill you can pick
> up next week end, can you?  It needs to be learned, and exercised.
>
> Complex things simply cannot be easy to learn without effort.

Actually, a common excuse for people who refuse to try Ada is to say
that the cost of learning Ada, the compiler, the libraries and the IDE
is expensive.  Of course they will dismiss the cost of learning the C
traps and pitfalls, recursive makefiles, compiler, libraries and IDE as
"negligible" since "everyone" knows them already.

The trap to avoid is to use rational arguments with irrational people.
That does not work; they always find another excuse.  If they were
rational, you would not have to convince them; they would already be
using Ada :)

So, I think the proper approach is to debunk their irrational fears of
Ada and expose the real cost of bugs in the C software, which they have
been ignoring up to now.  Show them that no, C is not "good enough".

-- 
Ludovic Brenta.

Re: Advice on selling Ada to a C shop

[Nasser M. Abbasi]

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.

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.

--Nasser

Re: Advice on selling Ada to a C shop

[Georg Bauhaus]

On 6/21/10 3:14 AM, Nasser M. Abbasi wrote:

> 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.

Do you happen to have a coffee consumption statistics?

Does it include controlled variables such as programmer
age, sex, language, average office temperature, religion,
rank, etc?


Georg

Re: Advice on selling Ada to a C shop

[BrianG]

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

Re: Advice on selling Ada to a C shop

[Warren]

BrianG expounded in news:hvu7ap$r2s$1@news.eternal-september.org:

> Nasser M. Abbasi wrote:
>> On 6/20/2010 5:29 PM, Ludovic Brenta wrote:
>> 
>>> Show them that no, C is not "good enough".
...
>> 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. :-)

Many of those programmers became diebetics ;-)  So coffee
is better (black) that way. 

"Real programmers drink it [coffee] black".

Warren

Re: Advice on selling Ada to a C shop

[Georg Bauhaus]

On 6/21/10 2:29 AM, Ludovic Brenta wrote:

> Actually, a common excuse for people who refuse to try Ada is to say
> that the cost of learning Ada, the compiler, the libraries and the IDE
> is expensive.

When people argue about the cost of learning Ada (in terms
of language, compiler, and libraries) they have accepted
the terms of a kind of rational discourse.  You can continue
quite logically,

"So there will be relative advantages, then, after having
learned Ada?"

Re: Advice on selling Ada to a C shop

[George Orwell]

> So, I think the proper approach is to debunk their irrational fears of
> Ada and expose the real cost of bugs in the C software, which they have
> been ignoring up to now.  Show them that no, C is not "good enough".

I'm going to continue to play the devil's advocate only because I was
recently involved in a debacle along these lines.

Whatever they have is good enough. There are very few companies today, even
software companies, that have not decided bugs, even serious bugs, are just
a fact of life. They accept they're going to anger or even lose some
percent of customers, but this is factored in to their financial
plans. Quality no longer matters, what matters is how much money we can
soak you for this quarter and how long we can get away with it. Good enough
is good enough, and being the best or putting out a product with no known
bugs that can't be circumvented is no longer on radar.

A lot of this has come from the poor quality of PC software (Windows) which
filtered up even to large platforms. Companies that years ago hired the
best people and wanted to put out the best products are now run by myopic
managers who think salesmen are the actual product, not software. They just
sell all they can, and if something goes wrong at a customer site they try
to fix it, but oh well if we caused you a problem that's life. All the big
companies are moving to offshore "talent" (cheap) and all the real talent
is dying by attrition. And if you don't like what we have, it doesn't
really matter, because believe us, we checked, and the whole industry is
moving towards a calculated lowest common denominator of quality- as little
as possible and still stay in business- until we can find our next job. Our
code sucks, but so does theirs...but guess what? We can give you the best
terms on the shit we're peddling. 90 day net to qualified buyers... 

Il mittente di questo messaggio|The sender address of this
non corrisponde ad un utente   |message is not related to a real
reale ma all'indirizzo fittizio|person but to a fake address of an
di un sistema anonimizzatore   |anonymous system
Per maggiori informazioni      |For more info
                  https://www.mixmaster.it

Re: Advice on selling Ada to a C shop

[Ludovic Brenta]

George Orwell wrote:
> There are very few companies today, even
> software companies, that have not decided bugs, even serious bugs, are just
> a fact of life. They accept they're going to anger or even lose some
> percent of customers, but this is factored in to their financial
> plans. Quality no longer matters, what matters is how much money we can
> soak you for this quarter and how long we can get away with it. Good enough
> is good enough, and being the best or putting out a product with no known
> bugs that can't be circumvented is no longer on radar.

It might be possible to turn this argument around.

Companies that choose the path of low quality will go bankrupt when
other low-quality companies from the Far East under-bid them. Those
Far East companies are, in fact, catching up on the quality front.

Companies that choose the path of high quality have a chance to
survive. This is what Germany does, by tradition.

If you buy a car, would you prefer to buy from Germany or from China?
If you buy industrial equipment, would you prefer to buy from Germany
or from China?
If you sell industrial equipment, would you prefer to be Germany or
China?

--
Ludovic Brenta.

Re: Advice on selling Ada to a C shop

[Yannick Duchêne (Hibou57)]

Le Mon, 21 Jun 2010 15:59:54 +0200, Ludovic Brenta  
<ludovic@ludovic-brenta.org> a écrit:
> It might be possible to turn this argument around.
>
> Companies that choose the path of low quality will go bankrupt when
> other low-quality companies from the Far East under-bid them. Those
> Far East companies are, in fact, catching up on the quality front.
>
> Companies that choose the path of high quality have a chance to
> survive. This is what Germany does, by tradition.
>
> If you buy a car, would you prefer to buy from Germany or from China?
> If you buy industrial equipment, would you prefer to buy from Germany
> or from China?
> If you sell industrial equipment, would you prefer to be Germany or
> China?
See what you meant, but just face the fact: who sells the more ? Germany  
or China ?

Re: Advice on selling Ada to a C shop

[Ludovic Brenta]

Yannick Duchêne writes on comp.lang.ada:
> Le Mon, 21 Jun 2010 15:59:54 +0200, Ludovic Brenta
> <ludovic@ludovic-brenta.org> a écrit:
>> It might be possible to turn this argument around.
>>
>> Companies that choose the path of low quality will go bankrupt when
>> other low-quality companies from the Far East under-bid them. Those
>> Far East companies are, in fact, catching up on the quality front.
>>
>> Companies that choose the path of high quality have a chance to
>> survive. This is what Germany does, by tradition.
>>
>> If you buy a car, would you prefer to buy from Germany or from China?
>> If you buy industrial equipment, would you prefer to buy from Germany
>> or from China?
>> If you sell industrial equipment, would you prefer to be Germany or
>> China?
> See what you meant, but just face the fact: who sells the more ?
> Germany or China ?

I think it is more appropriate to ask: who makes a better living, German
employees or Chinese employees?

-- 
Ludovic Brenta.

Re: Advice on selling Ada to a C shop

[Brian Drummond]

On Sat, 21 Aug 2010 06:28:52 +0200, Yannick Duch�ne (Hibou57)
<yannick_duchene@yahoo.fr> wrote:

>Le Mon, 21 Jun 2010 15:59:54 +0200, Ludovic Brenta  
><ludovic@ludovic-brenta.org> a �crit:
>> It might be possible to turn this argument around.
>>
>> Companies that choose the path of low quality will go bankrupt when
>> other low-quality companies from the Far East under-bid them. Those
>> Far East companies are, in fact, catching up on the quality front.
>>
>> Companies that choose the path of high quality have a chance to
>> survive. This is what Germany does, by tradition.
>>
>> If you buy a car, would you prefer to buy from Germany or from China?
>> If you buy industrial equipment, would you prefer to buy from Germany
>> or from China?
>> If you sell industrial equipment, would you prefer to be Germany or
>> China?
>See what you meant, but just face the fact: who sells the more ? Germany  
>or China ?

China, ahem, the Central Empire is, of course, the epitome of quality.

I am naturally justified in using the present tense, since any other perspective
has been in existence for far less than a millennium. 

(Apparently Chou En-Li was asked his opinion of the French Revolution, and
answered "Too soon to tell")

Lately, however, the Western nations have introduced the Central Empire to the
strange notion that cheap shoddy goods will actually sell - and we have bought
all they can make, at the cost of trashing our own economy.

Twice.

Last time, we engineered a narrow escape from financial ruin, in an episode that
does not quite cover us with glory
http://en.wikipedia.org/wiki/Opium_wars
but I don't think we can try that again...

Time will tell what happens this time round...

- Brian (and apologies for drifting off-topic)

Re: Advice on selling Ada to a C shop

[Warren]

George Orwell expounded in
news:2bb211f057648e4d892829e5ee79e34c@mixmaster.it: 

>> So, I think the proper approach is to debunk their irrational fears
>> of Ada and expose the real cost of bugs in the C software, which they
>> have been ignoring up to now.  Show them that no, C is not "good
>> enough". 
> 
> I'm going to continue to play the devil's advocate only because I was
> recently involved in a debacle along these lines.
> 
> Whatever they have is good enough. There are very few companies today,
> even software companies, that have not decided bugs, even serious
> bugs, are just a fact of life. They accept they're going to anger or
> even lose some percent of customers, but this is factored in to their
> financial plans. Quality no longer matters, what matters is how much
> money we can soak you for this quarter and how long we can get away
> with it. 

I think you are generally right, until you get to "Quality
no longer matters". I think it usually _does_ matter, but as
you say, they've come to accept bugs as "normal".  A quality
product is still the goal from semi-honest companies. Certainly
from a competitive pov.

> A lot of this has come from the poor quality of PC software (Windows)
> .... All the big companies are moving to offshore

Sad but seemingly true. Worse than that, the programmer is no
longer "needed". Business is always saying "we can do that
ourselves" after they do a few weeks of night school 
on VB and Access.   Eventually, something big goes wrong,
and it all gets swept under a carpet (perhaps after a
dismissal somewhere).

Warren

Re: Advice on selling Ada to a C shop

[Jeffrey R. Carter]

Warren wrote:
> 
> I think you are generally right, until you get to "Quality
> no longer matters". I think it usually _does_ matter, but as
> you say, they've come to accept bugs as "normal".  A quality
> product is still the goal from semi-honest companies. Certainly
> from a competitive pov.

Not necessarily. US defense "cost-plus" contracts are more profitable the lower 
the quality (as long as the quality remains acceptable to the customer, who has 
been brainwashed to accept fairly low quality).

Then there's commercial SW. Once you have the perfect word processor, you won't 
be able to sell upgrades, so a buggy product is more profitable. In fact, 
current word processors may be approaching this (for the most common uses), 
leading major word-processor vendors to transition to a SW-as-a-service model to 
maintain a revenue stream.

-- 
Jeff Carter
"We use a large, vibrating egg."
Annie Hall
44

Re: Advice on selling Ada to a C shop

[Warren]

Jeffrey R. Carter expounded in news:hvo844$h10$1@tornado.tornevall.net:

> Warren wrote:
>> 
>> I think you are generally right, until you get to "Quality
>> no longer matters". I think it usually _does_ matter, but as
>> you say, they've come to accept bugs as "normal".  A quality
>> product is still the goal from semi-honest companies. Certainly
>> from a competitive pov.
> 
> Not necessarily. US defense "cost-plus" contracts are more profitable
> the lower the quality (as long as the quality remains acceptable to
> the customer, who has been brainwashed to accept fairly low quality).

I agree with the "not necessarily" part. But when a company
(any company) has enough work already, then getting it right
the first time has advantages. OTOH, if you want to milk a 
contract, then I can see the attraction that bugs 
may provide.

Warren

Re: Advice on selling Ada to a C shop

[starwars]

> I think you are generally right, until you get to "Quality
> no longer matters". I think it usually _does_ matter, but as
> you say, they've come to accept bugs as "normal".  A quality
> product is still the goal from semi-honest companies. Certainly
> from a competitive pov.

That is simply not the case in several markets I am aware of, to the extent
that the management called all the staff together and announced something
like "We are no longer interested in being the best or putting out the best
code. We studied the market and being the best is too expensive and not a
priority for our customers. We are going to realign to do an adequate job
and save everybody money since that is what the market is telling us."

This is from a very prominent software company, and they are not alone.

Re: Advice on selling Ada to a C shop

[Warren]

starwars expounded in
news:8bd88ec5e6b94d7a9924f620f3c35dab@tatooine.homelinux.net: 

>> I think you are generally right, until you get to "Quality
>> no longer matters". I think it usually _does_ matter, but as
>> you say, they've come to accept bugs as "normal".  A quality
>> product is still the goal from semi-honest companies. Certainly
>> from a competitive pov.
> 
> That is simply not the case in several markets I am aware of, to the
> extent that the management called all the staff together and announced
> something like "We are no longer interested in being the best or
> putting out the best code. We studied the market and being ...

But it is the "being the best is too expensive" part that
is being challenged by Ada. If you solved that problem, then 
it either moves to the next _excuse_ or they actually do 
become the best.

Warren

Re: Advice on selling Ada to a C shop

[Warren]

Ludovic Brenta expounded in news:87631dmdmz.fsf@ludovic-brenta.org:
> Georg Bauhaus writes on comp.lang.ada:
>> On 6/20/10 8:06 PM, Ludovic Brenta wrote:
>>
>>>> Unless you can come up with a programming platform/language/system
>>>> that costs you less right now, in people, in hardware, in software,
>>>> you have the snowball's chance in Hell of making it happen. Good
>>>> doesn't matter, cheap wins every time.
...
> The trap to avoid is to use rational arguments with irrational people.
> That does not work; they always find another excuse.  If they were
> rational, you would not have to convince them; they would already be
> using Ada :)
> 
> So, I think the proper approach is to debunk their irrational fears of
> Ada and expose the real cost of bugs in the C software, which they have
> been ignoring up to now.  Show them that no, C is not "good enough".

So maybe the proof of concept project should be an
AVR controller for some sort of life support machine
(a simulation with a real micro-controller).

The challenge winners (C or Ada teams), will be the
ones who survive a few days on that machine. ;-)

Warren

Re: Advice on selling Ada to a C shop

[Warren]

Ludovic Brenta expounded in news:87aaqpmve5.fsf@ludovic-brenta.org:
> Fritz Wuehler writes:
..
>> Unless you can come up with a programming platform/language/system
>> that costs you less right now, in people, in hardware, in software,
>> you have the snowball's chance in Hell of making it happen. Good
>> doesn't matter, cheap wins every time.
> 
> I'm not so pessimistic, at least I will not give in without a fight :)
> 
> If you already know Ada, then to the evil bean counters, the training
> costs zero; you can offer to give introductory training to a couple of
> your colleagues yourself, reducing the immediate cost of training.  If
> you explain that your use of Ada saves you 20% of the development cost
> *this quarter* and 50% the next quarter, you can win.

If you have good developers, they should be curious enough
to find out more about "this Ada" first hand.  The non-curious
will just do their jobs, and collect pay cheques. They won't
want any change.

With GNAT (and now GNAT with AVR support), good developers should
be curious enough to try it.  The key is to make it a "fun" learning
experience. Make sure they have the tool(s) and book(s) to learn
from. You want to avoid them hitting roadblocks (or compiler
errors) that they don't know how to resolve. So a big part of
winning them over will be resources, resources and resources.

Warren

Re: Advice on selling Ada to a C shop

[Fritz Wuehler]

> If you have good developers, they should be curious enough
> to find out more about "this Ada" first hand.  The non-curious
> will just do their jobs, and collect pay cheques. They won't
> want any change.

The problem is it doesn't help what the developers want. The industry has
long transitioned to a market-based or business-centric view of IT,
developers are just another nasty cost. There were days when we ruled the
earth, but those days are gone.

Re: Advice on selling Ada to a C shop

[Yannick Duchêne (Hibou57)]

Le Sun, 20 Jun 2010 19:44:34 +0200, Fritz Wuehler  
<fritz@spamexpire-201006.rodent.frell.theremailer.net> a écrit:
> changing a mindset or paying top dollar for a toolchain (look at GHS
> prices!)
What is this GHS please ?

> Unless you can come up with a programming platform/language/system that
> costs you less right now, in people, in hardware, in software, you have  
> the
> snowball's chance in Hell of making it happen. Good doesn't matter, cheap
> wins every time.
Or even not fees at all

Well, anyway every things is very-short terms nowadays... we are far now  
 from the Chinese Wall, a project of all of a society, spanning over a  
whole millennium. The nowadays “philosophy” is  
right-now-cost-nothing-immediately-consumable. The next year did not even  
exist and supposed to never happens.

Re: Advice on selling Ada to a C shop

[Pascal Obry]

Yannick,

> What is this GHS please ?

Green Hills Software (http://www.ghs.com/).

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|    http://www.obry.net  -  http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: Advice on selling Ada to a C shop

[Ludovic Brenta]

"Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr> writes:

> Le Sun, 20 Jun 2010 19:44:34 +0200, Fritz Wuehler
> <fritz@spamexpire-201006.rodent.frell.theremailer.net> a écrit:
>> changing a mindset or paying top dollar for a toolchain (look at GHS
>> prices!)
> What is this GHS please ?

http://en.wikibooks.org/wiki/Ada_Programming/Installing#AdaMULTI_from_Green_Hills_Software

-- 
Ludovic Brenta.

Re: Advice on selling Ada to a C shop

[Maciej Sobczak]

On 20 Cze, 01:01, use...@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. It is relatively
easy to write correct C program of small size and therefore there will
be no visible problem that Ada might possibly solve. Also, since the C
syntax is "lighter" visually, it will be taken as a proof that C is
actually more readable.
Don't laugh here, we're talking about simple programs and people who
are already used to C. Hello World in C *is* more readable to them
than Hello World in Ada, no matter what you're going to say about
maintainability of packages. It is just impossible to sell large scale
features with small scale examples.

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.

Last but not least - there is a difference between C and C++ and there
is a difference between respective communities as well, even if it's
usually forgotten on this group. If your fellows are "real C
programmes", you're doomed and forget about selling Ada to them - they
will just don't see the point, ever. Just forget. But if they are C++
programmers and they already understand the importance of large-scale
constructs like namespaces, object-orientation, encapsulation,
abstraction, design patterns, controlled memory usage, and so on, then
this is where you can start your pitch, because they will already
understand what you're talking about and most importantly, they
already feel the need for such things.

And don't forget to highlight (repeatedly!) that Ada can link to C and
C++ libraries, because this argument shows that the transition can be
smoother and that some existing investments can be preserved. This is
actually the reason for why the transition from C or C++ to Ada makes
much more business sense than the transition from C++ to Java, even
though sheeple will usually go for the latter.

Oh, yes - don't despair if you fail. I think it usually takes more
than one iteration...

--
Maciej Sobczak * http://www.inspirel.com

YAMI4 - Messaging Solution for Distributed Systems
http://www.inspirel.com/yami4

Re: Advice on selling Ada to a C shop

[Ludovic Brenta]

Maciej Sobczak wrote on comp.lang.ada:
> Last but not least - there is a difference between C and C++ and there
> is a difference between respective communities as well, even if it's
> usually forgotten on this group. If your fellows are "real C
> programmes", you're doomed and forget about selling Ada to them - they
> will just don't see the point, ever. Just forget. But if they are C++
> programmers and they already understand the importance of large-scale
> constructs like namespaces, object-orientation, encapsulation,
> abstraction, design patterns, controlled memory usage, and so on, then
> this is where you can start your pitch, because they will already
> understand what you're talking about and most importantly, they
> already feel the need for such things.

IMHO, there exists a subset of the "real C programmers" that can be
sensitive to the quality afforded by Ada. This is the subset that
understands that C is harmful and relies on "coding standards",
"language subsets", "lint" and "code review" to reduce the amount of
bugs they write. With C, all these tools and techniques are optional,
non-standard add-ons to their toolchain. With Ada, they get it for
free with the compiler. I like to think that the compiler does a code
review every time I compile. In addition, Ada is amenable to even more
thorough automatic code checking (see AdaControl, GNAT Checker,
CodePeer).

--
Ludovic Brenta.
"Examples of languages generally recognised to be more suitable than C
are Ada and Modula 2. If such languages could be available for a
proposed system then their use should be seriously considered in
preference to C." MISRA, "Guidelines For The Use Of The C Language In
Vehicle Based Software", 1998, Section 1.3.

Re: Advice on selling Ada to a C shop

[Brian Drummond]

On Mon, 21 Jun 2010 01:29:50 -0700 (PDT), Maciej Sobczak
<see.my.homepage@gmail.com> wrote:

>On 20 Cze, 01:01, use...@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

Re: Advice on selling Ada to a C shop

[Warren]

 expounded in news:101bf8f3-b823-45ee-9afd-40cbafb4b7a9
@t26g2000prt.googlegroups.com:

> I may have the opportunity to pitch Ada for use in some new projects
> (industrial equipment) at work.  

Your situation may be better (industrial equipment) than the 
one in which I made an attempt. But I think you will face two
major challenges:

1. Price tag on Ada development suite (depending upon 
   "equipment" choices)  - a management sell.  In my
   case, the idea was considered too "weird" to be 
   taken seriously (in a financial institution).
2. Selling it to the development staff (which you mentioned)

To pitch it to management, I think one possibility is to 
demonstrate it in something inexpensive. I understand
that GNAT 2010 will support the AVR suite. So that has
almost zero cost if you do a "proof of concept" project.

As part of that, perhaps you can organize a pair of
"challenge" teams. Have the project well defined and
involving concurrency. Measure the progress and success
of each team.

Selling to the development staff may be a tough sell,
outside of the US.  If there is a virtually zero job
market for Ada, then I've seen developers snub it
for that reason alone.  If you have that problem, then
a favourable management decision might be where your
focus should be. ;-)

> In the end, it seems, it all comes down to money.  Money saved in
> greater productivity and less debugging, money saved in lower
> liability and maintenance, money gained from satisfied customers who
> get a robust product, and maybe even money saved in having programmers
> who have a more powerful and safer tool at their disposal.

Maybe. I sense that some defence contractors enjoy the
followup servicing of bugs, if they can charge for it. ;-)

Warren

Re: Advice on selling Ada to a C shop

[Lucretia]

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.

Re: Advice on selling Ada to a C shop

[anon]

In <774c25c4-3270-4ffb-ad19-366a0ab16659@i31g2000yqm.googlegroups.com>, Lucretia <Lucretia9000@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.  

The C conditional stops the concept of Ada being portable. Because Ada 
strictly follows the Ada RM, the Ada libraries calls to the system 
libraries are the only part that should be different. Which allow all 
user program to be written and transferred to any Ada compiler without 
change. Which enforces the main concept of Ada being truly portable.

A second problem is until Ada 2012, C is the only common used language 
that allows functions to have "in out" type of parameters. If functions 
having the "in out" parameters, was a good idea, you would think then 
other older languages like Fortran, Pascal would have them.  Or even 
the the most modified language called java would have this concept but 
it does not. So, why include that into Ada's function, is a mystery 
unless one is trying to alter Ada into C. Or they the powers that be 
are trying to destroy Ada because they do not want people to leave C 
for Ada.

Now for the main topic selling Ada over C.  Its a hard sell because most 
shops require that all employees of any project to be replaceable. It is 
hard to find a replacement programmer that knows Ada, but you can find 
100s of C programmers due to the fact that schools are turning out 1000s 
of programmers that know C inside and out. Because most schools required 
C and Java, but Ada if they teach it is mostly taught as an elective.

Re: Advice on selling Ada to a C shop

[Nasser M. Abbasi]

On 6/22/2010 11:01 AM, anon@anon.org wrote:

> In<774c25c4-3270-4ffb-ad19-366a0ab16659@i31g2000yqm.googlegroups.com>, Lucretia<Lucretia9000@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

Re: Advice on selling Ada to a C shop

[anon]

In <hvr1j8$f1k$1@speranza.aioe.org>, "Nasser M. Abbasi" <nma@12000.org> writes:
>On 6/22/2010 11:01 AM, anon@anon.org wrote:
>
>> In<774c25c4-3270-4ffb-ad19-366a0ab16659@i31g2000yqm.googlegroups.com>, Lucretia<Lucretia9000@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.

Re: Advice on selling Ada to a C shop

[(see below)]

On 23/06/2010 17:20, in article hvtc8u$rpp$1@speranza.aioe.org,
"anon@anon.org" <anon@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

Re: Advice on selling Ada to a C shop

[Brian Drummond]

On Wed, 23 Jun 2010 19:19:42 +0100, "(see below)" <yaldnif.w@blueyonder.co.uk>
wrote:

>On 23/06/2010 17:20, in article hvtc8u$rpp$1@speranza.aioe.org,
>"anon@anon.org" <anon@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.

Having cut my teeth on Algol-W, so am I.

If-expressions and case-expressions in Algol-W seemed natural to me, and gave
very readable code.

(Though I never felt comfortable with the C syntax. Given the usual C values for
true and false, it feels too much like an arithmetic-if, but with the list of
choices, confusingly, in descending order!)

And Ada is not alone in modern languages; they are also coming back in
sequential code in VHDL-2008 (with different syntax, alas). 
VHDL has always had them among its concurrent statements.

- Brian

Re: Advice on selling Ada to a C shop

[Peter C. Chapin]

anon@anon.org wrote:

> 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.

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.

Of course some people do want GUI support and, in fact, there are Ada
libraries that do that now. If you feel they are inadequate, you could
perhaps create something better. The question isn't about the value of GUI
packages (I'm sure we all agree such packages have value) but rather the
value of putting such support into the language standard.

> 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.

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. When writing a post-condition on a subprogram you only get a
single expression... not a statement (please correct me if I'm wrong). Thus
if you want to write something complicated conditional expressions and case
expressions become useful. Once you've added such expressions to the language
there is little point is prohibiting them from "normal" code sequences.

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.

Peter

Re: Advice on selling Ada to a C shop

[Adam Beneschan]

On Jun 23, 12:57 pm, "Peter C. Chapin" <pcc482...@gmail.com> wrote:

> > 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.
>
> 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.

I don't think conditional expressions are officially part of Ada yet.
The changes haven't been approved.  So if some compiler accepts them,
it's a compiler for some other language that isn't Ada.

                         -- Adam

Re: Advice on selling Ada to a C shop

[Robert A Duff]

Adam Beneschan <adam@irvine.com> writes:

> I don't think conditional expressions are officially part of Ada yet.
> The changes haven't been approved.  So if some compiler accepts them,
> it's a compiler for some other language that isn't Ada.

That's right.  They are proposed for Ada 2012.  GNAT accepts them
under the -gnat2012 switch.  AdaCore will probably be adding more
Ada 2012 features in the future.

If you choose to use Ada 2012 features before the Ada 2012 is
standardized, then you are not using Ada, and you run the
risk that things might change.

- Bob

Re: Advice on selling Ada to a C shop

[Randy Brukardt]

"Adam Beneschan" <adam@irvine.com> wrote in message 
news:f8cf7493-96cf-4265-8e60-28a3945e1169@j8g2000yqd.googlegroups.com...
...
>I don't think conditional expressions are officially part of Ada yet.
>The changes haven't been approved.  So if some compiler accepts them,
>it's a compiler for some other language that isn't Ada.

The ARG approved AI-147 on Sunday, June 20th by a 9-0-0 vote.

Note that we had decided long ago to add conditional expressions; we have 
been hung up on the detailed wording of the resolution rules for them, and 
whether various obscure cases needed to work properly. For instance:

In a function returning T'Class:
    return (if C then A else B); -- A and B have different types, both 
covered by T'Class.

A conversion:
    T'Class (if C then A else B); -- A and B as above.

The goal was to make them as natural as possible, so ultimately, both of the 
above were determined to be acceptable.

                                        Randy.

Re: Advice on selling Ada to a C shop

[Adam Beneschan]

On Jun 29, 1:30 pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
> "Adam Beneschan" <a...@irvine.com> wrote in message
>
> news:f8cf7493-96cf-4265-8e60-28a3945e1169@j8g2000yqd.googlegroups.com...
> ...
>
> >I don't think conditional expressions are officially part of Ada yet.
> >The changes haven't been approved.  So if some compiler accepts them,
> >it's a compiler for some other language that isn't Ada.
>
> The ARG approved AI-147 on Sunday, June 20th by a 9-0-0 vote.

Good to know.  Thanks for the information.

                         -- Adam

Re: Advice on selling Ada to a C shop

[Stephen Leake]

Dennis Lee Bieber <wlfraed@ix.netcom.com> writes:

> On Tue, 29 Jun 2010 15:30:12 -0500, "Randy Brukardt"
> <randy@rrsoftware.com> declaimed the following in comp.lang.ada:
>
>
>> In a function returning T'Class:
>>     return (if C then A else B); -- A and B have different types, both 
>> covered by T'Class.
>>
> 	Ah, at least the syntax reads naturally... I'd have preferred that
> Python not have added conditional expressions, but I sure don't like
> what they did add:
>
>>>> A = "It's me"
>>>> B = "Not me"
>>>> C = True
>>>> A if C else B
> "It's me"
>>>> C = False
>>>> A if C else B
> 'Not me'
>>>> 
>
> 	I'd have preferred the condition first...

That's because you have not been exposed to the Forth language. One of
my favorite bumber stickers reads:

4th <heart> if honk

-- 
-- Stephe

Re: Advice on selling Ada to a C shop

[Robert A Duff]

"Peter C. Chapin" <pcc482719@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

Re: Advice on selling Ada to a C shop

[anon]

In <wcc63198mdn.fsf@shell01.TheWorld.com>, Robert A Duff <bobduff@shell01.TheWorld.com> writes:
>"Peter C. Chapin" <pcc482719@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 ) ;

Re: Advice on selling Ada to a C shop

[Adam Beneschan]

On Jun 24, 10:25 am, a...@att.net wrote:

> 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).

I don't know what the heck brought all this on.  However: (1) it is
indisputable that Pascal was a major influence on Ada; (2) the
Wikipedia entry for Pascal says, right up front, "Pascal is based on
the ALGOL programming language"; (3) the post in this thread that
you're apparently responding to referred to Algol as a "direct
ancestor" of Ada---not as a "parent" of Ada.  So you've taken a whole
lot of space attempting to debunk something that nobody said.  That's
all I'm going to say on the subject.

                            -- Adam

Re: Advice on selling Ada to a C shop

[Maciej Sobczak]

On 23 Cze, 21:57, "Peter C. Chapin" <pcc482...@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

Re: Advice on selling Ada to a C shop

[anon]

In <9b5af9c0-43a3-4a9d-9a03-5b6c794f611e@e5g2000yqn.googlegroups.com>, Maciej Sobczak <see.my.homepage@gmail.com> writes:
>On 23 Cze, 21:57, "Peter C. Chapin" <pcc482...@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.

Re: Advice on selling Ada to a C shop

[Maciej Sobczak]

On 24 Cze, 19:24, 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

Re: Advice on selling Ada to a C shop

[David Thompson]

On Tue, 22 Jun 2010 22:39:51 -0700, Dennis Lee Bieber
<wlfraed@ix.netcom.com> wrote:

> On Tue, 22 Jun 2010 18:01:50 +0000 (UTC), anon@anon.org declaimed the
> following in comp.lang.ada:
> 
> > A second problem is until Ada 2012, C is the only common used language 
> > that allows functions to have "in out" type of parameters. If functions 
> > having the "in out" parameters, was a good idea, you would think then 
> > other older languages like Fortran, Pascal would have them.  Or even 
> 
> 	Uhm... The last time I worked FORTRAN (about a decade ago),
> functions COULD have side-effects. After all, the normal passing method
> in FORTRAN is by-reference, and I never encountered a compiler that
> would enforce read-only access to arguments inside a function. Now,
> maybe post '90/'95 standard have implemented such -- but I'd bet most
> shops are still running a compatibility option for older code...

Indeed. Classic Fortran did, and F90+ still does by default (i.e.
INTENT unspecified) or if you specify INTENT OUTor INOUT.
Only if you explicitly make a subprogram PURE or ELEMENTAL then a
function, but not a subroutine, is prohibited from having modifiable
arguments. (Both a function and subroutine are prohibited from other
'global' side-effects, i.e. on module~package data or external files.)

So did Pascal if you specify VAR, a68 with ref, and COBOL and PL/I
always. anon may argue that some of those are not now 'common[ly]
used', but Java certainly is and makes all nonprimitive arguments
writable references; there's not even a syntax to make a reference
readonly -- although you can write a target object, or a wrapper or
adapter etc., to be readonly (always or controllably) and some
important standard objects like java.lang.String are immutable.

And C++ of course, but that's arguably covered under C. It does have
added syntax for references (and OO 'this') but same semantics.

Re: Advice on selling Ada to a C shop

[anon]

In <avd536h33st9rfce1ld2b4nidcsmeaggv8@4ax.com>, David Thompson <dave.thompson2@verizon.net> writes:
>On Tue, 22 Jun 2010 22:39:51 -0700, Dennis Lee Bieber
><wlfraed@ix.netcom.com> wrote:
>
>> On Tue, 22 Jun 2010 18:01:50 +0000 (UTC), anon@anon.org declaimed the
>> following in comp.lang.ada:
>> 
>> > A second problem is until Ada 2012, C is the only common used language 
>> > that allows functions to have "in out" type of parameters. If functions 
>> > having the "in out" parameters, was a good idea, you would think then 
>> > other older languages like Fortran, Pascal would have them.  Or even 
>> 
>> 	Uhm... The last time I worked FORTRAN (about a decade ago),
>> functions COULD have side-effects. After all, the normal passing method
>> in FORTRAN is by-reference, and I never encountered a compiler that
>> would enforce read-only access to arguments inside a function. Now,
>> maybe post '90/'95 standard have implemented such -- but I'd bet most
>> shops are still running a compatibility option for older code...
>
>Indeed. Classic Fortran did, and F90+ still does by default (i.e.
>INTENT unspecified) or if you specify INTENT OUTor INOUT.
>Only if you explicitly make a subprogram PURE or ELEMENTAL then a
>function, but not a subroutine, is prohibited from having modifiable
>arguments. (Both a function and subroutine are prohibited from other
>'global' side-effects, i.e. on module~package data or external files.)
>
>So did Pascal if you specify VAR, a68 with ref, and COBOL and PL/I
>always. anon may argue that some of those are not now 'common[ly]
>used', but Java certainly is and makes all nonprimitive arguments
>writable references; there's not even a syntax to make a reference
>readonly -- although you can write a target object, or a wrapper or
>adapter etc., to be readonly (always or controllably) and some
>important standard objects like java.lang.String are immutable.
>
>And C++ of course, but that's arguably covered under C. It does have
>added syntax for references (and OO 'this') but same semantics.
>

Classic Fortran is Fortran I,Fortran II, Fortran IV. Now with Fortran 77 
they introduce the if-then-else structure which start the fall of 
Fortran. But "Intent" was not a Fortran keywords yet.  And with the
addition of the keyword "Intent" in Fortran 90/95 and other features, 
it just hammered the nails in the coffin for Fortran.  Most of the 
major Fortran players have since move on.

But now, Adacore and others wants to do the same for Ada. by allowing 
functions to have or "out" and "in out" as parameter modes. As well as 
some other features.

What people are trying to do is create a PLII or PL2. If people want to 
create a PLII aka "Programming Language II" then they should start from 
scratch and create it.  And stop trying to add the features of one 
language they like into an other language, and in the process destroying 
the beauty of the unmodified original language.  Building PLII is not 
difficult, it start with setting down and make a list of what features 
one like about each language then adopt common features and then add 
those features that are desired. But most people who want a type of PLII 
just think they can modify an existing language and community for that 
language will accept it. The community as a whole does not accept the 
changes they just find another language. So, it is time to tell those 
modifiers that's  enough.  If you want PLII then create it and leave 
the other languages like "Ada" alone.

If Adacore and others want to modify Ada why not create a new language 
which base language would be Ada, then they could called new language 
may be Ada2.  And this new language could adopt the new additions, they 
want to add, and remove some features they dislike about the original Ada.
This way they could keep their existing clients that wants the original 
Ada design without unintentionally destroying the "Ada language" as well 
as their relationship with existing clients that uses the original Ada. 
And if Ada2 works then fine, no harm done to either language or their 
clients, but if Ada2 falls then Adacore has the original Ada and clients 
to fall back on and still no harm done. Just a little cost for "research 
and development" which could be a waste or grow into a great value.

In other words, if Adacore keep playing this game with adding features 
of other languages, like C they may find themselves out of bussiness. With
the death of the "Ada Language".

Note: I started using Ada before Fortran 90 came into existence, and 
found it to be a better language for my needs than Fortran, C or 
any other language.

Re: Advice on selling Ada to a C shop

[Marco]

On Jul 6, 4:14 am, a...@att.net wrote:

> What people are trying to do is create a PLII or PL2. If people want to
> create a PLII aka "Programming Language II" then they should start from
> scratch and create it.  And stop trying to add the features of one
> language they like into an other language, and in the process destroying
> the beauty of the unmodified original language.  Building PLII is not
> difficult, it start with setting down and make a list of what features
> one like about each language then adopt common features and then add
> those features that are desired. But most people who want a type of PLII
> just think they can modify an existing language and community for that
> language will accept it. The community as a whole does not accept the
> changes they just find another language. So, it is time to tell those
> modifiers that's  enough.  If you want PLII then create it and leave
> the other languages like "Ada" alone.

  Agreed - it is either a function that returns a value or a procedure
that can manipulate state not both

Re: Advice on selling Ada to a C shop

[Dmitry A. Kazakov]

On Fri, 9 Jul 2010 06:21:07 -0700 (PDT), Marco wrote:

>   Agreed - it is either a function that returns a value or a procedure
> that can manipulate state not both

Function manipulates the state of its result.

(Stateless computing is a fiction)

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Advice on selling Ada to a C shop

[Georg Bauhaus]

On 09.07.10 15:45, Dmitry A. Kazakov wrote:
> On Fri, 9 Jul 2010 06:21:07 -0700 (PDT), Marco wrote:
> 
>>   Agreed - it is either a function that returns a value or a procedure
>> that can manipulate state not both
> 
> Function manipulates the state of its result.
> 
> (Stateless computing is a fiction)

When the word "function" is just not present in
a programming language, is there a problem at all?
I mean, do people complain?

Every terminating procedure does compute a function
from input variables and stores the result in some
output variables. Correct?

Do we want "function"?  Or do we want "modifies"?

Re: Advice on selling Ada to a C shop

[Dmitry A. Kazakov]

On Fri, 09 Jul 2010 16:12:15 +0200, Georg Bauhaus wrote:

> On 09.07.10 15:45, Dmitry A. Kazakov wrote:
>> On Fri, 9 Jul 2010 06:21:07 -0700 (PDT), Marco wrote:
>> 
>>>   Agreed - it is either a function that returns a value or a procedure
>>> that can manipulate state not both
>> 
>> Function manipulates the state of its result.
>> 
>> (Stateless computing is a fiction)
> 
> When the word "function" is just not present in
> a programming language, is there a problem at all?
> I mean, do people complain?
> 
> Every terminating procedure does compute a function
> from input variables and stores the result in some
> output variables. Correct?

No, because you have no way to denote them as an entity. Function in Ada is
a procedure, which allows to denote its dedicated argument called result in
a useful way:

1. in a transition context (temporary result)
2. supporting constraint inference (indefinite result)
3. constructing the result out of nothing, as an object, function is
"equivalent" to the object it returns, and any object can thought as a
function ("functional view").

> Do we want "function"?  Or do we want "modifies"?

We (I) want to keep the following three issues separated:

1. Syntax of a call
2. Purity of a subprogram
3. Ordering of side effects

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Advice on selling Ada to a C shop

[Phil Clayton]

On Jun 20, 12:01 am, use...@scriptoriumdesigns.com wrote:
> I may have the opportunity to pitch Ada for use in some new projects
> (industrial equipment) at work.  The place has been using C by
> default, not by any conscious choice, and of course they've been
> paying a typical price for that default.  The head of engineering (who
> is not a software guy) MAY be open to trying Ada if presented with a
> compelling case.  The programmers are another question - they may
> resist or they may be intrigued by some of Ada's features e.g.
> concurrency.  They may also be open to improving the very ad-hoc
> software culture now in place, and the idea of having fewer bugs, and
> those caught sooner and less painfully.
>
> So, what points would you emphasize to each (manager, programmers) to
> make the Ada sale?  I've read a lot of the advocacy and I think I have
> a fair handle on it, but I'd still like other viewpoints, and perhaps
> even examples of such a successful switch.
>
> In the end, it seems, it all comes down to money.  Money saved in
> greater productivity and less debugging, money saved in lower
> liability and maintenance, money gained from satisfied customers who
> get a robust product, and maybe even money saved in having programmers
> who have a more powerful and safer tool at their disposal.
>
> I know that language choice is not the be-all-and-end-all of better
> software, but I'm convinced it's a key component, and I'm also
> convinced that the sooner we leave C and its baggage behind the better
> we can become.

Perhaps subsumed under 'maintenance' but it may be worth mentioning
separately the portability of Ada across different hardware in
comparison to C.  Ada is undoubtedly more portable as there is better
separation between hardware and software aspects but I don't have any
real-world examples to cite.  Have there been any issues porting the
existing C?

Having a lower barrier to re-host on different hardware would offer
greater flexibility, but perhaps this is more of a long term advantage
associated with hardware obsolescence that would tend to get
overlooked.  Talking about different hardware also raises the question
of compiler availability.  Of course, if there's no prospect of
changing hardware, then it's probably not worth mentioning.

Phil

Re: Advice on selling Ada to a C shop

[Gautier write-only]

On Jun 22, 8:06 pm, Phil Clayton <phil.clay...@lineone.net>:

> Perhaps subsumed under 'maintenance' but it may be worth mentioning
> separately the portability of Ada across different hardware in
> comparison to C.  Ada is undoubtedly more portable as there is better
> separation between hardware and software aspects but I don't have any
> real-world examples to cite.

Here are some - sorry for some self-advertisement...
  zip-ada: http://unzip-ada.sf.net/
  ini files: http://sf.net/projects/ini-files/
  excel writer: http://excel-writer.sf.net/
  generic image decoder: http://sf.net/projects/gen-img-dec/

______________________________________________________________
Gautier's Ada programming -- http://gautiersblog.blogspot.com/
NB: For a direct answer, e-mail address on the following web site:
http://www.fechtenafz.ethz.ch/wm_email.htm

Re: Advice on selling Ada to a C shop

[Gautier write-only]

Something in the "small example" category but with big monetary
figures.
At work, I came across a benchmarking, based on a real production
model, with two languages having "end if"s, and C with its '}'s (or no
'}' sometimes). I've added one more language to the test, for the fun
of it.
But something seemed strange in the results, although all in double-
precision, run on the same machine. From time to time, a result (in a
list of tens of thousands), was different in the column for C. Didn't
seem a big deal. But summing the $'s, it was a big deal: millions! I
looked at the C code for long time, then with its author; tried to add
parentheses, to make smaller expressions. Nothing helped. Finally, it
was a '}' at the wrong place, and a misleading indentation... This in
only ~15 lines (but important ones: a double loop where everything is
summed). Funny, isn't it ?
______________________________________________________________
Gautier's Ada programming -- http://gautiersblog.blogspot.com/
NB: For a direct answer, e-mail address on the following web site:
http://www.fechtenafz.ethz.ch/wm_email.htm

Re: Advice on selling Ada to a C shop

[Maciej Sobczak]

On 22 Cze, 23:00, Gautier write-only <gautier_niou...@hotmail.com>
wrote:

> At work, I came across a benchmarking, based on a real production
> model, with two languages having "end if"s, and C with its '}'s (or no
> '}' sometimes).

> Finally, it
> was a '}' at the wrong place, and a misleading indentation...

Do you think that 'end if' at the wrong place and a misleading
indentation would produce much better results?

Playing the devil's advocate, but remember: you are selling Ada to a C
shop here. Weak arguments are very dangerous, because not only they
don't sell anything, but actually discourage further investigation.
My experience is that Ada does not sell on brackets.

--
Maciej Sobczak * http://www.inspirel.com

YAMI4 - Messaging Solution for Distributed Systems
http://www.inspirel.com/yami4

Re: Advice on selling Ada to a C shop

[Gautier write-only]

On 23 juin, 09:17, Maciej Sobczak <see.my.homep...@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...

G.

Re: Advice on selling Ada to a C shop

[Georg Bauhaus]

On 23.06.10 09:40, Gautier write-only wrote:
> On 23 juin, 09:17, Maciej Sobczak <see.my.homep...@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.

Re: Advice on selling Ada to a C shop

[Jeffrey R. Carter]

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

Re: Advice on selling Ada to a C shop

[Gautier write-only]

On 23 juin, 09:17, Maciej Sobczak <see.my.homep...@gmail.com> wrote:

> Playing the devil's advocate, but remember: you are selling Ada to a C
> shop here. Weak arguments are very dangerous, because not only they
> don't sell anything, but actually discourage further investigation.

You're right, a single case is statistically not enough; then it is
better to stick comparison of with whole projects, if possible with a
parallel development (Jean-Pierre's example), where thousands of
similar situations are summed together.

G.