www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Slightly off the wall question about D strategy . . .

reply Russel Winder <russel russel.org.uk> writes:
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 :-)

Thanks.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Oct 13 2010
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Russel Winder:


 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.


I think D needs to take more care of the needs of: GUI building, databases
usage, heavy numeric computing. All three will enjoy some syntax/semantics
support. The GUI may enjoy signals&slots and other bits, the HPC some ideas
from languages like Chapel and X10.



 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.


I think D wants to replace the whole group of languages. But I don't think it
will be able to replace that dynamic languages glue, so it will need to
interoperate. In D1 I have used a Python-D bridge named Pyd. When D2 is more
polished I presume someone will eventually try to port Pyd to D2 or to create
another similar tool.

Bye,
bearophile
Oct 13 2010
prev sibling next sibling parent retard <re tard.com.invalid> writes:
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/

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.
Oct 13 2010
prev sibling parent Jesse Phillips <jessekphillips+D gmail.com> writes:
Russel Winder Wrote:


 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.


D is aiming to be a systems and applications programming language. In the eyes
of many here, D makes static programming feel as easy as dynamic programming,
but what you are actually asking is whether D wishes to also replace embedded
languages.

The CLR/JVM are making improvements which increase performance of dynamic

advantage of communicating with dynamic languages by adding the 'dynamic' type.
And best I can tell D's 'variant' type is already a close second to it.

I think D as positioned well for accepting embedded languages. PyD[1] has done
some very nice stuff already in D1 and Python. And the Lua bindings[2] look to
integrate very nicely with D1 and D2. I haven't worked with either of these, so
I do not know their actually usability.

Personally I will probably be combining D and Lua in more of my projects.

1. http://pyd.dsource.org/
2. http://www.dsource.org/projects/luad/wiki
Oct 13 2010