Slightly off the wall question about D strategy . . .

[retard]

Wed, 13 Oct 2010 19:25:35 +0100, Russel Winder wrote:

> The standard paradigm increasingly in the HPC and large embedded systems
> spheres is to have C and C++ application code coordinated and tested
> using Python.  Also the post-production community have C and C++
> applications but use Python for plugins and other dynamic code
> requirements.  Some games people have gone with Lua rather Python, as
> has one notable graphics software company.
> 
> Is this dynamic/static synthesis something D should embrace and
> therefore get bindings for (D able to call into Python and Python able
> to call D -- cf. ctypes package in Python) or is it seeking to try and
> replace the whole shebang.  If the latter then perhaps there needs to be
> a strategy to support data visualization (which is what the Python ends
> up doing in HPC), extend the unit testing stuff to integration and
> acceptance testing and have an easy way to handle dynamically loaded
> code.
> 
> (I know some of this exists already, but I haven't been able to
> investigate to a deep enough level as yet.)
> 
> (I should point out that currently I am approaching all this from a
> Python perspective, i.e. that C and C++ is the language you descend to
> when Python is insufficiently performant :-)

FWIW, this static/dynamic coexistence is becoming a reality also on JVM/
CLR. I think both C# 4.0 and Java 7 have these dynamic features and JVM 7 
has better support for dynamic languages. It's really hard to believe D 
will replace all these languages with a single solution. The flexibility 
of duck typing combined with homoiconicity and compact syntax is 
something projects like DDL can't compete with.