The Ada type model (was Re: Top 10 Language Constructs (Ada))

["Marc A. Criley" <marc.a.criley@lmco.com>]

My point is not that programmer's have trouble understanding the Ada
type model (whence Richard then goes on to discuss an area where 
programmer's do sometimes have difficulty).  It's that programmers, of
Ada or other languages, generally don't consciously grasp that strong
typing, as exemplified by Ada, permits and encourages the embedding
of a huge amount of domain information within the software which can
subsequently be extracted via attributes.

Instead of passing an array and the number of elements in it to a
subprogram, Ada permits passing a slice and then provides 'First,
'Last, 'Range, etc. to get at the information associated with that
slice.

You don't have to explicitly pass around or make visible "Maximum_X
constants", "Minimum_X constants", or "Current_Length" values.  In a
well-designed software system, all that information can be extracted
directly from the data items because of their employment of strong
typing.

To provide a similar kind of strong typing behavior in C++ or Java,
one has to constuct a class for each such data item, and then
_explicitly_ implement the strong typing behavior that is desired
(such as range checking for C++).

Ada, in contrast, provides most desired typing features and
information extraction attributes "for free" because of the
nature of the language's implementation of its strong typing
model.

Marc


Richard Riehle wrote:
> 
> "Marc A. Criley" wrote:
> 
> > The critical foundation of the Ada programming language is its "type model". (In
> > claiming this I want to credit Doug Bryan for triggering this insight for me at
> > an Ada conference seminar about a dozen years ago.)
> >
> 
> Marc's exposition of the type model is interesting and comprehensive.   He is
> correct that it is
> an essential element of the Ada language.   It is also an essential element of many
> other
> languages, including Modula-3, Oberon, Eiffel, and even C++.
> 
> The real secret is not the type model, as important and unique as it is in Ada.
> Almost never do I
> encounter a programmer who has difficulty understanding the type model.   More
> often, Ada
> programmers, novice and experienced alike, have trouble with the rules of ALRM
> Chapter 8,
> Scope and Visibility.   In particular, they have difficulty with the difference
> between scope and
> visibility and with the visibility rules themselves.
> 
> No other programming language defines with such care the difference between scope
> and visibility.
> C++ has its scoping rules, but suffers from the ancestral rules of C.   Coupled with
> scope and
> visibility is the difference between name-equivalence and structural equivalence for
> types.  Modula-3,
> and several other languages suffer from reliance on structural equivalence.   It is
> subtle distinction
> that Dr. Stroustrup was careful to insist upon in C++ just as we do in Ada.
> 
> How many Ada programmers do you know who have read and understand the meaning of the
> rules
> in Chapter 8 of the ALRM.   Probably very few.   Yet more programming problems, more
> compiler
> error messages, originate in misunderstandings of this chapter than in any other set
> of rules, excepting
> perhaps the new accessibility rules for access and tagged types.
> 
> The Ada type model is not nearly as strong as one might think without the rules of
> Chapter 8.
> 
> Richard Riehle.