Top 3 use cases for D

[H. S. Teoh]

On Fri, Sep 27, 2024 at 06:49:27PM +0000, Imperatorn via Digitalmars-d wrote:
> In your opinion, what is the selling point of D, the top 3 use cases
> where D would be a nice fit?

The top selling point of D for me is that it's easy to write working
code in D.  My typical development times are much shorter in D compared
with equivalent code in C/C++/Java.  D also has very nice built-in
features, like unittests, which in spite of whatever warts they may have
make it easy to develop correct, working code.  In C/C++ I'd have to
spend inordinate amounts of time debugging the code after writing it,
and in other languages I'd have to resort to external test frameworks,
which add to the inertia of being too lazy to actually do it.

My current actual (not hypothetical!) use cases for D are:

- A handy shell-script replacement that has none of the shell's
  irritating points (like greedy string interpolation, that leads to
  needless fragility and Leaning Toothpick Syndrome, plus I can get
  parallization almost for free with almost no effort).

- Quick prototyping of programs that do complex computations -- because
  D has so many boilerplate-reducing features that makes it possible to
  try out new ideas quickly without drowning in boilerplate (like Java
  is wont to do).  Many of these prototypes can be easily turned into
  real applications relatively painlessly -- because D is just so
  flexible that refactoring is almost always a breeze. Built-in
  unittests ensure refactorings don't introduce too many breakages in
  the transition.

- Workhorse programs that I use repeatedly: because D's features make
  maintenance relatively easy, and adding new features often doesn't
  require major refactorings like the equivalent C/C++ projects often
  require IME.


> D has struggled to find a niche (because it's so flexible?), but is
> that also why it hasn't seen wider adoption?

I'd say the small- to medium-sized application zone is where D excels
the most at.  For larger applications I can't really say, haven't had
too much experience in that area, but based on what I know, in a larger
application that may depend on external libraries, finding said
libraries may be a problem.  I generally have to resort to writing my
own wrappers for C APIs to call external libraries with.  It's workable,
but maintenance is a bit of a pain when the external APIs change.


> What do you think are the top 3 places where you think "I could use D
> here instead of {language} because {reasons}"?

I'm already using D instead of shell scripts, because D is just so much
better at dealing with data manipulations than hacking the equivalent
functionality with sed, awk, grep, and expr.

I'm also using D instead of Perl scripts these days, because Perl is
just not very maintainable once you get past a certain level of
complexity (which is not very high).

And I'm definitely using D instead of C/C++ in my personal projects,
because it just takes far too much effort to implement things in C/C++
and afterwards it takes far too much effort to debug.  In spite of its
warts, D does much better in this area IME than C/C++.

//

Having said that, though, I'm still hesitant to introduce my
C/C++-minded colleagues to D, because their first reaction would be
GC-phobia, and their second reaction would be "who uses this unknown
language?", and their third reaction would be "are you sure we want
company products to depend on such a small unknown team?".  I've no
interest in participating in this fashion show, so I'm not even going to
bother.

On the more technical side, things like shared, which "does what it's
designed to do" but nevertheless obviously screams "incomplete solution"
to an outsider, or dip1000 that nobody can explain in 2 sentences before
would-be adopters glaze over in their eyes, or the absence of read/write
barriers that would have given us a modern, generational GC instead of
the conservative compromise we have today -- these just don't look good
to a newcomer.  And the attribute soup looks scarier and scarier every
time we attempt to fix it.  Plus a ton of peripheral half-baked features
that were never completed, or were completed but don't present a
comprehensive solution, I honestly wouldn't know how to answer if
someone asked me "why has feature X been like this for Y many years, and
what are you guys doing about it?".


T

-- 
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird. -- D. Knuth