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/13/04 

Date: Tue, 13 Jul 2004 10:53:53 +0200

On Mon, 12 Jul 2004 20:01:54 -0400, Mark S. Hathaway wrote:

>>>>Dmitry A. Kazakov wrote:
>>>>
>>>>This is where static typing helps. Assumptions are replaced by type
>>>>contracts.
>
>>> On Mon, 12 Jul 2004 13:29:32 -0400, Mark S. Hathaway wrote:
>>>
>>>I'm beginning to think that type is an entirely human concept
>>>which can't be explicitly shown with static typing
>
>> Dmitry A. Kazakov wrote:
>>
>> Finite deterministic systems are inherently limited. They have no soul, so
>> to speak.
>
> Would you care to elaborate on that?

Depends on your religion! (:-)) If you believe that human brain is
equivalent to a computer, then there is no difference of course.

>>>or OO constructs,
>>>but only with the actual usage of data in an algorithm.
>
>> Yes any program exposes some types even if they were not explicitly stated.
>> The problem is with the word "any". This includes erroneous programs as
>> well!
>
> Indeed, just as with static typing or dynamic typing.

Yes, but the difference is that an explicitly typed approach tells: here is
a type. I do not care whether it has any semantics, right or wrong, I just
check it formally according to its contract. End of story. More we can
check formally is better.

>>>Thus, within Smalltalk one structures the class library, not
>>>to show 'type', but to enable one to access pre-defined sets
>>>of algorithms which when used with data construct the type,
>>>which is then referred to as an object of that type.
>
>> How do you know that the algorithms together with values they operate on,
>> comprise a right type?
>
> Excellent question. What's the answer? Isn't the proof
> in the pudding, when the software is executed and either
> works or doesn't, kind like an APL program nobody can
> decipher, but which still works?

Ah, but you cannot decide whether it works. It is a halting problem. So the
mainstream of programming, as I see it, should make things checkable as
much as possible. The rest will be gambling anyway. Do not trust
test-driven-developing guys. All Cretans are liars! (:-))

>> The difference between static and dynamic approach
>> is:
>>
>> static: any stack has Push
>> dynamic: anything that has Push is a stack
>
> That difference is merely a word game.

No it isn't. The first statement is correct, the second is wrong, a push
button is not a stack.

>> Technically, it is the difference between constructive/a priory (so
>> checkable) and non-constructive/a-posteriory.
>
> Isn't that difference always a matter of who's doing
> the testing and how rigorous and time intensive that
> testing is?

Any testing is incomplete. It is very efficient in the beginning. You can
get a good coverage with little effort. Then the price starts to grow and
does it quicker than exponent, because 100% coverage cannot be achieved.

>> [ Actually the only valid argument against static typing could be
>> questioning whether models are indeed static. They are not, not always, so
>> generic programming comes into play. Incredibly, but it can also be made in
>> a static way! ]
>
> Static typing fails if you have need of some type of object
> for which you have no prior type in your language or library.
> Hopefully the language would then provide some other means
> by which to create a working type.
>
> What type is a range of -32..965 ?

Integer range. Formally it is a set of integers (provided that literals are
integers). It can be made a first-class object. Unfortunately Ada missed
that opportunity, it has ranges but they are not first class.

But how a dynamic language can help here? You have to define the type this
or that way. The result does not depend on when types are checked, but on
how rich is the type algebra: which operations the language offers for
building new types:

aggregation (record, array types)
inheritance (interface, implementation of)
parameterization (mix-in, generics, constrains)
closures (class-wide types)
access types (pointers)
...

In my view, dynamic languages have a mission to study that algebra and
bring new operations there. Once well studied, they can be incorporated
into mainstream statically typed languages used for code production.

> Many languages ignore trying to be precise with that
> by just using an int and then some algorithm to check
> the bounds. Is the static type system enough? Who checks
> the algorithm and program performance to see if the more
> accurate type checking is correct? Doesn't it always lead
> to "non-constructive/a-posteriory" problems?

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):

type Buffer_Index is mod 100; -- 100 is the buffer size
type Ring_Buffer is array (Buffer_Index) of ...;

A : RingBuffer;
I : Buffer_Index := 99;
I := I + 1; -- Results in 0
...
A (I) := ...; -- Anything I could with I, this will always stay in bounds

>>>Is 2 an integer or a character or a time or what?
>>>It all depends!
>
>> ...on its type! (:-))
>
> Somehow I fear there's a Yogi Berra statement about
> types of things...a statement which makes absolutely
> no sense, but is clearly a Yogi Berra type of statement.

In the reality, everything is not as it is! (:-)) 

-- 
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
    ... >> Finite deterministic systems are inherently limited. ... I do not care whether it has any semantics, right or wrong, I just ... > for which you have no prior type in your language or library. ... But you can formalize a part of ...
    (comp.object)
  • Re: FpgaC developers wanted :)
    ... in many languages this requires a first assignment ... to the state of "don't care" that may or may not be overridden. ... doesn't have an explict implicant, ... there is no support in the language for this. ...
    (comp.arch.fpga)
  • Re: Godel Incompleteness Theorem
    ... Of course it is true that we can't analyze natural language in EVERY ... can formalize Godel's arguments in a completely formal language for a ... You seem to be saying that 'is a number theoretic relation' cannot be ...
    (sci.math)
  • Re: OS Threads behavior
    ... > might run at higher priorities than your threads. ... >>I care about it, since I need it, "This answer is so famelies in Microsoft ... >> heavy tools in this language, the language does not support Hardware ... it's the OS the one who decide which thread to execute. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: a relational database done in forth would r0ck
    ... Forth group implemented a smart card with an embedded web server in Forth - ... you stated they changed language and added people; you stated nothing about the similarity taken in the approach. ... Most of the strategies commonly associated with Forth programmers are part of modern software development practice. ... Those who care more about results don't care about historical timelines-- they just follow these strategies and get the same results regardless of language. ...
    (comp.lang.forth)