[plt-scheme] Why do folks implement statically typed languages?

On Tue, May 29, 2007 at 09:42:51PM -0500, Grant Rettke wrote:
> Hi folks,
> 
> Why do people design dynamically typed (DL) languages over statically
> typed languages (Sl)?

In your subject line, you ask the opposite:
    Why do folks implement statically typed languages?

> 
> In the case of Lisp, it seems obvious, metaprogramming. That said, you
> can metaprogram in SLs, so maybe it is not so obvious.

When Lisp was new, they just didn't know any better.  The languages that 
did have typing had it for low-level machine efficiency, and that was 
not Lisp's primary concern.  It really had only one type, S-expression, 
and everything else (like floating-point) was an add-on.

It took years before anyone figured out that static types could help 
security.  The first language I'm aware of that really went to towm on 
static typing for security was Algol 68, which combined strong static 
type checks with garbage collection and stringent run-time bounds 
checks on arrays and the like.  Others have copied various aspects of 
this, but few have gone it all the way.  Modula-3 (which is a 
*different* language from Modula-2) and Eiffel are good examples of its 
heritage.

In languages that combine rigorous static checking with run-time 
security, it is not unusual to write programs of a thousand lines and 
have them run correctly the first time they get through the compiler.

But a lot of programmers consider the specification of types everywhere 
to be tedious and boring.  So we get languages with dynamic typing.
They provide the security that makes debugging easy, but type failures 
are detected only at run-time, in a hit-or-miss fashion, and in a 
context where it can be difficult to track down the ultimate actual 
error.

Dynamically typed languages also tend to be easier to implement, 
especially when they're interpretive.

To do static checking properly requires a fair amount of logical 
superstructure.  It is not enough, for example, for a function to be 
known as a value.  It has to be known as a function, and moreover, a 
function that accepts arguments of specific types and returns values of 
specific types.  Those types may themselves be complicated in the same 
way.  And that doesn't even begin to describe the subtleties involved 
with type parameters.

In the dynamic-types scenario, all that has to be done to check this 
statically is nothing (it's just not done).  When the function is 
called, the caller checks that the thing being called is a function 
at run time, and the function istelf can check whether it has the right 
number of arguments, and it doesn't even matter if they're the right 
kind of arguments - that will get checked somewhere within the function 
if they're ever used for anything.

Ease of implementation is, I think, the main real advantage of dynamic 
typing -- it enables you to get to market faster -- and that's 
important.

Ease of coding is an illusion -- what you gain in coding speed you lose 
in debugging -- but it's a seductive illusion.

And, just to make it clear, C and C++ appear to have static typing, but 
it doesn't accomplish the task it ought to, so the effort expended on 
it is somewhat wasted.  With no bounds checks, with no safe storage 
management, you can still get indebuggable messes.  Static checking is 
useful only if it is an accurate description of the run-time state.

Even in C and C++. static types can still indicate the programmer's 
intent, so they are useful for documentation.  They can check that this 
documented behaviour is consistent, which is helpful.  But they cannot 
check that the documented type behaviour is consistent with run-time 
bahaviour, which is what matters.

I can well see the advantages of run-time typed languages over languages 
that appear to do static-checking but actually commit dynamic 
self-sabotage.  That's the advantage of *any* rigourously typed language 
over unimaginable chaos.  And because a problem-specific secure 
run-time-typed language has a shorter time-to-market, it can take over 
while the developers are still working out the details of a 
correspondingly statically-typed language.

But, speaking as a programmer that has to ensure that my systems work 
correctly, I far prefer to use secure languages that perform their type 
checking statically.

-- hendrik