www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - does D already have too many language features ?

reply GreatSam4sure <greatsam4sure gmail.com> writes:
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.


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.
Dec 30 2019
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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).




 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
Dec 30 2019
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
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...
Dec 30 2019
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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.
Dec 30 2019
prev sibling parent Guillaume Piolat <first.last gmail.com> writes:
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.
Jan 01 2020
prev sibling parent GreatSam4sure <greatsam4sure gmail.com> writes:
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
Dec 31 2019