Why is D unpopular?

[H. S. Teoh]

On Sun, May 15, 2022 at 02:30:52AM +0000, forkit via Digitalmars-d wrote:
[...]
> Modern programming languages should be encouraging a move away from C
> (and providing the means to do so), and not encouraging a move towards
> C.

I think it's a matter of perspective.  I don't see ImportC as
encouraging a move towards C; if somebody wanted to move towards C, D
would be last thing he would be looking at. :-P  Rather, I see ImportC
as a way for current C programmers to move *away* from C --
incrementally. You can start writing parts of your code in D without
needing to rewrite your existing C code, and gradually migrate away from
C as you go along.

Nobody has the time and/or resources to reengineer an entire C project
in D in one shot.  ImportC serves as a smooth off-ramp to get off C and
start writing D.


> My real concern though (and in relation to the topic of this thread),
> is that ImportC will actually make D even less popular.

Why would ImportC make D less popular?  If anything, it would make D
*more* popular, because now if you have some project that depends on an
existing C library (and let's face it, D's ecosystem is *nowhere* near
replacing the entire C ecosystem, which pervades pretty much every
corner of the programming landscape as the lingua franca of OS APIs, and
the future where C is completely supplanted for OS APIs is nowhere in
sight yet), you can now write your code in D and have no worries about
integrating with the C library.  Whereas without ImportC you have to
jump through additional hoops to do so.  Which equals more friction,
which equals less inclination for people to start using D.


> Who has the time to be (continually) well-versed in both D and C?

Why would you need to be well-versed in C just because D provides a way
for you to smoothly integrate with existing C libraries?  By the same
logic, you might as well say `extern(C)` is a bad idea because now
people reading D code has to be well-versed in C, and we should kill off
`extern(C)` completely and make D an isolated walled garden that only
interacts with other D code and nothing else.

The reality is that you'd just treat ImportC the same way as extern(C):
black-box interfaces to OS APIs and foreign language libraries.

I wrote quite a lot of D code that uses C libraries -- libfreetype,
libxcb, libmpfr, to name a few.  If D didn't have an easy way to
interface with libfreetype, for example, my project would never have
gotten off the ground.  In fact, I'd have been motivated to write more C
code instead.  There is no way I'm gonna waste my time/energy to
reinvent libfreetype just because it happens to be written in C rather
than D.  Life is too short to be reinventing square wheels at every
single turn.

As it stands, it took a bit of effort to make it work -- thankfully I
use a sane build system (cough) so it wasn't a big problem, but I *did*
have to spend the time to hand-port some libfreetype prototypes into D
extern(C) declarations, and do the trick with cpp to auto-generate error
message strings from one of libfreetype's headers.  Now if ImportC had
been at the high level of integration (that we're still working
towards), I wouldn't have needed to put in this effort -- I'd have just
written `import freetype.freetype;` and went on with my business. *That*
would have given me MUCH more motivation to write D code. Truth is, I
balked at using libfreetype for a period of time because of the
anticipated effort needed to interface with it. Ultimately I decided to
go ahead -- thanks to D's relatively easy integration with C.  But had
`import freetype.freetype;` Just Worked(tm) at that time, I wouldn't
even have hesitated in the first place.

TL;DR: if ImportC had been done 10 years ago, I'd have had MORE
motivation to write more D code, not less.  And if interfacing D with C
had been harder than it was, I'd have been motivated to write my project
in C rather than D (or just decided not to start the project in the
first place).


T

-- 
IBM = I'll Buy Microsoft!