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

From: Mark S. Hathaway (hathawa2_at_marshall.edu)
Date: 07/15/04 

Date: Wed, 14 Jul 2004 23:04:36 -0400

>>>>>>>Dmitry A. Kazakov wrote:
>>>>>>>
>>>>>>>This is where static typing helps. Assumptions are replaced
>>>>>>>by type contracts.

>> Mark S. Hathaway wrote:
>>
>> Maybe it's some minor differences you have with the dynamic
>> creation of types in a language such as Smalltalk, but do you
>> really differ in their usage, which is really just as strict
>> as in a static type system language?

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

>> Mark wrote:
>>
>>How do you see the difference between a static typing system
>>and the types which are created for a new Smalltalk program?
>>Is it only the compile-time checking of types which you think
>>is crucial?

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

>> Mark wrote:
>>
>>Isn't that pretty well overcome in ST by the fact
>>a method can only be utilized by the object bound up in that
>>type (class)? Isn't that pretty strict type checking?

> Dmitry A. Kazakov wrote:
>
> Yes. But the difference is in the contract. When type is checked at
> compile-time, then the contract is: "that thing has this [sub]type". When
> it is checked at run-time, then the contract is: "either that thing has the
> [sub]type, or an exception propagates". It is quite often crucial, whether
> I should expect an exception and handle it or not. Further, to determine if
> an exception will be raised is in general case a halting problem. So it is
> not provable.

>>Can't I use the word Push to refer to different things?

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

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

>> 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. Yet, in most languages one would say they
are 'int'. Bad static typing? Mixing storage with utility or
just a limited typing system?

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.

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.

>>I don't see why one has to drop (!) back to static type-checking
>>if those other dynamic ways of constructing types are sufficient.
>>And, whether something is sufficient is always by usage (Darwinian).

The key word being "sufficient"!

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

C'mon SmallTalk foks, chime in here! We want to know how you
feel about this debate over the necessity of static type-checking.

>>>Always, one cannot check semantics, no way. But you can formalize a part of
>>>semantics and make it checkable. If you know that the bounds of a number
>>>are static, why not to use this information? Moreover, if that number is
>>>used to index a ring buffer, why not to tell that (Ada):

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

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

>>This relates to what I was saying earlier about a type being
>>the completely fictitious construction of humans, flaws and all.

> Types constitute an abstraction layer. We can work with individual values
> not knowing their commonalities. For CPU it is OK. For us humans there is a
> great difference in what level of complexity we could manage with types or
> without them. The next level of abstraction deals the commonalities between
> types. That is how generic programming appears. This ladder has no end.

Managing complexity is a ... complex problem!

Relevant Pages

  • Re: Static vs. Dynamic typing (big advantage or not)---WAS: c.programming: OOP and memory management
    ... >> creation of types in a language such as Smalltalk, ... > dynamic camp just argue against explicit contracts. ... I have used static type checking languages and have found ... >>How do you see the difference between a static typing system ...
    (comp.programming)
  • Re: creaping coupling......
    ... >>of your original examples on your web site were from Smalltalk. ... > examples in those languages either. ... statically bound fee (dependency management). ... to relative addresses but in a dynamically bound OOPL one still needs ...
    (comp.object)
  • Re: Community Edition limitations
    ... Are you launching it each time from the "Dolphin Smalltalk ... It is this image file that you need to open each time you subsequently ... languages I've taken the time to learn, ...
    (comp.lang.smalltalk.dolphin)
  • Re: Static vs. Dynamic typing (big advantage or not)---WAS: c.programming: OOP and memory management
    ... >>A few years ago I started learning Smalltalk. ... >>features in alternative languages. ... > know that there is widespread ignorance about programming language features ... eiffel developers even though the type system in eiffel is superior to Java. ...
    (comp.programming)
  • Re: OT: HTML (WAS: MF having issues?)
    ... are real pissed that Java outshone Smalltalk, ... Does that book point the finger at Xerox or specifically at PARC? ... The original Smalltalk *required* the Smalltalk ... but isn't it nice that with both languages we can each satisfy ...
    (comp.lang.cobol)