https://forum.dlang.org/post/teubgxjtrlzpstvgwtwu@forum.dlang.org

On Monday, 8 April 2019 at 09:46:06 UTC, adam77 wrote:
> Hello everyone,
>
> I started using D as an alternative to Java, what attracted me to D was the robust memory management (including the way arrays are handled), and interoperability with C (specifically libraries) so far so good, but almost every language out there (maybe with the exception of C) seems the eschew language stability in favour of adopting whatever the latest fad is in programming languages features. I see on forums for a number of languages how features like lambda's or auto properties are essential to their language or if they are missing some feature how it is a major detriment to the language. I sometimes wonder how a Turing machine could ever manage...
>
> I'd be interested to hear other peoples opinion, does the language has enough features? is it already overloaded with features?
>
> Any help will be appreciated!


The features set of D is perfect. It makes D the mother of language IMHO.
What I think the community is should focus on is:
(1)My D app file size should be base on the feature uses. D should be modularized just like the current java 13
(2)Each feature should be fully baked. I mean it should it up to its purpose.

With more effort D could use all java, C#, Python, C++ in addition to C libraries. This is huge for D. I think of D as one language to rule them all

Let nobody move the motion of removing from D it is not to the advantage of D at all.

On Mon, Dec 30, 2019 at 11:59:27PM +0000, GreatSam4sure via Digitalmars-d wrote: [...]
> The features set of D is perfect. It makes D the mother of language IMHO.  What I think the community is should focus on is:
>
> (1)My D app file size should be base on the feature uses. D should be modularized just like the current java 13

+1, pay-as-you-go.  I've been wanting this for a while now.

Keep in mind, though, that using LDC with --gc-sections *does* in fact trim the fat down significantly.  Only thing is, you need to be careful in how you configure it, and some code may break if they implicitly assume the existence of certain sections that aren't referred to directly (such code should be very rare, though, and whoever would write such code probably already knows not to use --gc-sections so it shouldn't be an actual problem in practice).

I've tried this with dynamic libraries created for Android before, and it works like a charm (~1.3 MB bloated .so --> 400+ KB with --gc-sections and a custom linker configuration file -- and this is *with* a significant amount of Phobos usage, so we're not talking about straitjacketing yourself with -betterC here).


> (2)Each feature should be fully baked. I mean it should it up to its
> purpose.

I find myself wishing the same thing too, esp. when two features, when used together, interact (break :-P) in unexpected ways.  Most recent example: Grapheme[] interacts badly with .map.

OTOH, because D has so many features that have complex interactions, it's almost unavoidable to have some combination of features that nobody has put to use together before, or they haven't used it thoroughly enough to uncover the problem spots.  The only thing I can propose here is, please file all such bugs to bugzilla so that they don't get forgotten.  Maybe somebody should come up with a fuzzer specially geared for finding problematic combinations of features (seems hard to do, though, since it's not obvious how a set of randomly-picked features "ought" to interact and what the results should be, so you can't exactly automate such a thing).


> With more effort D could use all java, C#, Python, C++ in addition to C libraries. This is huge for D. I think of D as one language to rule them all
[...]

Have you seen Adam Ruppe's latest jni.d?  Barring some current limitations, it lets you interoperate D code with Java via JNI almost in a transparent way.  The fact that this is possible at all is absolutely amazing, and a testament to D's awesomeness, and I hope sometime in 2020 Adam will come up with a way to solve the remaining issues so that jni.d can become a general solution to D <-> Java interop.  Just think of the huge amounts of Java class libraries that can be made available to D at the press of a button.  This is HUGE.


T

-- 
A computer doesn't mind if its programs are put to purposes that don't match their names. -- D. Knuth

On Tuesday, 31 December 2019 at 00:39:01 UTC, H. S. Teoh wrote:
> Just think of the huge amounts of Java class libraries that can be made available to D at the press of a button.

BTW at this very moment I am writing a .class and .jar auto-converter to my jni interfacer...

On Tue, Dec 31, 2019 at 01:02:05AM +0000, Adam D. Ruppe via Digitalmars-d wrote:
> On Tuesday, 31 December 2019 at 00:39:01 UTC, H. S. Teoh wrote:
> > Just think of the huge amounts of Java class libraries that can be made available to D at the press of a button.
> 
> BTW at this very moment I am writing a .class and .jar auto-converter to my jni interfacer...

This is super-awesome stuff, dude. I imagine that, even given the current limitations of jni.d, a large number of class libraries ought to be usable already.

Writing D code for Android just got taken to a whole new level: now interfacing with the built-in Android GUI APIs just became so easy.  I'm anticipating that when I have time to work on my Android project again I'll be taking advantage of this much more than I'd been able to in the past.


T

-- 
Notwithstanding the eloquent discontent that you have just respectfully expressed at length against my verbal capabilities, I am afraid that I must unfortunately bring it to your attention that I am, in fact, NOT verbose.

On Tuesday, 31 December 2019 at 00:39:01 UTC, H. S. Teoh wrote:
> On Mon, Dec 30, 2019 at 11:59:27PM +0000, GreatSam4sure via Digitalmars-d wrote: [...]
>> [...]
>
> +1, pay-as-you-go.  I've been wanting this for a while now.
>
> Keep in mind, though, that using LDC with --gc-sections *does* in fact trim the fat down significantly.  Only thing is, you need to be careful in how you configure it, and some code may break if they implicitly assume the existence of certain sections that aren't referred to directly (such code should be very rare, though, and whoever would write such code probably already knows not to use --gc-sections so it shouldn't be an actual problem in practice).
>
> I've tried this with dynamic libraries created for Android before, and it works like a charm (~1.3 MB bloated .so --> 400+ KB with --gc-sections and a custom linker configuration file -- and this is *with* a significant amount of Phobos usage, so we're not talking about straitjacketing yourself with -betterC here).
>
>
>> [...]
>
> I find myself wishing the same thing too, esp. when two features, when used together, interact (break :-P) in unexpected ways.  Most recent example: Grapheme[] interacts badly with .map.
>
> OTOH, because D has so many features that have complex interactions, it's almost unavoidable to have some combination of features that nobody has put to use together before, or they haven't used it thoroughly enough to uncover the problem spots.
>  The only thing I can propose here is, please file all such bugs to bugzilla so that they don't get forgotten.  Maybe somebody should come up with a fuzzer specially geared for finding problematic combinations of features (seems hard to do, though, since it's not obvious how a set of randomly-picked features "ought" to interact and what the results should be, so you can't exactly automate such a thing).
>
>
>> [...]
> [...]
>
> Have you seen Adam Ruppe's latest jni.d?  Barring some current limitations, it lets you interoperate D code with Java via JNI almost in a transparent way.  The fact that this is possible at all is absolutely amazing, and a testament to D's awesomeness, and I hope sometime in 2020 Adam will come up with a way to solve the remaining issues so that jni.d can become a general solution to D <-> Java interop.  Just think of the huge amounts of Java class libraries that can be made available to D at the press of a button.  This is HUGE.
>
>
> T

Thanks for your patient and detail explanation for the issue at hand.

The feature set of D is thoroughly awesome. I am amazed at how a language of these feature sets can be simple to write, precise and we'll readable with the raw power of C and C++. I am hoping that the D community we know that they have a beautiful language in there and maximize it to their language.

D is well ahead of most languages with great publicity out there. What D need is through polishing not triming.

I am aware of Adam JNI but I have not really understand how to apply it. I have ask for tutorial he is yet to reply

On Tuesday, 31 December 2019 at 01:02:05 UTC, Adam D. Ruppe wrote:
> On Tuesday, 31 December 2019 at 00:39:01 UTC, H. S. Teoh wrote:
>> Just think of the huge amounts of Java class libraries that can be made available to D at the press of a button.
>
> BTW at this very moment I am writing a .class and .jar auto-converter to my jni interfacer...

This is probably great stuff. having used JNI for Java to C++ interface, it was very cumbersome and needed to write a lot of trampoline functions.