Scientific computing and parallel computing C++23/C++26

H. S. Teoh hsteoh at
Tue Jan 18 21:22:11 UTC 2022

On Tue, Jan 18, 2022 at 08:28:52PM +0000, bachmeier via Digitalmars-d wrote:
> On Tuesday, 18 January 2022 at 17:03:33 UTC, sfp wrote:
> > You must also consider that the items that bioinfornatics listed are
> > all somewhat contingent on each other. In isolation they aren't
> > nearly as useful. You might have a numpy/scipy clone, but if you
> > don't also have a matplotlib clone (or some other means of doing
> > data visualization from D) their utility is a bit limited.
> To my knowledge pyd still works. There's not much to be gained from
> rewriting a plotting library from scratch. It's not common that you're
> plotting 100 million times for each run of your program.
> I see too much NIH syndrome here. If you can call another language,
> all you need to do is write convenience wrappers on top of the many
> thousands of hours of work done in that language. You can replace the
> pieces where it makes sense to do so. The goal of the D program is
> whatever analysis you're doing on top of those libraries, not the
> libraries themselves.

+1.  Why do we need to reinvent numpy/scipy? One of the advantages
conferred by D's metaprogramming capabilities is easier integration with
other languages.  Adam Ruppe's jni.d is one prime example of how
metaprogramming can abstract away the nasty amounts of boilerplate
you're otherwise forced to write when interfacing with Java via JNI. D's
C ABI compatibility also means you can leverage the tons of C libraries
out there right now, instead of waiting for somebody to reinvent the
same libraries in D years down the road.  D's capabilities makes it very
amenable to being a "glue" language for interfacing with other


Caffeine underflow. Brain dumped.

More information about the Digitalmars-d mailing list