Re: Rather, DSSLs increase modularity, productivity

[Michael Vanier <address@hidden>]

> Date: Mon, 17 Nov 2003 02:08:02 +0100
> From: David Lichteblau <david@lichteblau.com>
> 
> Quoting Michael Vanier (mvanier@cs.caltech.edu):
> > The only examples of this I've seen that are reasonably compelling are
> > common lisp and Dylan, the latter having been designed explicitly to allow
> > two universes to cooperate.
> 
> Which two universes are that?

The universe of the scripting language and the universe of the
non-scripting language.  In Dylan, the difference is blurry to
non-existent.  "Script" code is just regular code without type annotations,
whereas "non-script" code has those annotations.

Incidentally, I think the pain of writing type annotations is grossly
exaggerated.  I think it gets associated with several other unrelated
features:

1) An explicit edit-compile-link-run-crash-debug mode of programming.

2) Unsafe languages that permit e.g. direct pointer manipulations and have
   no array bounds checking etc.

Java, whatever else one might say about it, has removed item (2) from
consideration for most programmers.  Item (1) is still a factor, and I must
say I prefer a more interactive programming environment than java usually
provides.  But that has little to do with type systems, I think.

What *is* valid is that type systems usually bring along serious
restrictions on what can be expressed.  That's cause for concern if your
application needs extreme dynamism.  If it doesn't, then not having a type
system is often more of a negative than a positive.  Still, as Matthias has
suggested, I think that there is lots of interesting work that can be done
on making dynamic languages more statically checkable when you know that a
certain argument (for instance) should be of a certain type.

If I look at all the python scripts I've written, nearly ALL of them could
have been written in a statically-typed language.  Python is extremely
dynamic, but I've rarely needed to use that power.  But that's just my
experience.

Mike