D vs C++

[bearophile]

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