Metaprogramming with D

[Ali Çehreli]

On 6/6/20 5:03 PM, FunkyD wrote:> On Saturday, 6 June 2020 at 09:57:36 
UTC, Jan Hönig wrote:

 > D is pretty good for meta-programming. For certain other things it is
 > terrible.

I am glad I don't know enough about other technologies to feel that way.

 > String mixins simply mix in D code. It lets you build generic D code.
 > The big problem here is debugging. There is ZERO ability to properly
 > debug string mixins.

"Zero" is too strong an assertion and because of the following, false:

   dmd -mixin=<filename> ...

 > Well, what it boils down to is writing out the
 > string mixin and then debugging that.

When I compile my program and there is an issue with a string mixin, 
Emacs opens the mixin file and shows me the compilation there. This is 
because dmd's error include the exact line in the <filename> where my 
mixin was broken. Not a shiny IDE but still pretty awesome support.

 > It would be nice if D had a special D code string that the IDE could
 > interpret properly.

I must be misunderstanding you but it must be an IDE limitation because 
of the following:

   writeln(q{
       void foo() {
       }
     });

My IDE gives me syntax highlighting in that string, so it works somehow.

 > D basically tries to resolve things after the fact so
 >
 > R add(T)(T a, T b)
 > {
 >      return a + b;
 > }
 >
 > this will attempt to + on a and b after the types are known. If they
 > can't be added then an error will occur, which is usually cryptic for
 > templates.

That's why we use template constraints and in some cases 'static assert' 
for custom error messages.

 > The issue in using D should not be made based on it's metaprogramming.

I agree. What feature to use usually emerges by itself. For example, 
when an algorithm is repeated for many types, it is an opportunity for 
templates.

 > D, IMO, is not capable of writing sophisticated programs...

"Sophisticated" is relative but such strong assertions can be falsified 
by a single counterexample. For example, Weka's product is very 
sophisticated and is written in D. And there is nothing extra or missing 
in D that makes it incapable in that regard.

 > this is why
 > you do not see any.

I think the fact that many smart programmers are hostage to other 
languages is a stronger reason.

 > No one writes large commercial apps in D.

False.

 > There is
 > not one!

False. And again, even if so, that's not because of D, but because of 
humans. Can you imagine a CTO, say, in Silicon Valley to have guts to 
bring D instead of C++? With C++, the CTO will never be blamed; but D, 
he or she can easily be blamed upon failure. Not because of the 
technologies but because of politics.

 > The D ecosystems is poorly structured compared to the top
 > contenders.

Agreed but that is not because D is inferior. Again, that's because 
people happen to be busy with other technologies.

 > D is good for small apps, utilities, etc. D can be
 > integrated with other apps though but then one loses some of the meta
 > capabilities(since they won't translate).

What would one technology that is good for small code not work for a 
larger system? Threads, communication e.g. memory mapped files, etc. are 
all there. What magical thing would happen and suddenly D won't work 
beyond a certain limit? If so, is that any different from any other 
language?

Ali