What is Expressiveness in a Computer Language

[Joachim Durchholz]

Raffael Cavallaro schrieb:
> There is a very large class of software where user inputs are 
> unpredictable and/or where input data comes from an untrusted source. In 
> these cases run-time checks are going to be needed anyway so the 
> advantages of static type checking are greatly reduced - you end up 
> doing run-time checks anyway, precisely the thing you were trying to 
> avoid by doing static analysis.

There's still a large class of errors that *can* be excluded via type 
checking.

> Ideally one wants a language with switchable typing - static where 
> possible and necessary, dynamic elsewhere.

That has been my position for a long time now.

 > To a certain extent this is
> what common lisp does but it requires programmer declarations. Some 
> implementations try to move beyond this by doing type inference and 
> alerting the programmer to potential static guarantees that the 
> programmer could make that would allow the compiler to do a better job.

I think it's easier to start with a good (!) statically-typed language 
and relax the checking, than to start with a dynamically-typed one and 
add static checks.
With the right restrictions, a language can make all kinds of strong 
guarantees, and it can make it easy to construct software where static 
guarantees abound. If the mechanisms are cleverly chosen, they interfere 
just minimally with the programming process. (A classical example it 
Hindley-Milner type inference systems. Typical reports from languages 
with HM systems say that you can have it verify thousand-line programs 
without a single type annotation in the code. That's actually far better 
than you'd need - you'd *want* to document the types at least on the 
major internal interfaces after all *grin*.)
With a dynamically-typed language, programming style tends to evolve in 
directions that make it harder to give static guarantees.

> It seems to 
> me that if we set aside that class of software where safety is paramount 
> - mostly embedded software such as aircraft and medical devices - we are 
> left mostly with efficiency concerns.

Nope. Efficiency has taken a back seat. Software is getting slower 
(barely offset by increasing machine speed), and newer languages even 
don't statically typecheck everything (C++, Java). (Note that the 
impossibility to statically typecheck everything in OO languages doesn't 
mean that it's impossible to do rigorous static checking in general. 
FPLs have been quite rigorous about static checks; the only cases when 
an FPL needs to dynamically typecheck its data structures is after 
unmarshalling one from an untyped data source such as a network stream, 
a file, or an IPC interface.)

The prime factor nowadays seems to be maintainability.

And the difference here is this:
With dynamic typing, I have to rely on the discipline of the programmers 
to document interfaces.
With static typing, the compiler will infer (and possibly document) at 
least part of their semantics (namely the types).

> So static typing should be invoked for that small portion of a program 
> where efficiency is really needed and that dynamic typing should be the 
> default elswhere. This is how common lisp works - dynamic typing by 
> default with static guarantees available where one needs them.

Actually static typing seems to become more powerful at finding errors 
as the program size increases.
(Yes, that's a maintainability argument. Efficiency isn't *that* 
important; since maintenance is usually the most important single 
factor, squelching bugs even before testing is definitely helpful.)

Regards,
Jo