On Sunday, 13 March 2016 at 18:12:07 UTC, cym13 wrote:
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.
Thanks for all the very useful replies!
Overall seems that D on its own may be better. May not be such a
bad thing in the end if it moves the scientists away from
commerical matlab and the great python 2/3 schism.
I guess my resilience to using D for the algorithms is because
with python, I have access to numpy and matplotlib. There do seem
to be some ongoing developments though:
http://forum.dlang.org/post/mailman.4923.1434903477.7663.digitalmar...@puremagic.com
So maybe that will all change. I've just ordered a couple books
which will hopefully give me a bit more insight into the
feasibility of this project. Otherwise, I'll fall back on
python...
