From: Alex R. Mosteo on
usenet(a)scriptoriumdesigns.com wrote:

> Serious question: What do you consider the N best things / strong
> points / biggest benefits of using Ada? I'm asking as part of my case-
> building for using Ada at work. Of course I have my own list, but I
> don't have anywhere near the Ada experience of most of you folks.

Out of my head --

1. Separation of spec/impl.
2. Easy tasking/data sharing with monitors.
3. If it compiles, bugs are almost always of logic nature and not silly
time-wasters (although there's the rare occurrence when I get too smart ;).
4. Unconstrained types that minimize dynamic allocation needs.
4.1 I guess the use of 'Class is a particular instance of this.
5. Rep. clauses, custom numeric types.
6. Easy interfacing to C.
From: John McCormick on
On Jul 8, 7:52 pm, use...(a)scriptoriumdesigns.com wrote:
> Serious question:  What do you consider the N best things / strong
> points / biggest benefits of using Ada?  I'm asking as part of my case-
> building for using Ada at work.  Of course I have my own list, but I
> don't have anywhere near the Ada experience of most of you folks.
>
> Thanks.

The ability to model scalars.


This is the primary reason why my Ada students succeed and my C
students fail in my Real-Time Systems class.

One of the principles of object-oriented programming is the
development of classes that accurately model the objects in the
problem. We can apply this same approach to the design of our scalar
types. By using scalar types that more accurately reflect the nature
of the data in a problem we are solving, we can write better
programs. One research study by Eisenstadt and analyzed by me in 1997
on the nature of costly software faults indicates that poor models of
scalar quantities were responsible for nearly 90% of the errors in the
cases studied. Ada allows programmers to define their own scalar data
types that accurately model the scalar values in the problem domain.

Eisenstadt, M, My hariest bug war stories, Commun ACM, 1997, vol 40,
#4 30-37
McCormick, J., Forum letter, Commun ACM, 1997, vol 40, #8, 30
From: (see below) on
On 09/07/2010 12:52, in article
bff0da99-cd58-4612-a720-4c94ace50804(a)s9g2000yqd.googlegroups.com, "John
McCormick" <mccormick(a)cs.uni.edu> wrote:

> On Jul 8, 7:52�pm, use...(a)scriptoriumdesigns.com wrote:
>> Serious question: �What do you consider the N best things / strong
>> points / biggest benefits of using Ada? �I'm asking as part of my case-
>> building for using Ada at work. �Of course I have my own list, but I
>> don't have anywhere near the Ada experience of most of you folks.
>>
>> Thanks.
>
> The ability to model scalars.
>
>
> This is the primary reason why my Ada students succeed and my C
> students fail in my Real-Time Systems class.

My own teaching experience is completely in agreement with this.

I would just add that the mindset induced by being very careful about scalar
types then carries over to other aspects of the job.

--
Bill Findlay
<surname><forename> chez blueyonder.co.uk


From: anon on
In <1122ac0c-8f74-47f9-ade4-fe6348bff6d7(a)i28g2000yqa.googlegroups.com>, tonyg <tonythegair(a)googlemail.com> writes:
>On Jul 9, 4:08=A0am, a...(a)att.net wrote:
>> In <97691fd2-7411-4ccc-bc7b-290aca633...(a)z30g2000prg.googlegroups.com>, u=
>se...(a)scriptoriumdesigns.com writes:
>>
>> >Serious question: =A0What do you consider the N best things / strong
>> >points / biggest benefits of using Ada? =A0I'm asking as part of my case=
>-
>> >building for using Ada at work. =A0Of course I have my own list, but I
>> >don't have anywhere near the Ada experience of most of you folks.
>>
>> >Thanks.
>>
>> 1. RM defines the language.
>>
>> 2. Muti-Core programs are easy. Just modify/create few run-time packages =
>to
>> switch the real-time concurrent system to a real-time mutiple-core system=
>..
>>
>> 3. Readablity, Reliability, Maintainability, and Efficiency.
>>
>> 4. Portable without conditionals statement. Update the OS or change
>> processor only requires a simple recomping of the source code without
>> changes.
>>
>> 5. from Section 1 of the RM 95:
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Section 1: Gen=
>eral
>>
>> 1 =A0 Ada is a programming language designed to support the construction =
>of
>> long-lived, highly reliable software systems. =A0The language includes
>> facilities to define packages of related types, objects, and operations. =
>=A0The
>> packages may be parameterized and the types may be extended to support th=
>e
>> construction of libraries of reusable, adaptable software components. =A0=
>The
>> operations may be implemented as subprograms using conventional sequentia=
>l
>> control structures, or as entries that include synchronization of concurr=
>ent
>> threads of control as part of their invocation. =A0The language treats
>> modularity in the physical sense as well, with a facility to support sepa=
>rate
>> compilation.
>>
>> 2 =A0 The language includes a complete facility for the support of real-t=
>ime,
>> concurrent programming. =A0Errors can be signaled as exceptions and handl=
>ed
>> explicitly. =A0The language also covers systems programming; this require=
>s
>> precise control over the representation of data and access to
>> system-dependent properties. =A0Finally, a predefined environment of stan=
>dard
>> packages is provided, including facilities for, among others, input-outpu=
>t,
>> string manipulation, numeric elementary functions, and random number
>> generation.
>
>A few years at a eminent european institution which uses Ada, C++ and
>linux I was hired as part of a 5 man team to conduct a migration of a
>monumental system from a 32 bit environment to a 64 bit environment.
>There were two C++ guys, one hardware guy and I was the ada guy, and
>the boss flew in, / worked remtoely a lot. Two days after the start
>the Boss Guy took me aside to tell me that there appeared to be no
>work for me because the Ada was all going to work. The rest required
>all sorts of changes. (Luckily I was useful elsewhere).
>

Well that the up and downside of a Ada programmer.

We create the partition and after finding and repairing those foolish bugs,
we like to move on, because there no money in upgrading Ada program.
That's because it a few hours recompiling to the new system, then a few
more hours to adjusting the documentation and your done. On to the next job.

From: Shark8 on
People have mentioned packages, non-textual-substitution generics, and
such.
But one thing that could come in handy is the named parameters, and it
is something I like; one of those "little things."

"Circle( Radius => 23, X => 28, Y => 14 );" will always be more
readable than "Circle( 23, 28, 14 );" plus, there's the added benefit
that 1) changes in parameter-ordering will not impact calls of this
sort, & 2) the users of the functions/procedures can place the more
pertinent parameters [to their task] more prominently [e.g. first].