does D already have too many language features ?

H. S. Teoh hsteoh at quickfur.ath.cx
Tue Dec 31 00:39:01 UTC 2019


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


More information about the Digitalmars-d mailing list