N best things about Ada?

N best things about Ada?

[usenet]

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.

Re: N best things about Ada?

[Britt Snodgrass]

On Jul 8, 7:52 pm, use...@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.

My short list:

 1. Packages as organizational units
 2. Separation of specification from implementation (body)
 3. Subtype ranges
 4. Representation clauses for precise data representation (e.g., for
hardware interfacing)
 5. Case insensitivity (i.e., "case sensitivity considered harmful")
 6. Great readability (e.g., begin/end instead of curly braces)
 7. Underscores allowed in numeric literals (e.g.,
24_3345.7689_3345_8807)
 8. A good (well thought out and reviewed) language standard
 9. The GNAT compiler's great error and warning messages.
10. The availability of SPARK when very high (safe & secure) assurance
is needed.

- Britt

Re: N best things about Ada?

[Pascal Obry]

My list would be:

  1. Packages as organizational units not mixed-up with object support

  2. Separation of specification from implementation (body)

  3. Unconstrained objects, can even be declared on the stack
     (no much need for dynamic allocation).

  4. Representation clauses for precise data representation (e.g., for
     hardware interfacing)

  5. Support for concurrent and distributed applications.

  6. Great readability (e.g., begin/end instead of curly braces)

  7. Sound generic support

  8. A good (well thought out and reviewed) language standard

  9. The GNAT compiler's great error and warning messages.

 10. The availability of SPARK when very high (safe & secure) assurance
     is needed.

-- 

--|------------------------------------------------------
--| 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: N best things about Ada?

[Nasser M. Abbasi]

On 7/13/2010 12:05 PM, Pascal Obry wrote:

>
>    6. Great readability (e.g., begin/end instead of curly braces)
>

fyi, the new kid on the block (F#) has done away all together of the 
curly braces and begin. Like Python as well.

These languages use space indentation as part of the logic of the 
program. The idea is that less "clutter" improves readability.

 From MS web site om F#

"The lightweight syntax is shorter and uses indentation to signal the 
beginning and end of constructs, rather than additional keywords like 
begin, end, in, and so on"

 From Python web site:

"Python functions have no explicit begin or end, and no curly braces to 
mark where the function code starts and stops."

I am still not sure which is better. Using an explicit BEGIN END or 
space indentation.

--Nasser

Re: N best things about Ada?

[BrianG]

Nasser M. Abbasi wrote:
> On 7/13/2010 12:05 PM, Pascal Obry wrote:
> 
>>
>>    6. Great readability (e.g., begin/end instead of curly braces)
>>
> 
> fyi, the new kid on the block (F#) has done away all together of the 
> curly braces and begin. Like Python as well.
> 
> These languages use space indentation as part of the logic of the 
> program. The idea is that less "clutter" improves readability.
> 
>  From MS web site om F#
> 
> "The lightweight syntax is shorter and uses indentation to signal the 
> beginning and end of constructs, rather than additional keywords like 
> begin, end, in, and so on"
> 
>  From Python web site:
> 
> "Python functions have no explicit begin or end, and no curly braces to 
> mark where the function code starts and stops."
> 
> I am still not sure which is better. Using an explicit BEGIN END or 
> space indentation.
> 
> --Nasser

I've always wondered - what would these languages do with a program the 
has a mix of space-for-indent and tab-for-indent?  Assuming that can 
even happen.

I'm constantly running into these, because of different people editing 
using different editors.  Usually it's someone else's, where they didn't 
notice that the published final code looks terrible (obviously not in 
Python).

Is F# a version of Fortran for .Net?  :-)  (Like A#.)  Or is it Forth?

Re: N best things about Ada?

[Britt Snodgrass]

On Jul 13, 8:12 pm, BrianG <briang...@gmail.com> wrote:

>
> I've always wondered - what would these languages do with a program the
> has a mix of space-for-indent and tab-for-indent?  Assuming that can
> even happen.
>
> I'm constantly running into these, because of different people editing
> using different editors.  Usually it's someone else's, where they didn't
> notice that the published final code looks terrible (obviously not in
> Python).

With GNAT and the -gnatyh switch, the compiler will issue a warning if
it encounters tabs in source code.  Our coding standard "requires"
users to set the "convert tabs to spaces" and the "trim trailing
spaces" settings in whatever editor they use (usually GPS, GNATbench,
or UltraEdit)

We also use the ASIS based gnatcheck (coding standard checker) and
gnatpp (pretty printer) to check and standardize source code format
for our Ada projects. I suspect other languages don't have such good
utilities since they have no equivalent to ASIS (that I'm aware of).

>
> Is F# a version of Fortran for .Net?  :-)  (Like A#.)  Or is it Forth?
>

Neither. It seems to be Microsoft's attempt at yet another functional
language (YAFL).

- Britt

Re: N best things about Ada?

[Shark8]

> Neither. It seems to be Microsoft's attempt at yet another functional
> language (YAFL).


Don't they have a LISP for .NET? How about Scheme which, as I
understand it, is basically a LISP-decedent/varient developed in
response to Common Lisp (which, IIRC, had the commonality of
alienating large portions of particular-implementation-X for all
implementations).

Re: N best things about Ada?

[Simon Wright]

BrianG <briang000@gmail.com> writes:

> I've always wondered - what would these languages do with a program
> the has a mix of space-for-indent and tab-for-indent?  Assuming that
> can even happen.

Use 'python -tt', inconsistent tab/space usage => error!
(I didn't know this until I looked on StackOverflow for 'python edit tab
space')

Re: N best things about Ada?

[Jeffrey R. Carter]

On 07/08/2010 05:52 PM, usenet@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.

Off the top of my head:

Separation of spec and body
Application-defined numeric types
High-level, safe concurrency
Early detection of common errors
Great expressiveness

-- 
Jeff Carter
"When danger reared its ugly head, he bravely
turned his tail and fled."
Monty Python and the Holy Grail
60

Re: N best things about Ada?

[anon]

In <97691fd2-7411-4ccc-bc7b-290aca633cd5@z30g2000prg.googlegroups.com>, usenet@scriptoriumdesigns.com writes:
>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.
>
>

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:

                             Section 1: General


1   Ada is a programming language designed to support the construction of
long-lived, highly reliable software systems.  The language includes
facilities to define packages of related types, objects, and operations.  The
packages may be parameterized and the types may be extended to support the
construction of libraries of reusable, adaptable software components.  The
operations may be implemented as subprograms using conventional sequential
control structures, or as entries that include synchronization of concurrent
threads of control as part of their invocation.  The language treats
modularity in the physical sense as well, with a facility to support separate
compilation.

2   The language includes a complete facility for the support of real-time,
concurrent programming.  Errors can be signaled as exceptions and handled
explicitly.  The language also covers systems programming; this requires
precise control over the representation of data and access to
system-dependent properties.  Finally, a predefined environment of standard
packages is provided, including facilities for, among others, input-output,
string manipulation, numeric elementary functions, and random number
generation.

Re: N best things about Ada?

[tonyg]

On Jul 9, 4:08 am, a...@att.net wrote:
> In <97691fd2-7411-4ccc-bc7b-290aca633...@z30g2000prg.googlegroups.com>, use...@scriptoriumdesigns.com writes:
>
> >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.
>
> 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:
>
>                              Section 1: General
>
> 1   Ada is a programming language designed to support the construction of
> long-lived, highly reliable software systems.  The language includes
> facilities to define packages of related types, objects, and operations.  The
> packages may be parameterized and the types may be extended to support the
> construction of libraries of reusable, adaptable software components.  The
> operations may be implemented as subprograms using conventional sequential
> control structures, or as entries that include synchronization of concurrent
> threads of control as part of their invocation.  The language treats
> modularity in the physical sense as well, with a facility to support separate
> compilation.
>
> 2   The language includes a complete facility for the support of real-time,
> concurrent programming.  Errors can be signaled as exceptions and handled
> explicitly.  The language also covers systems programming; this requires
> precise control over the representation of data and access to
> system-dependent properties.  Finally, a predefined environment of standard
> packages is provided, including facilities for, among others, input-output,
> 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).

Re: N best things about Ada?

[anon]

In <1122ac0c-8f74-47f9-ade4-fe6348bff6d7@i28g2000yqa.googlegroups.com>, tonyg <tonythegair@googlemail.com> writes:
>On Jul 9, 4:08=A0am, a...@att.net wrote:
>> In <97691fd2-7411-4ccc-bc7b-290aca633...@z30g2000prg.googlegroups.com>, u=
>se...@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.

Re: N best things about Ada?

[Alex R. Mosteo]

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

Re: N best things about Ada?

[John McCormick]

On Jul 8, 7:52 pm, use...@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

Re: N best things about Ada?

[(see below)]

On 09/07/2010 12:52, in article
bff0da99-cd58-4612-a720-4c94ace50804@s9g2000yqd.googlegroups.com, "John
McCormick" <mccormick@cs.uni.edu> wrote:

> On Jul 8, 7:52�pm, use...@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

Re: N best things about Ada?

[Shark8]

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

Re: N best things about Ada?

[Robert A Duff]

Shark8 <onewingedshark@gmail.com> writes:

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

Yes.  It's such a small feature, yet has a huge benefit.
People should use it more often.

Another small feature: underscores in numeric literals.
One of my pet peeves is when I have to carefully
count the zeroes in 10000000, when it's so easy
to write 10_000_000.

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

Do you have any examples of that last part?  That is, examples
where using different parameter orders in different calls
makes the code more readable?

I think that sort of inconsistency usually makes the code less readable.
I wouldn't mind a rule that says the parameter order has to match
the declaration.  (A Legality Rule, not a Name Resolution Rule!)

- Bob

Re: N best things about Ada?

[Shark8]

On Jul 12, 9:13 am, Robert A Duff <bobd...@shell01.TheWorld.com>
wrote:
> Shark8 <onewingedsh...@gmail.com> writes:
> > 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."
>
> Yes.  It's such a small feature, yet has a huge benefit.
> People should use it more often.
>
> Another small feature: underscores in numeric literals.
> One of my pet peeves is when I have to carefully
> count the zeroes in 10000000, when it's so easy
> to write 10_000_000.
>
> > "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].
>
> Do you have any examples of that last part?  That is, examples
> where using different parameter orders in different calls
> makes the code more readable?
>
> I think that sort of inconsistency usually makes the code less readable.
> I wouldn't mind a rule that says the parameter order has to match
> the declaration.  (A Legality Rule, not a Name Resolution Rule!)
>
> - Bob

Well, in image-manipulation there are a number of formats that store
their information Y, then X. (That is they use column-major order
instead of row-major order.)

Given a call:
 "Get_Pixel(K,J);"
Is that in familiar X-Y space, or in the image's native Y-X space?

Get_Pixel( X=> K, Y=> J);
and
Get_Pixel( Y=> J, X=> K);
are unambiguous, and given the situation/problem you may be thinking
in
one or the other.

Let's say you were to want to extend/overload Get_Pixel for a Point-
type:
 Type Point_Type is record
  Y, X : Integer;
 end record;

You could write it as:
Function Get_Pixel( Point : Point_Type ) return Pixel_Value is
begin
 Return Get_Pixel( X=> Point.X, Y=> Point.Y);
end;

Re: N best things about Ada?

[Simon Wright]

Robert A Duff <bobduff@shell01.TheWorld.com> writes:

> I wouldn't mind a rule that says the parameter order has to match the
> declaration.  (A Legality Rule, not a Name Resolution Rule!)

Sounds more like a style rule (or an AdaControl rule) to me. Like the
GNAT style rule that wants subprograms to be in alphabetical order.

Re: N best things about Ada?

[Nasser M. Abbasi]

On 7/12/2010 7:05 AM, Shark8 wrote:
> 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].

Yes.

One way to simulate the above when using languages that do not have 
named parameters but do have records or struct, is by passing a record, 
and stick the parameters in the record as fields.

The caller will read the parameters out by the _name_ of the record field.

So, one can change a position of a field in the record, and the called 
function do not have to change, since it is reading the data by the 
field name.

It is not as good as named parameters, but one way around it.

This worked in Matlab, which is interpreted. One nice side benefit is 
that if one has large number of parameters in the call, they now all 
collapse to just one parameter (the record) which holds everything.

One might have to compile everything in other stronger typed static 
languages? but the called function code should not have to change.

--Nasser

Re: N best things about Ada?

[Warren]

 expounded in news:97691fd2-7411-4ccc-bc7b-290aca633cd5
@z30g2000prg.googlegroups.com:

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

In addition to all of the other posts:

- Variant records (vs C unions)

Having proper "checked" variant records has 
saved my bacon many times in a large project.

There is nothing better than early bug detection!

Warren

Re: N best things about Ada?

[Georg Bauhaus]

On 13.07.10 18:18, Warren wrote:

> There is nothing better than early bug detection!

Indeed!  Finding type errors in trace output after
run-time is another way of type checking. I don't find it so
productive.  But it is both popular and respectable,
since, for example, Python applications on Google App Engine
work that way. And it does work.

Most of the time.

If you develop the skills to guess correctly ...

So your argument doesn't carry enough weight: Google is big,
GAE is inexpensive at first, Python is reasonably popular.
This all shows there *is* something better than
early bug detection!

Don't bother with early type checking performed by
language translators. Learn how to write correct code, instead!

Use test cases! O.K., they work a little different
in the testing environment...

Phew. Sorry. I guess you see what I'm currently doing.
I should take notes of the minutes spent in finding stupid
mistakes like mixing str/unicode + encoding vs binary strings
vs strings of limited size, the latter being a restriction
that is enforced after deployment only.  Yes, most of this can
be explained.  But it could be enforced by a compiler, using
type checking ...

How much does type checking save?
Can this be spelled out in time and money?

Re: N best things about Ada?

[Warren]

Georg Bauhaus expounded in news:4c3ca07c$0$6889$9b4e6d93
@newsspool2.arcor-online.net:

> On 13.07.10 18:18, Warren wrote:
> 
>> There is nothing better than early bug detection!
> 
> Indeed!  Finding type errors in trace output after
> run-time is another way of type checking. I don't find it so
> productive.  But it is both popular and respectable,
> since, for example, Python applications on Google App Engine
> work that way. And it does work.
> 
> Most of the time.
> 
> If you develop the skills to guess correctly ...
> 
> So your argument doesn't carry enough weight: Google is big,
> GAE is inexpensive at first, Python is reasonably popular.
> This all shows there *is* something better than
> early bug detection!

I think you just bent the meter needle of my sarcasm
detector, heh heh.

Warren

Re: N best things about Ada?

[Jeffrey R. Carter]

On 07/13/2010 09:18 AM, Warren wrote:
>
> There is nothing better than early bug detection!

To which we can add completeness checks for case statements and record aggregates.

In fact, aggregates in general. I take them for granted now, but I can remember 
using languages that didn't have them.

I remember watching the videos of the "Ada Launch" (Ada 80, 1980 Dec 10) and 
Barnes presenting a generic discrete (bit-mapped) set package. That was quite a 
revelation for me. I had read about, but not really understood, information 
hiding; seeing packages was the light-bulb event for me. When I saw the use of 
an array aggregate as a "literal" actual parameter for the make-set function I 
realized that this language was more expressive than anything I'd used.

-- 
Jeff Carter
"When Roman engineers built a bridge, they had to stand under it
while the first legion marched across. If programmers today
worked under similar ground rules, they might well find
themselves getting much more interested in Ada!"
Robert Dewar
62

Re: N best things about Ada?

[Georg Bauhaus]

On 7/13/10 7:51 PM, Jeffrey R. Carter wrote:

> I remember watching the videos of the "Ada Launch" (Ada 80, 1980 Dec 10)
> and Barnes presenting a generic discrete (bit-mapped) set package. That
> was quite a revelation for me.


I guess these videos are pretty good, then?  Is there material in there
for an Ada Diamond of the Week to be added to AdaCore's Ada Gem
of the Week series?  If copyright and the wishes of the performers
will permit etc etc.

All references I have been able to find  (some volumes II + III
of accompanying material) point to a two-digit number of video
tapes by Alsys from 1984.

Re: N best things about Ada?

[usenet]

On Jul 8, 5:52 pm, use...@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.

Thanks to all for the comments.  You covered many points that I had
long considered benefits (and so...darn...nice!), and some that I
hadn't really thought about.

Re: N best things about Ada?

[Gautier write-only]

OK, my list:
First, the facts:

1) The type system: you can work most of the time with value types -
as opposed to C/C++/C#. So you use accesses/pointers/references only
when it makes sense. As a result objects live and die in synch with
the scope where they are defined, (unless you need a longer lifespan,
and then you are using an access). So, away with null references,
dangling pointers, bad cloning surprises and memory leaks that even a
good garbage collector has trouble to catch...

2) Orthogonality between the modularity (packages), the type system
(includes the choice tagged or not), generics - and I miss some

3) Nesting: you can nest sub-programs and packages into other sub-
programs and packages, saving much parameter passing

4) Expressions: you can have explicit expressions for any type,
whetever its complexity

On the taste side (so it's weak arguments: people may prefer the other
way!):

5) Readable, fully-bracketed, intuitive, wysiwyg syntax

6) Errors tend to be detected more on the compile-time phase, so you
can be more productive
______________________________________________________________
Gautier's Ada programming -- http://gautiersblog.blogspot.com/