On Sunday, 15 May 2022 at 03:52:28 UTC, Mike Parker wrote:
> On Sunday, 15 May 2022 at 03:02:24 UTC, forkit wrote:
>
>>
>> Integrating a library whose code you're not well versed in, seems like a recipe for disaster.
>>
>
> Then how do you ever use any libraries?

Getting it wrong in software has always had consequences, sometimes really bad consequences. But since software now operates in entirely new spheres that affect all aspects of our life and economy, developers have a wider obligation that just stitching together software so that it works.

Structured higher-level languages is where we need to be moving towards, not moving backwards to low-level languages like C.

Also, operating systems of the (near) future will require safety guarantees from the software that is intended to run on that operating system. C is not a language that facilitates this.

I understand the appeal of making it easier to use C libraries in a otherwise D solution. But that does not progress or advance the nature of software development, and the responsibility programmers have to their clients.

I was (initially) attracted to D because of how it advanced the problem of writing safe code (particulary @safe). This is what would make D 'popular'.

But ImportC is short-sighted in my opinion, and is a step in the opposite direction.

The focus should instead be on @safe, not C.

On Sunday, 15 May 2022 at 06:18:58 UTC, forkit wrote:

>
> But ImportC is short-sighted in my opinion, and is a step in the opposite direction.

Like it or not, C libraries are a critical part of the D ecosystem. They fill in the gaps. C interop is also important for integrating D into existing code bases. ImportC improves D's interop by making it part of the out-of-the-box experience. It's something we should have had long ago.

>
> The focus should instead be on @safe, not C.

Memory safety is very much in focus. While Walter is working on ImportC, Atila has been focused on setting the stage to enable DIP 1000 by default. Dennis Korpel has overseen the squashing of several DIP 1000 bugs. There will be more work on shoring up memory safety features going forward.

On Sunday, 15 May 2022 at 07:06:46 UTC, Ola Fosheim Grøstad wrote:
> ...
> ....
> Most software is not critical, but in this case you are worse off by hand translating a header file which is more error prone.
> ...

Umm..a part of that statement is not correct.

Most software (in fact) runs things that are critical to our everyday lives (both personally and economically).

A such, the focus really should be on creating safer programming languages, and enabling developers to write safer software, that is less prone to bugs and attacks.

D's new focus on encouraging even more C into D projects, is not something that should be getting underway in the year 2022.

I perfectly understand, that those who want to such a thing, will have different opinion ;-)

On Sunday, 15 May 2022 at 07:13:34 UTC, Mike Parker wrote:
> ..
> ...
> Memory safety is very much in focus. While Walter is working on ImportC, Atila has been focused on setting the stage to enable DIP 1000 by default. Dennis Korpel has overseen the squashing of several DIP 1000 bugs. There will be more work on shoring up memory safety features going forward.

That's nice to hear.

I'd much rather people coming over to D, were doing so, because they want to write safer software, rather than wanting to stitch together new solutions using their old C code (which they've been able to do, with C++, for decades now - and look where that got us).

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!

On Sun, May 15, 2022 at 03:02:24AM +0000, forkit via Digitalmars-d wrote:
> On Sunday, 15 May 2022 at 02:38:12 UTC, Mike Parker wrote:
> > On Sunday, 15 May 2022 at 02:30:52 UTC, forkit wrote:
> > 
> > > Who has the time to be (continually) well-versed in both D and C?
> > 
> > That's kind of the point. With ImportC, you don't *have* to be well-versed in C if you need to use a C library.
> 
> Integrating a library whose code you're not well versed in, seems like a recipe for disaster.
[...]

So you'd rather reinvent every C library out there that you need for your project, just because it's not written in D?  Pretty much every OS API out there is, under the hood, written in C.  Would you reinvent your own OS too, just because existing OSes aren't written in D?

If I were deciding whether to start a new project and my choices are (1) use an existing C library that provides a critical part of the functionality I need, vs. (2) rewrite said C library from scratch because it's not written in D, guess which option I'm gonna choose. And guess which option is going to keep my business going, as opposed to sinking my project in the amount of resources/programmer time needed to write it from scratch.

I mean, I admire your ideals, but you can't just start from zero every time.  You wouldn't be able to fly past your own backyard that way. *Somewhere* along the line you have to stand on the shoulders of existing technology and take off from there, rather than reinventing fire with sticks and stones just because whoever originally discovered fire didn't use D to do it.


T

-- 
Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald Knuth