On 2010-12-27 18:58, bearophile wrote:
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.
[...]
C# 4 has a keyword "dynamic" that will resolve the type and any call on
that variable during runtime instead of compile time. C# 4 also has
default arguments and named arguments just to be able to solve to
problem you mention above.
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
--
/Jacob Carlborg
