bearophile, let me reply to some of your quotations briefly.
I think those comments are directed toward older generation static
languages. D blows them out of the water. And surpasses older
dynamic languages, like Javascript, at the same time. Observe:
> So if we were writing [the Word open code] in C#, we would have
> to do one of two things [...]
Or 3) Use overloads or default parameters. Easy.
> COMObj objDoc = COMObj.create("Word.Application");
> objDoc.invoke("Open", new COMData[] { new COMString(strFilename) };
Gah, D could do the VBScript example literally using a variadic
template on opDispatch. It's dynamic, but the dynamicness is limited
to only the part of the program where it is needed.
(Note that I've actually done this. My web.d code lets you call
D functions by passing it a string[string] and my pretty.d from
my dmdscript d2 port allows you to call script objects from D
with a virtually identical syntax to calling them from inside
javascript itself.
My dom.d also uses opDispatch to allow easy access to XML
attributes, very similarly to how you do it from inside Javascript.
So this isn't an in-theory "could", this is something I use daily
in production. Interestingly, this is *easier* to do in D than
it is in Javascript too! Mozilla JS has something similar to
opDispatch, but the other implementations don't, so it can't often
be used in real world code...)
> Similarly is with SQL (dynamic typed)
With SQL, it is still advantageous to have a static type in some
areas (not all) to confirm you are actually getting what you need
to use. When I wrote Ruby, one of my biggest sources of bugs was
due to a SQL query not returning the type I was expecting. In D,
that's a simple compile error, not a runtime bug.
Dynamicness is sometimes good, but D lets it flow in pretty
easily where it belongs and keeps things sane everywhere else.
