Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[mcq95@earthlink.net (Marc A. Criley)]

softeng3456@netscape.net (soft-eng) wrote in message news:<9fa75d42.0305010621.55e99deb@posting.google.com>...
> That having said, if you cannot hire well, a good type
> safe language might help in eliminating smaller
> errors.  But then, you are never going to have
> anything working anyway, so what's the big deal
> about eliminating smaller syntax-level errors?
> 
> If you can hire well, a super-strong type safe
> language will only annoy your best programmers,
> who don't need the type safety to avoid bugs
> but have to work around it for all the things
> that they do need to do.  You can still deliver
> projects in that case, but your quality
> will be poorer, not better, and you will
> have taken much longer for no good reason.
> (Though the relation to job-safety issues
> is apparent, which is why bureaucrat types
> might love such languages.)

This is one of the biggest misconceptions about type-safety and the
languages that utilize it: that its primary purpose is just to help
avoid bugs.  (And this is a misconception held by many Ada programmers
as well.)

Ada is a language whose definition is built around the concept of a
"type model".

The proper definition of types for an application allows the embedding
of vast quantities of information that is there just for the asking by
the application.  One doesn't "work around it" because the "best
programmers...don't need the type safety", one _exploits_ the
information that the type definitions encode.

For example, say you have a scalar C or C++ type, called Altitude; to
what information about that type and its objects does the application
have direct access?  Pretty much just "sizeof()" and the address of a
variable of that type.

Now for a comparable properly defined Ada type, one has the following:

- The first and last values ('First and 'Last)
- Access to the previous and next valid values ('Pred and 'Succ)
- Conversion of the type to a string--without having to know its
  size or whether it's floating, numeric, or enumeration ('Image
  and 'Wide_Image)
- The maximum number of characters such a string representation can
  take ('Width and 'Wide_Width)
- Ability to convert a string representation of that type--whatever
  kind it is--back to a value--with range checking! ('Value,
 'Wide_Value)
- The number of bits required to hold the type's largest value ('Size)

If you have a variable of that type, at the very least you get:
- The number of bits actually allocated for that value ('Size)
- It's address ('Address)

If you know a little bit more about your type, specifically whether
it's a discrete or floating point type, what else do you get with
C/C++?  Nothing.

With Ada (discrete):
- 'Pos, the ordinal position of an enumeral (or number)
- 'Val, convert an ordinal position into a value of the type

(floating):
- 'Machine_Mantissa
- 'Machine_Radix
     and it goes on...

(And yes, one could write a CAltitude class that provides all this
information, but one would have to implement and debug
_all_of_those_functions.  In Ada you write:

  type Altitude is digits 6.0 range -100.0 .. 50_000.0;

and you get access to all that information for free!)

I've seen that one of the critical requirements of an effective Ada
program is getting the types well and correctly defined.  Then
exploiting that information as needed throughout the application.  The
identification of object and interface type mismatches (your nominal
"type safety") is then just a welcome addition, it's the exploitation
of the application's type model that gives the bang for the buck.

And I give Hyman a lot of credit for figuring this out as well,
despite his peripheral familiarity with Ada.  If more programmers
understood the motivation for, and power of, strong typing (such as it
is in C++, Java, or Ada) much better software would get written, and
the "best" programmers wouldn't be struggling to work around it.

Marc A. Criley