On Sunday, 13 March 2016 at 13:02:16 UTC, Bastien wrote:
Hi, apologies for what may be a fairly obvious question to some.
## The background:
I have been tasked with building software to process data
output by scientific instruments for non-experts - basically
with GUI, menus, easy config files (JSON or similar) - and the
ability to do some serious number crunching.
My background is python/octave and would be happy building it
in python (or god forbid, even octave), but it would end up
clunky and slow once ported to a standalone executable. Hence
why I'm looking at other languages. D caught my eye.
## The problem:
The sticking point is unless I commit the rest of my life to
maintaining this software, I can't write it all in D. The
algorithms change/are improved yearly; the output format from
the instrument changes once in a while and therefore these need
to be easily scripted/modified by other (non-programming)
scientists and the community that only really know python and
octave.
Essentially I'd like a D front end, and a D back-end that does
most of the memory and data management but calls and interprets
.py, .m and/or .jl scripts (python, matlab, julia) to know how
to treat the data. This leaves the py/m/jl scripts visible to
be edited by the end user.
## The question:
Can it be done?
Does this entirely defeat the point of using D and I should
just code it in python because of the added overheads?
Thanks for your help!
B
I don't have much experience in mixing python and D but here's my
take on it:
D is a great language but it's not a great glue language. I know
of no
binding to Julia but good bindings to python exist (pyd as said
above).
However, if what you want to keep in python is the algorithms
themselves then
I don't see the point. If I were to mix the two languages I'd use
python to
do the user interface, some module interface in order to link the
tool to
others maybe, but the algorithm would definitely be the one thing
I would do
in D because that's what D is for.