My Long Term Vision for the D programming language

Robert Schadek rburners at gmail.com
Wed Nov 17 07:33:03 UTC 2021


On Tuesday, 16 November 2021 at 22:46:24 UTC, bachmeier wrote:
>> Batteries included, all of them, even the small flat strange 
>> ones.
>
> I agree. But only if the batteries are high quality (bug-free) 
> and high quality (make it easy to do the important tasks). 
> Otherwise it's better to leave them as third-party libraries 
> that are simple to add to your project.

No, nothing is every bug-free. Having stuff in code.dlang reduces
visibility of the thing, which reduces the number of people using 
it
with increases the number of bugs.
Please get me right, I'm not saying get any crap code into phobos,
but aiming for perfect will get us nothing, when aiming for good 
will
get us a lot.

>
> We don't want to promote it, but it does have an appeal to 
> current C programmers, who often prefer an updated version of C 
> to learning a new language.

Frankly, who cares the C programs are not graduating 12 week 
coding camps
these days they are retiring.
Consider, that at least for now, we have limited resources why 
waste them?

>
> It makes sense to publish preprocessed versions of popular C 
> libraries as Dub packages/standalone files that can be included 
> in D programs. This can, to some extent, be done with what we 
> already have.

Again, visibility and friction.

>
> Finally, on interop, there should also be support for R, 
> Matlab, Julia, and Fortran. D is a natural fit for data 
> processing. It also would not be that hard, since all of those 
> languages are designed to work easily with C libraries. And all 
> but Matlab (not sure about that one) are easy to call from D.

Fair enough, I didn't list all candidates as the *vision* was 
already quite long.
I think working on interop with different languages can be 
parallelized
quite well.




More information about the Digitalmars-d mailing list