What is Expressiveness in a Computer Language

[Pascal Costanza]

ilitzroth at gmail.com wrote:
>  > 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.
> 
> I have trouble understanding your use of the wording "Model of a
> program".
> If it is a system that behaves according to the rules of your program
> then
> statements about your program should consider *all* possible models.
> If it is a formal system that makes statements about properties of your
> program
> than the static type system is a simplified model that is suitable for
> automatic
> analysis and your runtime model is in most cases nonexistent.
> Can you give a definition of a "model of a program"? Can you explain
> why
> Lisp doesn't have two (SBCL does do a lot of typechecking and gives
> type errors)?

I wasn't talking about models that the language implementation may or 
may not have, but the models that I as a programmer must have in order 
to convince the compiler to let me program run.

Consider a simple expression like 'a + b': In a dynamically typed 
language, all I need to have in mind is that the program will attempt to 
add two numbers. In a statically typed language, I additionally need to 
know that there must a guarantee that a and b will always hold numbers.

In a trivial example like this, this doesn't hurt a lot, but can be 
problematic as soon as the program size grows.

>> 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.)
> 
> It is also valuable when you don't know your domain very well and you
> want to rely on feedback by your compiler that you haven't made any
> mistakes  in encoding your limited knowledge

I have more or less used exactly the same words in the paragraph that 
followed the one you cited from my previous posting, and I have already 
given a reply there.

>> 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. our domain).
> 
> In the sense that you can start writing code without the compiler
> pointing out
> all but the most glaring holes in your program, I agree.

I don't know what language environments you are used to, but the Common 
Lisp compilers I use always point out the most glaring holes in my 
programs. But maybe I just have trouble understanding your use of the 
wording "most glaring holes". Can you give a definition of "most glaring 
holes"? ;)

> Most of your
> arguments
> aren't very convincing and the thruth is that I have seem lisp
> programmers using
> the debugger to find out that you can't add a number and a hastable.
> The static view
> was not there and the dynamic view must have been too complicated so
> they had
> nothing to think about.

We have all seen less-than-average programmers who would fail in all 
kinds of languages. What they do is typically not very illuminating.

My goal is not to convince anyone, my goal is to illustrate for those 
who are interested in getting a possibly different perspective.


Pascal

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