Re: ADA Popularity Discussion Request

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 08 Sep 2004 12:26:54 -0400, jayessay wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> The philosophy behind is that types are random artifacts of the
>> program,
> 
> No, this is also incorrect.  The real difference is that with dynamic
> typing _values_ have types _not_ variables.  Since _variables_ don't
> even exist at runtime, your type information is largely gone at
> runtime in static systems.

I suppose you are talking about polymorphic objects. They still have *a*
type. It is what Ada calls "class". So what is your point:

1. That statically typed languages cannot express polymorphism? This is
plainly wrong.

2. That all polymorphic values should be considered of same type ANY? This
is also wrong.

> In dynamically typed system you can never
> have something like Unchecked_Conversion, because the type information
> is actually with the value at all times.  You can convert, but this
> always creates a _new_ value.

As Unchecked_Conversion does.

And I still do not see your point. You have accepted that types exist. So
you are talking about type information, excellent. Where is then any
difference between static and dynamic typing? There is *no* one. From this
perspective, dynamically typed systems are subset of statical ones. This is
important to understand. This is also the reason why "truly dynamic" people
sooner or later start to argue against types. Because, take a static
language, derive everything from same base, and you will have the case,
where the type information would be as useless (at compile time) as in a
dynamically typed language. Static typing does not make type information
unavailable. It makes it in some cases a-priory known.

Note that to argue against type is not a crime. On the contrary, it is
interesting to speculate whether an alternative approach to our view on
software design were possible. The only problem is that modern dynamically
typed languages do not offer that alternative. They are still typed, badly
typed, if you want. (:-))

>> rather than the basis of software design. When the program
>> is not thought in terms of types, there is nothing to check, either
>> statically or dynamically.
> 
> This is wrong on two counts:
> 
> First, types are indeed part of program design in dynamic languages.
> In some respects they are even more important than in static languages
> as they exist at _all_ times: compile load (link) and run.  They are
> _always_ checked _all_ the time.  If you want to say "Ooo!  this has a
> performance hit", fine, but with current systems any such checks are
> basically in the noise.  OTOH, you can annotate a dynamic program with
> static type information and/or use type inference to remove this issue
> from most cases.

Fine, types exist. Then you also have to accept that types need to be
documented in some way. The next step is that the documentation language
should be a part of the programming language. And the final step, if that
is a part of the language, why the compiler should be prevented from
checking where it can?

Again, having accepted types you cannot argue that to check them earlier is
worse than to check them later. You can only say that static checks, when
imposed, would limit you in using this and that *concrete* programming
pattern. And anyway, there are others very useful patterns nicely working
with static checks. So what is the point?

> Second, types are _not_ the only thing to check in a program.  There
> are many aspects that are not and even cannot be described by types.
> This should be obvious or else you would never have the need to ever
> write any functions/procedures.  Checking the correctness of
> algorithms is every bit as important as type consistency.  I'm pretty
> sure that you (anyone) will agree with this once brought to your
> attention.

Yes. Under nothing to check I meant types. But you are not proposing to get
rid of them...

-- 
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de