What is Expressiveness in a Computer Language

[Joachim Durchholz]

Sacha schrieb:
> 
> Many lists are heterogenous, even in statically typed languages.
> For instance lisp code are lists, with several kinds of atoms and 
> sub-lists..

Lisp isn't exactly a statically-typed language :-)

> A car dealer will sell cars, trucks and equipment..
> In a statically typed language you would need to type the list on a common 
> ancestor...

Where's the problem with that?

BTW the OO way isn't the only way to set up a list from heterogenous data.
In statically-typed FPL land, lists require homogenous data types all 
right, but the list elements aren't restricted to data - they can be 
functions as well.
Now the other specialty of FPLs is that you can construct functions at 
run-time - you take a function, fill some of its parameters and leave 
others open - the result is another function. And since you'll iterate 
over the list and will do homogenous processing over it, you construct 
the function so that it will do all the processing that you'll later need.

The advantage of the FPL way over the OO way is that you can use ad-hoc 
functions. You don't need precognition to know which kinds of data 
should be lumped under a common supertype - you simply write and/or 
construct functions of a common type that will go into the list.

> What would then be the point of statical typing , as you stilll need to type 
> check each element in order to process that list ?

Both OO and FPL construction allow static type checks.

 > Sure you can do this in a
> statically-typed
> language, you just need to make sure some relevant ancestor exists. In my 
> experience
> you'll end up with the base object-class more often than not, and that's 
> what i call dynamic typing.

Not quite - the common supertype is more often than not actually useful.

However, getting the type hierarchy right requires a *lot* of 
experimentation and fine-tuning. You can easily spend a year or more 
(sometimes *much* more) with that (been there, done that). Even worse, 
once the better hierarchy is available, you typically have to adapt all 
the client code that uses it (been there, done that, too).

That's the problems in OO land. FPL land doesn't have these problems - 
if the list type is just a function mapping two integers to another 
integer, reworking the data types that went into the functions of the 
list don't require those global changes.

>> Give a case of calling nonexistent functions that's useful.
> 
> I might want to test some other parts of my program before writing this 
> function.

That's unrelated to dynamic typing. All that's needed is an environment 
that throws an exception once such an undefined function is called, 
instead of aborting the compilation.

I'll readily admit that very few static languages offer such an 
environment. (Though, actually, C interpreters do exist.)

> Or maybe will my program compile that function depending on user input.

Hmm... do I really want this kind of power at the user's hand in the age 
of malware?

> As long as i get a warning for calling a non-existing function, everything 
> is fine.

That depends.
For software that's written to run once (or very few times), and where 
somebody who's able to correct problems is always nearby, that's a 
perfectly viable strategy.
For safety-critical software where problems must be handled within 
seconds (or an even shorter period of time), you want to statically 
ensure as many properties as you can. You'll take not just static 
typing, you also want to ascertain value ranges and dozens of other 
properties. (In Spark, an Ada subset, this is indeed done.)

Between those extremes, there's a broad spectrum.