Metaprogramming with D

[FunkyD]

On Sunday, 7 June 2020 at 00:45:37 UTC, Ali Çehreli wrote:
> 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.

Ok, that isn't my fault.

>
> > 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:

You know the difference between logic and statistics? Ever heard 
of measure theory?

It's a pretty poor argument to claim that "Oh, logically it is 
not 100% true so it can't be true at all". I'm fine with stating 
something as All if it's true 98%+ of the time when it doesn't 
matter if it's 90% or 100% or anything in between.

If, for example, you had cancer almost all over your body I don't 
think someone you fault you if you said all instead of almost 
all. Pedanticism usually isn't a feature but a fault.




>
>   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.

Syntax highlighting is entirely different from semantic analysis. 
Try getting a line number of an error a multi-line string...

>
> > 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.
>

Yeah, that is definitely not the way to go... I could just throw 
rocks at my computer until it works too. Just because one can do 
it doesn't mean one should. In this case one is nearly forced.

Claiming that because we have the most primitive form of a 
solution makes up for having a good solution is pretty primitive.



> > 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.
>

As you said, sophisticated is quite relative. It seems you seem 
to think this is a math pissing contest. Anyone that makes a 
decision based on logical facts rather than statistical facts for 
statistical problems is quite illogical.

> > 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.

Maybe, maybe not... sounds like an excuse. Maybe they are 
actually rational beings who understanding that moving to an 
unpredictable and rather incompletely language is not worth the 
trouble?

>
> > No one writes large commercial apps in D.
>
> False.

Prove it. Saying something is false is not the same as it being 
false. Since you want to play hardball:

Name one commercial D app that has over 1 million in revenue and 
is used by 10k people. Just one. I'll let you play your games. 
Here I'm talking about an actual app that is entirely written in 
D.  You cannot claim an app is written in D when it just imports 
some D library. Nor are we talking about ad revenue generating 
software. I'm talking about something normal people use as an 
application... like a word processor, painting app, web browser, 
etc. Something external users  use, not a internal to a company.


Just one, come on, you said it was easy!


> > 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.
>

Now you are claiming that they don't exist. Which is it? Do they 
exist or do they not exist and they don't exist for some ad hoc 
theories you have?

> > 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.

No, that is PRECISELY because D is inferior. You like to move the 
goal posts so you can get the 10 yard 3 pointer when ever you 
like.

> > 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?
>

It's called dependencies and cohesion. It's the same reason why 
free energy doesn't scale up. Do you believe in free energy? I 
saw a guy run a toaster off the heat of his balls after rough sex 
with an expensive hooker... maybe we can use this technology to 
provide all the energy to the planet for 10M years with just one 
case? After all, it's just a scale problem. Right? Not just a 
scale problem but surely it must be linear... you know, y = mx + 
b?