I agree with you. I use D for complex economic calculations that are run from a
web site. The great part about D is that other people in the company can easily
read the code and it is fast enough for what I need to do. I ported a few ATLAS
C functions and wrapped them with a class, offering high speed matrix
calculations with excellent usability. Not many other languages allow for this.
JC
Lars Kyllingstad wrote:
I think D is, or at least could be, the scientific programming language
of the future. Here's why -- and possibly how:
A couple of years ago, I took a university class called Numerical
Physics. After finishing the course, I was left with the impression that
numerical computing was all about squeezing every last bit of
performance out of the computer -- that unnecessary operations and
function calls should be avoided at any cost, even if the resulting code
is full of nasty hacks and tricks, making it completely illegible and
utterly unmaintainable. And of course, in many cases this is true.
Now, however, I have a bit more experience in the field and I know that
it is not always so. In numerics, as in other areas of programming, it
is a trade-off between development time and execution time.
Traditionally, if one has a desperate need for speed (sorry), one uses
FORTRAN, C or C++. The programs run very fast, but can be hard to
develop, debug and maintain. For less processor-intensive tasks one uses
Matlab, Mathematica, etc. which have a lot of built-in functionality and
make for rapid development, but programs run at a snail's pace.
With D one has the best of both worlds. I've used both C++ and
Mathematica for numerics in the past, but now I use D almost
exclusively. I find it a lot easier (and more fun) to code in than C++,
and I spend a LOT less time debugging my programs. On the other hand,
calculations that would take an entire day in Mathematica are finished
in a matter of minutes using D.
It's a fact that D programs don't have the performance of C(++) ones,
but that, I think, is just a matter of time (pun not intended). It's a
relatively new language, and the compilers are still somewhat immature.
The one thing I miss the most, however, and which I think is necessary
for D to "take off" as a scientific language, is a native D scientific
library.
Searching dsource, I find that many nice modules and libraries have been
made already:
- MultiArray (Bill, Fawzi)
- dstat (dsimcha)
- blip (Fawzi)
- MathExtra, BLADE (Don)
- Scrapple/backmath (BCS)
- Scrapple/units (BCS)
- bindings to GSL, BLAS, etc.
- ...and probably more
Myself, I've written/ported some routines for numerical differentiation
and integration, one- and multi-dimensional root-finding and some very
basic linear algebra, but so far only for personal use. Currently, I'm
thinking of porting QUADPACK to D.
I think it would be really nice if many or all of the above mentioned
things could be collected in a single library, together with all kinds
of other stuff. Something like the GSL, only written in D. (In my head
it's called SciD. At first I thought of DSL - D Scientific Library - but
that acronym is used all over the place.) I haven't the time, nor the
skills, to write an entire such library myself, but I'd be happy to
contribute where I can.
Here are some design goals I find important:
- sensible, logical and tidy package hierarchy
- access to high-level functionality for rapid development
- access to low-level functionality for performance
- make use of D's awesome compile-time functionality
- reusability, pluggability and extensibility
(By the last point I mean that if one method doesn't work it should be
quickly and easily replaceable in code with something else. This is
achievable through the use of templates and interfaces, and ties in with
the second point.)
So, what do you think? Am I making any sense? Am I the only one
interested in these things?
All of the above are, of course, my personal opinions. What are yours?
-Lars
