On Sun, May 15, 2022 at 06:18:58AM +0000, forkit via Digitalmars-d wrote: [...]
> 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.

Making it easier to use C libraries actually *increases* the motivation to write @safe code.

Because, if I were to start a new project and I need to use a C library, then if it was too hard to interface D with that C library, it'd incentivize me to write the project in C instead. Net result: I write more unsafe code -- because it'd be in C.

OTOH, if it was easy to integrate that C library, I would be motivated to write D code instead.  Net result: I write more @safe code.  Sure it's not 100%, but that's still better than 0%.

There is, of course, the option of rewriting said C library in D. But that's a low-incentive option, because it requires a lot of time/effort, and is a net loss from a business POV (why reinvent functionality that already exists / increases time to market, which reduces competitiveness).  Depending on which library you're talking about, this cost could be very prohibitive.  Concrete example: text layout with something like Cairo.  There is NO WAY I'm gonna be able to reinvent the whole thing myself; that'd take me several lifetimes to pull off. (And believe me, I've tried. Text layout is an extremely convoluted and messy process, with tons of unexpected complexities in this day and age of internationalization and Unicode.  It's not something you can just reinvent in a fortnight; it took YEARS for existing solutions to be produced, and requires expertise you probably do not have (and would not have for years even if you were to start studying it now).  You can't just throw it all out the window because OMG it's not written in D so it's BAD!)

Which would you rather have -- more projects to be written in C because that's the only way you can leverage this existing technology, because it's too hard to use it from D; or more projects to be written in D because you can easily use a C library with minimum friction, so you actually *have* the option of writing it in D in the first place?


T

-- 
Живёшь только однажды.

On 5/15/2022 4:55 AM, H. S. Teoh wrote:
> There is, of course, the option of rewriting said C library in D.
In my experience, it is not an option to rewrite working C code into D.

Note that I have successfully converted small and medium C code projects to D. I've done other translations of programs from one language to another.

1. if you don't have a test suite for the program, a successful conversion becomes an order of magnitude harder

2. converting a program all at once does not work. It must be done incrementally, one function at a time

3. even so, when faced with a large, complex project, there's just no business case for doing a conversion

Even just converting the .h files to D can be a major, rather unpleasant undertaking. We've put a lot of time into converting the various system .h files into D for druntime. There's always a risk of a mistake, and we've made them and the result is bizarre crashes because of ABI mismatches. Hand-checking them is error-prone, tedious and very boring work.

ImportC makes things so much easier. You can write new D code and hook it up with your existing C code base. You can get reliable, easy, and accurate access to .h files. D will happily work with a project that's a patchwork of C and D code.

I.e. it dramatically lowers the barrier to adopting D.

As for languages other than C, they routinely have a C interface. ImportC makes it easy to hook up with them via the C interface they provide.

On 5/15/2022 4:25 AM, H. S. Teoh wrote:
> 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).

I made a big mistake not doing ImportC 15 years ago!