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

On Friday, 27 September 2024 at 19:15:36 UTC, H. S. Teoh wrote:
> Quick prototyping of programs
The runnable unit-tests in the docs make exploration of the stdlib very fast. This is almost ten percent as good as a REPL, which is much better than what most compiled languages offer.

> I'd say the small- to medium-sized application zone is where D excels the most at.
It definitely has some competitive advantages that are most apparent in this zone.
Some small nits that would help here:
Integrated unittests already help a lot, but I wish one of the popular unittest frameworks were included in the stdlib to make it zero-friction.
Tuples and sumtypes are important QoL features that are missing for me that would reduce boilerplate and increase expressiveness for the straightforward data-transformation programs.