On Friday, 29 May 2015 at 14:46:06 UTC, Ola Fosheim Grøstad wrote:
On Friday, 29 May 2015 at 14:22:58 UTC, Chris wrote:
However, for a constantly growing long-term code base, D is my
language of choice. It's clean (i.e. maintainable), flexible
(many ways to tackle new problems), easily unit-testable and,
of course, compiles to native machine code. It also interfaces
to C(++) which is very important.
Yes, C++ interfacing could prove important, if it can cover
>95% of C++ library interfaces.
Are you using D for a constantly growing long-term code base,
or planning to?
I've been using D for a long-term project for quite a while now.
There is no way a generic solution can beat a tailored
solution when it comes to abstract datatypes and memory
management, so having lots of options in a standard library
sounds useful.
Ugh, I said the opposite of what I meant. I don't think having
lots of allocation options in a standard library sounds all
that useful, since I will most likely roll my own when hitting
a serious performance problem. Rolling your own is often the
same amount of work as "searching for a narrow solution"
unless you are doing something really complicated.
I think many standard libraries could be cut down to the most
generally useful functionality. In C++ I use std::array or my
own data structures, I only occasionally use std::vector… In
Python I use no more than 5% of the standard library. Generally
useful solutions (like comprehensions) beats narrow solutions
99% of the time, because when you need something narrow then
the pre-canned narrow solutions often require hacks to serve
the purpose (the wrong kind of narrowness or "fits perfectly
except it doesn't work when…X…").
