Re: Static vs. Dynamic typing (big advantage or not)---WAS: c.programming: OOP

["Richard Riehle" <adaworks@earthlink.net>]

"Cristiano Sadun" <cristianoTAKEsadun@THIShotmailOUT.com> wrote in message
news:Xns954B81678A9D6cristianosadunhotmai@130.133.1.4...
> brangdon@cix.co.uk (Dave Harris) wrote in
> news:memo.20040819213812.1988A@brangdon.m:
>
> > I notice you mention, "different primitive types". I suspect a fair
> > fraction of type errors in C/C++ are due to mixing up the integers,
> > int versus short versus long versus bool versus char versus wchar_t
> > versus unsigned. Sometimes it's useful to have that much control, but
> > often it just gets in the way and makes opportunity for mistakes.
>
> Hm. It could be - but just why you should want to declare something as,
> say, short, if it isn't necessary? If int or long fit all your
> situations, just declare everything as int or long.
>
1)  In languages that support automatic type promotion,
     one is always at risk.

2)  Type casting needs to be more disciplined in some of
      those languages.

3)  When I declare a type, with a given bounds, it allows the
      compiler to check whether I any objects of that type,
      when used within my program, are likely to be out of
      bounds (above or below the given range).  For example,
      (in Ada)

      type T1 is range -473 .. 451;
      type T2 is digits 7 range -30_000.0 ... 100_000.0;
      type Unsigned_Small_Integer is mod 256;
      for Unsigned_Small_Integer use 8;

      I could give many more examples some of which would
      illustrate the ability to create types of quite sophisiticated
      properties.

In type T1, I have defined a type with a given upper and lower
bounds.   The compiler can use this information.   Also, every
Ada program sits on top of a small run-time executive.  The
RTE is tiny, but it does its job well.   When something occurs
that causes an object of type T1 to go out of bounds (not
common, but possible), the RTE raises a constraint error.

In the case (contrived, I admit) of Unsigned_Small_Integer, we
have an unsiged integer that can be represented in eight bits. I
use a representation clause (for ... use 8) to force the size
of the representation eight.  I could just as easily force the
size to 16 bits or 32 bits, and then specified the alignment
I want for objects of that type.   If I make an error, the
compiler immediately notifies me of it.

Granted, when writing programs for less critical systems, these
features can be overkill. For a large category of embedded,
real-time systems, particularly those targeted to bare-board
environments), these features are a blessing.

As several people have noted, it is not (or should not be) a
debate about the virtues of static typing over non-static
typing.  Rather the discussion should be about when it is
appropriate to use static typing (if often is) and when it
is appropriate, as it often is, to use non-static typing.  It
should not be a debate about Smalltalk or Lisp, at one
extreme, versus Ada, at the other the other extreme.
Instead, it should be the case that we all learn the tools
of our profession, understand when to use which tool,
and not be so dogmatic about one tool over another,
that we fail to understand the advantages of each tool
in different circumstances.

I personally like Smalltalk.  I like, but am not proficient
in Lisp. I have seen enough successful software in both
languages to have respect for both the developers and
the languages.   At least one Smalltalk afficionado of
my acquaintance is smart enough to understand that
Smalltalk has its limitations for certain classes of
problems.   I readily admit that Ada may not always
be the right solution.  Of course, I continue to believe
that there is no situation where I would deliberately
choose C++, so I guess I am a bit inflexible in that
regard.   That is, if I have a choice of Ada versus
C++, I would almost always choose Ada.  On the
other hand, if there were choice between Ada and
Smalltalk, Ada and Eiffel, Smalltalk and Lisp, Perl
and Eiffel, etc., I would want to evaluate the context,
the circumstances, the architecture, and many other
considerations before making a decision.    Does that
not seem a sensible approach?

Richard Riehle