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

From: Dmitry A. Kazakov (mailbox_at_dmitry-kazakov.de)
Date: 07/15/04 

Date: Thu, 15 Jul 2004 11:26:10 +0200

On Wed, 14 Jul 2004 23:04:36 -0400, Mark S. Hathaway wrote:

>> Dmitry A. Kazakov wrote:
>>
>> Dynamic creation is not a problem. In Ada you can create types dynamically,
>> yet they remain statically checkable. The key issue is type contracts,
>> whether they are implied or explicitly specified. It seems that many in
>> dynamic camp just argue against explicit contracts.
>
> I have used static type checking languages and have found
> that there is often need for extensive re-typing of parameters
> and such. This slows the work tremendously sometimes. There is
> also the added clutter of all that type information throughout
> the text.

> How much do you think it adds, in terms of defining the TYPE
> more perfectly than the 'class library with inheritance' system?

Which information you are talking about? How many variables you have. It
seems that too many of them if you have a problem to specify their types.
It is funny, when you have a 'class library with inheritance' and inherit
from a class, why do not you complain that you have to specify the type you
inherit from? Isn't it an awful amount of re-typing work? (:-))

>> Dmitry A. Kazakov wrote:
>>
>> Crucial are checkable contracts. More precisely, how much of semantics can
>> be expressed in checkable contracts and thus proved.
>
> I suppose there isn't a lot of disagreement that this
> can be done, but only how much is gained from it and
> whether it's crucial.

Crucial because no matter what TDD folk tells you, testing as any other
empirical approach is insufficient. They try to bring us back to ancient
Egypt. Egyptians knew, from tests, how big Pi approximately is, but they
failed to go any further.

>> You can, but a language indiscriminately sending messages cannot.
>
> I don't know of any language/program which 'indiscriminately
> sends messages'. Perhaps you'd like to elaborate.

An ability to send any message to any object, not being caught by the
compiler.

>> Not at all. I prefer languages supporting overloading and statical type
>> checking.
>
> So, what languages do you actually prefer?
>
> BTW, I don't ask such questions to start language wars, just
> to find out what you see as currently best serving your
> needs/ideals.

Ada 95 is the closest one. Though IMO no of existing OOPL languages has
full blown consistent ADT.

> >> re: -32..965 range
>
>> You called it range. But if you meant just ADT, then well there have to be
>> operator ".." visible in the scope which being applied to two arguments
>> gives the result of some type. The operator can be overloaded. The literals
>> 32 and 965 as well. Where is any problem?
>
> Perhaps the method isn't to apply any binary operator with
> mathematical properties, but to know if a temperature is
> too cold or too hot, so the method might be 'Cold()', 'Hot()',
> etc. The number might be abstracted from temperature, rather
> than mathematics.

What do you mean under temperature. A physical measure of statistical
nature in K? A thing we can sense and describe in fuzzy terms? Depending on
the choice a corresponding ADT has to be created to model it.

> Yet, in most languages one would say they
> are 'int'.

Not in Ada where implementation and interface are separated.

> Bad static typing? Mixing storage with utility or
> just a limited typing system?

A misuse of typing system. A FORTRAN program can be written in any
language.

> I think OOPLs with class and inheritance have improved our
> abilities to break out of the very small box (type system)
> we previously had with Fortran and C.

You probably mean ADT.

> Now, if an OOPL wishes to do static typing then is there any
> problem if only user-created (including standard class library)
> types are the only types used? I wonder what limitations the
> SmallTalk people see with such a combination of static type-checking
> and class library with inheritance features.

How can you use an non-existing type? SmallTalk is no different in that
respect. It creates types as any other language. If you mean unnamed, but
existing types, then that is also no problem. Statically typed languages
have anonymous types. They also have type inference. Static checks do not
preclude that. Ada has both, though sometimes too limited to my taste.

>> As I see it, we have two challenges:
>>
>> 1. To have a rich type algebra
>> 2. To have contracts provable
>>
>> If your argument is that richer 1 leads to weaker 2, then I would agree, in
>> general it should be so.
>>
>> Also from "dynamic people" I *do* expect examples of useful type operations
>> with proofs that having them would lead to loss of static checkability here
>> and there. So far their argumentation is like we need no 2, because we do
>> not like it. Further, I saw no advances in 1 made by dynamic languages,
>> which in the end were not adopted by statically typed languages.
>
> "because they don't like it"? or because they don't feel it's
> necessary, given their other language features?

That's the same.

>>>Isn't that used in ST when the method associated with that
>>>range only allows the use of an object of that type in the
>>>appropriate ways?
>
>> It isn't. Because the "appropriate ways" are defined within method, while
>> in Ada it is a visible (and sometimes provable) contract. It is again
>> about:
>
> "Visible"? How so? You say it's defined within the method, so
> isn't that the same as what I was saying, that there are some
> situations where the TYPE can only be handled by dynamic means
> and not mere labeling?

We were talking about static bounds. In Ada or Eifell, because bounds are
static, they can be made a part of the type. In SmallTalk, you may claim
that they can be too, but in fact, because checked dynamically, they are
just a part of the value. As I said before, statically typed languages
represent a more general case than dynamic ones.

> > "any program that does not crash is valid" vs.
> > "valid program never crash"
>
> Again, we're arguing specious things like 'validity'
> and SmallTalk and XPers skip that and go straight to
> whether the product performs as needed -- utility.

Yep, no need in pills until you die... (:-)) 

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Relevant Pages

  • Re: Static vs. Dynamic typing (big advantage or not)---WAS: c.programming: OOP and memory management
    ... >> dynamic camp just argue against explicit contracts. ... > I have used static type checking languages and have found ... Ada 95 is the closest one. ... >> with proofs that having them would lead to loss of static checkability here ...
    (comp.object)
  • Re: Why is Ada considered "too specialized" for scientific use
    ... What is the best high-level language to use for scientific programming? ... literally hundreds of high-level languages have been developed. ... because I think Ada can be the best programming language for numerical work. ... The main problem I see with Ada for scientific use is that it does not have as nearly as many packages and functions ready to use output of the box for this, other than that, the language itself I think is better than Fortran and C for scientific work. ...
    (comp.lang.ada)
  • Re: why learn C?
    ... I can do this error in Ada quite easily. ... have that option in any of the C family of languages. ... rigorous software requirements prior to beginning the programming process. ... before dealing with the details of that design. ...
    (comp.lang.ada)
  • Re: Clause "with and use"
    ... there is a large corpus of existing Ada code that must not be ... > broken by language-rule changes. ... If the choice of programming languages in the real world were based ... The leaky roof *must* be fixed, but the clutter in the yard is ...
    (comp.lang.ada)
  • Re: How come Ada isnt more popular?
    ... Most programming languages were terrible at that time, ... And we talked about "Why isn't Ada more popular?". ... Adopting Java ...
    (comp.lang.ada)