Andrei:
> Conversely, I wonder how we can improve the dynamic typing capabilities of D.
On the Lambda the Ultimate blog I have found few interesting comments about
dynamic typing (all the text below are quotations):
Dim objDoc
objDoc = CreateObject("Word.Application")
objDoc.Open(strFilename)
That's enough VBScript. The point here is that different versions of Word have
different signatures for the "Open" method (the number of parameters increases
with each successive version). If the parameters are "optional", then VBScript
lets you get away with not supplying them; all bar the first parameter are
optional. There is no common interface or base class that all the different
versions share. So if we were writing the above in C#, we would have to do one
of two things:
1. Simulate dynamic dispatch via reflection, or
2. Write adaptor classes for each of the different versions of Word we might
find on the target system.
[...]
Frank goes a bridge too far when he says "Static typing is superior to dynamic
typing in every way". Indeed it is superior, but only asympotically, for
software big enough. For tiny scripts, there is little advantage to justify
typing more letters.
About VBScript example: how about a static-typed language bundled with library
which is equally powerful as VBScript library. So we could type with a few
additional keystrokes:
COMObj objDoc = COMObj.create("Word.Application");
objDoc.invoke("Open", new COMData[] { new COMString(strFilename) };
Alas, the world is not so easy. What good are static types for OLE Automation?
After all it is a dynamic typed invocation, so using it annihilates all the
advantages of static typing (unless you have some additional type info).
Similarly is with SQL (dynamic typed), XML (dynamic typed mostly), and most of
external technologies -- even if they are statically typed, their type system
is incompatible with yours or at least type info is unavailable at compile time.
Therefore, when writing pieces of code which merely glues together some
external technologies (and certainly over 95% software produced falls into this
category), static typing is badly hindered. But if your software really does
something on its own, static type system is your friend.
--------------
There you go again. I think using the term "relax" to talk about increasing
the expressivity of typing is exactly the wrong way to think about it. It's not
about relaxing type systems so we can annotate more untyped programs; it's
about making type systems more rigorous so we can express more dynamic
behaviors.
That's precisely one of the points of disagreement. You're taking the above
point as an article of faith, since you can't point to a type system that
provides all the capabilities of dynamically-checked languages, including e.g.
runtime evolvability. I'm not saying you're wrong, necessarily - but how many
years will it be before you can demonstrate that you're right, with an actual
language?
The more you relax something, the less you can say about it.
Exactly. And that's a feature - when you're prototyping, for example, or when
you're developing a system whose specification is evolving as you develop it,
and there are many aspects of the system that you can't say much about. You
earlier mentioned the idea of types as a skeleton for an application - well, in
the real world, having an application's skeleton be very flexible, even weakly
defined, can be an enormous asset!
The idea that more rigour is better is simply one of perspective - it doesn't
apply in all situations. While you're figuring out how to statically type the
universe, people have real projects to get done, and if we want them to take
advantage of better type systems, more relaxed type systems are one of the
things that are going to be needed.
Take a look at the holes in the Java and C++ type systems - some of them are
there for a reason. Upcasting and downcasting etc. are not necessarily things
to be eliminated, they're features! However, the rest of those type systems
could presumably be done better. And you could probably usefully add more holes
into those type systems to produce useful languages.
The problem with what I'm saying is that there are certainly no end of
applications for which more rigour is better, and with the predilections of
academics such as yourself, that's what's going to get focused on, and you'll
be able to point to high-tech applications and say "see?" But then you
shouldn't be surprised when this stuff doesn't translate into the mainstream -
it's because it's not delivering some of the features that count in those
contexts.
Bye,
bearophile
