What is Expressiveness in a Computer Language

[Pascal Costanza]

David Hopwood wrote:
> Marshall wrote:
>> Chris Smith wrote:
>>> Marshall <marshall.spight at gmail.com> wrote:
>>>
>>>> I think what this highlights is the fact that our existing terminology
>>>> is not up to the task of representing all the possible design
>>>> choices we could make. Some parts of dynamic vs. static
>>>> a mutually exclusive; some parts are orthogonal.
>>> Really?  I can see that in a strong enough static type system, many
>>> dynamic typing features would become unobservable and therefore would be
>>> pragmatically excluded from any probable implementations... but I don't
>>> see any other kind of mutual exclusion between the two.
>> Well, it strikes me that some of what the dynamic camp likes
>> is the actual *absence* of declared types, or the necessity
>> of having them.
> 
> So why aren't they happy with something like, say, Alice ML, which is
> statically typed, but has a "dynamic" type and type inference? I mean
> this as a serious question.

Note: I haven't yet worked with such a language, but here is my take anyway.

A statically type language requires you to think about two models of 
your program at the same time: the static type model and the dynamic 
behavioral model. A static type system ensures that these two 
_different_ (that's important!) perspectives are always in sync. This is 
especially valuable in settings where you know your domain well and want 
to rely on feedback by your compiler that you haven't made any mistakes 
in encoding your knowledge. (A static type system based on type 
inferencing doesn't essentially change the requirement to think in two 
models at the same time.)

A dynamically typed language is especially well suited when you don't 
(yet) have a good idea about your domain and you want to use programming 
especially to explore that domain. Some static typing advocates claim 
that static typing is still suitable for exploring domains because of 
the compiler's feedback about the preliminary encoding of your 
incomplete knowledge, but the disadvantages are a) that you still have 
to think about two models at the same time when you don't even have 
_one_ model ready and b) that you cannot just run your incomplete 
program to see what it does as part of your exploration.

A statically typed language with a dynamic type treats dynamic typing as 
the exception, not as the general approach, so this doesn't help a lot 
in the second setting (or so it seems to me).

A language like Common Lisp treats static typing as the exception, so 
you can write a program without static types / type checks, but later on 
add type declarations as soon as you get a better understanding of your 
domain. Common Lisp implementations like CMUCL or SBCL even include 
static type inference to aid you here, which gives you warnings but 
still allows you to run a program even in the presence of static type 
errors. I guess the feedback you get from such a system is probably not 
"strong" enough to be appreciated by static typing advocates in the 
first setting (where you have a good understanding of your domain).


Pascal

-- 
3rd European Lisp Workshop
July 3 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/